Разработчик описал, как взялся за Java-монолит примерно на 2000 классов и 120 тысяч строк кода, который шесть лет писала команда из двух–пяти человек. Останавливать выпуск новых функций ради рефакторинга не разрешили, поэтому исправлять проект пришлось на ходу.

Первые две недели ушли на диагностику, а не на исправления. Claude готовил отчёты по отдельным аспектам проекта: безопасности и публичным точкам доступа API, покрытию тестами и политике использования заглушек, многопоточности, неизменяемым структурам данных, работе с внешними HTTP-сервисами и персональным данным.

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

Первой линией защиты стали архитектурные тесты на базе библиотеки ArchUnit. Они задали слоистую архитектуру: запретили вызовы из нижних слоёв в верхние, обращения к базе данных из контроллеров и сервисов и вызовы сервисов из бизнес-слоя. Чтобы не ломать сборку старым кодом, каждый тест получил список исключений для существующих классов и методов, но новые нарушения блокируют сборку.

Поверх слоёв добавили точечные запреты: постепенную миграцию на Java records и отказ от новых изменяемых DTO, разделение перегруженных сервисов, а также запрет отдавать клиентам DTO базы данных с внутренними состояниями и персональными данными. Перед этим GraphQL-схему заморозили, чтобы рефакторинг не сломал контракт с клиентской частью.

За первые два месяца работы число тестов выросло с 700 до 6800. Для модели написали руководство по интеграционным сквозным тестам с настоящей базой данных и кэшами и по мутационным проверкам, а тесты фиксировали текущее поведение, даже ошибочное, и помечали такие места для будущих решений. Раз в две недели анализировали быстродействие тестов, попутно понадобились собственная очередь слияния и собственные раннеры GitHub Actions.

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