Ловушка ИИ-кодинга

Представьте себе: вы наблюдаете, как кто-то «пишет код». На экране — редактор, пара открытых вкладок, мигает курсор. Но человек почти не печатает. Он просто сидит и задумчиво смотрит в одну точку.

Нет, он не ленится. Просто программирование — это не про набор текста, а про решение задач. Как в кроссворде: большая часть работы происходит в голове, а не на клавиатуре.

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

Если коротко, процесс выглядит примерно так: сначала думаем — потом пишем.

Но с приходом ИИ-кодинга всё изменилось.

«Сначала код, потом вопросы»

Инструменты вроде Claude Code позволяют писать код молниеносно — без контекста, без долгих раздумий. Однако реальное ПО не живёт в вакууме. Оно существует в сложных системах, и пока LLM-модели не умеют держать весь контекст проекта в памяти, человеческая проверка и тестирование никуда не денутся.

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

Вот в этом и есть разница между рекламными обещаниями — «ИИ ускоряет разработку в 10 раз!» — и реальностью, где прирост производительности в продакшене ближе к 10%.

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

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

Дилемма тимлида

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

При этом почти всегда тимлид — самый опытный человек в команде. У него больше знаний и по предметной области, и по архитектуре, и по инструментам. Но есть проблема: разный уровень опыта сильно влияет на скорость разработки. 

Перед тимлидом встаёт выбор между двумя стратегиями:

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

2. Брать на себя всё сложное, а младшим отдавать только простые задачи — так проект будет развиваться быстро, но команда не начнёт расти.

Второй вариант, как ни странно, работает, особенно на короткой дистанции. Опытный инженер берёт на себя самые трудные задачи и закрывает их одна за другой. Общий прогресс команды впечатляет.

Но расплата приходит позже: знания концентрируются у одного человека, отчего поддерживать систему становится всё труднее. Со временем весь рабочий процесс начинает держаться только на одном тимлиде.

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

Решение, как обычно, лежит посередине. Звучит оно примерно так:

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

Когда я был CTO в Datasine, мы сформулировали это в виде короткого девиза команды:

Learn. Deliver. Have fun. — Учись. Делай. Наслаждайся.

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

Классические практики, которые помогают в этом деле, знакомы всем:

• Code review

• Инкрементальная поставка

• Модульный дизайн

• Test-Driven Development

• Парное программирование

• Документация

• CI/CD

И главный вопрос 2025 года: как адаптировать эти принципы в эпоху ИИ-кодинга?

LLM — это очень быстрые «джуны»

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

Обычные инженеры, по мере накопления опыта, растут сразу по двум направлениям:

1. Качество: пишут более сложный, надёжный, поддерживаемый код.

2. Скорость: делают задачи быстрее, с меньшим количеством багов.

Хорошие инженеры развиваются по обеим осям одновременно.

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

Так что можно рассматривать ИИ-кодеров как очень быстрых джунов с двумя ключевыми особенностями:

1. Они пишут код в сотни раз быстрее любого новичка — без раздумий, без пауз.

2. Они не учатся. Улучшить их можно только снаружи — с помощью нового контекста или новой модели.

Как и с реальными джунами, можно выбрать один из двух подходов:

• AI-driven engineering: внедрять лучшие практики, обеспечивать понимание кода, двигаться медленно, но устойчиво.

• Vibe coding: забить на процессы, выпускать новые фичи любой ценой, жертвуя пониманием ради скорости — до тех пор, пока кодовая база не превратится в хаос.

И, как легко догадаться, vibe-coding заканчивается так же, как и привычка тимлида брать всё на себя: короткий успех, потом катастрофа.

Для небольших проектов и прототипов vibe-coding даже удобен. Если приложение простое, можно дать ИИ «побаловаться» и получить рабочий результат за пару часов. Ограничить сложность задачи — значит использовать сильные стороны модели.

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

Как не попасть в ловушку ИИ-кодинга

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

Чтобы писать рабочее ПО эффективно, нам нужен новый набор правил. Достаточно вспомнить, как мы выстраивали процессы в командах. Если рассматривать LLM как сверхбыстрых джунов, то логика та же: применяем старые добрые практики, но теперь к взаимодействию человека и модели.

ИИ может быть полезен на каждом этапе жизненного цикла разработки:

• Спецификация. Использовать модели для анализа и уточнения требований, проработки крайних сценариев.

• Документация. Генерировать и ревьюить документацию заранее, чтобы задать «рельсы» для кода и зафиксировать важные детали проекта.

• Модульный дизайн. Строить архитектуру, где каждый компонент изолирован и понятен модели.

• TDD. Генерировать тесты до написания кода — как шаблон и страховку от регрессий.

• Стандарты кода. Задавать стандарты и проверенные подходы прямо в контексте промпта, чтобы ИИ следовал корпоративным правилам.

• Мониторинг и анализ. Поручать ИИ разбор логов и выявление причин сбоев или неочевидных зависимостей — он справится с этим быстрее любого человека.

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

Спасибо за внимание, ваш Cloud4Y. Читайте нас здесь или в Telegram‑канале!