Долг понимания: новый вид технического долга

Код компилируется.

Тесты проходят.

PR смержен.

Фича работает.

Формально всё хорошо. Но через несколько месяцев выясняется, что никто в команде толком не понимает, почему решение устроено именно так.

С AI попасть в эту ситуацию стало проще.

Разработчик ставит задачу агенту. Агент исследует кодовую базу, предлагает реализацию, пишет тесты и исправляет ошибки. Результат выглядит убедительно, поэтому хочется проверить только внешнее поведение:

Работает?

Работает.

Значит, можно принимать.

Проблема проявится позже, когда изменятся требования. Тогда окажется, что команда не знает:

— какие предположения заложены в решение; — почему выбран именно этот подход; — какие альтернативы были отброшены; — где находятся скрытые ограничения; — что сломается при следующем изменении.

Я бы назвал это долгом понимания.

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

С долгом понимания хуже. Команда может даже не знать, что компромисс существует. Код уже стал частью системы, а объяснение осталось где-то в истории диалога с агентом.

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

Поэтому правила «тесты зелёные» уже недостаточно.

Перед merge я бы добавил ещё одну проверку:

Могу ли я объяснить это решение другому инженеру без открытия истории диалога с AI?

Почему код устроен именно так? На каких предположениях он держится? Где его границы? Что придётся пересмотреть при изменении требований?

Если ответов нет, код может быть рабочим. Но ownership над ним у команды ещё не появился.

AI делает создание кода дешевле. Значит, понимание этого кода становится дороже и ценнее.