Эта статья подготовлена по третьему вебинару разработчиком агента Михаилом Костицыным о работе с ИИ-инструментами. Первые два вебинара были посвящены уровню компании и уровню проекта. Теперь разберем уровень пользователя: как построить личный процесс, в котором постановка задачи, реализация и проверка связаны в воспроизводимый процесс.

По общим тезисам каждый может проверить выводы у себя.

Записи вебинаров на RuTube / YouTube: 

Вебинар 1 — AI-инструменты для разработчиков 2026 

Вебинар 2 — Настройка проекта под агента

Вебинар 3 — Как работать с ИИ-агентом: SDD, TDD, самопроверка и субагенты

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

Почему хороший промпт не решает проблему целиком

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

На практике встречаются три сценария.

Агент решает другую задачу

Запрос «добавь тесты» допускает несколько трактовок. Агент может написать юнит-тесты, хотя команде нужны интеграционные или e2e-тесты. Формально запрос выполнен. Пользователь ожидал другой результат.

Причина в неполном запросе: пользователь не указал тип тестов, область покрытия и критерии готовности.

Контекст смешивает несколько задач

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

Рабочее правило:

Один чат соответствует одной задаче.

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

Код принимают без исполнимой проверки

Уверенный ответ модели легко принять за отчет о реально выполненной проверке. Но фразы «все готово» недостаточно. Нужны результаты сборки, тестов, линтера, анализа покрытия или проверки интерфейса.

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

Базовая схема: контролировать вход, выход и точки решений

Процесс можно разделить на пять этапов:

1. Изолировать контекст задачи.

2. Зафиксировать требования и ограничения в спецификации.

3. До реализации определить исполнимые критерии готовности.

4. Поручить агенту реализацию с обязательным запуском проверок.

5. Передать результат отдельному агенту на ревью, затем проверить критичные места человеку.

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

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

SDD: сначала зафиксировать задачу

Specification-Driven Development, или SDD, разделяет понимание задачи и написание кода. Сначала агент изучает проект, задает вопросы и готовит спецификацию. После проверки документа начинается реализация.

У спецификации два уровня.

Уровень проекта

AGENTS.md хранит сведения, которые нужны во многих задачах:

• структура репозитория;

• стек и версии;

• команды сборки и тестирования;

• архитектурные ограничения;

• правила именования;

• требования к тестам;

• файлы и директории, которые нельзя менять;

• критерии готовности изменений.

Такую информацию не приходится повторять в каждом запросе. Файл лежит в репозитории и доступен всей команде. После генерации его нужно проверить: ошибочное описание проекта будет влиять на все последующие задачи.

Уровень задачи

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

Минимальная спецификация задачи отвечает на вопросы:

Цель:
Какое поведение должно появиться или измениться?

Текущее состояние:
Как система работает сейчас?

Границы:
Какие модули и сценарии входят в задачу?
Что явно не входит?

Ограничения:
Какие API, зависимости, таблицы и форматы нельзя менять?

Критерии приемки:
Какие наблюдаемые результаты подтверждают готовность?

Проверка:
Какие тесты, команды и ручные сценарии нужно выполнить?

Полезный запрос для начала планирования:

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

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

Почему план и реализацию полезно разделять

Во время исследования агент читает много файлов, ищет связи и рассматривает варианты. Спецификация сжимает результаты этого исследования в проверяемый документ. Реализация может начаться в новом чате и опираться на утвержденную версию, не перенося всю промежуточную переписку.

Для большой задачи удобно хранить отдельные файлы:

.task/
├── plan.md
├── task-01-domain-model.md
├── task-02-api.md
├── task-03-tests.md
└── acceptance.md

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

TDD: создать проверку до реализации

Если SDD уточняет вход, Test-Driven Development формализует ожидаемый выход. Агент сначала пишет тесты, пользователь проверяет их, затем начинается реализация.

Рабочий цикл выглядит так:

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

Пример задания агенту:

Работай по TDD на основе утвержденной спецификации.
Сначала добавь тесты для критериев приемки.
Не переходи к реализации до подтверждения тестов.
После реализации запусти целевой набор тестов, полную сборку
и перечисли фактически выполненные команды с результатами.

Как соединить SDD и TDD

