PR утвердили за четыре минуты. Тесты зелёные, код чистый, диф читаемый. Approved.

Через три дня авторизация тихо легла у части пользователей. Без ошибок в логах, без алертов. Люди просто не могли залогиниться, и никто этого не замечал - до первых жалоб в саппорт. На поиск причины ушло 11 часов. Причина - тот самый PR.

Код сгенерировал AI. Ревьюер глянул. Всё выглядело нормально.

Я эту историю прочитал на DEV Community, закрыл вкладку. Открыл следующую. Потом ещё одну. За неделю пролистал больше тридцати статей, тредов и отчётов про AI-кодинг - от The Register до исследований Faros AI. Искал что-то конкретное: есть ли данные, что AI реально ускоряет доставку кода в прод. Не написание - а именно доставку.

Нашёл. Только данные говорят не то, что ожидаешь.

84 и 29

84% разработчиков используют AI-инструменты ежедневно. Данные за апрель 2026, агрегация нескольких опросов.

29% доверяют тому, что выкатывают в прод.

В 2024-м у 70% было позитивное отношение к AI-кодинг-инструментам. Сейчас 46% активно не доверяют их точности - рост с 31% за год. Daily usage при этом вырос с 18% до 73%. Инструменты - везде. Уверенность в них - сползает.

А вот METR - рандомизированное контролируемое исследование, не опрос. Опытные разработчики выполняли реальные задачи в своих собственных open-source репозиториях, с AI и без. Замеряли фактическое время от старта до мёрджа. Результат: с AI на 19% медленнее. При этом сами оценивали себя на 20% быстрее.

39 процентных пунктов между восприятием и реальностью. (Оговорка: выборка в METR небольшая, и авторы сами пишут, что это не окончательный вердикт. Но разрыв между ощущением и замером - это факт, а не интерпретация.)

Я назвал это галлюцинация продуктивности. Ты пишешь больше кода, генерируешь больше PR, закрываешь больше задач, и поэтому чувствуешь себя продуктивнее. Но код до прода добирается с той же скоростью. Или медленнее.

И есть вторая форма этой же галлюцинации, может даже опаснее. VirtusLab в статье про cognitive debt от 10 апреля нашли: разработчики, которые регулярно используют AI, оценивают свои навыки выше, чем те, кто не использует. А на тестах без AI показывают результаты хуже. AI маскирует пробелы, выдавая рабочий код в тех местах, где ты бы застрял. С твоей стороны это выглядит как «я справился». По факту - справился инструмент, а ты не заметил, что не понимаешь результат.

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

10 000 разработчиков, 1 255 команд

Faros AI проанализировали телеметрию крупной выборки. На командах с высоким AI-adoption:

  • Задач закрывается на 21% больше

  • PR стало на 98% больше

  • Размер PR вырос на 154%

  • Время ревью - на 91%

  • Баги - плюс 9% на разработчика

Вдвое больше PR. Каждый вдвое крупнее. Ревью вдвое дольше. И багов больше - несмотря на ревью.

Google DORA Report добавляет контекста: каждые 25% роста AI-adoption коррелируют с падением скорости доставки на 1.5% и снижением стабильности на 7.2%. Не потому что код плохой - потому что процессы не переваривают объём.

Проблема не в том, что AI замедляет работу. Проблема в том, что мы мерим не то. Bottleneck переехал из написания кода в проверку, а метрики по-прежнему считают вход.

Входные метрики (то, что обычно на дашборде): PR count, LOC written, tasks closed, story points burned.

Выходные метрики (то, что реально показывает доставку): lead time to production, review latency, rollback rate, incident rate, hotfix volume.

Если входные растут, а выходные стоят на месте или ухудшаются - это и есть галлюцинация продуктивности. Не абстрактная концепция, а конкретный разрыв в двух наборах чисел. Все примеры дальше - по сути про этот разрыв.

Один вторник, одиннадцать PR

Один разработчик открыл 11 PR за вторник. Раньше делал 2-3 в неделю. Его процесс: описал фичу, Claude Code написал, глянул диф, открыл PR.

