GitClear: AI acelera os releases de código, mas aumenta a 'dívida de compreensão' e os riscos ocultos

ИИ-ассистенты ускоряют разработку, но всё чаще оставляют после себя код, который формально работает, а по сути никем не понят. На это указывают и данные GitClear, и опыт команд, которые обнаружили новый скрытый риск — «долг понимания».

Что нашёл

GitClear В исследовании GitClear 2025 года проанализировали 211 миллионов изменённых строк кода за 2020–2024 годы. Главный сигнал: code churn, то есть строки, переписанные в течение двух недель после коммита, по сравнению с до-ИИ базой 2021 года фактически удвоился. Одновременно просела доля рефакторинга и повторного использования кода, а дублирование стало встречаться чаще, чем раньше.

Проще говоря, команды производят больше кода, но значительная часть этого объёма быстро возвращается на доработку. Это важно не только как метрика качества, но и как управленческая проблема. В марте 2026 года инженер Google Addy Osmani описал это как comprehension debt — разрыв между объёмом кода в системе и объёмом кода, который команда реально понимает.

Внешне всё выглядит нормально: CI зелёный, покрытие не падает, PR мержатся быстрее. Но при первом нетипичном инциденте выясняется, что никто не может быстро объяснить, почему логика устроена именно так.

«ИИ генерирует код быстрее, чем люди успевают его оценить».

Почему тесты подводят

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

Но он может не проверить отсутствие order_id, повторную доставку события, новый статус в API платёжки или ситуацию, когда система возвращает 200, хотя заказ вообще не найден. Такие тесты создают ложное чувство надёжности. Они увеличивают coverage, красиво выглядят в отчётах и позволяют быстрее закрывать задачи, но не заменяют понимание доменных ограничений и граничных случаев.

Это особенно заметно в новых технологиях. В январе 2026 года Anthropic опубликовала эксперимент с 52 разработчиками Python, которые изучали библиотеку Trio: группа с ИИ-помощником показала результат на 17% хуже в тесте на понимание, чем группа без ИИ. При этом лучше остальных выступали не те, кто делегировал код целиком, а те, кто использовал модель для вопросов «почему» и «что произойдёт, если».

Как снижать риск Практика показывает, что сам по себе ИИ не гарантирует ни провала, ни успеха.

Решающим становится процесс вокруг него. Если команда принимает огромные PR, не требует объяснений и считает зелёные тесты достаточным основанием для merge, она почти неизбежно накапливает код, который трудно поддерживать. Если же стандарты ревью остаются жёсткими, ИИ начинает приносить пользу без резкого роста хаоса.

• Делить большие изменения на маленькие PR, которые реально можно прочитать и обсудить Требовать от автора объяснения решений и явно фиксировать допущения по бизнес-логике Писать тесты до реализации или хотя бы отделять проверку намерения от проверки сгенерированного happy path * Добавлять модульные правила, автоматические проверки и актуальную документацию, чтобы ИИ работал в рамках контекста проекта Парадокс в том, что ИИ может быть не только источником проблемы, но и инструментом её решения. Те же модели неплохо объясняют старый легаси-код, помогают найти забытые условия и подсветить слабые места в архитектуре. То есть «код без автора» существовал и раньше, просто ИИ резко поднял объём изменений и сделал этот долг заметным уже не через годы, а почти сразу после merge.

Что это значит Для команд меняется не цель, а критерий качества.

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