SavePearlHarbor

Как широкий доступ к ИИ‑кодогенерации тихо разъедает инженерную команду

—

от автора

admin

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

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

Сразу про источники, чтобы потом не возвращаться. Рядом с каждой цифрой я помечаю, откуда она: независимое рецензируемое исследование или RCT, телеметрия с открытой методологией, вендорские данные (и тогда отдельно говорю про конфликт интересов) либо опрос. К самым громким тезисам я старался прикладывать самый сильный контраргумент, который удалось найти. Это не реверанс объективности ради галочки, а страховка от того, чтобы весь разбор не скатился в подтверждение вывода, который я придумал заранее.

Почему это не вина «плохого инженера»

Картинка, с которой мы начали (через два года систему целиком не понимает никто, но тесты зелёные), это не единичная жалоба с какого‑то проклятого проекта. У неё есть имя. В индустрии это называют comprehension debt, долг понимания, и аккуратно отделяют от технического долга. И вот почему это важно. Технический долг о себе сигналит: медленные сборки, разбухшие зависимости, страшные места, которые все обходят стороной. Долг понимания не сигналит вообще. Кодовая база выглядит чистой, тесты проходят, ревью пройдено, а полную модель того, что написано, ни автор, ни ревьюер ни разу не построили. Это код, который ни один живой человек не писал и целиком не прочитал.

Что это не локальная аномалия, видно по опросам. Stack Overflow Developer Survey 2025 (около 49 тысяч ответов из более чем 160 стран) поймал редкую вещь: разрыв между тем, как охотно инструментом пользуются, и тем, насколько ему доверяют. ИИ‑инструменты используют или собираются 84% разработчиков. И при этом доверие к точности их вывода за год упало с примерно 40% до 29%. Вдумайтесь, насколько это противоестественно. Обычно чем дольше пользуешься, тем больше доверяешь: узнаёшь сильные места, нарабатываешь привычки, понимаешь, где подстелить соломки. А тут наоборот: чем плотнее люди работают с ИИ, тем меньше ему верят. Активно не доверяют точности 46% против 33% доверяющих, высокое доверие декларируют всего 3%. И вишенка: чем опытнее разработчик, тем он осторожнее. У самых опытных высокое доверие к ИИ всего у 2,6%, а активное недоверие доходит до 20%.

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

Дальше у меня три довода, почему рамка «наняли не тех» не держится.

Довод первый: разрыв между ощущением и реальностью не зависит от квалификации. Это самый сильный сюжет во всём разборе, поэтому остановлюсь подробно. METR в своём RCT 2025 года (arXiv:2507.09089) набрал не «средних» разработчиков, а матёрых мейнтейнеров крупных опенсорс‑проектов: в среднем по 5 лет в конкретной кодовой базе, большие зрелые репозитории, в среднем за 22 тысячи звёзд. Перед стартом задач люди прогнозировали, что ИИ ускорит их на 24%. После того как всё закончилось и они уже видели свой результат, они оценивали ускорение в 20%. А по факту ИИ замедлил их на 19%. Перечитайте ещё раз: люди, которые знают свой код и свой процесс лучше всех на свете, сохранили иллюзию ускорения даже после того, как собственными руками получили замедление. Если на это покупаются даже они, разговор про «недостаточную зрелость отдельных ребят» можно закрывать.

Довод второй: эффект асимметричный, и зависит он от типа работы, а не от человека. Те же данные METR и разборы вендорских телеметрий сходятся: вайб‑кодинг лучше всего работает на greenfield и одноразовых прототипах. Там паттернов ещё нет, конфликтовать ИИ не с чем, а цена ошибки невелика. Один и тот же разработчик с одним и тем же инструментом получает ускорение на типовой задаче в свежем проекте и замедление на похожей задаче в зрелом коде. Это характеристика инструмента, а не диагноз человеку.

