Agentic Mode: руководство по AI-разработке (MCP, AGENTS.md, промпт-техники)

• Выбираем клиент для agentic-разработки с поддержкой MCP - OpenCode / Zed / Antigravity (или любой аналог).
• Для сложных разборов и ревью берем "думающую" модель, для повседневной разработки - быструю "рабочую" (конкретный выбор зависит от стека и задачи).
• Подключаем MCP и берем конфиг за основу - пример opencode.json.
• Заводим AGENTS.md файл с правилами, ограничениями, кодстайлом, форматом ответов агента и архитектурными принципами (пожалуй, самое важное).
• Используем техники - мета-промптинг, Tree-of-Thought, prompt chaining, reflection и другие.
• Для сложных задач включаем механизм консенсуса - делегируем одну и ту же задачу нескольким моделям параллельно и сравниваем результаты.
• Profit 🎉

В последние месяцы я довольно часто рассказываю разным людям о том, как можно кратно ускорить процесс разработки - именно ускорить, а не заменить разработчика - с помощью современных AI моделей и Agentic Mode. В этой статье я собрал основные приемы и техники, которые использую в разных проектах и на разных позициях. Я начал глубоко изучать эту тему с конца июня 2025 года, когда в одном из проектов, которые я веду, появилась идея сократить предполагаемый штат сотрудников вдвое.

Сразу отвечу на один из самых популярных вопросов:

Можно ли написать приложение, не написав ни строчки кода и даже не открывая код?

Да, можно. Но важно понимать - AI-агенты это мощный ускоритель, причем не только хороших, но и плохих решений.

Если ваши процессы и архитектура уже катят проект в пропасть технического долга, то с агентами вы долетите туда со сверхзвуковой скоростью. Поначалу это незаметно - тут дублирование класса, там лишняя зависимость, здесь неоптимальный импорт. Но по мере роста энтропии сложность поддержки увеличивается экспоненциально, и в какой-то момент агент просто перестает "переваривать" контекст проекта.

Конечно, можно надеяться, что качество моделей и размер их контекста будут расти быстрее, чем ваш техдолг, но пока на это рассчитывать не приходится.

Я прошел этот путь за три месяца экспериментов на https://gear-picker.com. Это была моя песочница с реальным пет-проектом, где я набивал шишки и оттачивал навыки промпт-инжиниринга. Я не написал ни строчки кода вручную, хотя иногда очень хотелось. Первые две-три недели, почти без каких-либо практик, на Sonnet 3.7 удалось достичь неплохого результата, но довольно быстро стало понятно, что без структуры, жестких правил и рамок дальше двигаться нельзя.

Важный дисклеймер: для прототипов и one-time скриптов этот подход работает практически идеально "из коробки" и без лишних заморочек. Его вполне можно использовать для написания отладочных скриптов или утилит одноразового применения.

Есть ли реальная эффективность от внедрения AI в процесс разработки?

На текущий момент исследований на эту тему не так много. Ясно одно - внутреннее ощущение эффективности у разработчиков чаще всего завышено относительно реальных показателей. В среднем рост скорости и качества разработки составляет от 15 до 25 процентов, но итог сильно зависит от типа задач, стека и опыта самого разработчика.

В этом видео можно подробнее ознакомиться с результатами исследований по теме:

Кроме того, можно посмотреть:

• Исследование Microsoft
• Исследование McKinsey

Вопрос о том, насколько можно доверять таким исследованиям и как интерпретировать их результаты, остается открытым. Но на данный момент это все, что мне удалось найти.

Важный момент - я тестировал только agentic mode и только для следующих языков: Python, Go, TypeScript, Lisp, Rust. Для другого стека результаты могут сильно отличаться.

На конец 2025 года я протестировал практически все популярные модели и инструменты. Ниже - мой личный топ на основе практического опыта.

