Agentic Engineering

С какой ситуации всё обычно начинается

Команда подключает AI coding tool. Первые результаты выглядят хорошо: мелкие fixes делаются быстро, boilerplate исчезает, тесты иногда даже пишутся вместе с кодом.

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

• PR становится больше, чем reviewer готов держать в голове;
• agent чинит симптом, но не root cause;
• одна задача незаметно превращается в refactor соседних файлов;
• никто не может объяснить, какой context был у agent в момент решения;
• "tests pass" не отвечает на вопрос, был ли закрыт product intent;
• approvals становятся механическими, потому что запросов слишком много.

Это не значит, что AI coding бесполезен. Это значит, что bottleneck переехал. Раньше главным ограничением было написание кода. Теперь ограничение - постановка задачи, проверка, интеграция и контроль side effects.

Что мы называем Agentic Engineering

Agentic Engineering — это проектирование инженерной среды, в которой agent может выполнять ограниченную работу и оставлять проверяемый след.

Практически это означает:

spec -> task contract -> selected context -> harness -> backend output -> checks -> logs -> review

Модель важна, но она не центральная часть системы. Центральная часть — границы, проверки и evidence.

Из чего состоит agent

Полезная базовая формула из engineering-практики:

agent = model + context + tools

Если перевести её на язык software-команды:

Часть	Что означает для команды
Model	Reasoning engine: понимает intent, выбирает следующий шаг, решает, когда нужен tool.
Context	Working set: task, project rules, specs, trajectory, tool results, state.
Tools	Action interfaces: file read/write, commands, search, tests, API calls, human handoff.

Этой формулы достаточно для demo. Для production её нужно расширить:

agent = model + harness
harness = context + tools + constrain + verify + correct

Constrain ограничивает действие до разрешённого blast radius. Verify проверяет, что работа реально сделана. Correct описывает recovery: retry, rollback, blocked state или handoff человеку.

Именно поэтому хендбук постоянно возвращается к contracts, policy, checks и logs. Они не «обвязка вокруг настоящего AI», а та часть системы, которая превращает demo в engineering workflow.

Как выглядит хороший run

Хороший agent run можно объяснить другому инженеру без демонстрации чата:

1. Вот spec, из которого взята задача.
2. Вот task contract: scope, non-goals, acceptance criteria.
3. Вот context pack, который получил agent.
4. Вот backend, который выполнял работу.
5. Вот files, которые он изменил.
6. Вот checks и их output.
7. Вот policy decisions и approvals.
8. Вот итог: done, failed, blocked или needs_review.

Если любой пункт отсутствует, reviewer вынужден доверять словам агента или памяти автора задачи. Для production workflow этого мало.

Такой run можно рассматривать как trajectory: последовательность user/task messages, assistant decisions, tool calls, tool results, checks и итоговой classification. Важно не только сохранить финальный diff, но и понимать, на каком шаге agent принял решение, какой feedback получил и почему остановился.

Какие слои нужны вокруг модели

Слой	Что решает
Spec	Какое поведение нужно получить и зачем.
Task contract	Как ограничить работу агента до проверяемой задачи.
Context	Что агенту нужно знать именно для этого run.
Harness	Как запускать backend, применять output, запускать checks и классифицировать result.
Verification	Какие внешние сигналы доказывают, что работа годится.
Observability	Как восстановить ход run после факта.
Governance	Какие действия требуют approval, rollback или human review.

Каждый следующий слой снижает необходимость верить агенту на слово.

Три дисциплины, которые нельзя смешивать

Prompt engineering отвечает за конкретную инструкцию модели.

Context engineering отвечает за то, какой context доступен агенту, как он выбран, сжат, изолирован и поддерживается актуальным.

Harness engineering отвечает за производственную линию вокруг агента: task queue, runner, sandbox, tool access, checks, logs, retry, review и result classification.

Что сделать руками

Возьмите один недавний AI-assisted change и восстановите его как run:

• какая была исходная задача;
• где был spec или хотя бы intent;
• какие files agent изменил;
• какие checks реально запускались;
• что reviewer должен был проверить вручную;
• где run должен был стать blocked или needs_review.

Не нужно сразу строить platform. Достаточно увидеть разницу между "agent написал код" и "команда получила проверяемый engineering artifact".