Довод третий: когда телеметрию агрегируют по командам, всё повторяется этажом выше. Faros AI (вендор) на данных больше чем 10 тысяч разработчиков и 1255 команд показал рост числа смерженных PR на 98% и закрытых задач на 21%, но одновременно рост времени ревью на 91% и размера PR на 154%, и всё это без измеримого улучшения DORA‑метрик на уровне организации. На обновлённой выборке в 22 тысячи разработчиков и 4 тысячи команд стало только хуже: больше багов, больше инцидентов, более длинные циклы ревью. Отдельно неприятно, что даже команды со зрелыми DevOps‑практиками, которые были производительными ещё до ИИ, просели в доставке так же, как все остальные. Faros называет это Acceleration Whiplash. Оговорка обязательна: Faros продаёт аналитические панели, и им выгодно показывать проблему, под которую у них же есть решение. Но методология (телеметрия из систем контроля версий, CI и инцидентов) проверяема, а само расхождение между индивидуальным выхлопом и результатом организации подтверждается независимо.

Сложите три уровня. Эффект виден у отдельного человека (METR), в артефактах (GitClear, CodeRabbit) и в организации (DORA, Faros). Когда одно и то же лезет со всех трёх уровней сразу, искать конкретного виноватого бессмысленно. Это свойство системы, а не человека в ней.

Как именно всё разваливается: пять механизмов

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

Размывание ролей

Когда один человек с ИИ строчит артефакты сразу во всех ролях, доменной глубины от этого не прибавляется. Удобно объяснить через два понятия Фреда Брукса из «No Silver Bullet». Брукс делил сложность на essential (сложность самой задачи) и accidental (сложность инструментов и обвязки вокруг). ИИ массово удешевляет генерацию правдоподобного кода, то есть возится с синтаксисом и шаблонами, а это слой accidental. А вот архитектурная глубина, понимание домена, чутьё на структурный конфликт это essential, которой в коде напрямую нет. Удешевили одну сторону, не тронув другую, и получили характерный перекос: артефакты на всех уровнях лепятся быстрее, чем команда успевает дойти до понимания, на котором эти артефакты по‑хорошему должны стоять.

Закон Конвея добавляет второй ракурс. Если структура системы повторяет структуру общения, то «команда из одного человека в пяти ролях» впечатывает в систему ровно эту фигуру, то есть отсутствие общения между ролями. Архитектуру, фронт и тесты пишет один и тот же человек, и решает он за минуты внутри одной IDE‑сессии. Снаружи это выглядит как скорость. На языке Конвея это значит, что границы модулей и интерфейсов теперь повторяют границы внимания одного человека в одну минуту времени.

Прямых замеров деспециализации мало, тут с эмпирикой хуже всего. Но косвенный сигнал есть: в разборе 22 953 пулреквестов от 1719 вайб‑кодеров (Asdaque et al., MSR 2026) PR от менее опытных оказались в 2,15 раза больше по коммитам и в 1,47 раза по изменённым файлам, собирали в 4,52 раза больше комментариев на ревью, принимались на 31% реже и висели открытыми в 5,16 раза дольше, чем у опытных вайб‑кодеров. Без доменной глубины ИИ‑генерация даёт больше кода, более низкого качества и без понимания собственного результата. Вот это и есть размывание ролей в действии.

Где этот аргумент слабоват, скажу честно. «Фуллстек» и «тыжпрограммист» давили на людей задолго до всякого ИИ. Утверждать, что именно ИИ это породил, без сопоставимых исторических замеров было бы передёргиванием. Аккуратнее так: ИИ снижает порог входа в чужую роль ровно тогда, когда прежние сдерживающие факторы (явная некомпетентность, честный страх собственного непонимания) уже сняты, а новых не подвезли. Это слабее, чем «ИИ создаёт деспециализацию», но всё ещё по делу.

Налог на ревью

Читать чужой код когнитивно дороже, чем писать свой, а ИИ выдаёт чужой код в темпе, который ревью не вывозит. Ориентир тут классический: по известной работе Минелли с соавторами разработчики тратят на чтение и понимание кода около 70% времени. Это базовая структура работы, а не сюрприз от ИИ. Сюрприз в том, что ИИ меняет: по данным CodeRabbit (вендор) проблемы читаемости в ИИ‑сгенерированных PR встречаются втрое чаще, чем в человеческих, и это невнятные имена, переусложнённая логика, отсутствие документации, разъезжающийся стиль внутри одного файла. Брайан Керниган сформулировал суть ещё в 1974-м: читать код тяжелее, чем писать. А теперь представьте, что ИИ выдаёт 300 строк за то время, пока вы только обдумываете подход.

