Ключевые выводы

Код и продукт — не одно и то же. Функция может компилироваться, проходить тесты и даже выглядеть «готовой» — но система в целом остаётся непригодной для эксплуатации без архитектуры, наблюдаемости, безопасности и согласованности с бизнес-процессами.

ИИ уже революционен в шаблонах и рутине. CRUD, тесты, документация, прототипы за часы — это реальный прирост производительности. Проблемы начинаются на масштабе ERP, банка, производства или госсервиса, где важен контекст десятилетий.

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

Бизнес платит не за символы в редакторе. Платят за предсказуемость, снижение рисков и способность связать технологию с целями компании — особенно когда код пишет не только человек.

Введение: почему ИИ переломил разговор о программировании

До 2022 года спор «нужны ли программисты» звучал абстрактно: автоматизация, low-code, «достаточно Excel». С появлением больших языковых моделей, обученных на репозиториях, аргумент стал конкретным: модель генерирует код по описанию на естественном языке — иногда лучше, чем средний разработчик на узкой задаче.

Отсюда иллюзия полной замены: если ИИ пишет функции, зачем команда? Ответ не в том, что «ИИ глупый», а в том, что программный продукт — это не сумма функций. Это согласованная система под конкретные ограничения: бюджет, регуляторика, legacy, команда, срок жизни решения.

Главный вопрос статьи: в какой момент перестаёт быть достаточным «написать код» и начинается инженерия — работа, за которую платят senior-разработчикам, архитекторам и техническим лидерам?

Код ≠ программный продукт

Что такое генерация кода сегодня

Под «генерацией» понимают не только автодополнение в IDE. Это:

• чат с ChatGPT, Claude, Gemini по задаче «сделай endpoint + тесты»;
• агентные режимы (Cursor, Claude Code, Copilot Workspace), которые правят несколько файлов;
• встроенные ассистенты в GitLab, JetBrains, VS Code;
• корпоративные RAG-контуры поверх внутренних репозиториев.

Модели хорошо справляются с шаблонами, известными из миллионов открытых проектов: REST CRUD, формы, миграции, типовые интеграции с платёжными API, unit-тесты по образцу. На таких задачах ИИ часто быстрее человека — не потому что «умнее», а потому что видел тысячи похожих решений.

Типичные успешные сценарии: прототип админки за вечер, черновик OpenAPI-спецификации, рефакторинг именования по всему модулю, объяснение незнакомого фрагмента legacy на Java.

Почему рабочий код ещё не означает рабочую систему

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

Код может:

• компилироваться;
• проходить unit-тесты;
• даже пройти code review «на глаз».

И при этом система не готова к эксплуатации: нет стратегии миграций БД, не описаны SLO, секреты лежат в репозитории, интеграция с банком не переживёт изменение API, а «временный» флаг в конфиге уже три года управляет расчётом НДС.

Разница — как между кирпичом и зданием: кирпич может быть качественным, но без проекта, фундамента и норм пожарной безопасности дом не построишь.

Аналогия со строительством

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

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

Что ИИ действительно умеет хорошо

Генерация шаблонного кода

Здесь ИИ снимает механическую нагрузку. Разработчик задаёт контракт и проверяет краевые случаи; модель заполняет «скелет».

Автоматизация рутинных задач

• Тесты — unit и иногда integration по образцу существующих;
• Рефакторинг — переименование, вынос методов, приведение к стилю проекта;
• Документация — README, комментарии к API, описание модулей по коду;
• SQL — запросы, миграции, индексы под типовые схемы.

Это не «игрушка», а измеримый прирост: команды фиксируют двузначные проценты ускорения на рутине (данные GitHub, JetBrains, отраслевые опросы 2025–2026).

Быстрое прототипирование

MVP за часы вместо недель, демо для заказчика, проверка гипотезы «сработает ли интеграция с X» — классическая зона победы ИИ. Бизнес получает раннюю обратную связь; инженер получает черновик, который ещё предстоит превратить в продукт или сознательно выбросить.

Почему это уже революция

Три последствия:

1. Порог входа снижается — junior быстрее выходит на продуктивность по шаблонам.
2. Скорость бизнеса растёт — меньше очереди на «простые фичи».
3. Фокус команды смещается — меньше времени на бойлерплейт, больше на интеграцию, безопасность и согласование с доменом.

Отдельный риск: команда может переоценить скорость прототипа и недооценить стоимость доведения до prod — observability, откаты, права доступа, согласование с безопасностью. Именно здесь снова включается инженерия.

Революция не в том, что «код пишет машина», а в том, что стоимость черновика упала. Отсюда — следующий раздел: где ломается наивная картина.

Где начинаются проблемы

Маленькая задача против большой системы

Маленькие задачи (ИИ справляется часто хорошо):

• форма обратной связи;
• авторизация через OAuth в greenfield-проекте;
• отчёт по одной таблице;
• скрипт миграции данных на 10k строк.

Большие системы (контекст и последствия):

• ERP с десятками модулей и интеграций;
• интернет-банк с регуляторикой и antifraud;
• MES на производстве с простоями в миллионы;
• госсервисы с требованиями доступности и аудита.

В большой системе локально правильный патч может сломать закрытие месяца в другом департаменте. ИИ без полного контекста не видит эту связь.

Проблема контекста

Модель не была на совещании, где отказались от event sourcing «до следующего года», и не знает, что таблица payments_old ещё читает ночной batch.

Почему ИИ сложно с проектами 10–15 лет