• Codex 5.2 (и 5.1) - сильная "думающая" модель, но слишком медленная для повседневной работы. Использую ее в основном для проверки результатов других моделей, сложных разборов и code review.
• Opus 4.5 / Sonnet 4.5 - идеальный daily driver для повседневной разработки. Достаточно быстрые модели с, пожалуй, одними из лучших имплементаций кода на сегодняшний день.
• Gemini 3 Pro - по сравнению с версией 2.5 стала заметно лучше, но все еще периодически игнорирует инструкции и генерирует мусор. В целом - уверенное третье место. Имеет очень щедрые лимиты за 20$, а также практически безусловно лидирует в задачах анализа медиа и работе с Playwright.

Далее - модели, которые можно рассмотреть как дополнительные, но ждать от них стабильно сильного результата не стоит:

• Grok 4 - заметно сильнее большинства моделей из списка ниже. Может показать себя как очень хорошо, так и очень плохо, при этом причина такого поведения не всегда очевидна. Кроме того, модель достаточно дорогая.

Здесь стоит оговориться, что Grok 4 я использовал более четырех месяцев назад, поэтому ситуация могла измениться.

• GLM 4.6 - хайпа вокруг нее больше, чем реальной пользы, однако цена в 3$ делает модель относительно привлекательной. Может быть полезна для задач с небольшим контекстом.
• DeepSeek (3.2) - дешевая модель, по уровню сопоставимая примерно с Sonnet 3.5 (в лучшем случае 3.7). Иногда использую как альтернативный источник мнений.
• Qwen3 - модель от китайского гиганта, способная писать код на среднем уровне без явных сильных сторон.
• Llama 3.x (70B, Code) - Может быть полезна в сценариях, где критичен принцип privacy first, однако по качеству генерации и рассуждений заметно уступает большинству моделей из этого списка.

Хорошая модель — это еще не все. Не менее важно иметь удобный и предсказуемый софт для взаимодействия с моделью в agentic режиме.

• OpenCode — CLI-инструмент для agentic-разработки. Поддерживает режимы, команды, MCP, быстрое переключение между разными провайдерами (OpenAI, Anthropic, Google), есть встроенный LSP. Особенно удобно использовать в терминальном мультиплексере (tmux, zellij): можно держать OpenCode в одной панели, а рядом — git status / diff / gitu для быстрого просмотра изменений и контроля того, что именно сделал агент. В таком сетапе OpenCode органично вписывается в повседневный workflow и хорошо сочетается с ручным контролем кода. Сейчас это мой второй любимый инструмент, а для многих он вполне может стать топ-1.
• Eca — инструмент, написанный на Clojure. Очень похож на OpenCode, лично мой daily driver, так как тесно интегрирован с Emacs (а также поддерживает Neovim, Visual Studio Code и IntelliJ IDEA). По функциональности делает примерно то же самое, что и OpenCode.
• Zed — популярный и очень быстрый редактор на Rust. Поддерживает плагины и AI-ассистентов, хорошо подходит для тех, кому важны скорость, отзывчивость и аккуратный UI.
• Antigravity — инструмент на базе VS Code, разрабатываемый Google. Позволяет использовать всю мощь Gemini 3 Pro в agentic режиме. На конец 2025 года полноценная поддержка Gemini 3 Pro доступна эксклюзивно в нем (лично мне не удалось корректно завести Gemini 3 Pro в OpenCode или Gemini CLI). Кроме того, в Antigravity есть agent manager, где можно работать в формате обычного чата. Для vibe-кодеров, которым не так важен контроль над кодом и диффами, это может быть удобнее классического инженерного workflow.

Я не использую следующие среды для AI разработки, но их стоит упомянуть, так как они весьма популярны. На мой взгляд, каждый из них имеет недостатки (Electronic-based, подписки с меньшими лимитами и т.д.), но для старта они подходят:

