AI-кодинг в разработке дает не тот эффект, который удобно показывать на слайдах: у активных пользователей AI-инструментов выпуск кода вырос на 25%, зато дублирование блоков поднялось на 81%. По данным The New Stack, свежий анализ GitClear превращает разговор об «ускорении разработчиков» в менее приятный вопрос: кто потом будет сопровождать весь этот быстро сгенерированный код.
Материал Стива Фентона опирается на отчет GitClear Maintainability Gap, опубликованный в июне 2026 года. В выборке — 623 млн изменений кода за период с 2023 по 2026 год. GitClear отслеживал операции изменения кода, дублирование, «горячие» участки и признаки удачного или плохого факторинга. Это не опрос в духе «стало ли вам веселее писать код с ассистентом», а попытка посмотреть на следы, которые AI оставляет в репозиториях.
Главная цифра выглядит двусмысленно. Команды и разработчики, активно использующие AI-среды и помощников вроде Cursor и Claude Code, действительно ускорились: плюс 25% к собственной прежней скорости изменений. Но это далеко от любимого рынком мифа про 10-кратный рост. При этом GitClear увидел, что самые продуктивные AI-пользователи обгоняют команды без AI в 4-10 раз. Фентон делает важную оговорку: эти команды были сильнее еще до массового прихода AI-инструментов. Иными словами, инструмент усилил тех, кто уже умел строить процесс, а не magically fixed everything.
Проблема начинается там, где менеджмент считает строки кода, pull request’ы или количество закрытых задач хорошей заменой ценности для бизнеса. Быстрее набросать изменения — не то же самое, что быстрее довести фичу до пользователя, снизить инциденты или ускорить поставку продукта. Часть выигрыша съедают ревью, тестирование, исправление побочных эффектов и будущая поддержка. Если компания до закупки AI-подписок не понимала собственный value stream, после закупки ей будет просто дороже не понимать.
Самая неприятная часть отчета — качество. Дублирование блоков кода выросло на 81% по сравнению с 2023 годом: с 40,3 до 73,0 случая на миллион измененных строк. Перемещенный код, который GitClear использует как один из признаков рефакторинга, упал с 21% измененных строк в 2022 году до 3,8% в 2026-м. Это похоже не на инженерную зрелость с новым инструментом, а на откат к режиму «написал, починил, забыл, повторил».
Для разработчиков это звучит знакомо до зубовного скрежета. Два одинаковых фрагмента сегодня — это две расходящиеся версии бизнес-логики завтра. Потом появляется баг, его чинят в одном месте, забывают во втором, получают странное поведение на проде и называют это «исторически сложилось». AI в таком сценарии работает как очень быстрый младший разработчик без усталости и с опасной уверенностью: он помогает произвести больше кода, но не гарантирует, что код будет проще менять.
Фентон напоминает, что до AI разработчики чаще выбирали рефакторинг вместо копирования: примерно два к одному. Теперь, по его пересказу данных GitClear, они примерно в пять раз чаще идут в копипаст. Это важный сдвиг поведения. Не потому, что копирование само по себе смертный грех, а потому что массовая генерация похожих решений быстро раздувает стоимость сопровождения. Сначала команда радуется скорости. Через несколько кварталов новые фичи начинают вязнуть в связанных кусках логики, тесты становятся хрупкими, а исправления требуют все больше контекста.
Рынок уже начал считать деньги. The New Stack связывает эту дискуссию с более широким охлаждением вокруг расходов на AI: Rippling добавила консоль контроля AI-затрат для CFO и CTO, а вице-председатель IBM Гэри Кон говорил, что отдача от AI оказалась «не настолько высокой, как многие могли думать». На этом фоне бюджеты на Claude Code, Cursor и похожие инструменты будут смотреть не только через призму восторгов разработчиков, но и через счета, лимиты и метрики сопровождения.
AI-кодинг в разработке не становится бесполезным от этих цифр. Скорее, он перестает быть индульгенцией. Его сильная сторона может быть не в гонке за прямолинейной скоростью, а в тяжелых операциях: массовых миграциях, замене устаревших библиотек, однотипных изменениях по большой кодовой базе. Но для этого нужны тесты, код-ревью, архитектурные ограничения и метрики здоровья кода. Без них ассистент не ускоряет инженерию, а просто быстрее печатает технический долг.
Для русскоязычных IT-команд вывод прагматичный: закупка AI-инструментов без инженерной дисциплины похожа на покупку спортивной машины для дороги с ямами. Да, по прямой она едет бодро. Но если в команде рефакторинг считается «необязательной задачей», тесты пишутся по остаточному принципу, а качество меряют числом закрытых тикетов, AI-кодинг в разработке лишь подсветит старые проблемы и добавит новых. Следующий спор в компаниях будет не о том, нужен ли AI разработчикам, а о том, кто отвечает за поддерживаемость кода, который он помог произвести.