Долг понимания: новый вид технического долга
Долг понимания: новый вид технического долгаКод компилируется.
Тесты проходят.
PR смержен.
Фича работает.
Формально всё хорошо. Но через несколько месяцев выясняется, что никто в команде толком не понимает, почему решение устроено именно так.
С AI попасть в эту ситуацию стало проще.
Разработчик ставит задачу агенту. Агент исследует кодовую базу, предлагает реализацию, пишет тесты и исправляет ошибки. Результат выглядит убедительно, поэтому хочется проверить только внешнее поведение:
Работает?
Работает.
Значит, можно принимать.
Проблема проявится позже, когда изменятся требования. Тогда окажется, что команда не знает:
— какие предположения заложены в решение;
— почему выбран именно этот подход;
— какие альтернативы были отброшены;
— где находятся скрытые ограничения;
— что сломается при следующем изменении.
Я бы назвал это долгом понимания.
Обычный технический долг часто появляется как осознанный компромисс: сейчас делаем проще, потом переделаем.
С долгом понимания хуже. Команда может даже не знать, что компромисс существует. Код уже стал частью системы, а объяснение осталось где-то в истории диалога с агентом.
Особенно опасно принимать таким образом сложную бизнес-логику, инфраструктурный код, concurrency, безопасность, нетривиальные оптимизации и архитектурные изменения.
Поэтому правила «тесты зелёные» уже недостаточно.
Перед merge я бы добавил ещё одну проверку:
Могу ли я объяснить это решение другому инженеру без открытия истории диалога с AI?
Почему код устроен именно так? На каких предположениях он держится? Где его границы? Что придётся пересмотреть при изменении требований?
Если ответов нет, код может быть рабочим. Но ownership над ним у команды ещё не появился.
AI делает создание кода дешевле. Значит, понимание этого кода становится дороже и ценнее.