Дальше было так. Эти 11 PR висели в ревью в среднем четыре дня. Три - больше недели. К мёрджу последнего - конфликты с main, ещё час на резолв. Два сеньора-ревьюера к пятнице выглядели, цитата, «как после войны».

Код писался быстрее, чем когда-либо. В прод попадал - с той же скоростью.

Тут есть деталь. Ревьюить AI-код - не то же самое, что ревьюить код коллеги. У коллеги есть контекст: вы обсуждали подход, ты знаешь его стиль. У AI-кода контекста ноль - каждое решение по неймингу, структуре, обработке ошибок надо оценивать с нуля. На практике один AI-PR часто съедает столько же когнитивного ресурса, сколько раньше уходило на два-три знакомых PR от коллег. А их одиннадцать, и после 200-400 строк качество ревью падает резко - неважно, кто ревьюер.

Я когда это читал, подумал: ну банально же. А потом честно вспомнил, что у меня на проекте ревью тоже стали дольше, PR - толще, а на ретро мы говорим «стали продуктивнее». Потому что считаем созданные PR, не доставленные фичи. Входные метрики растут. Выходные - нет.

Миллион строк, которые никто не прочитал

Финтех-фирма внедрила Cursor. Ежемесячный объём кода: с 25 000 строк до 250 000. Результатом стал не рост продуктивности - а бэклог в миллион строк, ожидающих ревью. Джони Клипперт, CEO StackHawk: объём и уязвимости стали неуправляемыми для человеческих команд.

GitHub за 2025-й зафиксировал рост AI-контрибьюций на 400%. Python Software Foundation - скачок выгорания мейнтейнеров на 60%. 78% опрошенных винят AI-сабмиты.

А на DEV Community разработчик описал спираль, которую узнает любой, кто работает с AI-кодом дольше полугода: «Шесть месяцев назад шипили фичи за два дня. Сейчас одно изменение - две недели». Каждая AI-сессия оптимизирует текущую задачу, не зная про общую архитектуру. Бизнес-логика расползается по слоям. Файлы, которые были single-purpose, обрастают десятком concerns. Verification debt нарастает на 30-40% в квартал - не потому что разработчики стали хуже, а потому что структура кода деградирует быстрее, чем её успевают чинить.

Кстати - если хотите посмотреть, насколько это касается вашего проекта, есть простой способ:

git log --since="30 days ago" --pretty=format:"%H" | while read hash; do
  git diff-tree --no-commit-id --name-only -r $hash
done | sort | uniq -c | sort -rn | head -10

Если одни и те же файлы всплывают в каждом коммите - границы доменов, скорее всего, размыты, и каждое изменение потенциально ломает что-то в другом конце проекта. Здоровый показатель - 2-4 файла на коммит. Больше 8 - красный флаг.

А слоп стал лучше

Вот штука, которая мне реально не давала покоя.

Даниэль Стенберг, автор curl, пишет: раньше приходили AI-отчёты об уязвимостях - откровенный мусор. Легко отклонить. Сейчас мусор прекратился. Вместо него - «действительно хорошие отчёты, почти все с помощью AI». Грег Кро-Хартман из ядра Linux подтверждает: меньше слопа, больше валидных проблем.

Звучит как прогресс.

Но их стало настолько больше, что мейнтейнеры физически не успевают обрабатывать. Стенберг перестал платить за отчёты. Internet Bug Bounty приостановил приём вообще. Формулировка: «баланс между обнаружением и способностью к исправлению существенно сместился».

Когда AI-код был плохим - его легко отклоняли. Теперь он выглядит хорошим - и на верификацию уходит больше времени, не меньше. «Выглядит хорошо» и «работает правильно» - разные вещи. Чтобы понять разницу, нужен человек, который знает домен.

Может я перегибаю. Может это просто growing pains, и через год всё наладится. Но тренд прямо сейчас: AI делает генерацию дешёвой, а верификацию - дорогой. И это та же механика, что с PR: порог входа упал, стоимость проверки выросла. Генерация масштабируется бесконечно. Проверка - ограничена количеством людей, которые понимают, что они проверяют.

78% по-тихому

78% сотрудников используют AI без одобрения IT. Треть редко проверяют вывод. 15% скрывают использование от менеджеров.

