Генеративный ИИ ускорил процесс разработки, но также создал новую проблему: стоимость создания кода снижается, тогда как его обслуживание становится дороже. По информации State of Code Developer Survey 2026 (SonarSource), 82% разработчиков используют ИИ для более быстрой работы, однако 96% не уверены в функциональной корректности сгенерированного кода. Технический директор Umbrella IT Константин Попандопуло поделился с IT Speaker, почему генерация кода перестала быть узким местом и как акцент смещается к инженерному контролю, архитектуре и поддержке.
Ловушка убедительного результата
Основная проблема ИИ-разработки заключается в том, что результат часто кажется убедительным. Код работает, сценарий завершается, демонстрация проходит успешно – на уровне бизнес-задачи создается впечатление, что все успешно выполнено.
Однако между «работает» и «можно поддерживать» – огромная разница. Код должен адаптироваться к изменяющимся требованиям, увеличению нагрузки, новым интеграциям, правкам от других команд, ошибкам в продакшене и возвращению к задаче через полгода. Если внутри отсутствует ясная структура, любое изменение становится рискованным.
В одном из внутренних экспериментов команда изучила рабочий код, созданный ИИ, и обнаружила каскад вложенных if/else. Пользовательский сценарий был завершен – с внешней стороны проблема не заметна. Но безопасно развивать такое решение сложно: при глубокой вложенности логика становится хрупкой, изменение одной ветви затрагивает другие и может привести к непредсказуемым побочным эффектам.
Кто и когда может позволить себе вайбкодинг
Важно различать два подхода, которые часто перепутывают.
Вайбкодинг – это когда человек получает рабочий результат от ИИ, но не понимает его внутреннюю структуру. Этот подход может использовать аналитик, продуктолог или представитель бизнеса: он хорошо осведомлен о задаче, может четко описать нужный сценарий и быстро получить прототип.
Разработка с использованием ИИ – это совсем другое дело. Инженер применяет модель как инструмент, но не передает ей управление. Он задает стек, архитектуру, ограничения, правила тестирования, обработку ошибок и требования к качеству. ИИ ускоряет работу, но не заменяет инженерное мышление.
Вайбкодинг полезен для проверки гипотез, но превращение прототипа в полноценный сервис без инженерной структуры является рискованным. На начальном этапе правила и архитектура требуют времени – зато при следующем изменении команде не придется заново знакомиться с собственным продуктом.
Сопровождение дороже генерации
ИИ снизил барьер для написания кода, но все, что происходит после генерации, остается неизменным: ревью, интеграция в архитектуру, тесты, поддержка после запуска. Чем быстрее увеличивается объем кода, тем больше нагрузки на эти этапы.
В этом и заключается кризис сложности. Дефицитный ресурс – это не способность генерировать код, а умение понимать структуру продукта и безопасно его изменять.
Бизнес-задача без архитектуры – риск
Чтобы ИИ создавал код, который можно развивать, ему необходим контекст.
Бизнес-контекст объясняет, что нужно достичь: какой сценарий завершить и какого результата добиться. Инженерный – как это должно быть реализовано внутри: архитектура, стек, взаимодействие модулей, работа с данными, логирование, обработка ошибок, требования к тестированию и безопасности.
Без этого контекста ИИ оптимизирует ближайшую задачу. Он найдет способ получить работающий результат, но не будет думать о будущем продукта. Важно также обновлять инженерные правила вместе с продуктом – в противном случае ИИ будет опираться на устаревшую модель.
От хорошего промпта к инженерным границам
С ИИ руководителю необходимо задавать правила не только людям, но и агентам: определять архитектурные ограничения, требования к проекту и решения, которые требуют отдельной проверки. Вместо многократного исправления одной и той же проблемы на ревью можно изменить общее правило – и оно начнет действовать для всех помощников.
Власти РФ хотят ежегодно направлять 100 млрд рублей на микроэлектронику
Это уже не просто «хороший промпт», а новый уровень инженерного управления: задача руководителя – обеспечить, чтобы ИИ изначально работал в четких рамках.
При бесконтрольной генерации ИИ действительно может накапливать технический долг. Однако при ясных инженерных правилах возможно и обратное.
Здесь уместно правило туриста: пришел в лес – убери за собой мусор и прихвати немного чужого. В разработке это означает, что при изменении модуля команда одновременно очищает дубли, упрощает ветвления или обновляет тесты в затронутой области. ИИ может ускорить такую работу – находить похожие фрагменты, помогать с типовыми изменениями. Но направление задает инженер, который понимает, что именно следует исправить.
Пять правил для команды
Сам доступ к ИИ-инструментам еще не меняет процесс разработки. Если процесс остается прежним, команда просто быстрее производит код, который затем требует больше времени на разбор.
Минимально необходимо:
-
определить, какие задачи можно передавать ИИ, а какие не стоит;
-
четко описать инженерные правила проекта;
-
сделать ревью обязательным для кода, созданного ИИ;
-
проверять не только работоспособность, но и возможность сопровождения;
-
обновлять тексты и документацию вместе с кодом.
Ключевой вопрос на ревью: «Сможем ли мы безопасно изменить это через месяц, квартал или год – и поймет ли человек, который будет делать изменения, замысел?»
Генеративный ИИ упростил процесс создания кода, однако его сопровождение не стало проще. Чем быстрее команда вносит изменения, тем важнее способность понимать уже существующее решение и безопасно его дорабатывать.
Основная нагрузка смещается с самого кода на все, что происходит после: ревью, тестирование, документацию и поддержку. Именно на этом этапе обычно приходит понимание, можно ли развивать продукт дальше без постоянного увеличения технического долга.
В итоге ценность специалистов определяется их способностью сопровождать уже созданное: находить ошибки, изменять поведение системы, добавлять новые функции – и не ломать то, что и так функционирует.
Облачный рынок РФ достигнет 666-930 млрд рублей к 2030 году
