Недавно один из наших клиентов столкнулся с неожиданной ситуацией: пришлось расстаться с мидл-разработчиком, который активно использовал ИИ для генерации кода, но при этом не погружался в бизнес-логику проекта. Каждый его пулреквест превращался в марафон правок для 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 — хотя это одна сущность:
Вот как это выглядело в реальности:
Такие вещи кажутся мелочью, но когда модуль разрастается до 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 — чтобы видеть реальную стоимость ИИ-долга;
- единый бэклог — чтобы приоритизировать рефакторинг наравне с фичами;
- фокус на росте компетенций — чтобы разработчики понимали не только как написать код, но и почему именно так.
Это не быстро, это не просто, и у каждой команды свой путь. Но альтернатива — выгорание сеньоров, накопление технического долга и команда, которая умеет только генерировать код, но не понимает, что делает.
А как вы справляетесь с последствиями использования ИИ в разработке?
