Заменят ли Claude Code и Codex инженеров инфраструктуры и сетей? — Реальность эксплуатации в эпоху ИИ

«Я сказал Claude Code: "напиши Terraform-код, который поднимает EC2-инстанс" — и через 30 секунд получил готовый IaC. Это что, означает, что работа инженера инфры исчезает?»

Такие мысли сейчас посещают многих. Эволюция ИИ-инструментов для кодирования действительно впечатляет: в инфраструктурной области ускоряются и генерация кода, и составление конфигов, и анализ логов. Анонсированный OpenAI в 2025 году Codex (агент для кодирования) тоже отлично справляется с автоматической генерацией инфраструктурного кода.

Но значит ли это, что инженеры инфраструктуры и сетей действительно станут ненужными?

Сразу скажу вывод: реалистичный взгляд — происходит не «замена», а «изменение роли». В этой статье мы разберём, что ИИ умеет и в чём слаб именно в инфраструктурной сфере, и расскажем, какую стратегию стоит выбрать инженерам.

1. Что происходит сейчас — эволюция ИИ-инструментов для кодирования

Для начала посмотрим, что именно ИИ-инструменты научились делать в инфраструктурной области.

Главные ИИ-инструменты и их возможности в инфре

Важно, что эти инструменты вышли за рамки простого автодополнения и стали работать как «агенты». Claude Code уже читает и пишет файлы, запускает команды, а Codex выполняет код в песочнице и проверяет результаты.

Диапазон возможностей быстро расширяется

Если в 2024 году ИИ умел разве что «накидать шаблон Terraform», то в 2025–2026 годах стало возможным следующее.

• Прочитать существующий инфраструктурный код и указать на проблемы безопасности
• «Хочу развернуть это приложение в AWS» → предложить связку VPC, подсетей, SG, ALB, ECS/EKS целиком
• Проанализировать продакшен-логи ошибок и предложить кандидатов в причины и варианты решения
• Построить CI/CD-пайплайн с нуля
• Сгенерировать и поправить манифесты Kubernetes и Helm-чарты

Глядя на такую скорость эволюции, неудивительно, что появляется мысль «инженеры инфры уже не нужны». Но это лишь одна сторона того, «что ИИ умеет».

2. Что ИИ «может» делать в инфраструктурных задачах

ИИ особенно силён там, где работа «выразима кодом», «имеет паттерн» и «основана на тексте».

① Генерация Infrastructure as Code (IaC)

Terraform, CloudFormation, Pulumi, Ansible, Chef — генерация кода для этих IaC-инструментов является одной из самых сильных сторон ИИ.

② Генерация и оптимизация конфигурационных файлов

nginx.conf, apache.conf, правила iptables/nftables, unit-файлы systemd — со всеми ними ИИ справляется хорошо. Скажите ему: «напиши конфиг обратного прокси nginx для этого веб-приложения с поддержкой SSL» — и получите вариант, соответствующий лучшим практикам.

③ Анализ логов и поиск аномалий

Поиск паттернов в огромных объёмах логов — это коронная задача ИИ.

• Суммаризация текстовых логов: syslog, journald, CloudWatch Logs
• Классификация и частотный анализ паттернов ошибок
• Мгновенный ответ на вопрос «что резко выросло за последний час?»
• Гипотезы о причинах и предлагаемые действия на основе логов

④ Автогенерация документации и инструкций

ИИ может прочитать существующий инфраструктурный код и сгенерировать черновики: описание архитектурной схемы, эксплуатационные инструкции, руководство по реагированию на инциденты. Это одна из самых ненавистных (но важных) задач для инженеров инфры.

⑤ Проверки безопасности

Проверка IAM-политик на избыточные права, верификация правил security groups, соответствие Terraform-кода CIS Benchmark — типовые ревью безопасности ИИ тоже может поддержать.

3. Что ИИ «не может» делать в инфраструктурных задачах

Это ключевая часть. Если не понимать пределы ИИ точно, можно легко скатиться в худший сценарий: «давайте всё доверим ИИ» → крупная авария.

① Работы на физическом уровне

Очевидно, но ИИ не умеет выполнять физические операции.

• Установка оборудования в серверные стойки, прокладка кабелей
• Замена вышедших из строя HDD/SSD
• Физическая настройка и замена сетевого оборудования (маршрутизаторы, коммутаторы, файрволы)
• Контроль доступа в дата-центр и физическая безопасность

