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