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

1. Опишите результат, который хотите увидеть.

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

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

2. Дайте агенту задачу с понятным окончанием.

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

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

3. Держите одну понятную очередь.

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

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

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

4. Проверяйте изменение, а не объём активности.

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

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

Различайте сохранённый код, локально проверенный результат, опубликованное изменение и то, что вы уже приняли. Это разные состояния; переход между ними должен быть виден.

5. Согласуйте, где нужно ваше решение.

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

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

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

6. Добавляйте параллельность там, где понятны границы.

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

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

Это отправная точка, которую можно приспособить к своему процессу. Она не требует определённого трекера, редактора или модели. Увеличивайте сложность тогда, когда она помогает выполнять и проверять работу.

Посмотреть, как устроен Vabes →