Можно возразить: «разве с переездом в облако физика не исчезнет?» Но около 60% японских компаний всё ещё используют on-premise-среду параллельно (по данным IDC Japan), так что физическая инфраструктура не уйдёт в ближайшее время.

② Бизнес-решения при авариях

Когда случается продакшен-инцидент, самое важное — это бизнес-решение о том, что приоритетнее.

• «БД повреждена. Восстановление из бэкапа означает потерю последних двух часов данных. Восстанавливать или пытаться чинить на месте?»
• «Легли оба сервиса — A и B. Ресурсов ограниченное количество, какой поднимать первым?»
• «Подозрение на взлом. Останавливать сервис для расследования или вести расследование на ходу?»

Такие решения требуют не только технических знаний, но и комплексного учёта влияния на бизнес, обязательств перед клиентами (SLA), юридических рисков и согласования с руководством — и их нельзя отдать ИИ. ИИ может «предложить варианты», но «принять ответственное решение» — нет.

③ Реакция на неизвестные типы сбоев

ИИ хорош в паттернах, которые есть в его обучающих данных, но слаб там, где не помогала ещё ничья практика.

• Нераскрытые баги на стороне облачного провайдера
• Комплексные сбои нескольких систем одновременно (сеть + DNS + приложение)
• Интерметтирующие сбои из-за деградации железа со временем

В таких ситуациях решающее значение имеет «чутьё» опытного инженера — способность проводить аналогии с прошлыми похожими случаями.

④ Конечная ответственность за безопасность

Даже если ИИ скажет «эта конфигурация безопасна», это не гарантия. Когда происходит инцидент, юридическую и этическую ответственность несёт не ИИ, а человек.

• Отчётность перед надзорными органами при утечке персональных данных
• Проведение форензики и сохранение доказательств
• Разработка мер предотвращения повторений и отчёт перед руководством
• Уведомление клиентов и коммуникация

⑤ Управление вендорами и переговоры

Облачные провайдеры, операторы дата-центров, интернет-провайдеры, вендоры безопасности — в работе инженера инфры много внешних переговоров. Обсуждение условий контракта, согласование SLA, координация при авариях — всё это то, что ИИ сделать не в состоянии, это чисто человеческая сфера.

4. Влияние на сетевых инженеров

Сетевая инженерия занимает несколько особое положение внутри инфраструктуры. Посмотрим отдельно, как ИИ влияет на неё.

Сетевые задачи, которые ИИ может автоматизировать

Сетевые задачи, с которыми ИИ справляется плохо

• Проектирование и монтаж физической проводки: планировка этажа, прокладка кабелей, организация кроссовых
• Радиообследование и проектирование Wi-Fi: нужен физический выход на объект, анализ материалов стен, поиск источников помех
• Локализация проблем на L1: обрыв кабеля, сбой порта, падение уровня оптического сигнала — нужна физическая проверка
• Переговоры с операторами связи: ввод новых каналов, изменение полосы, согласование схем резервирования
• Крупная миграция сети: планирование и проведение миграции сотен устройств, поэтапный переход для минимизации простоя

Поскольку сетевая инженерия сильно завязана на физический уровень, полностью заменить её ИИ сложнее, чем серверную инфраструктуру. Но вклад ИИ в ускорение генерации конфигов и диагностики всё равно значительный.

5. Как всё меняется на практике

Вместо теории посмотрим на несколько реальных паттернов использования ИИ.

Паттерн 1: ускорение разработки IaC

В одном стартапе инженер инфры использует Claude Code для генерации Terraform-кода. Если раньше на описание одного AWS-ресурса уходило 30 минут — 1 час, то теперь в формате «задаёшь ИИ требования → ревьюишь и правишь» это сокращается до 5–10 минут.

Но принципиально важно, что сгенерированный ИИ код никогда не применяется в продакшене «как есть». Его всегда ревьюит человек и дорабатывает с точки зрения безопасности и оптимизации затрат.

Паттерн 2: помощь при первой реакции на инцидент

При продакшен-аварии сначала ИИ анализирует логи и сужает круг причин-кандидатов. Затем уже человек принимает окончательное решение и проводит восстановление. Это схема разделения труда.

