Предыстория
Всё началось с нескольких встреч один на один с моим тимлидом. Ему было интересно, как я использую AI-инструменты, собираю личные Harnesses и выстраиваю свой рабочий процесс в AI Coding. В первую очередь потому, что я быстро и качественно закрываю требования и уже выступаю основным владельцем некоторых проектов. Так что я воспользовался этой возможностью, чтобы привести в порядок свой ежедневный AI-воркфлоу. Сейчас в команде я в основном занимаюсь разработкой агентов, параллельно поддерживая существующую бизнес-логику бэкенда.
Ранее я уже делился похожими подходами в Xiaohongshu. Тогда контекст был таким: GPT-5.4 и Opus 4.6 уже отлично справлялись с задачами, если дать им точный контекст и разумные ограничения. Расцвет Harness Engineering помог всем осознать одну вещь: мощными моделями можно управлять гораздо лучше, если добавить правильные ограничения.
Например, Skills вроде Superpowers предлагают довольно «тяжёлый» подход, который в основном строится вокруг Spec и TDD, помогая людям проще структурировать задачи и двигать их вперёд.
Но у этого есть свои минусы. Самое заметное ощущение — токены улетают с космической скоростью. Skills вроде Superpowers содержат множество Workflows, которые ограничивают следующий шаг модели. Даже если глобально какой-то этап уже не нужен (например, контекста достаточно и можно сразу писать код), модель всё равно может упорно идти по заранее прописанному процессу.
С выходом новых моделей я вижу, что многие разработчики начали делиться опытом: они практически перестали использовать такие перегруженные Skills. Главная причина в том, что с ростом возможностей моделей некоторые ограничения и процессы, которые раньше казались полезными, превращаются для них в шум. Например, когда OpenAI выпустила Astra, они специально написали статью о том, как убрать лишние Skills и системные промпты, чтобы улучшить опыт работы с моделью.
Поэтому в этой статье я объединю свой опыт за последние несколько месяцев и расскажу о методах, которые сейчас работают для меня. Поговорим о том, как эффективнее использовать разных агентов, чтобы повысить продуктивность в повседневной разработке.
1. Мои основные Skills и Prompts
Как сейчас распределены мои инструменты:
Для написания кода я в основном использую Codex + GPT-5.6 Sol, а для планирования — Astra. До выхода Astra задачи по планированию я отдавал GPT-5.6 Sol Max.
Для простых требований беру pi + DeepSeek V4 Flash; критический разбор решений и Code Review в основном делаю через Claude 5 Fable. В личных проектах для проектирования ключевых решений я также использую веб-версию GPT-6 Pro.
Мои основные Skills
- think: Skill от tw93, используется в основном для синхронизации по решениям и брейнштормов.
- grill me / grill with docs: Используются для уточнения требований. Через непрерывные вопросы агент проясняет цели, ограничения и компромиссы, а затем фиксирует их в ADR или CONTEXT.md в зависимости от процессов разработки. Помогает мне находить проблемы, которые мы упустили на этапе первичного согласования.
- implement: Используется вместе с grill, часть набора Skills от Matt Pocock. Нужен для реализации чётко описанных планов или Issues.
- ponytail: Применяется для очистки от AI-оверинжиниринга, чтобы упростить ревью. Я использую его часто, потому что GPT-5.6 Sol любит переусложнять.
- handoff: Упаковывает текущий контекст в файлы, чтобы удобно продолжать задачу в новой сессии. Обычно я применяю его для передачи контекста из Codex в Claude Code или pi agent.
- check: Используется для code review, как правило, при создании MR.
- Skills, накопленные в работе и личных проектах: В основном это переиспользуемые SOP процессов, например, сквозное тестирование. Мой совет: если в повседневной работе вы повторяете какой-то процесс больше трёх раз, попросите Codex оформить его в Skill, чтобы потом просто переиспользовать.
Мои основные Prompts
Сейчас я редко пишу большие промпты вручную. Если нужно, обычно прошу Codex помочь их собрать. Например, если после нескольких раундов обсуждений я хочу передать текущий контекст в GPT Pro для проектирования решения, я сначала прошу Codex сгенерировать готовый handoff-промпт.
Кроме того, я постоянно использую следующие типы очень коротких промптов.
Иногда они дают эффект «одна фраза стоит тысячи слов». Я воспринимаю их как «мыслительные ярлыки» для модели.
Это не магические заклинания, а методологии, которые давно стандартизированы в человеческих знаниях. Во время обучения модель видела огромное количество связанных статей, кода, дизайн-документов и обсуждений, поэтому часто нет нужды вручную писать сотни строк Workflow — достаточно сказать ей, какой подход к мышлению применить. Вот несколько промптов, которые на практике показали себя очень эффективно:
- Первые принципы (First Principles): Не продолжай оптимизировать текущее решение, задай вопрос заново — как эту проблему вообще нужно решать. Например, если интерфейс тормозит, можно сказать:
Не продолжай проектирование, отталкиваясь от готового решения «добавить Redis-кэш». Проанализируй с точки зрения первых принципов, почему этот интерфейс работает медленно и каким будет минимально необходимое решение.
Фокус модели смещается с «как правильно спроектировать Redis» на:
Узкое место в SQL, сети, сериализации, блокировках или повторных вычислениях? Если добавление индекса в SQL решает проблему, зачем тащить сюда Redis?
Такие промпты подходят, когда вы подозреваете, что «сам вопрос поставлен неверно».
- Критический разбор (Adversarial Review): Не ищи оправдания моему решению, попытайся доказать, что оно ошибочно.
Обычно люди спрашивают так:
Посмотри, есть ли проблемы в этом техническом решении.
Лучше изменить формулировку:
Проведи критический разбор этого решения, в первую очередь ищи контрпримеры, способные опровергнуть ключевые допущения.
Допустим, ваше решение — «внедрить распределённые блокировки для защиты от дублирующихся запросов». Модель уже не будет просто рассказывать, как настроить таймаут блокировки, а начнёт спрашивать:
Действительно ли дублирующимся запросам нужна взаимная блокировка? Может, хватит идемпотентности интерфейса? Что будет, если сервис блокировок упадёт? Что, если блокировка истечёт, а бизнес-логика ещё не выполнилась? Не вводим ли мы новую точку отказа в распределённой системе ради решения локальной проблемы?
Такой тип промптов особенно хорош для ревью архитектурных решений и Code Review.
- Абляционные эксперименты (Ablation Experiments): То, что система стала работать лучше, не значит, что полезно всё, что вы добавили.
Например, вы сделали три оптимизации за раз:
После добавления индексов, Redis-кэша и пакетных запросов задержка интерфейса упала с 800 мс до 100 мс.
В этот момент можно напрямую спросить:
Спроектируй абляционные эксперименты для этих трёх оптимизаций, чтобы понять, откуда берётся реальная польза.
Модель спроектирует контрольные группы для разных комбинаций: начнёт с Baseline, сравнит только с индексами, индексы + кэш, индексы + кэш + пакетные запросы и так далее.
В итоге она может обнаружить:
Одни только индексы снизили задержку с 800 мс до 120 мс, а оставшиеся два сложных решения дали лишь 20 мс.
Так вы гораздо чётче поймёте, какой код стоит оставить, а какая сложность оказалась избыточной.
- Бритва Оккама (Occam's Razor): При схожем эффекте выбирай решения с меньшим числом допущений и меньшей сложностью.
Например, агент спроектировал такое решение:
Kafka + Redis + распределённая блокировка + машина состояний + компенсация по таймеру.
Вы можете добавить одну фразу:
Пересмотри этот дизайн через призму бритвы Оккама: удали все необязательные механизмы при условии, что требования выполняются.
Часто в итоге оказывается:
В текущем сценарии запись идёт только в одну базу данных, достаточно одной транзакции и уникального индекса.
Эта фраза особенно полезна для современных Coding Agents, потому что модели легко уходят в оверинжиниринг ради «полноты картины».
- Высокая связность, низкая связанность (High Cohesion, Low Coupling): Перепроверь зоны ответственности и границы кода.
Например, если вы заметили, что OrderService разросся до 2000 строк, можно спросить:
Проанализируй границы ответственности OrderService согласно принципам высокой связности и низкой связанности. Не дроби код ради самого дробления.
Модель обычно начинает проверять:
Почему сервис заказов одновременно занимается складом, купонами, SMS, оплатой и отчётами? Какая логика относится к самому домену заказов, а что стоит отдать другим модулям через стабильные интерфейсы?
Это запускает не просто «разбивку файлов», а целый комплекс рассуждений о модульности, сокрытии информации, направлении зависимостей и разделении ответственности.
Поэтому я теперь редко пишу:
Шаг 1: проанализируй требования, Шаг 2: проверь допущения, Шаг 3: найди альтернативы, Шаг 4...
Многие зрелые методологии модель уже усвоила. Я предпочитаю говорить ей напрямую:
Переосмысли задачу с точки зрения первых принципов, проведи критический разбор текущего решения; ключевые механизмы должны быть подтверждены абляционными экспериментами; решение должно следовать бритве Оккама, а код — принципам высокой связности и низкой связанности.
За этими парой десятков слов на самом деле скрываются пять разных когнитивных действий:
Переформулировать проблему → Атаковать допущения → Проверить вклад каждого элемента → Убрать сложность → Выстроить границы системы.
В этом, как я понимаю, и заключается изменение Prompt Engineering в эпоху новых моделей: вместо того чтобы прописывать модели жёсткий пошаговый алгоритм мышления, лучше с помощью точных методологий подсказать ей, как думать, а затем добавить только те ограничения, которые действительно нужны для текущей задачи.
2. Мой ежедневный процесс разработки
Получив требование, я обычно сначала передаю агенту релевантный контекст: PRD, протоколы встреч, переписки, отзывы пользователей, а затем использую grill, чтобы синхронизироваться с ним по требованиям.
Часто эти материалы не складываются в цельную и непротиворечивую картину. PRD мог устареть, какие-то ограничения добавили на встрече, приоритеты поменяли в чате. Моё собственное понимание требований тоже может включать неозвученные допущения.
Я даю агенту изучить эти материалы вместе с командной Wiki и существующим кодом, а затем через непрерывные вопросы прояснить цели, границы и компромиссы, влияющие на реализацию. На часть вопросов я могу ответить сразу, а за ответами на другие приходится возвращаться к продакт-менеджеру или коллегам.
Здесь я придерживаюсь одного правила: разработка начинается тогда, когда ответы на оставшиеся вопросы уже не смогут кардинально изменить направление реализации и критерии приёмки.
Я не требую заранее спланировать все детали реализации, иначе само согласование требований превратится в невероятно тяжёлый процесс.
Итоги согласования фиксируются в Spec или CONTEXT.md, где записываются решаемая проблема, скоуп, ключевые решения и критерии приёмки. Это позволяет агентам, которые позже займутся реализацией и ревью, работать в едином контексте, не перечитывая всю историю переписки.
Когда решение определено, я оставляю главному агенту выбор способа выполнения в зависимости от сложности задачи. Простые требования реализуются сразу; сложные разбиваются на Issues с чёткими границами, которые можно принимать независимо. Только те части, которые можно делать автономно, отдаются суб-агентам для параллельной разработки в разных worktrees, а главный агент в конце всё интегрирует.
Coding Agent сначала пишет тесты. Когда он считает, что готов к сдаче, я в зависимости от сложности задачи подключаю других агентов для перекрёстного критического ревью. Найденные проблемы централизованно отправляются обратно главному coding-агенту (то есть Codex), который всё исправляет и проверяет заново.
Перед своим личным ревью я также провожу сквозное тестирование.
Сейчас я не читаю весь сгенерированный код построчно, в основном смотрю на результаты тестов и ключевую бизнес-логику. Здесь есть важное условие: каждый MR должен быть небольшим по объёму, а полные бизнес-сценарии должны постепенно проверяться по ходу разработки.
Небольшие MR позволяют держать объём изменений, требующих осмысления и оценки, в контролируемых рамках; а сквозные тесты помогают проверить, выдерживают ли эти изменения погружение в реальные бизнес-процессы. Во время ручного ревью я фокусируюсь на подтверждении бизнес-логики и на том, достаточно ли имеющихся результатов тестирования для этого релиза.
3. Как выстроить сквозное тестирование, удобное для агентов
AI уже отлично пишет тест-кейсы, часто выдавая сотни строк тестов на один багфикс (особенно 5.6 sol). Само по себе обилие тестов — не проблема, но после деплоя и релиза мы всё равно сталкиваемся с неожиданными ошибками.
В моей практике корень проблемы один: мы не даём агенту среду для сквозного тестирования, лишая его возможности находить такие ошибки на этапах написания кода и самотестирования.
Если построить такую среду, где агент сможет удобно выполнять задачи прямо с реальной точки входа тестового окружения и проверять всё вплоть до результатов, нужных пользователю, мы сможем уверенно запускать написанный AI код в реальных системах.
В реальной разработке я собрал набор сред для сквозного тестирования под наш бизнес. Агент может без проблем запрашивать таблицы баз данных, логи и подключаться к машинам для поиска причин ошибок.
По сути, весь процесс сборки сводится к тому, чтобы агент извлёк мои ежедневные рутинные проверки и объединил разрозненные инструменты и возможности: то, что можно превратить в инструмент, становится MCP или CLI; переиспользуемые процессы оформляются в Skills.
Да, на старте это требует усилий, но не бойтесь заморочиться. После настройки это радикально ускоряет разработку, снижает количество переделок и риск проблем на проде, и вам больше не придётся целыми днями переживать, не сломает ли что-нибудь код, написанный AI.
Вокруг удобного для агентов сквозного тестирования я сделал четыре вещи:
- Дал агенту освоиться в среде: например, настроил запуск тестового окружения в один клик, создание тестовых данных, прояснил текущие версии, тестовые аккаунты и права доступа, а также добавил возможности очистки и сброса.
- Дал агенту управлять бизнес-системами: выполнять реальные бизнес-процессы через браузеры, API или CLI.
- Дал агенту удобный доступ к таблицам БД и логам: подтверждать результаты записи через read-only MCP базы данных, искать проблемы через Skills лог-систем и Trace-запросы.
- Автоматизировал нудные, но стабильные процессы: записал надёжные операции в скрипты, оформил точки входа и методы траблшутинга в Skills, чтобы сократить ручное вмешательство и лишние диалоги.
Опираясь на эту работу, вот несколько методов, которые сейчас кажутся мне наиболее эффективными:
- Браузерная автоматизация: Если бизнес-системы требуют работы через браузер, рекомендую open-source инструмент ego lite. Он удобен и быстр. В связке с pi agent + DeepSeek V4 Flash тесты проходят довольно быстро, что экономит время.
- Сведение всех операций в CLI: Объедините переиспользуемые Skills, настроенные MCP и написанные скрипты в единый тестовый CLI, который умеет проверять окружение, готовить данные, прогонять сценарии, запрашивать результаты и делать очистку. Это может стать отличным внутренним инструментом для повышения эффективности. Я уже собрал такой набор в CLI, и он здорово выручает при поиске причин ошибок.
- Пусть инструменты служат приёмке: Запросы к БД нужны для подтверждения статуса, логи и трейсы — для объяснения падений, но ожидаемые результаты всё равно должны браться из бизнес-контрактов. Не позволяйте агенту считать результат верным только потому, что система что-то вернула. При сложной бизнес-логике система может вернуть абсолютно правдоподобный, но не соответствующий требованиям результат. Инструменты помогают нам собирать доказательства, а не определяют за нас правильные ответы.
- Если сам продукт — это агент, проверяйте качество ответов: Если тестируемый продукт сам является агентом, помимо успешного прохождения бизнес-процессов, нужно оценивать и качество ответов. Это то, что мы обычно называем Agent Eval, подробно останавливаться на этом здесь не буду.
4. Как проводить ревью кода, написанного AI
В предыдущих разделах мы говорили о том, как заставить AI писать качественный код, но в конечном счёте главным ответственным за бизнес-требования остаётся разработчик.
Без ревью в больших системах легко наломать дров.
И вряд ли вы хотите проснуться посреди ночи по On-call, чтобы выяснить, что инцидент вызвал код, написанный AI.
Что касается ревью, сейчас я придерживаюсь следующих практик:
- Сначала критерии приёмки, потом результаты тестов: Сначала проверяю заданные агентом критерии приёмки, затем сверяю их с результатами предыдущего сквозного тестирования, чтобы убедиться, что ожидания выполнены и ничего не упущено. Важно смотреть не только на количество пройденных тестов, но и на то, проверили ли эти тесты то, что действительно важно для данного требования.
- Идите по бизнес-путям при просмотре реализации, фокусируя силы на рискованных местах: Я в основном проверяю права доступа, изменения состояний, конкурентность, ретраи, консистентность данных и такие рискованные вещи, как миграции и откаты. На стабильный CRUD по шаблонам можно тратить меньше времени — часть такого кода я сейчас даже не смотрю.
- Отдельно проверяйте новые абстракции и механизмы: Для новых абстракций и механизмов я использую подходы вроде бритвы Оккама, чтобы AI провёл повторное ревью: действительно ли они нужны, есть ли реализация проще, не привнесли ли мы слишком много сложности ради локальной проблемы?
- Подумайте о выделенных Review-ботах, если MR много: Если в команде много MR, можно спроектировать специального Review Bot для перекрёстного ревью. В отличие от прямого вызова pi agent / Claude Code для критического разбора, о котором шла речь выше, здесь акцент делается на сочетании информации об изменениях из Git с заранее спроектированными процессами ревью, что формирует повторяемую систему проверки, заточенную именно под MR.
5. Несколько выводов и размышлений
Моё самое узкое место в разработке сейчас — скорость ревью.
Агенты могут параллельно двигать несколько задач, но моя скорость понимания бизнеса, оценки решений и приёмки кода растёт не пропорционально. Если просто позволить им писать больше, вы, скорее всего, получите лишь гору кода, ждущего ревью.
Поэтому следующее, что я хочу улучшить — сделать так, чтобы типовые проблемы находились и исправлялись до того, как попадут ко мне.
Всё, что можно выявить проверкой типов, тестами и бизнес-ассертами, агент должен максимально обрабатывать сам в процессе разработки; а моё участие должно концентрироваться на том, верно ли поняты требования, работает ли ключевая бизнес-логика и какие непроверенные риски остались в этом изменении.
Выделенные Review-боты могут с этим помочь, но их ценность определяется тем, снижают ли они количество пропущенных реальных проблем и ручную нагрузку, а не тем, сколько комментариев они оставляют.
Это также сделало моё понимание концепции Harness более конкретным: помимо предоставления агентам правильного контекста, им нужны среды, способные выполнять задачи, и база для оценки результатов.
Я упаковал операции, которые постоянно повторял при ручном тестировании, в CLI, скрипты и Skills, позволив агенту самому запускать системы, проверять результаты и искать причины падений. В будущих похожих задачах эти наработки можно будет использовать снова, а со временем — передать коллегам для переиспользования.
При этом воркфлоу нужно регулярно «вычитать».
Некоторые шаги компенсируют недостатки конкретного поколения моделей. Когда модели меняются, пользу этих шагов нужно переоценивать. Простые задачи делаются напрямую, для сложных добавляются планирование, декомпозиция и перекрёстное ревью. Например, после обновлений Astra я удалил часть излишне строгих ограничений из AGENTS.md. Модели развиваются, и наши рабочие процессы должны развиваться вместе с ними.
Конечно, тестирование и ревью снижают неопределённость, но корректные критерии приёмки всё равно должен задавать человек. Даже если код и тесты идеально соответствуют друг другу, они оба могут одинаково неправильно понять требования. Сквозные тесты покрывают поведение только в выбранных средах и сценариях; трафик, конкурентность и распределение данных в проде всё равно могут принести новые сюрпризы.
Как разработчик, который недавно начал работать, я всё ещё надеюсь получать больше профессиональных знаний в своей области через практику. Однако AI действительно сократил количество возможностей лично наступить на грабли. Часть ценного опыта, который раньше добывался через столкновение с проблемами и поиск их причин, теперь сводится к тому, что AI говорит:
«Я ошибся, сейчас исправлю».
Поэтому
сейчас я выделяю часть рабочего времени на обучение и рефлексию, параллельно размышляя: какие навыки действительно понадобятся разработчикам в эпоху AI.
Эта статья — фиксация набора методов, которые я постепенно нащупал в своих рабочих задачах за первые несколько месяцев. Область их применения и слабые места я продолжаю исследовать.
Каждый может начать с малого: выберите один привычный путь самотестирования, попробуйте дать агенту пройти его самостоятельно, сохраните доказательства, а затем зафиксируйте работающие шаги.
Из-за требований компании к конфиденциальности многие детали не попали в статью. Надеюсь, этот материал послужит отправной точкой для обсуждения, и мне будет очень интересно узнать о хороших практиках из вашей реальной разработки~
