Технический долг в эпоху генеративного кода

Есть один разговор, который я веду с людьми из моего окружения всё чаще. Выглядит он примерно так: «мы за три недели собрали MVP, всё работает, теперь нужно это поддерживать». А дальше выясняется, что MVP писал агент, код никто толком не ревьюил, тестов нет, архитектура — это громкое слово для того, что там происходит. И теперь они смотрят на меня с выражением человека, который только что понял, что влип.

Технический долг существовал всегда. Но раньше он накапливался медленно — пропорционально скорости, с которой люди могли писать код. Теперь этот предохранитель сломан.

Агент не устаёт. Агент не говорит «давай отложим рефакторинг на следующий спринт». Агент пишет столько кода, сколько ты у него просишь — и делает это быстро, уверенно и с минимальным сопротивлением. Именно в этом и проблема. Сопротивление в разработке — это не баг процесса, это сигнал. Когда тебе сложно написать функцию, потому что она делает слишком много — это сигнал. Когда тест не пишется, потому что непонятно, что именно проверять — это сигнал. Агент эти сигналы не слышит. Он просто продолжает.

Я видел репозитории, которые за месяц работы с агентом выросли в объёме в четыре раза. Новые файлы, новые модули, новые абстракции поверх старых абстракций. С первого взгляда — солидно. Со второго — страшно, потому что никто в команде не может объяснить, почему вот эта часть устроена именно так. Агент принял решение. Оно казалось разумным в моменте. Теперь это просто данность, которую трогать боятся.

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

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

Что с этим делать? Я пришёл к нескольким вещам, которые реально помогают. Первое — тесты до кода, не после. Это не новая идея, но с агентами она становится критической, а не просто хорошей практикой. Если у тебя есть тесты, агент ограничен в своей фантазии: он должен сделать так, чтобы они проходили. Это сужает пространство плохих решений. Второе — ревью не как формальность, а как единственный момент, когда ты реально понимаешь, что происходит в репозитории. Если ты мёржишь, не читая — ты не знаешь, что у тебя в продакшне. Третье — периодически спрашивать себя: а смогу ли я объяснить эту часть кода новому человеку? Если нет — это уже долг, вне зависимости от того, кто его написал.

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

Технический долг в эпоху агентов — это не про плохой код. Это про решения, которые никто не принимал осознанно.