Сегодня хочу поговорить об одном из самых горячих трендов в разработке — AI-ассистентах для написания кода. Я отношусь к тем, кто видит в AI-помощниках реальную пользу, но с важными оговорками. Они действительно ускоряют работу над MVP (Minimum Viable Product), автоматизацией или небольшими хобби-проектами. В этих сценариях они помогают быстро пройти путь от идеи до первой версии. Однако, когда дело доходит до продакшен-кода, картина меняется.
Давайте разберемся, где реальность, а где лишь иллюзия.
Дофамин против реальности
AI-ассистенты создают ощущение продуктивности, потому что дают мгновенную обратную связь. Вы вводите запрос — и сразу получаете готовый код. Этот цикл вознаграждает мозг дофамином, создавая иллюзию прогресса, похожую на закрытие задачи в Jira или исправление упавшего теста. Проблема в том, что дофамин поощряет активность в редакторе, а не работающий код в продакшене.
Это прекрасно показало исследование METR, проведенное в июле 2025 года. В эксперименте участвовали опытные open-source разработчики. Половина из них использовала AI-инструменты (в основном Cursor Pro с Claude 3.5 и 3.7 Sonnet), а вторая половина работала без них. Результат удивил: разработчики, использовавшие AI, в среднем были на 19% медленнее. При этом они были убеждены, что работали быстрее.
- До эксперимента: они прогнозировали, что AI ускорит их на 24%.
- После эксперимента: даже показав худший результат, они все еще верили, что AI ускорил их примерно на 20%.
Как сказал Маркус Хатчинс в своем эссе: «LLM похищают систему вознаграждения человеческого мозга... LLM дают то же чувство достижения, которое человек получил бы от самостоятельного выполнения работы, но без тяжелого труда». Это разрыв между восприятием и реальностью и есть «плацебо продуктивности».
Схожие данные были получены в опросе разработчиков Stack Overflow 2025. Только 16,3% опрошенных отметили, что AI-помощники значительно повысили их продуктивность. Самая большая группа (41,4%) заявила, что эффект был минимальным или его не было вовсе. Большинство разработчиков (42,3%) оказались где-то посередине, отметив «некоторый» прирост. Это подтверждает выводы METR: AI-кодинг ощущается быстрее, но измеримые улучшения минимальны или вообще отсутствуют.
Проблема качества: «Почти, но не совсем»
Скорость — это одно, а качество — совершенно другое. Разработчики, работающие с AI долго, замечают одну и ту же закономерность: качество выдаваемого кода падает по мере добавления контекста. Модель начинает подтягивать нерелевантные детали из ранних запросов, и точность снижается. Этот эффект называют «контекстной гнилью» (context rot).
На самом деле, больше контекста — не всегда лучше. Теоретически, большое контекстное окно должно помогать, но на практике оно часто отвлекает модель. Результат — раздутый или нецелевой код, который выглядит правильно, но не решает поставленную задачу.
Согласно тому же опросу Stack Overflow, 66% разработчиков назвали самой частой проблемой то, что код «почти правильный, но не совсем». Ещё 45,2% указали на время, потраченное на отладку кода, сгенерированного AI.
Это полностью соответствует моему опыту. Положительные отзывы, скорее всего исходят от людей, которые решают рутинные и шаблонные задачи, решенные уже миллион раз до этого. Код выданный агентом может работать, но чаще превращает проект в рассадник техдолга или уязвимостей. Однако использование ИИ полезно, когда нужно задать вопрос о кодовой базе или выполнить простейшие правки в коде, которые отнимут ценное время инженера.
Где же обещанный 10x прирост?
Утверждение о том, что AI делает разработчиков в 10 раз продуктивнее, звучит заманчиво, но не выдерживает критики. 10-кратное ускорение означало бы, что задача, которая раньше занимала три месяца, теперь решается за полторы недели. Любой, кто занимался разработкой сложного софта, знает, что это невозможно.
Узкие места в разработке — это не скорость печати. Это ревью дизайна, очереди на ревью пул реквестов, сбои тестов, переключение контекста и ожидание развертывания.
Интересное исследование 2023 года от GitHub и Microsoft показало, что разработчики, использовавшие Copilot, завершили задачу по созданию простого HTTP-сервера на JavaScript на 55,8% быстрее. Но это был скорее бенчмарк, чем реальная работа. Большую часть прироста показали менее опытные разработчики, которые использовали AI для создания "скелета" проекта. И, что важно, это были эксперименты, проведенные вендорами.
METR тестировал обратный сценарий: опытные инженеры работали в больших open-source репозиториях, которые они хорошо знали. В такой среде время, сэкономленное на шаблонном коде, полностью нивелировалось временем, потраченным на проверку, исправление или отбрасывание сгенерированного AI кода. Как выразился один из моих коллег: «Ты не экономишь время, ты просто меняешь меньше печати на больше времени, потраченного на чтение и распутывание кода».
Другое исследование Faros AI от июля 2025 года проанализировало данные более 10 000 разработчиков. Они обнаружили, что команды с высоким уровнем использования AI работали на 9% с большим количеством задач и на 47% с большим количеством пулл-реквестов в день. Разработчики жонглировали большим количеством параллельных задач, потому что AI позволял быстро создавать «скелеты» для нескольких задач одновременно. Исторически переключение контекста коррелирует с когнитивной перегрузкой и снижением фокусировки. Faros отмечает, что разработчики тратят больше времени на управление и проверку вкладов AI. Это дополнительное переключение контекста нивелирует большую часть прироста скорости набора кода.
Не все исследования негативны. В 2024 году исследователи из MIT, Harvard и Microsoft провели крупномасштабные эксперименты в трех компаниях. Они обнаружили, что разработчики с доступом к AI-инструментам в среднем выполняли на 26,08% больше задач. Самый большой прирост показали новички и младшие разработчики. Опытные же разработчики, знакомые с кодовой базой, показали незначительное или нулевое ускорение.
Безопасность — самый большой пробел
В Pingera мы занимаемся мониторингом и безопасностью внешнего периметра ИТ инфраструктуры. Поэтому мы смотрим на AI-ассистентов через призму безопасности.
Более ранние исследования 2023 года, проведенные в Стэнфорде, показали, что разработчики, использующие ассистентов, создавали больше уязвимостей, так как слишком доверяли их результатам. К счастью, в 2025 году разработчики уже менее доверчивы.
Тем не менее, исследование Apiiro 2024 года вызывает серьезную тревогу. Оно показало, что сгенерированный AI код приводил к увеличению числа путей эскалации привилегий на 322% и количества архитектурных изъянов на 153% по сравнению с кодом, написанным людьми.
- Коммиты, созданные с помощью AI, попадали в продакшен в 4 раза быстрее, чем обычные, что приводило к обходу стандартных циклов ревью.
- Проекты с AI-помощниками показали рост утечек секретов на 40%. Это в основном "зашитые" учетные данные и ключи API, сгенерированные в коде.
- Изменения, сгенерированные AI, привели к увеличению количества критических уязвимостей (CVSS 7.0+) в 2,5 раза.
- Сложность ревью значительно выросла: пулл-реквесты с AI-кодом требовали на 60% больше комментариев от ревьюеров по вопросам безопасности.
Но дело не только в безопасности, но и в комплаенсе. Если код, учетные данные или производственные данные покидают ваше окружение через AI-ассистента, вы не можете гарантировать их удаление или контролировать, где они окажутся. Для организаций, подпадающих под различные стандарты вроде SOC2, ISO, GDPR или HIPAA, это может означать нарушение политик или прямые юридические проблемы. Это именно те «слепые зоны», о которых переживают директора по информационной безопасности.
Как AI-ассистенты создают новые векторы атак
AI-ассистенты не просто генерируют код. Они привносят новые рантаймы, плагины и расширения в рабочий процесс разработчика. Это означает больше мест, где что-то может пойти не так, и злоумышленники уже начали это использовать.
В июле 2025 года в Gemini CLI от Google был обнаружен баг, который позволял злоумышленникам запускать произвольное выполнение кода на машине разработчика. Инструмент, призванный ускорить разработку, по сути, превратился в локальный вектор RCE (Remote Code Execution).
Годом ранее расширение Amazon Q в VS Code (август 2024) содержало вредоносное обновление. Скрытые инструкции в релизе приказывали ассистенту удалять локальные файлы и даже отключать инстансы AWS EC2. Поскольку расширение имело широкие локальные и облачные разрешения, вредоносные инструкции выполнялись без препятствий.
Эти инциденты указывают на конкретные сбои, но более серьезная проблема — структурная. Помощники для разработки расширяют цепочку поставок программного обеспечения и увеличивают количество привилегированных подключений, которыми можно злоупотребить.
Проблема 70%
Мне очень понравилась статья Addi Osmani в Pragmatic Engineer, потому что она точно описывает то, что видят многие разработчики. AI может довести вас до 70% пути, но последние 30% — самые сложные. Ассистент создает «скелет» фичи, но готовность к продакшену требует обработки, исправления архитектуры, написания тестов и наведения порядка в коде.
Для новичков эти 70% кажутся волшебством. Для опытных инженеров последние 30% часто занимают больше времени, чем написание чистого кода с нуля. Вот почему опытные разработчики в исследовании METR были медленнее с AI: они уже знали решение, а ассистент только добавил еще работы.
В этом и разница между демо и реальным приложением. AI быстро сокращает разрыв для демо, доводить код и приложение для состояния готового продукта - все еще остается прерогативой людей. Демо должно сработать один раз. Прод-код должен работать миллион раз без сбоев. Люди хотя бы знают, чего они хотят, даже если неправильно понимают требования. У LLM нет намерения, поэтому последние 30% всегда выходят боком.
Мнение бизнеса vs. мнение разработчиков
Идея «10х инженера» всегда была более привлекательной в залах заседаний, чем в code-ревью. Под давлением «делать больше с меньшими ресурсами» руководству очень хочется видеть в AI «мультипликатор», который позволит одной команде делать работу десяти. Нынешний хайп вокруг AI только подпитывает этот нарратив.
Разработчики, однако, знают, где находятся настоящие «узкие места». Никакой AI не отменяет обсуждение дизайна, планирование спринтов, митинги или QA. Он не стирает техдолг и не решает магическим образом проблемы зависимостей. Реальность — это постепенное ускорение на шаблонных задачах, а не 10-кратный прирост по всему циклу разработки.
И инженерам, и менеджерам нужно одно и то же: чтобы софт был безопасным, надежным и готовым к продакшену. AI может сыграть свою роль, но только если ожидания основаны на том, как на самом деле работает разработка.