Agentic Engineering

Допустим, в дневник боли ALGI нужно добавить отчёт: количество записей, средний и максимальный балл, несколько заметок. Агент умеет написать такую функцию. Но кто решит, можно ли включать заметки целиком? Кто проверит отчёт на пустом дневнике? Что произойдёт, если агент заодно изменит валидацию записей?

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

Здесь мы называем agentic engineering организацию такой работы: от постановки задачи и выдачи доступа до проверки изменений и решения об их принятии.

Кто за что отвечает

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

Например, задача запрещает публиковать отчёт и разрешает менять только код его формирования. Агенту можно выдать рабочую копию репозитория без токена почтового сервиса. Тогда отправка отчёта вообще недоступна из этого запуска. Ограничение не требует, чтобы модель правильно вспомнила запрет на каждом шаге.

Решение	Где его принимаем в примере
Какие поля содержит отчёт	В спецификации, до изменения кода.
Какие файлы можно менять	В задаче и настройках доступа runner.
Как реализовать расчёт среднего	Агент выбирает реализацию в разрешённых файлах.
Что делать при падении теста	Runner фиксирует ошибку; повтор разрешается по отдельному правилу.
Достаточно ли защиты личных данных	Проверки плюс ревью владельца этой части продукта.
Можно ли выпускать изменение	В обычном процессе приёмки команды.

Что получает модель

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

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

Уже используемый вами агентский CLI может выполнять часть функций harness: управлять доступами, хранить историю, запрашивать подтверждение. Внешнему runner стоит добавить недостающие части командного процесса: выбор задачи, независимые проверки и передачу результата на ревью.

Как разобрать один запуск

Возьмите недавнее изменение, сделанное с агентом, и откройте задачу рядом с diff. Найдите конкретный пункт задачи, который оправдывает каждое существенное изменение. Затем посмотрите вывод проверок: какая команда запускалась, над какой версией файлов и с каким результатом.

На примере отчёта вопросы будут такими:

• В задаче было разрешено включать исходные заметки?
• Тест использует заметку с телефоном или только безобидный текст?
• Агент изменил функцию валидации, хотя задача была про отчёт?
• После последнего изменения тесты запускались заново?

Если ответа нет, запишите, какого документа или события не хватает. Это даст первую задачу по улучшению процесса. Например: добавить в спецификацию пример заметки с контактом, а в runner - сохранение кода завершения теста.

С чего начнём в курсе

Сначала опишем поведение дневника и одну задачу на его реализацию. Затем разберём короткий Python-runner. В нём ответ модели заменён заранее подготовленными файлами, чтобы можно было воспроизводить каждый шаг без внешнего сервиса.

Далее тот же runner соберёт следующую версию себя, а она - часть ALGI. В практике приведены команды всей цепочки. Перед запуском разберём спецификацию поведения: именно из неё должны появиться критерии проверки.