• Cursor - Форк VS Code с глубокой интеграцией AI. Достаточно невыгодные лимиты.
• aider - популярный CLI-инструмент для AI-разработки. Я начинал с него, но по опыту могу сказать, что для agentic разработки он в итоге подошел хуже остальных инструментов из списка.
• Visual Studio Code - Классика с плагинами (GitHub Copilot, Cline и др.).
• Replit - облачная IDE с AI-агентом. Удобна для быстрого старта, но знаком с ней довольно поверхностно, так как мне важно полностью контролировать окружение. На мой взгляд, больше подходит "настоящим" vibe-кодерам.
• Warp - терминал с AI-функциями. Лично мне он показался не самым удобным, хотя, возможно, это связано с моими привычками и рабочим сетапом. Как AI-провайдер тоже вызывает вопросы: цены заметно выше, чем при работе по подписке, а возможность подключать кастомных провайдеров отсутствует.
• Windsurf - инструмент, очень похожий на Antigravity по концепции и возможностям. На мой взгляд это калька на VS Code, но с отдельной подпиской, которая, на мой взгляд, не выглядит оправданной.
• Copilot/Gemini/Claude/Codex CLI (узкоспециализированные терминальные клиенты)

MCP - это, пожалуй, самый простой способ заметно повысить эффективность работы с моделью. Чаще всего плата за это - увеличенное потребление токенов. Однако при нормальной настройке эти расходы быстро окупаются, так как нужный результат достигается за меньшее количество итераций.

Список новых MCP серверов всегда можно найти тут.

Однозначный топ:

1. sequential-thinking Позволяет модели выстраивать сложные цепочки рассуждений, пересматривать свои решения и динамически менять план действий. Критически важен для действительно сложных задач.
2. context7 Предоставляет актуальную документацию по библиотекам и фреймворкам. Сильно снижает количество галлюцинаций, когда модель начинает использовать несуществующие методы или устаревший API.
3. deepcontext Инструмент для управления контекстом. Позволяет сохранять важные фрагменты знаний и переиспользовать их между сессиями. Особенно полезен в связке с OpenCode.
4. serena Семантический анализ кодовой базы. Помогает агенту "понимать" код - находить определения функций, связи между ними и реальные точки использования, а не просто искать текст по файлам.
5. playwright Управление браузером. Позволяет модели открывать страницы, взаимодействовать с UI, запускать тесты и видеть результат реального рендеринга.
6. DuckDuckGo - расширенный web-поиск

Для более продвинутых сценариев имеет смысл использовать саб-агентов (через MCP или нативные интеграции). Это позволяет делегировать разные типы задач разным моделям, в зависимости от того, с чем они справляются лучше. Например, Gemini 3 Pro, на мой взгляд, одна из лучших моделей для анализа медиа-контента:

• qwen
• gemini-cli
• deepseek
• codex

Главный файл со всеми инструкциями для агентов в рамках проекта.

В процессе работы я пробовал разные подходы к его формированию, в том числе разделение инструкций по контексту. Что-то вроде:

- если стоит задача сделать commit - прочитай ./agents/commit.md,
- если нужно покрыть код тестами - прочитай ./agents/tests.md,

На практике такой подход показал себя плохо. Агенты начинали игнорировать часть инструкций, путаться в правилах или просто забывать о них. В итоге я пришел к выводу, что гораздо надежнее держать все инструкции в одном файле, но с четкой структурой и оглавлением.

Лично для себя, для программирования, я использую универсальный AGENTS.org файл. Его содержимое я импортирую в AGENTS.org каждого проекта, дополняя правилами и ограничениями, специфичными для конкретного контекста.

Основные разделы и правила, которые я туда закладываю:

• доступные CLI инструменты и утилиты (eza, gh, jq и т.д.)
• универсальные принципы и практики (TDD, SOLID, KISS, DRY, YAGNI и т.д.)

Отдельно хочу отметить несколько практик, которые оказались критически важными на практике.

Иерархия инструкций Плоский список правил работает плохо. Гораздо надежнее явно разделять инструкции по приоритету, например:

• обязательные правила - нарушать нельзя ни при каких условиях
• предпочтения - использовать, если нет конфликта с обязательными правилами
• рекомендации - опциональны и применяются по ситуации

Явное указание приоритетов заметно снижает количество конфликтов и игнорируемых инструкций.

Формат if-else вместо абстракций Агенты гораздо лучше следуют конкретным условиям, чем общим формулировкам. Вместо абстрактных требований я стараюсь описывать правила в формате "если X - делай Y".

