90% кода будет генерировать ИИ — и чем тогда занимаются разработчики?

Вопрос, который задаёт каждая инженерная команда

Разработчик, который пишет 500 строк кода в день, теперь наблюдает, как ИИ-ассистент выдаёт тот же объём за считанные минуты. Естественная реакция: если машина берёт на себя набор текста, за что именно мы платим людям?

Это не гипотетический вопрос. Согласно масштабному исследованию, охватившему 300 инженеров за 12 месяцев, объём продакшен-кода вырос примерно на 28% при использовании ИИ, а наиболее активные пользователи показали рост объёма кода на 61%. Код пишется. Вопрос в том, тот ли это код, который нужен.

Если коротко: работа разработчика никогда не сводилась к набору текста. Она всегда была про решения. И решения только что стали гораздо важнее.

Почему «больше кода» — это не то же самое, что «лучшее ПО»

В нарративе «90% кода генерирует ИИ» скрыто опасное допущение — что объём кода равен прогрессу. Это не так. Система с вдвое большим количеством кода не вдвое лучше. Зачастую она вдвое хрупче.

Когда ИИ-инструменты ускоряют скорость написания кода, одновременно происходит несколько вещей:

• Пулл-реквесты становятся больше. Как отмечает аналитика Swarmia, ИИ-инструменты позволяют легко писать больше кода быстрее, что приводит к увеличению размера батчей. Более крупные батчи замедляют код-ревью и снижают его качество.
• Информационные силосы углубляются. Отдельные разработчики генерируют и выкатывают код без должного понимания командой. Один человек плюс ИИ-агент могут создать целую фичу, при этом никто другой в команде даже не прикоснётся к коду — и не поймёт его.
• Качество становится сложнее отслеживать. Исследование DX среди 18 компаний, включая GitHub, Dropbox и Atlassian, показало, что организации теперь отслеживают частоту сбоев при изменениях, частоту откатов PR и поддерживаемость кода именно для того, чтобы выявлять деградацию качества из-за ИИ-сгенерированного кода.

Реальные цифры: то же исследование 300 инженеров показало лишь 37% принятия ИИ-сгенерированного кода. Это значит, что 63% того, что выдал ИИ, было отклонено, изменено или отброшено. Машина продуктивна, но без человеческого суждения она ненадёжна.

Чем на самом деле занимаются разработчики, когда ИИ пишет код

1. Архитектура и проектирование систем

ИИ генерирует функции. Люди проектируют системы. Ни один ИИ-инструмент сегодня не понимает, почему существует конкретная граница сервиса, почему команда выбрала событийно-ориентированную архитектуру вместо синхронных вызовов или почему схема базы данных выглядит именно так.

Когда ИИ генерирует код, он заполняет пробелы, угадывая. Как отмечает анализ безопасности BrightSec: «Если требование неоднозначно, модель всё равно что-то выдаст. Это "что-то" может работать функционально, но при этом нарушать границы безопасности так, что это сложно заметить при обычном ревью».

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

2. Код-ревью становится ключевым навыком

Вот что мы рекомендуем: относитесь к ревью ИИ-сгенерированного кода как к самой критически важной инженерной активности в вашем рабочем процессе.

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

Это один пример более широкой истины. ИИ-сгенерированный код часто выглядит корректным. Он соблюдает правила синтаксиса, использует разумные имена переменных и выдаёт рабочий результат для happy path. Проблемы прячутся в:

• Предположениях о структуре проекта, которые не соответствуют реальности
• Пропущенных граничных случаях, которые ИИ не рассмотрел
• Дублированной логике, потому что ИИ не знал о существующей утилитарной функции
• Пробелах в безопасности при валидации ввода, проверках аутентификации и обработке данных

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

Честный взгляд: ревью ИИ-сгенерированного кода требует больше навыков, чем ревью кода, написанного человеком, а не меньше. Разработчик-человек делает предсказуемые ошибки. ИИ делает уверенно неправильные решения, которые выглядят отполированными.

3. Спецификации и промпт-инженерия

Качество ИИ-сгенерированного результата почти полностью зависит от качества входных данных. Расплывчатые инструкции порождают расплывчатый код. Cheesecake Labs рекомендует делиться путями к файлам, описаниями архитектуры, конвенциями именования и релевантными фрагментами кода, прежде чем просить ИИ что-либо генерировать.

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

4. Обеспечение качества и безопасность

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

