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