То есть представьте: ваш PR-pipeline уже наполовину состоит из AI-кода, но ни тимлид, ни IT-отдел об этом не знают. Метрики показывают рост throughput - и менеджмент доволен. А что конкретно попало в прод и кто это проверил - никто не отслеживает, потому что формально AI никто не внедрял.

Это не adoption. Это shadow engineering, и в ряде компаний его масштаб может быть сопоставим с официальным AI-внедрением или даже превышать его.

А вот где работает

Я специально искал контрпример. Хотел найти компанию, где AI-кодинг реально ускоряет доставку, а не только генерацию.

Kapwing. 25 человек. В Q1 2026 каждый сотрудник закоммитил код в прод. Дизайнер. Руководитель продаж. Контент-райтеры. Саппорт. 108 PR через AI-агентов за квартал. И - инциденты в проде снизились. Bug bash (ежеквартальный спринт по багам) отменили - потому что интеграция с баг-трекером закрывает мелочь автоматически. 36 инженерных дней в квартал - сэкономлены.

Почему у них работает, а у финтех-фирмы с миллионом строк - нет?

Не инструмент. Процесс:

  • Каждому дали конкретную, заранее подобранную задачу для первого PR - не «разбирайся сам»

  • Пять месяцев внедрения в три фазы: инфраструктура → обучение → автоматизация

  • Инженеры ревьюят каждый PR, включая PR от не-технических сотрудников

  • QA-менеджер стал одним из топ-контрибьюторов - навык точно описывать баги оказался ровно тем, что нужно для промптов

Kapwing перестроили процесс под новый объём. Не просто дали всем Codex и надеялись.

Anthropic в своём отчёте: AI-код - уже 41-42% всего кода глобально. Если верить их оценке, устойчивый порог качества находится где-то в диапазоне 25-40%. Выше - деградация начинает съедать прирост. Kapwing, видимо, нашли свой баланс. Как именно - из блог-поста не до конца ясно, данных для точного утверждения нет. Но одна деталь бросается в глаза: CEO сама вела тренинг. Не делегировала «AI-евангелисту» и не скинула в Notion. Это сигнал команде: мы не для галочки, мы реально хотим, чтобы это работало.

Что я из этого вынес

Не хочу делать «10 советов». Но две вещи из тридцати статей повторялись настолько часто, что игнорировать не получится.

Первая - лимит на размер PR. 400 строк, мягкий потолок. AI выдал целую фичу? Разбей на три PR. Пять минут на split экономят часы ревью. По данным Faros AI, после 200-400 строк качество ревью деградирует резко, и неважно, насколько хорош ревьюер. Кстати, Kapwing это тоже делают - их PR от не-инженеров маленькие и точечные по определению.

Вторая - не пропускать бизнес-логику и авторизацию через тот же процесс, что бойлерплейт. Бойлерплейт пусть сканирует AI-ревью, человек глянет за 30 секунд. А платежи и авторизация - два ревьюера и парная сессия. Когда всё идёт в одну очередь, важное тонет.

И ещё один вопрос, который я теперь задаю себе перед каждым approve: «Могу ли я объяснить, почему код структурирован именно так, не глядя в него?» Если нет - не аппрувлю. Не потому что код плохой. А потому что дебажить в два ночи придётся мне.

Как проверить, есть ли галлюцинация у вас

Если у вас есть GitHub, вы можете посмотреть за 5 минут. Три команды:

Медианный размер PR за последний месяц:

gh pr list --state merged --limit 50 --json additions,deletions | \
  jq '[.[] | .additions + .deletions] | sort | .[length/2]'

Если медиана выросла в 2+ раза за полгода, а lead time не сократился - это сильный индикатор галлюцинации продуктивности.

Медианное время от открытия PR до мёрджа:

gh pr list --state merged --limit 50 --json createdAt,mergedAt | \
  jq '[.[] | ((.mergedAt | fromdateiso8601) - (.createdAt | fromdateiso8601)) / 3600] | sort | .[length/2] | round'

Результат в часах. Если растёт при растущем количестве PR - bottleneck переехал в ревью.

И тот git log из секции выше - для coupling. Три команды, пять минут, и у вас есть фактическая картина вместо ощущений.