Структурно ломается вот что. Раньше автор PR владел контекстом по умолчанию: он сам построил ментальную модель, и сам процесс написания эту модель проверял. ИИ‑сгенерированный PR рвёт этот цикл. Формально автор есть, а владения нет, потому что своя модель не строилась. Ревью «своего» кода превратилось в ревью чужого, только этот «кто‑то» печатает быстрее, чем вы думаете.

На масштабе это и вылезает. Faros фиксирует рост времени ревью на 91% и размера PR на 154% без улучшения DORA‑метрик. Apiiro отмечает, что ИИ‑помощники запихивают больше кода в меньшее число PR, и ревью от этого тяжелее, потому что одно изменение цепляет больше частей системы. Удар приходится в саму единицу анализа: средний PR в ИИ‑эпоху перестаёт быть «единицей человеческого внимания». А самый компетентный человек в команде превращается в бутылочное горлышко процесса, темп которого он не контролирует.

Сюда же ложится Lee et al. (CHI 2025, Microsoft Research и CMU, 319 «работников знания», 936 примеров реального использования ИИ). Чем больше человек уверен в ИИ, тем меньше он включает критическое мышление; чем больше уверен в себе, тем больше. Качественно ИИ сдвигает само критическое мышление в сторону проверки чужого вывода и надзора за процессом. То есть инженера переоформляют в оператора‑надзирателя за непрозрачным процессом. И это прямо перекликается с тем, что Лизанн Бэйнбридж описала ещё в 1983-м (к ней вернёмся в пятом механизме, она там главная звезда).

Где слабое место. ИИ‑инструменты ревью (CodeRabbit, Augment Code и прочие, все вендоры) пытаются снять этот налог симметрично: ИИ ревьюит ИИ‑код. Часть рутины (стиль, простые баги) так и правда снимается. Но фундаментальную асимметрию это не убирает: ревьюер всё равно обязан восстановить намерение, которое никто не сформулировал, а ИИ‑ревью добавляет ещё один слой комментариев, который снова надо проверять. Долгосрочного эффекта ИИ‑ревью на качество на широких выборках пока нет, есть пилотные кейсы вендоров.

Метрики отрываются от реальности

«Зелёные тесты» и «99% покрытия» из индикатора превращаются в цель, а ИИ блестяще оптимизирует ровно тот прокси, по которому его оценивают. Это закон Гудхарта в чистом виде, и вот тут, в отличие от предыдущего механизма, эмпирика самая зрелая, причём накопленная до ИИ и без всякой связи с ним.

Inozemtseva и Holmes (ICSE 2014, «Coverage is not strongly correlated with test suite effectiveness», между прочим, получившая на ICSE 2024 награду как самая влиятельная статья десятилетия) показали главное: обнаружение мутантов коррелирует с поимкой реальных дефектов сильнее, чем с этим коррелирует покрытие. То есть покрытие это слабый прокси качества тестов. Just et al. (FSE 2014) подтвердили: ловля мутантов связана с ловлей реальных дефектов независимо от покрытия, и связь сильнее, чем у покрытия. Petrović et al. (ICSE 2021) добавили длинную дистанцию: проекты, которые гоняют mutation testing, со временем в среднем пишут больше тестов, чем те, кто гонится только за покрытием, потому что разработчики видят выживших мутантов и реагируют.

То есть проблема, к которой ИИ просто присоединился, известна больше десяти лет. KPI «покрытие 99%» это уже провал по Гудхарту сам по себе, а ИИ доводит его до абсурда. Любопытная деталь про то, что добавляет ИИ: в экспериментах с генерацией тестов через LLM ассерции от модели давали более высокий mutation score, чем у EvoSuite (в одном из замеров в среднем 19,1% против 17,3%). Иначе говоря, ИИ умеет писать осмысленные тесты, если его на это специально нацелить через mutation score. Без такой наводки он оптимизирует ровно то, что попросили, то есть покрытие. Метрика, которой инструмент управляется, и есть метрика, которую он удовлетворяет. Всё по Гудхарту.

