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

Чтобы не гадать, насколько можно доверять сгенерированному коду, нужны инструменты контроля качества. Есть четыре практики, которые помогут проверить качество уже сейчас.

Строгая типизация и линтеры

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

Агент, который знает, что его код пройдёт через TypeScript или pylint, пишет аккуратнее, особенно если правила проверки прописаны в style guide проекта. Сам style guide — это отдельный файл. Там зафиксированы соглашения о нейминге, форматировании и архитектурных ограничениях. Агент подчиняется ему удивительно хорошо, если правила сформулированы четко и без противоречий.

Чек‑листы

Агент может терять фокус на больших задачах. Эту проблему решает чек‑лист: каждый этап работы привязан к списку конкретных пунктов. Их нужно выполнить и отметить как завершённые. Например, при реализации базы данных чек‑лист может включать: поддержку команд SET и GET, обработку TTL, персистентность на диск, нагрузочное тестирование, проверка утечек памяти.

Агент проходит по списку и отчитывается, что сделано. Это не даёт ему объявить задачу выполненной, если не закрыты все пункты.

Имеет значение и размер чек‑листа — слишком длинные списки агент начинает игнорировать. Лучше разбивать работу на этапы с короткими чек‑листами по 5–7 пунктов.

Мутационное тестирование

Обычные тесты проверяют, что код работает. Мутационные тесты проверяют, что тесты действительно что‑то проверяют. Идея простая: вы (или другой агент) намеренно ломаете код, например, меняете знак в условии, подставляете пустой массив вместо данных, убираете вызов функции — и запускаете тесты. Если тесты продолжают проходить, значит, они написаны формально и не защищают логику. Такие тесты нужно переписывать.

Агента можно попросить сгенерировать мутационные тесты автоматически. Часто при этом вскрываются неочевидные проблемы, которые не нашли бы при обычном тестировании. Это особенно полезно для кода, сгенерированного LLM: модель может случайно инвертировать условие, и мутационный тест покажет, что существующие тесты этого не заметили.

BDD и TDD

Behavior‑Driven Development и Test‑Driven Development — это способы заставить агента думать о результате до того, как он начнёт писать код. В BDD сценарии описываются на языке «Given — When — Then»: какой пользователь, какое действие, какой результат.

Агент получает эти сценарии и пишет код, который должен им соответствовать. В TDD агент сначала пишет падающий тест, а потом код, который этот тест проходит.

Правда, с LLM есть нюанс: она иногда пытается смухлевать и написать пустую функцию. Та возвращает ожидаемое значение теста. Поэтому правило «сначала тест» должно подкрепляться проверкой.

Что в итоге

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

Коротко о главном

  • Качество AI‑кода зависит не от модели, а от инженерных практик вокруг неё.

  • Строгая типизация и style guide создают детерминированные рамки, которые агент не может обойти.

  • Чек‑листы не дают агенту закрыть задачу, пока она не выполнена полностью.

  • Мутационное тестирование вскрывает слабые тесты и неочевидные логические ошибки, которые пропускают обычные проверки.