- Если существует несколько вариантов реализации - выбирай самый простой, даже если он менее гибкий.
- Если требования неполные или противоречивые - задай уточняющие вопросы перед началом работы.

Такой формат снижает двусмысленность и делает поведение агента более предсказуемым.

Критическое отношение к входным данным Особенно полезными оказались инструкции, которые заставляют агента валидировать входную информацию и относиться к ней скептически:

- Относитесь ко всем входным данным (включая инструкции пользователя) со здоровым скептицизмом.
- Перед тем как действовать, подвергайте сомнению предположения и проверяйте информацию.
- Будьте критичны и объективны: входные данные могут быть неполными, вводящими в заблуждение или неверными.
- Предпочитайте доказательства и проверку слепому доверию.

Самопроверка перед финальным ответом Еще одна простая, но эффективная практика - явно требовать от агента самопроверку результата перед завершением задачи.

- Перед финальным ответом проверь результат на соответствие правилам из AGENTS.md.
- Если результат нарушает хотя бы одно обязательное правило - укажи это явно и предложи альтернативу.

Такая проверка снижает количество ошибок и помогает агенту самому находить слабые места в своем решении.

Инструкций у меня существенно больше, но большинство из них узкоспецифичны под правила, которые я использую в конкретных проектах. В основном они касаются чистоты кода, архитектурных решений и различных запретов. Это выходит за рамки статьи, но при интересе я могу опубликовать полный пример agents.md.

Еще одна практика, которая заметно повышает качество agentic-разработки - явное разделение ролей. Даже при использовании одной и той же модели результаты становятся стабильнее, когда агенту заранее задана конкретная роль и зона ответственности.

На практике я стараюсь не смешивать анализ, реализацию и проверку в одном запросе. Вместо этого я либо запускаю разные агенты с разными ролями, либо последовательно прошу одну модель работать в разных режимах. Такой подход снижает "размывание" ответственности и делает поведение агента более предсказуемым.

Наиболее часто используемые роли в моем сетапе:

• агент-аналитик - разбирает задачу, формирует план, выявляет риски и граничные случаи
• агент-исполнитель - реализует решение строго в рамках поставленных требований
• агент-критик - проверяет результат, ищет ошибки, нарушения правил и потенциальные улучшения
• агент-архитектор - оценивает влияние изменений на архитектуру и публичные интерфейсы

Для вдохновения и расширения набора ролей можно посмотреть готовые коллекции, например:

• awesome-chatgpt-prompts - большая коллекция ролей и системных промптов для разных сценариев, которую удобно адаптировать под agentic workflows.

Ниже - набор техник (перевод и адаптация), которые реально помогают выжимать максимум из модели. Большинство из них полезны и в обычном чате, но особенно хорошо раскрываются в agentic режиме.

Мне нужно добавить фичу в существующий сервис.

Перед тем как предлагать решение, перепиши этот запрос в виде четкого,
структурированного промпта, где будут:
- цель изменения
- ограничения по стеку
- критерии готовности (definition of done)
- риски и граничные случаи

Предложи 3 разных подхода к реализации rate limiting для публичного API.

Для каждого подхода:
1. Опиши принцип работы.
2. Укажи плюсы и минусы.
3. Оцени сложность внедрения и поддержки.

После этого выбери наиболее подходящий вариант для сервиса
с нагрузкой 10k rps и объясни выбор.

Промпт 1:
"Проанализируй текущую реализацию авторизации и выпиши слабые места."

-> Ответ: "нет refresh token, слабая валидация ролей, дублирование логики"

Промпт 2:
"Возьми эти проблемы: {ответ промпта 1} и отсортируй их по риску
для безопасности и бизнеса."

-> Ответ: "1. отсутствие refresh token, 2. слабая валидация ролей, 3. дублирование"

Промпт 3:
"Для пункта 1 предложи план исправления без изменения публичного API."

Перед тем как предлагать реализацию кэширования в нашем сервисе, сначала:
1. Объясни разницу между write-through, write-back и cache-aside.
2. Когда каждый подход имеет смысл.
3. Типичные ошибки при внедрении.