На безопасности тот же эффект виден в цифрах. По отчёту Veracode 2025 (вендор, больше 100 моделей на 80 задачах) сгенерированный ИИ код содержит уязвимость в 45% случаев: когда у модели есть выбор между безопасным и небезопасным способом, она выбирает небезопасный почти в половине случаев, и за поколениями моделей эта доля держится стабильно. Уязвимости спокойно проходят синтаксические проверки и сборку именно потому, что эти проверки и есть прокси, под который оптимизировалась генерация. Apiiro в исследовании на Fortune 50 (вендор) показал ту же асимметрию ещё нагляднее: тривиальные синтаксические ошибки в ИИ‑коде упали на 76%, логические баги более чем на 60%, зато пути privilege escalation выросли на 322%, а архитектурные дефекты на 153%. Запомните этот контраст: ИИ чинит опечатки и закладывает бомбы замедленного действия. Точнее иллюстрации Гудхарта в данных не придумаешь. Инструмент великолепен в том, что меряют линтеры и базовые тесты, и систематически плох в том, что автоматически никто не меряет.

Где слабое место. Тезис не в том, что зелёные тесты бесполезны, а в том, что это условие необходимое, но не достаточное. Где‑то покрытие нужно как минимальная гигиена, например в жёстко регулируемых отраслях. Правильная формулировка не «покрытие бесполезно», а «покрытие в роли целевой метрики становится бесполезным, и в эпоху ИИ особенно». На замену напрашиваются mutation score, время онбординга нового человека и простейшая проверка: способен ли кто‑то объяснить модуль вслух.

Долг понимания

Майкл Фезерс в «Working Effectively with Legacy Code» определял легаси как код без тестов на поведение. Сейчас у термина прорастает второе определение, родственное первому: это код без живого автора, который способен объяснить, почему сделано именно так. Долг понимания и есть тот растущий зазор между объёмом кода в системе и той его частью, которую хоть кто‑то реально держит в голове.

Bus factor описывает то же самое, только в индивидуальном разрезе: сколько человек должно «попасть под автобус», чтобы знание исчезло. ИИ порождает коллективную версию этой беды. Раньше уход эксперта обнулял понимание задним числом. Теперь понимание может вообще ни разу не возникнуть в человеческих головах: у кода никогда и не было живого автора с полной моделью.

Измерить это напрямую труднее всего, но косвенные данные сходятся. Те же Asdaque et al. (MSR 2026): менее опытные вайб‑кодеры фокусируются на генерации большего объёма кода, перекладывая проверку на ревьюеров. Объём растёт, понимание со стороны автора падает. GitClear через прокси‑метрики кода (база в 211 миллионов изменённых строк, 2020–2024) фиксирует ту же динамику: доля копипаст‑строк выросла с 8,3% (2020) до 12,3% (2024); доля рефакторинговых, «перемещённых» строк упала с 24,1% до 9,5%; частота блочных дубликатов в 2024-м подскочила примерно в 8 раз год к году; а код, который переписывают в первые две недели после коммита, вырос с 3,1% до 5,7%, то есть преждевременных коммитов стало почти вдвое больше. Цифры вендорские (GitClear зарабатывает на продаже анализа кода), но методология открыта, направление устойчиво и независимо подтверждается DORA и Faros.

И тут важная вещь, GitClear полезно читать с двух сторон. В январе 2026-го они выпустили обновление, частично смягчившее ранние выводы: кросс‑провайдерская телеметрия (Cursor, GitHub Copilot, Claude Code, 2172 разработчико‑недели) показала сильную связь между большей долей ИИ и большим объёмом «прочного кода» (durable code, который не удалили и не переписали за две недели) и предложила пересмотреть ожидания. Те же люди, что фиксировали проблему в 2024-м, в 2026-м нашли у эффекта и хорошую сторону. Это здоровое напоминание: метрики умеют ехать в обе стороны разом, и рост дубликатов не отменяет роста «прочного кода». Хотя «прочный» тут не значит «хороший». Код может оставаться в репозитории просто потому, что его страшно трогать, а это симптом долга понимания, а не его противоположность.

Где слабое место. ИИ умеет работать и против долга понимания: суммировать код, объяснять архитектурные решения, помогать онбордингу. Рамка «ИИ как живой комментарий к легаси» вполне реальна. Её слабость в том, что она работает при наличии исходной документации и приличных практик. Если их нет, ИИ сгенерирует правдоподобное объяснение, которое нечем проверить.