В режиме планирования нужно явно потребовать, чтобы тесты появились раньше реализации. Затем проверить порядок этапов в плане:

Спецификация
  -> тестовые сценарии
  -> падающие тесты
  -> реализация
  -> полный прогон
  -> отдельное ревью

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

Циклы обратной связи: агент проверяет себя до отчета пользователю

Цикл обратной связи, или feedback loop, связывает изменение кода с наблюдаемым сигналом. Агент не останавливается после записи файлов, а запускает проверку, читает результат и исправляет причину ошибки.

Критерий должен быть формальным и запускаемым. Например:

Продолжай работу, пока одновременно не выполнены условия:
проект компилируется;
проходят тесты модуля payments;
проходят интеграционные тесты сценария refund;
линтер не сообщает о новых нарушениях;
покрытие измененных ветвей не ниже согласованного порога.

В зависимости от задачи сигналом служат:

• ошибки компиляции;

• линтер;

• юнит-, интеграционные и e2e-тесты;

• покрытие строк и ветвей;

• пользовательский сценарий через Playwright MCP или Chrome MCP;

• специализированный проверочный скрипт.

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

Veai после правок получает из JetBrains IDE точные данные об ошибках кода. Для запуска тестов и анализа покрытия агент также использует инструменты IDE, если они доступны в проекте. Это сокращает число ручных передач между агентом и средой разработки: агент видит результат проверки и может продолжить исправление в том же рабочем процессе.

Опасность: агент меняет критерий вместо кода

Формулировка «добейся зеленых тестов» оставляет нежелательный путь: удалить проверку, добавить skip, ослабить проверочное утверждение или заменить реальную зависимость чрезмерным мокированием. Формально тесты проходят, но исходный дефект сохраняется.

Есть три уровня защиты.

1. Ограничить область редактирования

После проверки тестов запретить их изменение:

• закрыть тестовую директорию через .agentignore;

• в Veai включить Edit scope и указать файлы или директории, которые агенту разрешено менять;

• вынести реализацию в отдельную сессию с ограниченными правами.

.agentignore не всегда удобен, если его содержимое приходится часто менять под разные задачи. Поэтому в Veai мы добавили Edit Scope: область редактирования можно настроить прямо в агенте, указав файлы и директории, которые он может изменять. Не нужно каждый раз вручную открывать или закрывать доступ через .agentignore. Попробуйте Edit Scope в следующей задаче, где агенту требуется доступ только к части проекта.

2. Разделить роли

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

3. Проверять дифф тестов отдельно

Если тесты все же менялись, отдельный агент-ревьюер сначала анализирует именно этот дифф:

• не исчезли ли проверочные утверждения;

• не появились ли skip, disabled или ранний return;

• не заменена ли интеграционная проверка моками;

• проверяется ли негативный путь;

• падал ли новый тест до реализации.

Почему автор реализации не должен быть единственным ревьюером

Просьба «проверь свой код» в том же чате сохраняет исходный контекст, аргументы и предположения агента. Он уже выбрал решение и склонен подтверждать собственную линию.

Для ревью лучше открыть новый чат или запустить отдельного субагента. Ревьюер получает:

• спецификацию;

• дифф;

• результаты тестов;

• перечень рисков;

• требование искать конкретные дефекты, а не пересказывать изменения.

Пример задания:

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

Ревью можно разделить между несколькими агентами по независимым направлениям:

• корректность бизнес-логики;

• безопасность;

• конкурентный доступ;

• миграции и обратная совместимость;

• качество тестов.

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

Когда запускать субагентов

Субагент работает с отдельным контекстом, инструкциями и набором инструментов. Он возвращает основному агенту итог исследования или проверки, не перенося всю внутреннюю переписку.

Субагенты полезны в трех случаях.

Большая работа с независимыми частями

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

Анализ всего проекта

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

Ревью по нескольким рискам

Отдельные проверки корректности, тестов и безопасности не зависят друг от друга и хорошо распараллеливаются.

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

Практический критерий:

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

Параллельные агенты через git worktree

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

Пример:

git worktree add ../project-feature-a -b feature/a
git worktree add ../project-feature-b -b feature/b

После этого возможен процесс:

