GitHub, по прогнозу, может увидеть 14 млрд коммитов уже в 2026 году, и на этом фоне генерация кода ИИ все чаще продается как простой способ ускорить релизы. Но чем быстрее машины штампуют pull request'ы, тем дороже становится проверка, исправление и сопровождение этого кода уже после мержа. Для русскоязычных команд это не абстрактный спор о будущем, а вполне земной вопрос: кто будет разгребать последствия, если AI-копипасту уже пустили в прод.
Именно на этом акцентирует внимание The New Stack в колонке Анкита Агравала, опубликованной 16 мая 2026 года. Тезис у автора простой и неприятный: рынок много говорит о росте velocity, но почти не обсуждает, куда уезжает счет за последующую уборку. На входе AI действительно снижает порог разработки, помогает быстрее собирать прототипы, писать внутренние инструменты и закрывать мелкие баги. На выходе появляется другой дефицит: не идей и не строк кода, а человеческого времени на ревью, security-проверки, разбор инцидентов и поддержку того, что было сгенерировано за минуты.
Агравал раскладывает экосистему на несколько групп. Первая - компании и команды, которые делают базовые модели и стандарты, включая OpenAI, Anthropic и Google. Вторая - исследовательские лаборатории и авторы бенчмарков. Третья - платформы и дистрибуторы вроде GitHub, Hugging Face, Cursor, Apple и Webflow, которые через свои политики и дефолтные настройки фактически задают правила игры. Четвертая - обычные engineering-организации, которые встраивают AI и в собственные продукты, и во внутренние процессы. Для всех этих слоев выгода понятна: новый endpoint можно собрать и довести до тестов за десятки минут или часы, а не за дни; внутреннюю автоматизацию делают более компактные команды; часть прототипирования уходит к людям без глубокого инженерного бэкграунда. Иными словами, генерация кода ИИ действительно поднимает пропускную способность. Проблема начинается в тот момент, когда объем кода растет быстрее, чем способность команды его понимать.
Особенно жестко этот перекос бьет по независимым разработчикам и open source. У крупной компании есть коллеги по ревью, AppSec, legal и процессы эскалации. У фрилансера, автора плагина или мейнтейнера популярного репозитория всего этого обычно нет. Ошибка в лицензии, уязвимый пакет, неочевидный дефект в релизе - и репутационный ущерб уже вполне материальный: бан на платформе, вылет из стора, потеря контрактов или лавина тикетов от пользователей. В колонке приведена формулировка, которая хорошо описывает нынешнюю асимметрию: сгенерировать слабый AI pull request можно за пять минут, а на его нормальную проверку и аргументированный отказ у мейнтейнера уходят часы. То есть выигрыш автора промпта превращается в чужие накладные расходы.
Отдельный слой риска - безопасность. Агравал ссылается на весенний отчет Veracode за 2026 год, где, по его пересказу, показатели security pass rate у AI-сгенерированного кода с 2023 года почти не улучшаются, если модели не дали явные правила безопасной разработки. Речь не о синтаксисе: писать «правдоподобно» модели уже умеют. Речь о более неприятных вещах - XSS, log injection и других серьезных классах дефектов, которые продолжают просачиваться в готовый код. Автор также упоминает, что OpenAI оценивает долю AI-сгенерированного кода уже в 80%. Даже если воспринимать эту цифру как оценку из статьи, а не как универсальный рыночный стандарт, вывод все равно тревожный: доля машинного кода растет быстрее, чем его защищенность. Плюс никуда не делась старая боль с галлюцинациями зависимостей и опечатками в названиях пакетов, а это уже прямая дорожка к supply chain-атакам через typosquatting.
Не менее неприятен и второй тезис текста: окно на исправление уязвимостей сжимается. Если раньше между появлением уязвимости и ее практической эксплуатацией могли пройти месяцы, то теперь, по логике статьи, этот интервал во многих случаях ужался до дней, а иногда атаки стартуют еще до выхода патча. На этом фоне особенно показательна ссылка на Project Glasswing, в рамках которого Anthropic, как пишет автор, делилась с рядом критически важных поставщиков ПО еще не выпущенной моделью Claude Mythos. По данным колонки, эта система нашла 271 уязвимость только в Firefox, включая проблемы, которые пережили десятилетия человеческого ревью. Сигнал для рынка довольно прозрачный: AI помогает не только писать код, но и искать дыры в уже работающих продуктах, причем с темпом, к которому классические процессы defense-side не успевают адаптироваться.
Для продуктовых и платформенных команд из этого следует не мораль про «запретить AI», а более скучная и полезная вещь: считать полную стоимость генерации, а не только скорость первого коммита. Если AI увеличивает поток изменений, то нужно заранее усиливать ревью по риску, а не по принципу «все смотрим все». Нужны автоматические проверки маркетплейсных расширений и плагинов еще до публикации, отдельные правила для citizen development, sandbox-среды и понятный handoff в тот момент, когда «собранная на коленке» внутренняя утилита внезапно становится бизнес-критичным сервисом. Иначе organization chart у вас останется прежним, а фактическая работа старших инженеров начнет все сильнее смещаться от разработки к санитарной обработке AI-выхода.
Самый неприятный побочный эффект тут даже не в багах, а в размывании ответственности. Velocity обычно записывают в плюс той команде, которая быстро отгрузила функциональность. Cleanup cost почти всегда падает на других людей и позже: на reviewers, SRE, security, техподдержку, maintainers, а иногда уже на клиентов. Поэтому главный вопрос вокруг генерации кода ИИ на ближайший год звучит не «насколько быстрее она пишет», а «кто и по каким правилам будет обслуживать этот прирост объема». Если индустрия не научится отвечать на него заранее, выигрыш в скорости рискует оказаться просто новым способом дорого покупать технический долг.