Иллюзия скорости и атрофия навыка

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

Опорная работа тут опять не про ИИ. «Ironies of Automation» Лизанн Бэйнбридж (Automatica, 1983) до сих пор одна из самых цитируемых статей об автоматизации. Логика такая: когда автоматизируешь большую часть работы, человеку‑оператору достаются ровно те задачи, которые автоматизировать не вышло, то есть самые трудные. Навык в повседневной работе он при этом не тренирует, а сама работа теперь сводится к выматывающему мониторингу. Парадокс в том, что такому оператору нужно больше обучения, а не меньше, ради тех редких, но критичных моментов, когда вмешаться всё‑таки придётся.

В кодогенерацию это переписывается почти дословно. Автоматизация лёгкой части оставляет за человеком трудные баги, архитектурные решения и проверку, а сам навык в ежедневной работе ржавеет. METR RCT 2025 даёт прямое современное подтверждение: опытные сеньоры работают в опенсорс‑репозиториях, которые знают как свои пять пальцев, и минуты, сэкономленные на boilerplate, съедаются временем на ревью, правку или выбрасывание ИИ‑вывода. Один из участников сказал лучше любой статистики: вы не экономите время, вы меняете меньше печатания на больше чтения и распутывания чужого кода.

Lee et al. (CHI 2025) добавляют механику: чем сильнее человек уверен, что ИИ справится, тем чаще он «отпускает руль». Высокая вера в инструмент идёт рука об руку со снижением критического мышления, а высокая вера в себя, наоборот, с его сохранением. Есть и более ходовой сюжет, который я подам с оговоркой: разработчики, постоянно сидящие на ИИ, склонны оценивать свои навыки выше, а в тестах без ИИ показывать результаты хуже, чем те, кто работал руками. Похоже на эффект Даннинга‑Крюгера, разогнанный технологией. Конкретные первичные эксперименты за этим популярным пересказом стоит отслеживать отдельно и не выдавать за железобетонный факт, но направление совпадает с тем, что независимо подтверждают METR и Lee et al.

Где слабое место. Бэйнбридж писала про атомные станции, то есть про системы с дискретными авариями, где навык нужен редко, но критично. В софте граница не такая чёткая: «авариями» становятся ежедневные баги и архитектурные развилки, а не редкие катастрофы. Это меняет динамику: не «оператор не успел вмешаться в аварию», а «оператор хронически не строит модель». Менее драматично, зато более системно. Аналогия рабочая именно в направлении сдвига роли (инженер превращается в монитора), а не в буквальных деталях.

Что измерено по‑честному, а что вам продают

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

Прочнее всего стоит то, что измерено независимо. METR RCT 2025 это лучшее на сегодня свидетельство разрыва между ощущением и реальностью у сеньоров на знакомом коде. И что важно, авторы сами очерчивают границы и не кричат «ИИ замедляет всегда»: они честно перечисляют ограничения (слишком простые промпты, непривычка к интерфейсам вроде Cursor, высокая планка качества в их проектах, недобор сложных случаев у моделей) и аккуратно говорят про конкретный класс ситуаций. Знакомый сложный код, опытные люди, высокая планка, неоптимальное использование. Это ровно тот класс, про который весь наш разговор. Inozemtseva, Just и Petrović закрывают вопрос про покрытие, причём без всякого ИИ, ИИ лишь радикализирует уже известный провал прокси. Lee et al. дают корреляционную, но согласующуюся с другими областями (авиация, медицина) картину эрозии критического мышления при высоком доверии к инструменту.

Дальше идут вендорские заявления, к которым стоит относиться с прищуром. Знаменитые «55% быстрее» от GitHub (arXiv:2302.06590) получены в контролируемом эксперименте, где разработчиков просили написать HTTP‑сервер на JavaScript. Это хорошо очерченная, почти идеальная для ИИ‑автодополнения задача, и прирост на ней (55,8%, 71 минута против 160) мало что говорит про неоднозначные архитектурно сложные задачи. Независимые проверки с этой цифрой расходятся: где‑то ловили скромные единицы процентов, где‑то смешанные и негативные эффекты на качество. Честный вывод не «ИИ ускоряет на 55%» и не «ИИ всегда замедляет», а такой: средний разработчик на средней задаче, скорее всего, получит умеренный прирост; опытный на сложной задаче получит замедление; а на масштабе организации индивидуальный прирост утонет в нагрузке на ревью и просадке стабильности.

