В агентской разработке легко попасть в ловушку «еще одного промпта» (One More Prompt) перед финализацией. Я уже некоторое время работаю с агентами и несколько раз сам оказывался в этой ситуации, прежде чем понял, как ее избежать. Когда агенты так легко помогают что-то исправить, появляется соблазн без особой причины раздувать scope задачи.
В этом материале я покажу, как я реализовывал post-editor для функции записи Xcode Simulator в RocketSim. Запись экрана Simulator — один из самых популярных сценариев использования, поэтому я решил еще сильнее развить эту возможность. При этом скоуп был определен достаточно четко, хотя сама фича явно не из тех, что пишутся в пару строк.
Понимание сценария «еще одного промпта»
Прямо перед обедом, перед тем как сварить себе кофе или выйти погулять с собакой, у меня возникает одна и та же мысль:
«Давай отправлю еще один промпт, чтобы к моему возвращению уже было что посмотреть».
Вот несколько типичных ситуаций, которые теперь случаются у меня почти каждый день с тех пор, как я перешел на агентную разработку. Любое исправление находится буквально в одном промпте.
И в то же время по ходу разработки я постоянно натыкаюсь на баги или возможности что-то улучшить. Раньше на ручное исправление такого у меня ушло бы примерно 30 минут, а теперь я могу объединить все это в один planning prompt и закрыть сразу.
Так зачем откладывать исправление?
В итоге — огромный pull request
Так всё и началось. Я работал над пост-обработкой для скриншотов и видео. Получилось, кстати, довольно круто (если хотите протестировать его, можно присоединиться к бете RocketSim здесь).
Раньше этого экрана вообще не существовало. Я связал в нём большое количество уже существующей логики, добавил новое окно редактирования и внедрил всевозможные оптимизации производительности, чтобы можно было менять стили прямо во время воспроизведения видео в реальном времени.
Первая ошибка, которую я допустил, — я разрабатывал всё это целиком в одной feature-ветке. Да, я запускал worktree-результаты в отдельные ветки (например, feature/video-editor с таргетом в epic/post-editor), но недостаточно внимательно просматривал все изменения. Мысль в духе «если работает — значит, нормально» слишком уж часто казалась мне убедительной.
В результате получился гигантский PR:
Этот огромный pull request содержит множество изменений в файлах — типичный результат агентской разработки.
13 758 добавленных строк и 1 057 удалённых — это просто слишком много.
При этом я ещё и откладывал другие изменения, потому что сначала хотел влить этот массивный набор правок в основную ветку.
Хотя скоуп задачи был определён достаточно хорошо, я просто продолжал писать новые промпты. Мне всё время казалось, что я уже почти у цели и нужен всего лишь еще один промпт. Но реальность была другой: мои «100% готовности» на самом деле были лишь 80%, а оставшиеся 20% пришлось добивать множеством отдельных промптов.
Чему я научился: нужно по-другому определять задачу
Фичу я продумал достаточно подробно. Более того, я даже завёл отдельные ветки, которые были нацелены в основную feature-ветку (feature/capturing-editor-refactor на скриншоте выше как раз и была этой основной веткой).
Но когда я добрался до финального результата и начал его тестировать, выяснилось, что многое либо работает недостаточно быстро, либо выглядит не так, как я изначально представлял себе финальное состояние. Да, на промежуточных этапах всё часто выглядело хорошо, но последние промпты нередко приносили больше поломок, чем пользы. Главная причина была в том, что я не тратил достаточно времени на внимательное ревью кода. Вторая — в том, что по пути накопилось слишком много крупных PR.
Как огромный PR стал источником вдохновения
Любопытно, что в итоге неудачный опыт всё же дал полезный результат. У меня остался большой PR, который стал для агентов своего рода референсом: из него можно было брать изменения как ориентир. В какой-то момент я решил полностью пересобрать фичу и начать с нуля.
Цель была простой: быстрее доставлять изменения в основную ветку и действительно считать задачу завершённой, а не почти завершённой. Часть PR затрагивала production-код, а часть просто заранее готовила кодовую базу к следующим шагам.
Я вручную просматривал в GitHub каждый отдельный файл и мержил PR только в тех случаях, когда изменения действительно выглядели надёжно. Это помогло мне намного лучше понять, что именно меняется в коде, и дало больше уверенности в финальном результате. Парадоксально, но агентское кодирование слишком легко расслабляет в вопросах строгого ревью. Я это понял на собственном опыте.
В итоге вместо одного огромного PR у меня стало быстро появляться много небольших и понятных PR.
Обзор небольших PR, которые мержились напрямую в основную ветку
Каждый раз, когда я запускал нового агента, я просил его отталкиваться от текущего состояния main и сравнивать его с большой веткой, которая служила референсом:
«Проанализируйте нашу основную ветку и сравните её с feature/capturing-editor-refactor. Найдите самое незначительное следующее изменение, которое мы можем скопировать. Не копируйте вслепую, анализируйте изменения в коде, упрощайте и сводите технический долг к минимуму«.
Смысл такого промпта, думаю, очевиден. Я использовал его в planning mode, а затем уже решал, какие изменения действительно стоит брать. Некоторые PR оказывались совсем небольшими — например, они содержали только добавление public модификаторов. Такие изменения ревьюить очень легко. Да, все они уже присутствовали в большом PR, но после разбиения на отдельные PR их стало намного проще воспринимать как завершённые задачи.
Полностью уйти от крупных PR всё равно не получилось
Несколько «больших PR» у меня всё равно появились. Конечно, всё зависит от того, что именно считать большим, но для меня PR на 20+ файлов и несколько сотен строк кода — это уже серьёзный объём. Но здесь было важное отличие: каждый такой PR был посвящён одной конкретной задаче. Благодаря этому ревью стало заметно проще. Я отмечал каждый файл в GitHub как Viewed, и все последующие итерации сразу выделялись как новые, непросмотренные изменения. Это дало очень удобный и эффективный процесс, который помогал уверенно двигаться дальше.
Главный вывод: стоит пересмотреть саму идею «еще одного промпта»
Главный вывод для меня — нужно заново осмыслить сам подход к One More Prompt.
- Если это баг, который существовал ещё до текущей задачи
→ вынеси его в отдельный PR - Если это улучшение, без которого можно обойтись прямо сейчас
→ тоже вынеси его в отдельный PR
Другими словами, иногда лучше завершить текущую задачу в рамках текущего агентского контекста, а «еще один промпт» перенести в следующий. Так можно быстрее по-настоящему закрывать задачи, не отказываясь от нужных исправлений. Разница в том, что каждую отдельную правку делает отдельный агент, а значит, и PR получается более сфокусированным — а следовательно, и гораздо более удобным для ревью.
Заключение
Агентская разработка приносит с собой новые подходы к работе и новые вызовы. Я разрабатываю приложения с 2009 года — и как инди-разработчик, и в составе команд. Но даже при таком опыте мне пришлось пересмотреть свои привычные потоки, чтобы работать эффективнее в сегодняшней среде разработки.
Все описанные здесь подходы — только отправная точка и лишь часть того, что я разбираю в своем специализированном курсе Agentic Coding Fundamentals for Developers.
Увидимся?