Цикл работы с агентом

Цикл работы с агентом

Агентная разработка в курсе — не «попросил, вставил, сдал». Это цикл, в котором машина генерирует, а человек отвечает. Отсюда мера ответственности: сгенерированный агентом код — твой код, вопросы на защите будут к тебе.

Цикл состоит из трёх фаз. Ниже — то, что реально работает на проектах, а не идеальная схема из статьи.

Фаза A. Подготовка — до первой строчки кода

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

1. Собери контекст в отдельном пространстве. Задача, ограничения, примеры — в отдельный проект (Claude Projects, отдельный чат, папка research/), где формируется видение результата. Основной репозиторий не место для брейншторма.
2. Ресёрч воронкой: узкий → широкий → узкий. Сначала точный запрос, потом расширение поля, потом отбор релевантного. Каждый источник проверяется — агент уверенно цитирует несуществующее.
3. Напиши бриф. Одна страница: какой мир строим, для кого, чем меряем. Это вход и для команды, и для агента.
4. Создай память агента — AGENTS.md. Соглашения проекта, стек, грабли, глоссарий. Как её писать.
5. Окружение сразу. compose.yml и .env в первый день, а не «когда будет что запускать». Агент, у которого есть способ запустить код, работает принципиально иначе, чем агент, пишущий вслепую.

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

Фаза B. Работа — генерация под присмотром

6. «Гугли всё непонятное» — постоянная инструкция агенту. Незнакомый API, версия библиотеки, поведение фреймворка — ищем, а не галлюцинируем. Правило живёт в AGENTS.md, чтобы не повторять его каждую сессию.
7. Каждое действие просматривается человеком. Не уверен в решении — отправь агента искать подтверждение или дай направление сам. Принял не глядя — принял ответственность вслепую.

Два приёма, которые заметно повышают попадание:

• Брейншторм и исполнение — в разных сессиях. В финальный промпт уходит уже принятое решение, а не процесс его принятия.
• Заранее проговаривай, чего делать не нужно. Ограничения («не трогай схему БД», «без новых зависимостей») экономят больше времени, чем подробное описание желаемого.

Фаза C. Качество — планку держит машина

8. Ревью-циклы «пока не найдётся существенное». После пары модулей — полное ревью проекта агентом, исправления, повторный проход. Важная деталь: нужен порог значимости. Без него цикл не сходится — мелочи находятся бесконечно. Договорись заранее: чиним то, что ломает поведение или безопасность; косметику — списком в бэклог.
9. Инструментальная планка. uv (окружение и пакеты), ruff (линт и формат), ty (типы), pre-commit hook. Качество держит машина, а не сила воли в конце спринта.

uv sync                 # окружение из lock-файла
uv run ruff check --fix # линт и автоисправления
uv run ty check         # типы
uv run pre-commit install

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

Что из этого сдаётся

В лабе 3 роль Delivery сдаёт отчёт агентной разработки (docs/agent-workflow.md): что генерировал агент, что пришлось чинить руками, какие правила пришлось добавить в AGENTS.md. Это не бюрократия — это единственный способ отличить «агент написал систему» от «агент написал мне проблему, которую я не понимаю».

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