Отдельная пара, которую полезно держать рядом, это два отчёта DORA от Google. В 2024-м (методология открыта, но Google продаёт Gemini) рост принятия ИИ на 25% сопровождался снижением пропускной способности доставки на 1,5% и стабильности на 7,2%. В 2025-м позицию заметно пересмотрели: принятие ИИ среди разработчиков дошло до 90% (плюс 14% за год), пропускная способность теперь растёт, а вот нестабильность доставки всё ещё растёт тоже. Это не противоречие, а взросление тезиса: данных стало больше, разрез тоньше, и вместо «ИИ вредит доставке» появилась более точная формулировка, к которой я ещё вернусь. GitClear по той же логике полезно читать в двух версиях: жёсткий отчёт 2024–2025 (рост дубликатов и churn, обвал рефакторинга) и смягчающее обновление 2026-го (рост «прочного кода» у активных пользователей ИИ). Обе цифры могут быть правдой разом: можно генерировать больше кода, который не удаляют сразу, и при этом больше дубликатов внутри него.

Если свести всё к одному наблюдению, то главный кажущийся конфликт (GitHub с его плюс 55% против METR с его минус 19%) на самом деле не конфликт вовсе. ИИ ускоряет одни виды работы и замедляет другие, и направление зависит от того, greenfield это или знакомое legacy, новичок за рулём или сеньор, и что именно вы меряете: минуты на boilerplate, время до закрытия задачи или DORA‑метрики всей доставки.

Где это всё не работает

Чтобы разбор не превратился в самолюбование, нужна обязательная ветка с условиями, при которых тезис слаб или просто неверен. И таких условий хватает.

Тип задачи. Вайб‑кодинг устойчиво хорош на greenfield и одноразовых прототипах: паттернов ещё нет, конфликтовать не с чем, цена ошибки низкая. Прирост группируется вокруг чётко описанных задач с понятными критериями приёмки, прототипирования с нуля и повторяющегося рефакторинга. Это опять тот же Брукс, только с другой стороны: для прототипа «как печатать» и есть основное содержание, а для зрелой системы это уже побочка.

Архитектура и обратная связь. Тут показателен кейс Adidas из отчёта DORA 2025 (его приводит Фернандо Корнаго, под чьим присмотром около тысячи разработчиков): команды в слабо связанных архитектурах с быстрой обратной связью получили прирост производительности на 20–30% по числу коммитов, PR и общей скорости поставки фич плюс рост «Happy Time» на 50%, то есть больше времени на собственно код и меньше административной возни. А команды с медленной обратной связью из‑за тесной связки с ERP выгоды от ИИ не получили. Работают ровно те условия, которые DORA отстаивала десять лет до всякого ИИ: быстрые петли обратной связи (теперь нужны быстрее, чем когда‑либо, чтобы успевать за темпом генерации), слабо связанные архитектуры и культура обучения.

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

Культура обучения. Кейс Booking из того же отчёта DORA 2025 (его рассказывает Бруно Пассос, у которого больше 3 тысяч разработчиков): приём вайб‑кодинга и ассистентов шёл неровно, и команда поняла, что не хватало именно обучения. Когда разработчики научились давать ИИ более явные инструкции и более качественный контекст, они получили до 30% роста merge requests и более высокую удовлетворённость. Вопрос, как видите, не «работает ИИ или нет», а «готова ли команда вложиться в навык работы с ним». Распад наступает там, где этой инвестиции нет, а инструмент воспринимают как замену квалификации.

Метрики, устойчивые к Гудхарту. Команды, которые меняют покрытие на mutation score, время онбординга и способность объяснить модуль, в наблюдаемой степени «размазанной посредственности» не показывают. Тут, правда, доказательной базы меньше: отдельные кейсы и длинное исследование Petrović. Так что это правдоподобная, но недостаточно проверенная гипотеза, и честно держать её именно так.