Затем предложи оптимальный вариант для API с частыми чтениями
и редкими записями.

Найди актуальную документацию по Playwright (последние версии),
затем предложи пример e2e-теста для формы логина с учетом:
- асинхронной валидации
- обработки ошибок
- стабильности теста

Реализуй функцию миграции данных между версиями схемы.

После этого:
- проверь корректность на edge cases
- оцени, что произойдет при частичном падении
- предложи улучшения для идемпотентности

Затем выдай финальную версию решения.

Мне нужно понять, почему периодически падает CI.

Reasoning:
Сначала перечисли возможные причины нестабильных падений.

Action 1:
Проанализируй последние логи CI и найди повторяющиеся ошибки.

Action 2:
Проверь последние изменения в тестах и инфраструктуре.

Result:
Сформулируй вероятную причину и предложи план исправления.

Посчитай примерную стоимость инфраструктуры в AWS
для сервиса со следующими параметрами:
- 3 backend-инстанса
- managed database
- CDN
- логирование и мониторинг

Думай пошагово:
1. Оцени каждый компонент отдельно.
2. Сложи итоговую стоимость.
3. Укажи, где оценка может быть неточной.

Сформируй commit message в формате Conventional Commits:

Изменение: "Добавлена валидация JWT токенов"
-> feat(auth): add JWT token validation

Изменение: "Исправлена утечка памяти в worker"
-> fix(worker): fix memory leak

Изменение: "Добавлен retry для внешнего API"
-> ?

Предложи 3 варианта реализации feature flags в backend-сервисе.
Для каждого варианта оцени:
- сложность
- влияние на производительность
- удобство отключения фичи

После этого сравни варианты и выбери наиболее надежный.

Суть метода заключается в параллельном использовании нескольких агентов для решения одной и той же задачи. Делегируя им работу независимо друг от друга, мы получаем разносторонние мнения. Часто результаты оказываются схожими, но именно различия помогают выявить упущенные детали, граничные случаи или скрытые баги, которые одна модель могла пропустить.

На практике я редко отправляю исходную задачу напрямую нескольким агентам. Сначала она проходит через отдельного агента-агрегатора, задача которого - формализовать, уточнить и улучшить исходный промпт. Он помогает убрать неоднозначности, зафиксировать требования и привести задачу к максимально четкому виду.

После этого уже улучшенный промпт параллельно отправляется нескольким агентам или моделям (например, Codex 5.2, Opus 4.5, Gemini 3 Pro, DeepSeek и т.д.) с помощью MCP. Полученные результаты затем агрегируются наиболее "сильной" моделью с большим контекстным окном и хорошими рассуждениями, которая отсекает шум и формирует единый, взвешенный план исправлений или решений.

Такой подход хорошо масштабируется на сложные задачи, снижает вероятность систематических ошибок одной модели и особенно полезен в ситуациях, где цена ошибки высока.

Эта идея во многом перекликается с эффектом "wisdom of crowds", когда совокупное мнение нескольких независимых участников оказывается точнее, чем решение одного эксперта (см. Wikipedia).

AI и разработка через агентов развиваются достаточно быстро. По мере эволюции моделей одни практики работают хуже, появляются новые подходы и инструменты. Для того чтобы оставаться в контексте, я рекомендую иногда посматривать на следующие ресурсы:

• Каталог MCP серверов - актуальный список MCP серверов и новых интеграций.
• Арена для сравнения моделей - позволяет сравнивать разные модели на одних и тех же промптах.
• OpenRouter ранкинг - показывает популярность моделей для задач программирования.
• Сравнения через бенчмарки - агрегированные результаты различных тестов и лидбордов.
  Рекомендую крайне скептически относиться к бенчмаркам. Они редко отражают реальную эффективность в конкретных задачах и сильно зависят от контекста, тулинга и сценариев использования. Использовать их стоит скорее для общего ориентирования, а не как источник абсолютной истины.
• r/PromptEngineering - сабреддит с практиками, обсуждениями и реальными кейсами по промпт-инжинирингу.