Может через год AI-инструменты научатся нормально ревьюить и bottleneck опять сдвинется. Может Kapwing - шаблон. Может - исключение для маленьких команд.

Но если после внедрения AI у вас выросли PR count и throughput, а lead time to production не сократился - это сильный признак галлюцинации продуктивности. Команды, которые это замечают (как Kapwing), перестраивают процесс. Команды, которые не замечают, набирают verification debt до первого серьёзного инцидента.

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


P.S. Сам пользуюсь AI для кодинга каждый день. И да - ревью у меня тоже стали дольше. Ирония не ускользнула.

Комментарии (12)


  1. Assador
    11.04.2026 11:49

    Да, проблема очень актульна. Лично я работаю по принципу ревью на входе. Юзаю Zed, но без AI. Вообще. А по коду просто советуюсь с ИИшками (несколькими и разными по одной и той же задаче, для сверки), но код пишу сам. Либо копирую советуемый код если внешне выглядит годно, но после этого прохожусь по нему руками строка за строкой. Это не пиар; я действительно думаю, что это единственный разумный вариант сейчас.


    1. diffnotes-tech Автор
      11.04.2026 11:49

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


  1. AstRonin
    11.04.2026 11:49

    Вот придурки) это я про тех, кто стал 11 PR фигачить, вместо 3. Вас же забьют задачами, раз вы справляетесь быстрее! Я наоборот, делаю примерно столько же, сколько и до ИИ, но щас я стал спокойне брать большую задачу, потому что знаю, что рутиный код она спокойно напишет, а я пока разберусь с задачей, позадаю вопросов бизнесу, поспрашиваю другую команду, если код связан с ними, подумаю как лучше реализовать… потом мы только пишем. И время на само тестирование на Деве осталось больше, качественней задача получается.


    1. diffnotes-tech Автор
      11.04.2026 11:49

      ну да)) тот чувак с 11 PR по сути переложил свою скорость на двух сеньоров-ревьюеров и создал им ад. А ты наоборот забрал сэкономленное время себе на этап до кода. И это как раз то что по данным работает - Kapwing из статьи тоже не стали фигачить больше PR, они стали закрывать мелкие баги автоматом а людей отправили думать. По-моему твой подход ближе к тому как AI реально помогает - не “больше кода за день” а “лучше подготовленная задача”


  1. AlexTOPMAN
    11.04.2026 11:49

    2-4 файла на коммит. Ну, так и поставьте такую кипиайку иишке. ) Пускай переходит в режим: "Миша, всё херня - переделывай!". А как выполнит кпэ, тогда и будем сравнивать "скорость написания адекватного кода" у неё и у человека. ;)


    1. diffnotes-tech Автор
      11.04.2026 11:49

      Идея норм, но тут ловушка - агент-то послушается, он формально разобьёт. Только 2-4 файла на коммит это не KPI а симптом. Если архитектура такая что любое изменение трогает 12 файлов, агент начнёт делать 3 коммита по 4 файла и каждый из них будет ломать прод по отдельности.

      Метрика работает как диагностика, а не как ограничение - если git log показывает 8+ файлов, это значит что модули слиплись, и чинить надо модули, а не коммиты


  1. werevolff
    11.04.2026 11:49

    Сопровождаемость имеет значение. Лиды и сеньоры раньше тратили время на то, чтобы:

    1. PR занимал меньше строк кода. В идеале, если удаётся удалить больше старого легаси-кода, чем добавить нового - это показатель хорошего PR.

    2. Код был разбит так, чтобы последующие изменения были атомарными. Здесь мы руководствуемся принципами Clean Code, SOLID, GRASP. Не всегда это даёт производительный код, но его сопровождаемость увеличивается.

    3. Был соблюдён общий стиль кода, нэйминга и компоновки модулей.

    Эти подходы приводили к тому, что в проде задачи на фичи делались быстро. Доставка кода в прод - моментальная. Сокращалось время тестирования и CR.

    К сожалению, сопровождаемость трудно замерять. Скорость доставки фич в прод - один из показателей сопровождаемости, как и количество багов на PR. Однако, сейчас все сходят с ума по количеству строк кода, которые генерирует AI. По количеству задач, переданных в ревью. Хорошо, есть компании, где задача не считается закрытой до мержа PR как минимум в dev. А то и до доставки в тестовую среду. Если, конечно, не находится какой-нибудь продуктовый инженер, и не убеждает руководство в том, что нужно замерять количество строк кода в каждой ветке.


    1. diffnotes-tech Автор
      11.04.2026 11:49

      Про “удалить больше чем добавить” - это прям хороший индикатор, жаль что я его в статью не включил. По сути это ещё одна выходная метрика которую никто не считает когда хвалятся AI-продуктивностью. AI генерирует, он не удаляет. А хороший PR часто именно удаляет.

      С сопровождаемостью сложнее - ты прав что её трудно замерять напрямую. Но косвенно она вылезает в том самом verification debt из статьи. Когда каждая AI-сессия пихает логику куда удобно прямо сейчас, без оглядки на SOLID, через полгода любое изменение трогает полпроекта.

      И время на фичу растёт не потому что разработчик тупой а потому что код слипся


      1. tenzink
        11.04.2026 11:49

        На прошлой работе интереса ради смотрел на статистику +- в гите. Корреляция была отличная. У топов минус преобладал над плюс. А у одного разработчика, чей код меня очень сильно напрягал, был почти один плюс, с минусом, близким к нулю.


        1. werevolff
          11.04.2026 11:49

          Это ситуационно. Если мы говорим о новом компоненте, то, скорее-всего, код растёт. В АПИшках, вообще, добавление нового эндпоинта будет порождать кучу новых сущностей: модели и схемы данных, миграции, методы репозиториев, валидаторы, фильтры, сервисы/юз-кейсы. Ещё сверху добавятся интерфейсы. Прикол в том, что ИИ сделает это «в лоб». То есть, будет повторение кода, будут условные операторы вместо разделения интерфейсов. Будут непонятные связи в коде. Можно, конечно, разделить задачу для ИИ, заставив оптимизировать код. Можно сразу спроектировать все сущности и написать промпты для их создания. Но это не даст +150% к объёму создаваемого кода. Разработка будет быстрее, чем руками, но медленней, чем ИИ-соло. В этом ИИ походит на разработчика, который стремится решить задачу, но не соблюдает code-style и принципы/соглашения.

          Когда мы пишем код, мы приходим к консенсусу между сопровождаемостью и эффективностью решения. Зачастую, лишние интерфейсы, инверсия зависимостей, обилие схем негативно влияют на скорость выполнения программы, а также, на количество занимаемой памяти. Однако, это гарантирует нам лёгкость изменений, их атомарность. Уменьшает связанность компонентов. Устраняет риски возникновения инцидентов. Зачастую, нам всё-равно: будет эндпоинт исполняться 50 мс или 20 мс в асинхронном коде, с обращением в кэш или базу, при нескольких тысячах RPS. А вот стоимость изменения и надёжность имеют наивысший приоритет. И в этих условиях крайне важно, чтобы новые фичи, если они похожи на существующие, поставлялись с уменьшением кодовой базы. Чем меньше кода, тем дешевле обслуживание. Но, при этом, если фича требует добавление кода, он должен быть добавлен. Вопрос в том, чтобы эта производная не давала слишком большой рост. Сдерживание роста кодовой базы - одна из основных задач инженеров на проекте. То есть, мы все понимаем что база кода будет расти. Наша задача минимизировать этот рост в разумных пределах. А если он случился, то обеспечить низкую связанность кода.


      1. werevolff
        11.04.2026 11:49

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

        Что касается роста кодовой базы, то это безумие - считать её рост развитием проекта. Таски, как я понял, стали закрывать до релизов, чтобы отчитаться о внедрении ИИ. Этот рост закрытых задач не говорит об успешной доставке фичи в прод. Фича должна пройти тестирование прежде, чем состоится релиз. По сути, из хвалёной продуктивности мы имеем только повышение скорости написания кода. Частично, рост выполненных за единицу времени задач (тех, которые, всё-таки, считают по факту доставки в прод). В остальном, имеем снижение сопровождаемости, увеличение количества багов на релиз, замедление T2M и увеличение количества инцидентов (пока о последнем сужу по слухам).


  1. sanyvaa
    11.04.2026 11:49

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