Рабочая копия A: агент реализует изменение A.
Рабочая копия B: агент реализует изменение B.
Основная копия: разработчик проверяет ранее подготовленное исправление ошибки.

Перед параллельным запуском нужно определить:

• какие файлы может менять каждый агент;

• есть ли пересечение миграций, конфигурации и API;

• кто и в каком порядке объединяет ветки;

• какие проверки запускаются после слияния;

• кто отвечает за итоговое ревью.

В вебинаре практическим пределом названы два-три агента, за которыми пользователь способен следить одновременно. Это ориентир из опыта спикера, а не жесткое ограничение. При росте числа параллельных потоков узким местом становится проверка изменений: код создается быстрее, чем человек успевает его читать и интегрировать.

Как выбрать глубину процесса

Методология зависит от сложности и риска задачи.

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

Настройка личного процесса за 30 минут

На вебинаре предложен короткий стартовый чек-лист.

1. Глобальные Rules

Rules задают постоянные правила поведения агента. Зафиксируйте предпочтения, которые действуют во всех проектах:

• язык ответа;

• формат плана и отчета;

• допустимая автономность;

• обязанность задавать вопросы при неоднозначности;

• запрет начинать реализацию до подтверждения плана;

• требование перечислять запущенные проверки и их результаты;

• требование отдельного ревью для рискованных изменений.

Пример:

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

2. Один или два личных Skills

Skills описывают повторяемые процессы, которые агент применяет по запросу или при подходящих условиях. Начните с одного-двух процессов, например:

• подготовка спецификации;

• процесс TDD;

• ревью изменений;

• анализ падающего теста.

Skill должен описывать одну цель, последовательность действий, ограничения и формат результата.

3. Долгосрочная память

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

4. Проектный слой

В репозитории подготовьте:

• актуальный AGENTS.md;

• Rules и Skills проекта;

• .agentignore;

• настройки MCP-серверов;

• документированные команды сборки и тестов.

В Veai функция «Онбординг агента в проект» выполняет описанную выше настройку автоматически. Агент задает вопросы о роли пользователя, языках, технологиях, стиле общения, степени автономности и повторяемых задачах. На основе ответов он готовит глобальные Rules, подходящие Skills и AGENTS.md для проекта. Пользователю остается проверить предложенные файлы и скорректировать формулировки под свою работу.

5. Проверка на реальной задаче

Возьмите изменение среднего размера и измерьте не впечатление от ответа, а процесс:

• сколько уточнений потребовалось;

• сохранил ли агент границы задачи;

• падали ли тесты до реализации;

• какие проверки агент запустил сам;

• что нашел отдельный ревьюер;

• сколько ручных итераций понадобилось после отчета о готовности.

По результатам скорректируйте Rules и Skill. Личный процесс развивается на реальных сбоях, а не на абстрактном шаблоне.

Чек-лист перед передачей задачи агенту

Контекст

• Для задачи открыт отдельный чат.

• AGENTS.md актуален.

• Агенту доступны только нужные файлы и инструменты.

• Большая задача разделена на подзадачи, каждая помещается в отдельный контекст.

Спецификация

• Цель описана через наблюдаемое поведение.

• Границы задачи перечислены явно.

• Ограничения по API, данным и зависимостям зафиксированы.

• Неоднозначные решения согласованы.

• Критерии приемки можно проверить.

Реализация и тесты

• Тесты подготовлены до кода реализации, если риск задачи этого требует.

• Пользователь проверил тесты до перехода к реализации.

• После утверждения тесты защищены от изменения исполнителем.

• Агент знает точные команды сборки, тестов и линтера.

• Цикл обратной связи требует исправлять код до успешного прогона.

Ревью

• Ревью выполняется в отдельном контексте.

• Ревьюер получил спецификацию, дифф и результаты проверок.

• Изменения тестов проверены отдельно.

• Замечания содержат путь, строку и сценарий ошибки.

• Критичные решения подтверждены человеком.

Параллельная работа

• Подзадачи действительно независимы.

• Область каждого агента ограничена.

• Пересечения файлов и контрактов определены заранее.

• Назначены порядок слияния и итоговые проверки.

• Очередь ревью не перегружена количеством агентов.

Итог

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