Сложив условия, можно очертить, где тезис силён, а где слаб. Силён он на зрелой критичной кодовой базе с высокой планкой, при медленной обратной связи и тесной связке, при KPI на покрытие, скорость фич и объём, при отсутствии явного владения модулями и в командах, где менеджмент не отличает индивидуальный выхлоп от результата организации. А слаб он на greenfield или хорошо изолированных кусках зрелой системы, при быстрой обратной связи, культуре обучения, явном владении модулями, метриках против Гудхарта и подходе «джуниор под присмотром», а не «автор последней инстанции». Сценарий, с которого мы начали, целиком из первого набора. Поэтому тезис верен условно: внутри своих условий да, снаружи нет.

Чего мы пока не знаем

Этот раздел для меня важнее раздела с выводами, поэтому не пролистывайте. Он защищает разбор от того же Гудхарта, в котором мы обвиняем команды: очень легко принять набор согласованных сигналов за доказанную теорему. Не доказанную.

Долгосрочные эффекты на людей никто не мерил. Замера атрофии навыков на горизонте трёх‑пяти лет нет. Аналогии Бэйнбридж из авиации и медицины переносятся по форме, но чисел не дают. Сколько лет регулярной работы с ИИ нужно, чтобы сеньор разучился делать определённый класс задач без него, неизвестно. Ещё острее вопрос про джуниоров: формируется ли вообще новое поколение сеньоров, если стартовые задачи, на которых нарабатывается интуиция, теперь делает ИИ? Качественные сигналы есть (Кент Бек и другие говорят про «забыть, что код вообще существует»), а продольных данных нет.

Внутри пятого механизма мы не умеем разделить атрофию и иллюзию. METR показывает оба эффекта сразу (и замедление, и завышенную самооценку), но не разводит их по причинности. Может, ИИ объективно замедляет на этом классе задач и при этом ощущается ускорением. А может, ИИ объективно нейтрален, но субъективная оценка задрана так высоко, что нулевую разницу принимают за замедление. Эти случаи лечатся по‑разному, а различить их пока нечем.

Вся большая телеметрия по построению корреляционная. «У команд с высокой долей ИИ ревью длиннее» это не «ИИ удлиняет ревью». Возможны и обратные направления (команды, у которых ревью и так длинное, охотнее тянутся к ИИ), и общая причина (давление сроков рождает и ИИ, и спешку в ревью). DORA и Faros честно остаются корреляциями.

Открыт и вопрос про модели нового поколения. METR работал с Claude 3.5 и 3.7 (февраль‑июнь 2025). С тех пор вышли модели другого уровня и агентные системы. Воспроизводится ли минус 19% на них? METR запустил вторую RCT в августе 2025-го, но результаты, по их же словам, стали мутнее из‑за selection bias, и окончательного нового замера пока нет. Про безопасность отдельная оговорка: по Veracode более крупные и свежие модели общую 45-процентную уязвимость существенно не подвинули, она держится стабильно по поколениям. Надежда «новая модель всё исправит» данными пока не подкрепляется, но это именно открытый вопрос, а не приговор.

И наконец, мы так и не договорились, что считать качеством кода. «Прочный» (не удаляется быстро), «безопасный» (без уязвимостей), «понятный» (легко онбордить) и «изменяемый» (можно безопасно править) это разные вещи. ИИ‑код бывает прочным и непонятным разом, безопасным по сканеру и архитектурно слабым. Универсальной метрики нет, и сравнения «ИИ‑код против человеческого» осмысленны только в разрезе конкретного измерения.

Что бы существенно опровергло тезис? Долгий (три года и больше) RCT, где команды с ИИ сохраняют или наращивают глубину компетенций. Воспроизведение METR на новых моделях с нулевым или положительным эффектом. Большая телеметрия, показывающая рост способности команды объяснить собственный код спустя два года активного ИИ. Кейсы, где KPI на покрытие сочетались с широким ИИ‑доступом и распада не случилось. На июнь 2026 ничего из этого нет. Их отсутствие тезис не доказывает, но означает, что контраргументы пока опираются на короткие горизонты и узкие условия, а сам тезис стоит на согласованных сигналах из шести разных по природе источников: RCT, кросс‑секционная телеметрия, опросы, кейсы, литература по deskilling, литература по тестированию. Согласованность результатов, полученных разными методами, и есть самый сильный аргумент, который вообще доступен в отсутствие продольных данных.