Руководство по аудиту LogRocket выделяет ещё один риск: ИИ-модели ограничены датой отсечки их обучающих данных и часто добавляют устаревшие зависимости. Запуск npm audit после интеграции ИИ-сгенерированного кода — это не опция, а базовое требование.

Что это значит для вашего проекта: нагрузка по тестированию и безопасности не снижается с внедрением ИИ. Скорее, она растёт пропорционально объёму сгенерированного кода.

5. Интеграция и консистентность

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

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

Метрики, которые действительно важны

Фреймворк измерений DX предостерегает от фокуса на метриках тщеславия вроде «процент кода, написанного ИИ» без привязки к бизнес-результатам. Принятый код часто существенно модифицируется или удаляется перед коммитом, что делает показатель принятия ненадёжной мерой.

Ключевой вывод для бизнеса: отслеживайте вместо этого:

• Частота откатов PR — откатываются ли изменения с помощью ИИ чаще?
• Частота сбоев при изменениях — растёт ли количество продакшен-инцидентов параллельно с внедрением ИИ?
• Сэкономленные часы разработчика в неделю — реальная экономия времени, а не теоретическая
• Показатели поддерживаемости кода — становится ли кодовая база сложнее в работе со временем?
• Глубина ревью — становятся ли ревью более тщательными, или команды штампуют ИИ-результат без проверки?

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

Настоящий риск: пропуск этапа мышления

Исследование 300 инженеров выявило 85% удовлетворённости ИИ-ассистированным код-ревью и желание 93% разработчиков продолжать использование платформы. Эти инструменты действительно полезны. Но в данных скрыта важная оговорка: польза масштабировалась прямо пропорционально интенсивности использования инструмента, а пользователи с низкой вовлечённостью видели минимальные улучшения.

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

Честный взгляд: будущее «90% ИИ-сгенерированного кода» — это не будущее без разработчиков. Это будущее, где разрыв между хорошим и посредственным разработчиком драматически увеличивается. Хороший разработчик использует ИИ для решения деталей реализации, фокусируясь на архитектуре, безопасности и поведении системы. Посредственный превращается в оператора копипаста, который быстрее выкатывает баги.

Что командам следует делать прямо сейчас

Вот что мы рекомендуем инженерным командам, адаптирующимся к разработке с ИИ:

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

2. Держите пулл-реквесты маленькими. Если ИИ позволяет легко сгенерировать 2000 строк за одну сессию, разбейте это на четыре фокусных PR. Качество ревью резко падает с ростом размера PR.

3. Отслеживайте метрики качества наряду с метриками скорости. Если пропускная способность PR удваивается, но частота откатов утраивается, команда движется назад.

4. Инвестируйте в навыки спецификации. Умение описать, что код должен делать — точно, полно, с учётом граничных случаев — теперь самый ценный инженерный навык.

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

6. Запускайте сканирование безопасности на каждом ИИ-сгенерированном вкладе. Статический анализ, аудит зависимостей и автоматизированное тестирование должны быть неотъемлемыми частями пайплайна.

Роль разработчика не исчезает — она концентрируется

Если коротко: когда ИИ берёт на себя механический акт написания кода, остаётся всё то, что всегда было сложным в разработке ПО. Понимание требований. Проектирование систем. Поиск компромиссов. Отлов неочевидных багов. Обеспечение безопасности. Поддержание согласованности кодовой базы на протяжении лет.

Цифра в 90% — наступит ли она через два года или через пять — не устраняет потребность в разработчиках. Она устраняет потребность в разработчиках, которые умеют только набирать код. Те, кто понимает, зачем код должен существовать, как он вписывается в систему и что может пойти не так — становятся более ценными, а не менее.

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

Часто задаваемые вопросы

Как убедиться, что ИИ-сгенерированный код действительно решает бизнес-задачу, прежде чем отправлять его в продакшен?

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

Как поддерживать архитектурную консистентность в большой кодовой базе, когда ИИ генерирует большую часть кода?

Предоставляйте ИИ-инструментам явный контекст: документы по архитектуре, конвенции именования, правила файловой структуры и примеры существующих паттернов. Проверяйте сгенерированный код именно на консистентность, а не только на корректность. Cheesecake Labs рекомендует сверять результат ИИ с существующими утилитами проекта для предотвращения дублирования логики.

Если джуниоры пропускают рутинные задачи по написанию кода благодаря ИИ, как они развиваются до уровня сеньоров?

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

Что происходит с код-ревью, когда большая часть кода сгенерирована ИИ?

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