Всем привет! Я Игорь Уваров, старший фронтенд‑разработчик Mindbox. С января 2026 года агент пишет за меня 90% кода, а я проектирую верхнеуровневую архитектуру и ставлю ему задачи. Раньше я разбирался в них сам: вгружался в контекст, уточнял детали у коллег и готовил вопросы к грумингу. Если в работе было несколько задач, между ними приходилось постоянно переключаться и каждый раз заново вникать. На это уходило время, внимание рассеивалось, я мог упустить важные детали и ошибиться. Чтобы упростить себе работу, исследовательскую часть я тоже делегировал агенту.
В статье расскажу, как разработал и внедрил плагин, с помощью которого агент разбирается в задаче вместо меня. Он изучает документацию, ищет зависимости и неочевидные условия в коде, а затем готовит вопросы для обсуждения с командой.
С какой задачей бизнес пришел к разработчикам: улучшить информативность отчета
Я отвечаю за то, как работают и выглядят аналитические отчеты в личном кабинете Mindbox. С их помощью маркетологи отслеживают выручку, число заказов, средний чек и другие бизнес‑метрики по клиентским сегментам. Например, по новичкам, активным или клиентам с одной покупкой. Раньше в отчетах был сегмент «Все клиенты», куда попадали в том числе анонимные покупатели — те, кого система не смогла идентифицировать. Из‑за этого невозможно было оценить влияние анонимов на выручку.
Перед командами бэкенда и фронтенда стояла задача перестроить отчеты так, чтобы вместо одного сегмента «Все клиенты» стало три: «Все», «Идентифицированные» и «Анонимные». Еще в отчеты нужно было добавить два новых показателя — «Доля выручки» и «Доля заказов».
Зачем понадобился агент-аналитик: вайбкодинг не прокатил
Поначалу задача казалась простой, поэтому бэкенд‑разработчик решил не ждать меня и самостоятельно завайбкодил фронт‑часть — обратился к агенту в чате и попросил написать код. В итоге MR завернули на ревью с комментарием: «Вайбкодинг не прокатил. Таска на стопе, пока не возьмет фронт». Когда я взял задачу, оказалось, что агент размазал бизнес‑логику работы с новыми сегментами по 30 разрозненным функциям. Система изначально не предполагала, что сегмент «Все клиенты» можно разделить, а бэкенд‑разработчик не подумал, как пользователи будут работать с новыми сегментами в разных частях интерфейса.
В Mindbox нет системных аналитиков, которые писали бы техзадания и спецификации, поэтому разработчики делают это сами. Вместе с продакт‑менеджерами и дизайнерами мы изучаем бизнес‑требования и создаем задачи. Учитывая, что код сейчас пишут агенты, основная работа программиста сосредоточена на этапе подготовки: тут он собирает контекст и условия задачи. Чтобы облегчить себе жизнь, я решил привлечь агента и к этой работе.
Я не стал применять Spec‑Driven Development (SDD) целиком, где с помощью инструментов OpenSpec, BMAD, GSD агентам делегируют полный цикл разработки — от исследования до генерации кода. Мне хотелось автоматизировать только исследовательскую часть: чтобы агент изучал документацию и код в репозиториях, искал зависимости и ограничения, а затем приносил мне вопросы, которые нужно обсудить с командой.
В отличие от обычной работы по скиллу агент общается со мной, как прилежный ассистент: уточняет детали, старается подтвердить или опровергнуть полученную информацию, спорит и критикует мои решения. Например, когда мы обсуждали, как добавить анонимных клиентов в интерфейс, я обнаружил, что на фронтенде сегменты группируются по признаку «с заказами» и «без заказов». Я подумал, что признак анонимности тоже можно ввести через группировку сегментов и попросил агента проанализировать эту идею. Он поковырялся в репозиториях и выяснил, что группировка «без заказов» нигде не используется, хотя и формируется в коде фронтенда, так что проектировать интерфейс по моим представлениям нельзя. Благодаря тому, что агент нашел этот забытый артефакт, я вовремя отказался от заведомо нерабочего решения. Эту и подобные ей находки, неочевидные условия и ограничения я назвал «слепыми пятнами».
Что упустили люди, но нашел агент-аналитик: четыре «слепых пятна» в коде и документации
Проблема «слепых пятен» в том, что заранее никогда не знаешь, что это будет: зависимость от других модулей, особый случай, нигде не описанное и забытое решение двухлетней давности. Ниже опишу четыре кейса, когда агент помог вовремя обнаружить «слепые пятна» и избежать проблем разного масштаба.
Нашел забытое архитектурное решение. По истории git не всегда можно восстановить логику принятия решений при разработке, поэтому мы ведем Architecture Decision Record. ADR — это такой документ, где мы записываем, какой подход выбрали и почему. Люди могут забывать про эти документы или не знать о них вовсе: продакт‑менеджер их не читает, разработчик забыл или пришел в проект позже. По инструкции агент должен проверять, соответствует ли техническое задание ADR. Однажды мы приняли решение, которое противоречило одной из записей. Никто о ней не помнил, а агент отловил расхождение, и мы учли это в коде и тестах.
Предупредил, что запрос в бэкенд нарушит контракт и приведет к исключению. Когда я добавил сегмент анонимных клиентов, нужно было выяснить, что произойдет, если фронтенд отправит на бэкенд значение all для сегмента «Все». Бэкенд‑разработчик предполагал, что запрос пройдет, но советовал это проверить. Агент изучил код бэкенда и обнаружил, что all не входит в список допустимых значений: такой запрос завершился бы ошибкой и сломал сохранение всех настроек сегментов. Проверять гипотезу вручную и отвлекать бэкенд‑разработчика не пришлось.
Предотвратил удаление критически важного правила из кода при рефакторинге. Нам нужно было отрефакторить общий код метрик. В нем было правило, согласно которому для метрик по цели — например, по выкупленным заказам, — передается идентификатор целей. Когда агент готовил задачу, он обнаружил, что вместе со старой реализацией удаляется кусок кода с этим правилом. В целом, код бы не сломался после рефакторинга, но со временем это могло привести к некорректному расчету данных для пользователей.
Обнаружил, что сегмент «Все» по‑разному кодируется в разных частях отчета. Разработчики фронта добавили запрос сегмента «Все» в бэкенд по‑разному: для таблицы — пустым значением, для графика — константой all. Агент отследил ошибку и предупредил, что из‑за этого данные будут отображаться только на графике, а таблица под ним будет пустой.
Чего агент не может найти по определению: понятен ли интерфейс человеку
Полностью доверить агенту UI невозможно, поэтому мы в любом случае оцениваем результат вручную:
— смотрим, понятно ли пользователю, что происходит в интерфейсе;
— проверяем пограничные значения, которые могли не учесть при подготовке задачи.
Когда доработали отчеты и прогнали все тесты, задачу принимал человек. Он обнаружил недочеты, которые мы с агентом упустили при подготовке и реализации:
На карточках метрик «Доля выручки» и «Доля заказов» не было видно, по какому сегменту рассчитан показатель. Пользователь видел значение и мог решить, что оно относится ко всем клиентам. А по умолчанию метрика считалась для сегмента «Идентифицированные».
На карточке метрики «Доля заказов» прирост отображался как «−0%». Бэкенд передавал крохотное отрицательное значение, а на фронтенде оно округлялось до ближайшего целого. При подготовке мы забыли, что число может быть отрицательным и не договорились, что показывать пользователям в таких случаях.
Был случай, когда не спасла даже ручная приемка. При проведении рефакторинга мы выделяли общий код метрик в ядро и вводили единые правила. Согласно одному из них, фронт не должен отправлять на бэкенд фильтр, недоступный для выбранной метрики. После изменений фильтр, от которого зависела разбивка по подписчикам в отчете, перестал уходить в запросе. Это было исключением, которое мы не учли. Рефакторинг уехал в прод, спустя две недели клиент не увидел часть данных и обратился в поддержку. На следующий день мы внесли правки, написали тест и выпустили фикс.
Что под капотом: от скилла в 30 строк до плагина
Сейчас агент‑аналитик — это плагин, но я начинал с небольшого скилла из 30 строк. В нем были только общие правила подготовки спеки, поэтому результат получался предсказуемо слабым. Например, в одной задаче агент мог проверить права доступа к элементам UI, а в другой пропускал проверку, хотя она была важна.
Скилл для создания спеки
Твоя цель — выяснить все необходимое для точного планирования задачи: $ARGUMENTS
Как вести интервью:
- Если в $ARGUMENTS уже достаточно контекста — не начинай с нуля, выяви только пробелы.
- Задавай не более 2–3 вопросов за раз, начиная с наиболее рискованных или неясных аспектов.
- Не переходи к техническим решениям — только требования.
Когда открытых вопросов не осталось — составь черновик spec.md, покажи его в чате и дождись подтверждения перед сохранением.
Сохрани в .devflow/<branch>/spec.md:
- Цель задачи — что меняется с точки зрения пользователя/системы
- Требования — функциональные и нефункциональные
- Вне скоупа — что явно не входит в задачу
- Edge cases и исключения
- Критерии готовности — как проверить, что задача выполнена
- Архитектурные ограничения — инварианты из AGENTS.md (без предпочтений по подходу — это для /plan)
- Открытые вопросы (если остались)
Чтобы настроить агента под свои задачи, для начала я добавил в скилл чек‑лист, по которому проходился агент и проверял, все ли учли при подготовке задачи.
Что нужно учесть | Проверочные вопросы |
Права и роли | Кто может выполнить действие и что будет, если у пользователя нет прав? |
Корнер-кейсы | Что произойдет, если данных нет, есть только один элемент или достигнут максимальный объем? |
Сбои | Что произойдет, если недоступна сеть, внешний сервис или необходимый компонент системы? |
Конкурентный доступ | Что будет, если два пользователя одновременно работают с одними и теми же данными? |
Целостность данных | Корректно ли удаляются и обновляются связанные данные? |
Некорректный ввод | Какие форматы допустимы? Что делать с дубликатами? Какие есть ограничения на ввод? |
Необратимые действия | Можно ли откатить изменение? Что произойдет, если нельзя? |
Ограничения по объему данных | При каком объеме данных решение должно работать? |
Чтобы убедиться, что агент‑аналитик справляется с задачей, я добавил в процесс еще одного агента — критика. Перед тем как показать мне спецификацию, основной агент отдает ее на проверку субагенту. Критик ищет противоречия в требованиях и все, что мог пропустить агент‑аналитик, а я получаю спецификацию вместе со списком замечаний.
Субагент-критик
Ты критик предложенного решения. Твоя задача — найти проблемы, которые упустили агент и пользователь. Ты НЕ переписываешь решение — только указываешь на проблемы.
## Входные данные
Получаешь от вызывающего агента:
- Описание задачи
- Предложенное решение
- Релевантный контекст из кода
## Что искать
По приоритету:
1. Edge cases — сценарии которые решение не покрывает (пустые данные, ошибки, конкурентный доступ, граничные значения)
2. Область деструктивных операций — для каждой операции remove/delete/clear/overwrite/reset в решении: явно трассируй состояние. Что находится в объекте/массиве/DOM до операции? Что останется после? Не только целевые данные, но и все остальное что там было — оно тоже пострадает?
3. Скрытые недостатки — побочные эффекты, утечки, регрессии которые не очевидны из решения
4. Неверные предположения — на что решение молча опирается (стабильность API, формат данных, права, поведение при масштабировании)
5. Архитектурная согласованность — следует ли решение существующим паттернам кодовой базы? Не нарушает ли границы модулей, не утекает ли общая информация между несвязанными частями?
6. Blast radius — какой код вызывает затронутые части? Что может сломаться в стороне от точки изменения?
## Процесс
1. Изучи предложенное решение
2. Для каждой категории выше — проверь через код если нужно (Read, Grep, Glob)
3. Budget: до 3 исследований для Standard, до 5 для Deep (вызывающий агент укажет)
4. Если исследование опровергает находку — не включай ее в отчет
## Правила
- НЕ переписывай — только указывай на проблемы
- НЕ фильтруй — показывай все что нашел, фильтрация за основным агентом и пользователем
- Конкретика — не "может быть проблема", а "при условии X произойдет Y потому что Z"
- Не раздувай — если ничего не нашел, верни пустую таблицу
## Формат ответа
| Категория | Находка | Уверенность |
|-----------|---------|-------------|
| edge case | ... | high/medium/low |
| деструктивная операция | ... | high/medium/low |
| скрытый недостаток | ... | high/medium/low |
| неверное предположение | ... | high/medium/low |
| архитектура | ... | high/medium/low |
| blast radius | ... | high/medium/low |
Чтобы агент мог выполнять роль системного аналитика, нужно было дать ему доступ к информации, которую раньше я собирал сам. Для этого у агента есть набор инструкций о том, из чего собирать контекст:
— ADR, которые хранятся в репозитории рядом с кодом;
— бизнес‑требования к задачам, которые описаны в сервисе внутренней документации;
— описание верхнеуровневой архитектуры под конкретную задачу;
— пользовательские сценарии в формате Gherkin, чтобы агент писал по ним тесты, а затем с их помощью проверял свои же результаты;
— словарь терминов, чтобы при обсуждении задачи, а потом и в коде, агент использовал те же понятия, что и команда.
Помимо набора инструкций для наполнения контекста у агента есть инструменты, с помощью которых он работает с источниками информации, оператором и другими агентами:
Доступ к сетевым ресурсам и внутренней документации через MCP. Через Sourcebot MCP или Glab CLI агент может быстро прочитать код и историю его изменений в репозиториях связанных сервисов.
Plannotator для ревью. Спека занимает несколько экранов, и ее удобнее редактировать в специальном инструменте прямо в браузере. Агент публикует там спеку, а я оставляю замечания и отдаю их агенту пачкой.
Субагенты для обсуждения плана, генерации кода и прогона тестов, чтобы не забивать контекст основного агента.
Все вышеперечисленное никак не умещалось в один скилл. В итоге пришлось сгруппировать инструкции в девять скиллов для первой версии плагина. Агент исследовал задачу, готовил спецификацию, составлял план, генерировал код и открывал MR — все эти этапы я запускал вручную.
От плагина хотелось большей автоматизации, так что вторую версию я оформил в виде оркестратора с субагентами. Он последовательно запускал исследование задачи, готовил план, генерировал код и прогонял тесты. Архитектурно выглядело красиво, однако, если нужно было поменять то, что мы сделали на предыдущих этапах, с оркестратором возникали проблемы. Например, агент уже пишет код, а мы видим, что не учли в плане важное условие. Значит, надо исправлять план, менять код и снова запускать проверки. Каждый раз приходилось выяснять, что именно переделать и какие шаги повторить, но чаще всего перезапускали весь процесс.
Я решил не усложнять оркестратор и вернулся к набору скиллов: добавил к ним еще один скилл для проектирования архитектуры, а для генерации кода написал инструкции на использование субагентов. Так удалось сделать плагин архитектурно простым и более эффективным.
В текущую, четвертую, версию плагина я добавил агента‑критика, сверку с ADR и разбор проблем, которые возникали на этапе подготовки задачи. Оркестратор тоже вернулся, но только на этапе генерации кода: он берет задачи из плана и для каждой запускает субагента с чистым контекстом.
Иногда меня спрашивают, почему я не попросил нейронку сгенерировать плагин сразу и целиком или не воспользовался готовыми инструментами, типа OpenSpec. Отвечаю: потому что типовой инструмент, который не учитывает особенности моей работы, не решил бы мои задачи. Чтобы получить работающие инструкции и правила, пришлось пройти дорогой проб и ошибок от. начала до конца.