• Было: глазами вычитывать логи и искать причину — 30 минут — 1 час
• Стало: ИИ за 5 минут сужает причины до 3 вариантов → человек проверяет и действует

Средний MTTR сокращается, но появляется новый риск: слепое доверие анализу ИИ и как следствие — ошибочные действия. Поэтому окончательное решение всё равно должен принимать опытный инженер.

Паттерн 3: ускорение обучения джунов

Раньше говорили, что «в инфре без опыта ничего не сделаешь», но с ИИ кривая обучения резко выравнивается.

• «Объясни смысл этого Terraform-кода» → ИИ разбирает строчка за строчкой
• «Почему в этой SG нужно ограничивать 22-й порт?» → ИИ объясняет контекст и причины
• «Не понимаю этот лог ошибок» → ИИ объясняет структуру и выделяет важные места

Это не «инженеры больше не нужны», а эффект «скорость роста инженеров выросла».

Паттерн 4: «инфра-команда из одного человека»

Там, где раньше требовалась команда из 3–5 человек, с поддержкой ИИ теперь появляются случаи, когда с задачами справляются 1–2 человека. Численность падает, но к оставшимся сотрудникам предъявляются более высокие требования по навыкам и суждениям.

6. Как инженеру инфраструктуры выжить в эпоху ИИ

Дальше — конкретные стратегии. Разберём набор навыков, которые ИИ не заменяет, а наоборот — делает ещё ценнее.

① Научиться уверенно пользоваться ИИ

Самая важная и наиболее быстроокупаемая стратегия. Инженеры, которые воспринимают ИИ не как «угрозу», а как «инструмент», работают в несколько раз продуктивнее.

• Встроить в повседневную работу такие инструменты, как Claude Code, Codex, Copilot
• Научиться писать грамотные промпты (инструкции) для ИИ
• Сохранять технический уровень, чтобы корректно проверять и править результаты ИИ

О том, как бесплатно пользоваться разными ИИ-инструментами, смотрите статью «Как бесплатно пользоваться ИИ [обновление 2026]».

② Смещаться в сторону «проектирования и архитектуры»

ИИ хорошо «пишет код», но он не решает, «что и как проектировать».

• Проектирование облачной архитектуры: умение балансировать доступность, масштабируемость и стоимость
• Мультиклауд-стратегия: понимание особенностей AWS, GCP, Azure и умение комбинировать
• Проектирование DR (аварийного восстановления): от определения RPO/RTO до процедур восстановления

③ Углублять экспертизу в безопасности

Безопасность — это область, где «цена ошибки ИИ максимальна». Поэтому спрос на инженеров с экспертизой в безопасности с распространением ИИ, скорее всего, только вырастет.

• Проектирование и внедрение zero-trust архитектуры
• Навыки реагирования на инциденты безопасности
• Соответствие требованиям (ISMS, PCI DSS, GDPR и т.д.)

④ Смотреть на эксплуатацию с позиции SRE (Site Reliability Engineering)

Подход SRE, предложенный Google, — «рассматривать эксплуатацию как задачу разработки ПО» — в эпоху ИИ становится ещё важнее.

• Проектирование и поддержка SLI/SLO/SLA
• Решения на базе error budget
• Продвижение автоматизации (ИИ — один из её инструментов)
• Построение культуры post-mortem (разбора инцидентов)

⑤ Увеличивать точки соприкосновения с бизнесом

Хуже всего ИИ заменяет навык соединять технологии и бизнес.

• Предложения по оптимизации инфраструктурных затрат и отчёты для руководства
• Определение и оценка инфраструктурных требований новых продуктов
• Способность переводить технические риски в бизнес-риски понятным языком

7. Вывод — не «замена», а «эволюция»

Соберём выводы статьи ещё раз.

Главный посыл: самую высокую рыночную ценность получит «инженер инфры, умеющий пользоваться ИИ». Когда ИИ забирает рутину, инженер может сосредоточиться на более сложных задачах: проектировании, решениях, стратегии.

Это не «угроза», а «возможность эволюции». Не бояться ИИ, а сделать его своим оружием — вот стратегия выживания для инженера инфры в эпоху ИИ.

Про общую картину IT и начало разработки с помощью ИИ читайте также в статье «Руководство по AI-разработке для новичков».

FAQ