Все восторженные демо сняты на пустом проекте: «сделай мне приложение» — и
через десять минут работает. В чужом коде на двести тысяч строк тот же агент
ведёт себя иначе, и это не потому, что вы что-то делаете не так.
Легаси здесь — не ругательство. Это любой код, который писали не вы, писали
долго и по причинам, которые нигде не записаны.
Проект не влезает в окно. Агент физически не может прочитать всё и
работает по кусочку, который успел увидеть. Отсюда решения, разумные локально
и дикие в масштабе проекта.
Соглашения не выводятся из фрагмента. В четырёх местах сделано
по-разному, потому что так исторически сложилось. Модель выберет то, что чаще
встречалось в обучении, а не то, что принято у вас.
Причины утеряны. Странный код обычно странный не просто так: за ним стоит
баг у клиента, требование регулятора или чужое API, которое врёт. В коде
этого нет. Модель видит только странность — и радостно её «упрощает».
Нет обратной связи. Тестов мало, сборка долгая, поведение проверяется
руками. Агент работает вслепую, а цена ошибки уже
настоящая.
Побочные эффекты повсюду. Функция, которая по имени что-то считает, по
дороге пишет в базу и шлёт письмо. Это ловится только чтением.
Самая частая ошибка — начать с «отрефактори вот этот модуль». Начинать надо с
вопросов.
Что хорошо работает:
orders.»Поиск и чтение — то, в чём агент сильнее человека: он не устаёт грепать и
проходит по всем вызовам, а не по первым трём.
Пересказ проверяйте по коду. Уверенность модели не зависит от того, права
она или нет: правдоподобная схема, в которой один шаг выдуман, выглядит
ровно так же, как верная. Ошибка на этом этапе дороже всех остальных — вы
положите её в основу решения.
Побочная польза: из разведки получается первая версия файла
проекта. Пусть агент напишет черновик, а вы вычеркнете
враньё и допишете причины, которых он знать не мог.
Порядок именно такой, и он экономит недели.
Характеристические тесты. Не «правильное поведение», а снимок текущего:
что система делает сегодня, включая странности. Задача такого теста — не
одобрить поведение, а заметить, что оно изменилось. Агент пишет их хорошо:
работа механическая, а примеры входов и выходов можно взять из логов.
Одна команда проверки. Даже если она гоняет три теста из трёхсот
возможных — она должна быть и должна быть быстрой.
Только после этого — правки. Теперь у агента есть чем себя проверить, а у
вас — чем поймать регресс.
payments так же, как сделано для orders, вотМассовое переформатирование, «унификация стиля» по всему дереву, авто-
рефакторинг через сотню файлов, обновление всех зависимостей пачкой. Такой
диф невозможно прочитать, а настоящая ошибка в нём прячется идеально.
Ещё две ловушки, специфичные именно для чужого кода:
Удаление «мёртвого» кода. Модель уверенно сносит то, что не нашла по
имени, — а оно вызывается через рефлексию, из конфига, из крона, из
миграции или чужим сервисом. Правило: удаление неиспользуемого — отдельная
задача, отдельный коммит и проверка руками.
Улучшения по дороге. Просили починить баг — заодно переименованы
переменные, подтянут стиль и «немного улучшена» соседняя функция. Смешанный
диф невозможно ревьюить и невозможно откатить по частям. Проговаривайте
явно: только то, о чём просили.
Честный список, чтобы ожидания были верными:
| Задача | Как идёт |
|---|---|
| Разобраться, как это работает | сильно быстрее человека |
| Найти все вхождения, все вызовы | сильно быстрее |
| Однотипные правки по образцу | быстрее, качество ровное |
| Написать тесты на существующее | быстрее |
| Обновить API-вызовы под новую версию | быстрее, но требует вычитки |
| Понять, почему так сделано | не поможет: этого нет в коде |
| Архитектурное решение | не отдавать; это ваша работа |
| Снос легаси целиком | худшая из идей |
Агент ускоряет и создание технического долга. В зелёном проекте это заметно
через месяц, в легаси — сразу: свежий слой поверх старого, написанный по
другим правилам и без понимания причин, делает код ещё менее объяснимым.
Поэтому в чужом проекте ценность файла с соглашениями и привычки читать диф
выше, чем где бы то ни было.