Поддержка кода, написанного ИИ: кто чинит AI-код в 2026

Почему код, написанный ИИ, дорожает после релиза, а не до

Год назад ко мне приходили с вопросом «сколько вы сэкономите нам на разработке, если посадите агентов». В 2026-м спрашивают другое: «у нас есть сервис, который собрала команда с ИИ, автор ушёл, сервис падает раз в неделю – возьмёте на поддержку?». Это две стороны одной медали. Вторая дороже.

Механика простая. Стоимость строки кода складывается из двух частей: написать и потом с этим жить. Раньше обе части тащили одни и те же люди, и это дисциплинировало. Инженер знал, что через полгода дебажить в ночи будет он сам, поэтому раскладывал логику по модулям и подбирал внятные имена. У генеративного инструмента такой мотивации нет: он выдаёт рабочий фрагмент здесь и сейчас и оптимизирует прохождение проверки, а не десять следующих релизов.

Цифры это подтверждают. GitClear в отчёте по качеству AI-assisted кода разобрал 211 млн изменённых строк за 2020–2024 годы и увидел, что доля строк, связанных с рефакторингом, упала с 25% в 2021-м до менее 10% в 2024-м, а доля copy/paste-кода выросла с 8,3% до 12,3%. В более свежем срезе тенденция продолжилась: дублированные блоки выросли с 40,3 на миллион изменённых строк в 2023 году до 73,0, а доля перемещённого и переиспользованного кода схлопнулась с 21% в 2022-м до 3,8%. Связность нового кода с существующим тоже просела. Это метрики структуры изменений, а не приговор качеству, но направление читается однозначно: система превращается в набор похожих кусков вместо набора переиспользуемых деталей.

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

Что ломается в процессах: ревью, тесты, документация и владелец задачи

Технологии сломали не код. Они сломали контур контроля, который вокруг кода выстраивали годами.

Ревью. Классическое код-ревью рассчитано на человеческий объём: 200–400 строк, за которыми стоит понятная гипотеза автора. Когда в пул-реквест прилетает две тысячи строк, сгенерированных за сорок минут, ревьюер физически не удержит ту же планку. Появляется «одобрение по внешнему виду»: код красивый, тесты зелёные, стиль ровный – апрув. Опаснее всего почти-правильный код, в котором логика верна на 95%, а оставшиеся 5% всплывают на проде через месяц.

Тесты. Если тесты писала та же модель, что и реализацию, они проверяют не требование, а собственную трактовку требования. Зелёный прогон в такой конфигурации означает внутреннюю непротиворечивость, и всё.

Документация. Её стало меньше именно потому, что код «читается легко». Читается – да. Объясняет, почему выбран такой способ округления в расчёте комиссии – нет.

Владелец. Самое дорогое. Когда фичу собрал агент под общим присмотром, на вопрос «кто это делал» команда отвечает «ну, мы». Такое состояние я считаю опаснее любой технической проблемы: у задачи нет фамилии, а значит, нет и того, кто через полгода восстановит контекст за пятнадцать минут.

Недоверие к результату видно и в опросах. Stack Overflow в 2025 году получил 84% разработчиков, которые используют или планируют использовать ИИ-инструменты, и одновременно 46%, которые не доверяют точности их вывода – против 31% годом ранее. В отчёте DORA за 2025-й 90% участников используют ИИ в работе, при этом 30% почти не доверяют сгенерированному коду. Люди работают инструментом, которому не верят. Значит, контур проверки обязан быть внешним и формальным.

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

Как выглядит приёмка AI-кода: чек-лист, который мы используем в CRT

Мы в CRT агентов не запрещаем и не делаем вид, что модуль можно сгенерировать и сразу отдать заказчику. Между генерацией и мержем у нас стоит приёмка. Она съедает время, и это время мы закладываем в оценку сразу, честно.

Что проверяем:

1. Есть владелец задачи – конкретный инженер, который отвечает за фичу на проде, а не «команда».
2. Изменение помещается в один осмысленный пул-реквест. Если генерация выдала две тысячи строк, инженер разбивает их на логические куски и объясняет каждый.
3. Автор рассказывает решение словами: почему такая структура, какие альтернативы отброшены, где границы применимости. Не может объяснить – код не мержится.
4. Тесты пишет или переписывает человек и привязывает их к требованию из аналитики, а не к реализации.
5. Дубли ищем инструментально: статический анализ на copy/paste, проверка, что новый код обращается к существующим модулям.
6. Проверяем работу с данными отдельно: миграции, права доступа, персональные данные и требования ФЗ-152, обработка ошибок внешних интеграций.
7. Секреты, логирование, обработка исключений – отдельный пункт, потому что генерация обожает оставлять заглушки.
8. Наблюдаемость: у фичи есть метрики и алерты до релиза, а не после первого инцидента.

Больше всего денег экономят пункты 4 и 8. На проектах, где мы отвечаем за качество целиком, отдельная QA-линия окупается уже на втором квартале сопровождения – мы разбирали это на практике в QA и тестировании, где проверка идёт независимо от того, кто и чем писал код.

Где ИИ-агенты реально экономят деньги, а где мы их не пускаем

Универсального ответа нет, есть карта зон риска. У нас она примерно такая.

В проектах вроде системы управления процессами судовладельца Femco цена неверной бизнес-логики измеряется простоем флота, а не багом в интерфейсе. Там ускорение осмысленно ровно в тех местах, где ошибку ловит тест.

Что меняется в найме и аутстаффе: какие инженеры нужны команде с ИИ

Рынок труда перестроился быстрее процессов. Раньше мы искали тех, кто пишет код. Теперь – тех, кто умеет три вещи: сформулировать задачу так, чтобы её нельзя было понять двояко, прочитать чужое решение и нащупать в нём слабое место, и взять ответственность за результат на проде.

Отсюда три следствия для найма.

Первое: вырос спрос на инженеров с сильным аналитическим бэкграундом. Постановка стала частью инженерной работы, а не только заботой аналитика.

Второе: сеньоры теперь тратят заметную часть недели на ревью и наставничество. Это надо планировать в загрузке, иначе качество проверки падает ровно тогда, когда объём генерации растёт.

Третье: джунов по-прежнему нужно растить, но иначе. Если новичок только принимает предложения агента, он не набирает опыт отладки – а именно отладка через три года делает из него того, кто разгребает инциденты.

В аутстаффе изменился и запрос клиентов. Раньше просили «плюс два фронтендера». Сейчас чаще просят инженера, который наведёт порядок в процессе: настроит приёмку, ревью и тесты вокруг команды, уже работающей с ИИ. Такие задачи мы закрываем через IT-аутстаффинг, и по опыту первые два месяца человек занимается не фичами, а контуром вокруг них.

Сколько стоит сопровождение: как считать экономику AI-разработки на горизонте года

Считать экономию только по часам разработки – самообман. Полная формула на горизонте 12 месяцев выглядит так:

• часы генерации и доводки;
• часы ревью и приёмки (в проектах с активными агентами это заметная величина, а не округление);
• стоимость инцидентов: время на разбор, простой бизнеса, коммуникация с клиентами;
• переписывание – доля кода, которую пришлось выбросить или существенно изменить в течение месяца после релиза;
• стоимость входа нового человека в проект. Если онбординг вырос с двух недель до шести – это прямые деньги.

Метрики, которые мы смотрим на проектах с ИИ: доля строк, переписанных в первые две недели после мержа; количество дублированных блоков на тысячу строк; время восстановления после инцидента; доля пул-реквестов, вернувшихся с ревью с содержательными правками. Последняя показательна. Если она близка к нулю, ревью формальное, и я иду разбираться с процессом, а не радоваться красивому графику.

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

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