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

Это не единичный случай. Мы наблюдаем тренд:

• ИИ помогает джунам писать код быстрее, но перекладывает нагрузку на сеньоров;

• ИИ не понимает архитектуру проекта и принятые в команде подходы;

• создаёт иллюзию скорости — код написан быстро, но требует много правок;

• один и тот же тип ошибок повторяется от задачи к задаче.

В некоторых командах мы видели замедление delivery и выгорание сеньоров при активном использовании ИИ-генерации без контроля качества. Разработчик может быть отличным специалистом, но если он бесконтрольно использует ИИ без глубокого понимания контекста разработки, то ИИ превращается в генератор технического долга.

Я Артем Герасимов, владелец продукта SimpleOne SDLC, и в этой статье я расскажу, как использование ИИ для генерации кода может незаметно превратить senior-разработчиков в уборщиков чужого кода, и что с этим делать.

Отдельную благодарность за помощь в написании статьи выражаю автору SimpleOne Панфиловой Яне.

Как понять, что ИИ создаёт технический долг: три источника данных

Самое коварное: ИИ-долг маскируется под повышение продуктивности. Кажется, что код пишется быстрее, задачи закрываются активнее. Но реальная картина проявляется позже — в росте времени на ревью, в инцидентах на продакшне, в том, что модули с ИИ-кодом никто не хочет поддерживать.

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

1. Метрики code review

Первый и самый очевидный индикатор — что происходит на этапе ревью кода:

• сравнивайте время ревью для ИИ-кода и обычного — если ИИ-код требует значительно больше времени, это признак проблемы;

• отслеживайте количество итераций на пулреквест — рост числа правок указывает на низкое качество генерации;

• фиксируйте связь между ИИ-модулями и инцидентами в продакшне;

• измеряйте плотность дефектов в модулях с ИИ-кодом.

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

2. Поддержка и инциденты в ITSM

Второй источник данных — система управления инцидентами и задачами:

• связь инцидентов с ИИ-модулями через интеграцию ITSM-SDLC;

• KEDB (база знаний об известных ошибках) показывает повторяющиеся проблемы в одних модулях;

• MTTR для ИИ-модулей выше среднего;

• учащаются срочные релизы для исправления ИИ-кода.

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

3. Сами разработчики

Третий и самый важный источник — обратная связь от команды:

• сеньоры видят архитектурные проблемы, которые метрики не покажут;

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

• на ретроспективах звучат жалобы на одни и те же модули или типы задач;

• повторяющиеся проблемы указывают на системные ошибки ИИ-генерации.

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

Кстати, мы не в первый раз пишем о ИИ в разработке. О том, как мы научились дружить с ИИ читайте в нашей статье на Хабре. 

Чеклист: на что смотреть при ревью ИИ-кода

Мы собрали типичные проблемы, которые встречаются в ИИ-сгенерированном коде раз за разом.

Этот чеклист можно использовать как дополнение к обычному code review:

• дублирование существующих утилит и хелперов проекта (ИИ не знает, что в проекте уже есть formatDate() или convertCurrency());

• несоблюдение принятого в команде нейминга (смешение camelCase и snake_case, разные имена для одной сущности);

• игнорирование принятых архитектурных паттернов (например, прямой доступ к БД вместо Repository);

• отсутствие проверок граничных условий и edge cases;

• избыточная сложность — ИИ часто генерирует «универсальное» решение там, где нужно простое;

• отсутствие или формальные тесты, которые не покрывают реальные сценарии;

• хардкод значений, которые должны браться из конфигурации проекта.

Если на ревью вы регулярно ловите 3+ пункта из этого списка — скорее всего, разработчик вставляет ИИ-код без адаптации к проекту.

Как встроить управление ИИ-долгом в процесс разработки

Проблема не в том, что ИИ плох — просто у вас нет системы управления последствиями его использования. Разберём на примере гипотетической финтех-компании, как можно выстроить эту систему.

Представим команду из 12 человек (2 senior, 4 middle, 3 junior разработчика, 2 тестировщика и владелец продукта), которая разрабатывала платформу для автоматизации кредитных процессов.