Что со всем этим делать

Если совсем коротко, выводов семь.

Тезис подтверждается, но условно. В описанных условиях (зрелая критичная кодовая база, нет governance, KPI на покрытие и скорость, размытые роли) широкий ИИ‑доступ за пару лет систематически приводит к картине «зелёные тесты, но никто ничего не понимает». Это не индивидуальный сбой, а взаимодействие инструмента с уже имеющимися слабостями процесса.

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

Лучше всего обеспечен данными Гудхарт. Покрытие как KPI было провалом ещё до ИИ, а ИИ делает его катастрофическим. Замена покрытия на mutation score, время онбординга и способность объяснить модуль остаётся самой доказательной частью любых практических рекомендаций.

Картина не симметрична по типам работы. Greenfield, прототипы и изолированные модули с быстрой обратной связью это реальная зона пользы. Тезис применим к зрелым системам с большим accidental‑капиталом, медленной обратной связью и невыделенными границами модулей.

«ИИ как амплификатор» из DORA 2025 это ключевой нюанс, который стоит держать в любой рамке. ИИ не вызывает распад в вакууме, он ускоряет и проявляет то, что уже есть. Команда со зрелым процессом получает прирост. Команда без него получает «размазанную посредственность» как ускоренную версию собственных слабостей.

Почти все крупные источники по теме вендорские, кроме METR и академических работ. Это не дисквалификация, но при цитировании честно показывать отдельно независимые свидетельства (METR, Inozemtseva, Just, Lee, Asdaque) и вендорские (GitClear, GitHub, DORA, Faros, Apiiro, Veracode). Направление у них чаще совпадает, чем расходится, и в отсутствие длинных продольных исследований это лучшая опора, которая есть.

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

Источники по типам

Рецензируемое и контролируемое (независимое):

  • Becker, Rush, Barnes, Rein (METR). Measuring the Impact of Early-2025 AI on Experienced Open‑Source Developer Productivity. arXiv:2507.09089, июль 2025.

  • Inozemtseva, Holmes. Coverage is not strongly correlated with test suite effectiveness. ICSE 2014.

  • Just, Jalali, Inozemtseva, Ernst, Holmes, Fraser. Are Mutants a Valid Substitute for Real Faults in Software Testing? FSE 2014.

  • Petrović, Ivanković, Fraser, Just. Does mutation testing improve testing practices? ICSE 2021.

  • Lee, Sarkar, Tankelevitch, Drosos, Rintel, Banks, Wilson (Microsoft Research и CMU). The Impact of Generative AI on Critical Thinking. CHI 2025.

  • Asdaque и соавторы. Novice Developers Produce Larger Review Overhead for Project Maintainers while Vibe Coding. arXiv:2602.23905, MSR 2026.

  • Bainbridge. Ironies of Automation. Automatica 19(6), 1983.

  • Brooks. No Silver Bullet.

  • Feathers. Working Effectively with Legacy Code.

Большие телеметрии с открытой методологией (с вендорским интересом):

  • DORA 2024, Accelerate State of DevOps Report, Google.

  • DORA 2025, State of AI‑assisted Software Development, Google.

  • GitClear, Coding on Copilot (2024), AI Copilot Code Quality (2025), обновление 2026.

  • Faros AI, AI Productivity Paradox (2025), AI Engineering Report (2026).

  • Apiiro, 4x Velocity, 10x Vulnerabilities (2025).

  • Veracode, 2025 GenAI Code Security Report и обновление за октябрь 2025.

  • CodeRabbit, анализ читаемости (2025).

Опросы и качественные данные:

  • Stack Overflow Developer Survey 2025 (около 49 тысяч респондентов).

  • Кейсы DORA 2025 (Adidas, Booking).

  • Качественные обобщения про comprehension debt. Не первичные доказательства, но полезны как формулировки.

Вендорские success stories (читать с двойной осторожностью):

  • GitHub Copilot, 55% (2022, GitHub про GitHub, arXiv:2302.06590).

  • ANZ Bank совместно с GitHub.

  • Accenture совместно с GitHub.

  • ZoomInfo совместно с GitHub.

ссылка на оригинал статьи https://habr.com/ru/articles/1053830/