Задавайте AI-агенту не шаги, а артефакты работы

21 августа 2026 · 5 минут чтения

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

Обычно постановку задачи coding-агенту — инструменту на основе искусственного интеллекта, который читает репозиторий, меняет файлы и запускает проверки, — улучшают, добавляя инструкции: что прочитать, в каком порядке действовать, какие команды выполнить. Для повторяемой процедуры это правильно. Но в исследовании, диагностике и другой открытой работе маршрут заранее известен не полностью.

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

Что считать артефактом

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

Формат вторичен. Это может быть файл в Git-репозитории — директории проекта с историей изменений, — задача, таблица или запись в другой системе. Важно другое:

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

Передача работы (handoff) — это процесс, а не артефакт. Артефактом может быть handoff-документ: сохранённая запись о текущем состоянии, принятых решениях, открытых вопросах, проверках и следующем шаге. Но если эти факты уже живут в задаче, спецификации, коде и тестах, лучше сослаться на них, а не создавать ещё одну версию рабочей истины.

Просьба «поддерживай эти артефакты в актуальном состоянии» оставляет агенту свободу в способе выполнения и может сделать результат каждого этапа наблюдаемым — если для артефактов заранее определены роль и способ проверки.

Отчёт не заменяет артефакты

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

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

Что меняется в управлении

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

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

• какую рабочую истину разрешено менять;
• какие утверждения требуют доказательств;
• где нужен выбор человека;
• на какие артефакты должен ссылаться итоговый отчёт.

Пример: импорт данных с неожиданным дублем

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

1. В карточке задачи GitHub issue записаны ожидаемое поведение импорта, ограничения и критерии приёмки — наблюдаемые условия готовности.
2. Агент создаёт спецификацию, изменение кода и тесты. Эти файлы становятся артефактами работы, а не пересказом будущего результата.
3. Во время реализации обнаруживается два клиента с одним внешним идентификатором. Исходная постановка не говорит, объединять записи, отклонять файл или запрашивать выбор пользователя.
4. Агент фиксирует расхождение и варианты в карточке задачи. Решение остаётся за человеком, потому что меняет продуктовое поведение.
5. После решения обновляются спецификация, код и тесты. Проверка должна подтвердить уже согласованное правило обработки дубля.
6. Итоговый отчёт ссылается на эти артефакты и сообщает, что проверено. Следующая сессия может продолжить работу по их текущему состоянию, не восстанавливая решение из переписки.

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

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

Где проходит граница

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

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

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

Рабочая гипотеза, а не стандарт

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

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

Источники

• How OpenAI uses Codex — рекомендации формулировать задачи как GitHub issue и хранить постоянный контекст в AGENTS.md.
• ProductSpec — пример разделения намерения, доказательств выполнения и истории решений.
• SpecDD — пример локальных спецификаций, которые связывают контракты, код, тесты и задачи.
• Intermediate Artifacts as First-Class Citizens — свежая исследовательская работа о долговечных, проверяемых промежуточных артефактах; это proposal, а не подтверждённый отраслевой стандарт.

Термины

• Артефакт работы — сохраняемый результат или часть состояния задачи, которую можно проверить и передать следующему исполнителю.
• Coding-агент — инструмент на основе искусственного интеллекта, который читает репозиторий, изменяет файлы, запускает команды и проверяет результат.
• Git-репозиторий — директория проекта вместе с историей изменений и служебными данными Git.
• GitHub issue — карточка задачи, ошибки или обсуждения в GitHub с описанием и историей изменений.
• Критерии приёмки — наблюдаемые условия, по которым проверяют готовность результата.
• AGENTS.md — файл с локальными правилами работы coding-агентов в конкретном репозитории.
• Передача работы (handoff) — процесс передачи текущего состояния задачи другому человеку или агенту; сохранённый handoff-документ может быть артефактом этой передачи.

Автор: Данил Письменный · Дата: 21 августа 2026