Шесть месяцев назад команда начала активно использовать ИИ для ускорения разработки. Junior и middle разработчики генерировали код через Claude и ChatGPT, задачи закрывались быстрее, velocity спринта вырос на 40%. Руководство было довольно.

Но через три месяца появились первые звоночки. Senior-разработчик стал задерживаться на работе — ревью занимало всё больше времени. Тестировщики жаловались на рост количества дефектов. Владелец продукта не понимал, почему при росте velocity время до релиза не сокращается.

Анализ метрик AI vs non-AI пулреквестов за последние два месяца показал

• время ревью: 2ч 15м для ИИ-кода против 45м для обычного;

• итерации до мержа: 4–5 итераций для ИИ-кода против 1–2 для обычного;

• время в тестировании: выросло на 60% из-за увеличения количества дефектов;

• плотность дефектов: 12 дефектов на 1000 строк ИИ-кода против 4 дефектов на 1000 строк обычного кода.

Проблема была в деталях. Разработчики не всегда правили замечания с первого раза — приходилось многократно доуточнять. Например, senior-разработчик оставлял комментарий:

«Нужно использовать паттерн Repository для работы с базой данных»

Разработчик правил код, но ИИ генерировал реализацию, которая не учитывала специфику проекта — использовала другие названия методов, не соблюдала принятые в команде соглашения. Приходилось возвращать на доработку снова :(

Один мой знакомый разработчик поделился примером из личного опыта: «Я замучался писать промпты под каждый баг, молясь всем богам, чтобы с фиксом не появился новый баг. Естественно, он там появлялся. Имхо, единственный способ сделать нормально (и то не факт) — с нуля разобрать код, и сделать по-нормальному, где ИИ максимум будет как помощник в разборе кода, или анализе его работы, но никак «инструментом разработки». А то по итогу мы потом остаемся с негативным опытом, правим руками то, что нагенерила ИИ, что по итогу увеличивает время разработки/ нахождения карточки на доске». 

Ещё один пример: модуль расчёта кредитного рейтинга. Junior-разработчик через ИИ сгенерировал код за два дня. Казалось бы, успех. Но на ревью выяснилось:

• рейтинг рассчитывался по общей формуле вместо алгоритма, специфичного для продуктов компании;

• переменные назывались по-разному в разных частях модуля: creditScore, credit_rating, userCreditValue — хотя это одна сущность:

Вот как это выглядело в реальности:

// Что сгенерировал ИИ — три имени для одной сущности
const creditScore = calculateScore(user);
let credit_rating = getCreditRating(userId);
const userCreditValue = fetchCreditData(user.id);

// После рефакторинга — единый стиль, переиспользование утилит
const creditScore = this.creditRepository.calculateScore(user.id);
// credit_rating и userCreditValue удалены — это была одна сущность

Такие вещи кажутся мелочью, но когда модуль разрастается до 2000 строк, поддерживать его становится невозможно.

• код дублировал существующие утилиты для работы с датами и валютами вместо их переиспользования;

• отсутствовали проверки граничных условий, что привело к трем критичным дефектам на продакшне.

Senior-разработчик потратил 8 часов на ревью и правки. Это в четыре раза больше, чем он потратил бы на написание модуля с нуля. Но самое неприятное — после релиза модуль стал источником инцидентов.

Решение 1. Единый бэклог для всех типов задач

Первым шагом команда объединила все задачи в единый бэклог. Вот как это сработало:

• фичи, дефекты, рефакторинг ИИ-кода, техдолг — всё попало в один бэклог, без разделения на отдельные списки или проекты;

• приоритизация начала происходить по единым критериям: ценность для бизнеса, стоимость поддержки, риски для продукта;

• владелец продукта увидел реальную стоимость ИИ-долга в часах разработки и поддержки — задача на рефакторинг проблемного модуля встала рядом с новой фичей;

• команда стала брать задачи сверху бэклога, независимо от типа — сегодня это могла быть фича, завтра рефакторинг ИИ-модуля.

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

Решение 2. Связь ITSM/Service Desk и системы управления разработкой

Вторая проблема: команда не видела связи между инцидентами и проблемными модулями. Инциденты фиксировались в ITSM-системе, код жил в GitLab. Связь между ними отслеживалась вручную, через таблицы, которые никто не обновлял.

Команда интегрировала ITSM- и SDLC-системы, настроила автоматическую связь через теги модулей. Результат оказался показательным:

• модуль расчёта кредитного рейтинга: 8 инцидентов из 10 за последний месяц;

• модуль валидации документов: 6 инцидентов из 10;

• модуль формирования отчётов: 4 инцидента из 10.

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

• инцидент → KEDB → задача на рефакторинг создаётся автоматически;

• видимость: 8 из 10 инцидентов в одном AI-модуле = задача автоматически попадает в топ бэклога;

• владелец продукта видит стоимость в часах поддержки: модуль расчёта рейтинга — 64 часа за месяц.

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

Решение для команды было очевидным: проблемные модули отправились на полный рефакторинг. Senior-разработчик переписал самый критичный модуль за три дня. После релиза количество инцидентов упало с 8 до 1 за месяц, время поддержки сократилось с 64 до 8 часов.

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

Были и откаты. Один из middle разработчиков ушёл — не захотел «возвращаться в каменный век», как он выразился. Несколько задач пришлось вернуть на доработку после того, как команда попыталась полностью отказаться от ИИ — выяснилось, что для рутинных задач он всё-таки полезен, если правильно использовать.

Но самое важное — команда изменила подход. Junior и middle разработчики начали больше времени уделять изучению архитектуры, бизнес-правил и паттернов проекта. ИИ остался инструментом, но перестал быть костылём. Через два месяца velocity спринта вернулся к прежнему уровню, но при этом время ревью сократилось, а количество инцидентов упало на 70%.

Решение 3. Роли и ответственность

Ключевое изменение в команде — смещение фокуса с написания кода на развитие компетенций:

• рост компетенций junior и middle стал основной задачей — они начали больше погружаться в архитектуру и требования к коду, а не только писать код через ИИ;

• сеньоры сосредоточились на архитектуре, а не на правках стиля кода;

• поддержка начала фиксировать инциденты с тегом модуля для автоматической связи с задачами;

• владелец продукта стал приоритизировать на основе метрик из интегрированной системы.

Вместо бесконечного исправления ИИ-кода команда сделала ставку на обучение. Junior и middle начали изучать существующую кодовую базу, участвовать в архитектурных ревью, разбирать чужой код. Цель — научить их думать как senior, а не полагаться на ИИ как на костыль.

Где ИИ реально помогает

Было бы нечестно не сказать: после перестройки процессов команда не отказалась от ИИ. Он остался полезен в задачах, где контекст проекта менее критичен:

• генерация бойлерплейта и CRUD-операций по заданному шаблону;

• написание юнит-тестов по существующему коду;

• рефакторинг и упрощение запутанных функций, когда разработчик объясняет ИИ контекст;

• генерация документации и JSDoc/docstring по готовому коду;

• быстрый прототип для обсуждения подхода, который потом переписывается.

Ключевое отличие: во всех этих сценариях разработчик остаётся «водителем», а ИИ — «навигатором».

Резюме

Если после прочтения вы подозреваете, что ИИ-долг копится и у вас — вот три шага, которые можно начать прямо сейчас:

Неделя 1: замерьте среднее время ревью и количество итераций для ИИ-кода vs обычного. Достаточно поднять последние 20 пулреквестов.

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

Неделя 3: проведите ретро с командой, сфокусированное на одном вопросе: «Какие модули вы не хотите поддерживать и почему?»

ИИ — это не проблема, а инструмент. Проблема возникает, когда скорость написания кода растет быстрее, чем понимание разработчиками архитектуры и бизнес-логики продукта.

Если честно — мы сами всё ещё учимся работать с ИИ-кодом. Проблема не решается за неделю внедрением одного инструмента — это постоянный процесс балансирования между автоматизацией и развитием экспертизы команды.

Что помогает держать баланс:

• интеграция ITSM и SDLC — чтобы видеть реальную стоимость ИИ-долга;

• единый бэклог — чтобы приоритизировать рефакторинг наравне с фичами;

• фокус на росте компетенций — чтобы разработчики понимали не только как написать код, но и почему именно так.

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

А как вы справляетесь с последствиями использования ИИ в разработке?