Недавно у меня была сессия парного программирования с хорошим товарищем. Получилась классная коллаборация: он пишет код, а я наблюдаю за его флоу и предлагаю оптимизации по части использования агентов. В итоге получился набор советов, как работать с агентом при написании кода.
Мы работали в Cursor, поэтому часть примеров будет применима для него, но в целом подходы применимы к любому агенту для работы с кодом.
Флоу работы
В Cursor есть три ключевых режима: агент, автокомплит и CMD+K – локальный быстрый чат для файла. И именно их сочетание даёт максимальный буст.
Типичный рабочий флоу:
Начинаем с агентом – обсуждаем задачу, формируем решение.
Получаем код, делаем ревью.
Видим локальное место, которое нужно переписать – запускаем локальный чат по CMD+K, даём короткое уточнение, и агент точечно правит именно этот фрагмент.
Когда видим небольшую правку – буквально что-то в строке поправить – просто руками удаляем лишнее и начинаем писать. Часто автокомплит сходу подсказывает то, что нужно.
Комбинируя и чередуя эти инструменты в зависимости от потребности, получаем очень комфортный и быстрый цикл.
Главное – не пытаться долбить агента микроправками. Частые мелкие уточнения убивают весь профит, съедают контекст, ухудшают качество ответов. То, что отлично решает CMD+K или автокомплит, не нужно тащить в общий чат агента.
Не просить сделать всё под ключ
Ничего принципиально нового тут не скажу, но акцентировать внимание всё же стоит.
Не нужно просить агента выполнить большую задачу под ключ. Когда вы просите реализовать весь функционал сразу:
вы что-то упустите в формулировке
агент что-то нафантазирует
на выходе будет большая простыня кода
адекватно поревьюить её почти нереально
Гораздо эффективнее:
Сначала сформировать чёткий план решения.
Выполнять план по шагам.
Каждую подзадачу – в новом чате, с чистым контекстом.
Многие агенты поддерживают команды. Сделайте для себя команду plan.
Опишите в ней, как вы видите хороший план, и уточните, что агент должен фиксировать:
какие файлы будут изменены
какой результат считается корректным
что после каждого шага нужны тесты и запуск (здесь же можно конкретизировать тест-кейсы)
как именно вы будете проверять каждый шаг
Так вы получаете предсказуемую структуру, а агент – понятные рамки.
Отдельный момент: в том же Cursor или Claude Code есть "режимы планирования", но лично мне они не слишком нравятся. Обычно план получается не в том формате, который удобен мне. Например, можно увидеть такой сценарий: "сначала много пишем-пишем, а тесты только в самом конце" – ультра неудобно.
Команда plan, настроенная под ваши ожидания, решает эту проблему.
Rules: не просите агента их написать
Наверняка знаете о концепции rules / memory bank в агентах – когда вы формулируете правила, по которым агент должен работать. Иногда слышал советы: "да не парьтесь, сформулируйте правила прямо с агентом, он всё сам пропишет".
С моей точки зрения, это антипаттерн:
агент генерирует один, а зачастую несколько файлов, где подробно описывает ваш проект: паттерны написания кода, архитектуру и прочее
из-за объёма этот набор текста сложно вычитать, он оседает нечитабельным грузом с надеждой, что "теперь-то агент всё понял и будет писать как нужно"
вы не знаете, какие из этих правил реально важны, а какие агент и так соблюдает без всяких инструкций
В итоге:
агент всё равно пишет не так, как вы ожидаете
набор правил забивает контекст, который мы так хотим экономить
Куда полезнее, на мой взгляд, другой подход: если вы 2–3 раза просите агента исправить одно и то же – идёте и добавляете это в Rules.
Так правила растут органично, без мусора, и отражают реальные слабые места модели.
Например, в процессе работы у нас с ходу появилось несколько правил:
удивительно, но агенты до сих пор пытаются запускать контейнеры через
docker-compose. Так появилось правило: "используй командуdocker compose"многие кидаются в меня тапками, но тесты я люблю запускать в контейнерах, а не локально. Так появилось правило: "запускай тесты в Docker"
агенты любят сначала понаписать пачку тестов, а потом их запускать. Это очень непродуктивно, поэтому правило: "запускай тесты по одному, сразу после написания" – обычно решает эту проблему
ещё одно правило, которое я добавляю почти по умолчанию: "всегда оценивай свою уверенность; если уверенность меньше 8/10 – задавай уточняющие вопросы". Работает не на 100%, но иногда подпинывает агента уточнить детали, вместо того чтобы молча придумывать свои
Кстати, в Claude Code для оперативного добавления правил есть команда /memory, которая сразу открывает нужный файл, куда можно дописать что-то новое.
Переключение моделей – стоит попробовать
Иногда бывает так: вы нормально объяснили задачу, а модель ничего вменяемого не предлагает. Вроде всё ясно, а каменный цветочек не идет.
В этот момент очень помогает простое действие: переключить модель.
Иногда вторая модель мгновенно видит то, что первая "не заметила", и спокойно раскладывает задачку.
Со временем вырабатывается понимание:
этой моделью я проектирую,
этой – пишу код,
этой – провожу ревью.
А может быть вы все будете делать одной передовой моделью – и будет хорошо получаться, но при затыке имеет смысл попробовать другую модель.
Экспертиза важна. Агент дополняет, но не заменяет
Сейчас много хайпа вокруг вайбкодинга, когда код генерируется по принципу вроде работает – и ладно. Это нормальный режим для прототипов, быстрых экспериментов и pet-проектов.
Но при игре в долгую так не получится.
По моему опыту, агент эффективен тогда, когда вы сами понимаете, что хотите получить.
Рабочий флоу выглядит примерно так:
вы формулируете задачу,
агент выполняет её (частично или целиком),
вы как эксперт проверяете результат,
уточняете детали.
Если же вы не очень понимаете, "как должно быть", – агент будет тащить вас в сторону неизвестности.
Я не говорю, что такой подход плох в принципе – сам так делаю для прототипов.
Но если говорить о продакшене и долгоживущих системах, экспертиза важна. Агент усиливает вас, но не отменяет ответственность.