• Legacy-код — несколько эпох технологий в одном репозитории;
• тысячи файлов — невозможно держать целиком в одном запросе без индексации;
• неочевидные зависимости — триггеры, cron, «временные» адаптеры;
• утерянная документация — вики противоречит коду;
• бизнес-логика в головах — правила, которые никто не закоммитил.

Подробный разбор — в pillar-статье может ли ИИ разобраться в проекте с 15-летней историей: там эксперимент, цифры и границы «эксперт + модель».

Настоящая инженерия начинается не с кода

Формализация требований

Заказчик говорит: «нужен отчёт по продажам». Инженерия начинается с вопросов:

• Чего он хочет формально — Excel раз в неделю или дашборд в реальном времени?
• Чего он пытается достичь — контроль менеджеров или прогноз закупок?
• Где расходятся формулировка и цель — и не купим ли мы дорогую BI-платформу для задачи, которую закрывает один SQL.

ИИ может помочь сформулировать user story или checklist вопросов. Но ответственность за согласование с бизнесом — на человеке.

Проектирование системы

• Архитектура — монолит, сервисы, event-driven; где границы и почему;
• Границы сервисов — что можно менять независимо;
• Выбор технологий — не «модный стек», а fit под команду, SLA и legacy;
• Масштабируемость — что сломается при 10× нагрузке.

См. также как проектировать систему, которая проживёт 10 лет — про связанность, эволюцию и цену необратимых решений.

Работа с ограничениями

Инженерия — это оптимизация под ограничения, а не под абстрактный «идеальный дизайн»:

• бюджет и сроки;
• размер и опыт команды;
• технический долг, который нельзя игнорировать;
• безопасность — от OWASP до отраслевых стандартов.

ИИ предложит «лучший паттерн из учебника»; инженер выберет достижимый паттерн под ваши ограничения.

Управление рисками

• Что сломается через год при росте данных?
• Что произойдёт при пиковой нагрузке в «чёрную пятницу»?
• Какие решения необратимы (схема БД, публичный API, формат сообщений в Kafka)?

Самая недооценённая задача — принятие решений

Между правильным и оптимальным

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

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

Цена ошибки

Чем выше цена ошибки, тем меньше можно полагаться на непроверенную генерацию — тем больше нужны review, тесты, архитектурный контроль.

Ответственность нельзя делегировать ИИ

Модель предлагает варианты. Решение и подпись под релизом — у человека или у роли (tech lead, architect, ответственный за продукт). При инциденте спрашивают с команды, а не с весов модели.

Почему бизнес платит не за код

За что платят на разных уровнях

Когда ИИ ускоряет написание строк, рынок не обнуляет оплату senior'ам — он переносит премию на всё, что строками не измеряется.

За что будут платить в эпоху ИИ

• Управление сложностью — legacy, интеграции, организационный масштаб;
• Архитектурное мышление — границы, эволюция, отказоустойчивость;
• Работа на стыке бизнеса и технологий — перевод домена в систему;
• Умение вести ИИ-контур — промпты, агенты, проверка, agentic engineering вместо «vibe coding».

Материал как топ-команды реально используют ИИ показывает: лидеры инвестируют в каркас (тесты, правила, CI), а не только в модель.

Кейс: проект с 15-летней историей

Это не абстракция. В отдельной статье разобран реалистичный сценарий ERP-класса: миллионы строк, сотни таблиц, десятки интеграций.

Что сделает ИИ:

• найдёт, где меняется статус документа;
• объяснит модуль новому человеку;
• предложит рефакторинг или черновик документации;
• ускорит первичную карту зависимостей при индексации репозитория.

Где нужен инженер:

• восстановить зачем правило существует, если его нет в коде;
• оценить последствия изменения перед релизом;
• спроектировать эволюцию системы, а не только патч.

Итог эксперимента: ИИ помогает понимать систему; не заменяет того, кто понимает бизнес и несёт ответственность. Читать полный разбор →

Как изменится профессия разработчика

Исчезнут ли программисты

Полное исчезновение профессии маловероятно по той же причине, по которой не исчезли инженеры-строители при появлении prefab и CAD: сложность задач и ответственность растут быстрее, чем автоматизация их снимает. Спрос смещается — не обязательно падает.

Навыки, которые подешевеют

• чистое запоминание синтаксиса;
• шаблонное написание CRUD без контекста;
• ручное копирование boilerplate.

Навыки, которые подорожают

• Системное мышление — целое важнее файла;
• Архитектура и границы — см. почему ERP становятся монолитами;
• Анализ требований и коммуникация с заказчиком;
• Работа с ИИ — постановка задачи, верификация, безопасность;
• Domain knowledge — то, что ИИ не закроет во frontend и не только.

Новый тип инженера

От автора каждой строки — к проектировщику решений и дирижёру ассистентов: один агент пишет тесты, другой ищет по репозиторию, третий черновит ADR — человек задаёт рамки и принимает итог.

Заключение

Код дешевеет. Генерация превращается в товар: быстрый, доступный, местами бесплатный.

Инженерия дорожает. Проектирование, анализ, решения под ограничения, ответственность — то, за что компании платят, когда ошибка стоит не «переделать PR», а остановку бизнеса.

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

FAQ

Дальнейшее чтение

• Может ли ИИ разобраться в проекте с 15-летней историей — эксперимент, RAG, границы модели
• Как проектировать систему на 10 лет — архитектура и необратимые решения
• Vibe coding vs agentic engineering — каркас вокруг ИИ
• Как топ-команды используют ИИ — практика, не хайп
• Почему ERP становятся монолитами — сложность, которую код не исчерпывает
• Frontend: пробел знаний, который ИИ не закроет — domain и контекст