25 августа 2026 года Скотт Спенс опубликовал практический гайд «Agentic engineering: a practical guide to reliable coding agents» — не о том, как заставить агента писать больше кода, а о том, как построить вокруг него систему, в которой результат можно проверить. Главная мысль поста короткая и неудобная: модель может планировать и писать код, но она не решает, что её работа корректна. Ниже — разбор четырёх принципов гайда (context, scope, validation, evidence), анти-паттернов и чек-листа для старта, с переводом ключевых цитат.
Спенс — автор набора открытых инструментов вокруг своего агента my-pi (репозиторий), и гайд не теоретический: каждая секция ссылается на реализацию, которую он год держал в работе. Разбираем первоисточник по шагам. Версии и статусы — на момент публикации, 13.09.2026.
Что такое agentic engineering по Спенсу
Своё определение автор даёт в первом же абзаце, и оно расходится с популярным употреблением термина:
Agentic engineering is the practice of putting coding agents inside an engineering system that makes context, scope, validation, evidence and human review explicit. The model can plan and write the code, but it does not get to decide that its own work is correct.
Agentic engineering — это практика помещения кодинг-агентов в инженерную систему, где контекст, рамки задачи, проверки, доказательства и человеческое ревью явно выражены. Модель может планировать и писать код, но она не решает, что её собственная работа корректна.
— Scott Spence, «Agentic engineering: a practical guide», 25.08.2026
Термин ещё устоялся не до конца — Спенс честно пишет, что «не собирается притворяться, будто на него есть стандарт ISO». Популяризировал название Андрей Карпати в начале 2026 года, когда переосмыслил свой же термин «вайбкодинг» применительно к работе с агентами — эту историю Спенс приводит в тексте гайда со ссылкой на пост Карпати. Сам автор добавляет важную оговорку: работа не мистическая, это «спецификации, инструменты, права, тесты, наблюдаемость и ревью, применённые к работнику, который быстр, полезен и стохастичен».
Полезное различие — не «трогал ли код LLM», а где живёт доверие
Самое ценное место в гайде — критерий, который отделяет инженерию с агентами от вайбкодинга. Дело не в том, участвовала ли модель в написании кода:
The useful distinction is not whether an LLM touched the code. It is where trust lives. If the workflow is “prompt, glance at the result, ship and hope”, that is vibe coding. If the workflow has reviewable requirements, bounded access, mechanical checks, recorded evidence and a human accountable for the outcome, that is engineering with agents.
Полезное различие — не в том, касался ли код LLM. Оно в том, где живёт доверие. Если рабочий процесс — «промпт, взгляд на результат, запушить и надеяться» — это вайбкодинг. Если в процессе есть проверяемые требования, ограниченный доступ, механические проверки, записанные доказательства и человек, отвечающий за результат, — это инженерия с агентами.
— Scott Spence, там же
Вайбкодинг он не запрещает: для прототипов, одноразовых инструментов и исследования идей он «может быть блестящим». Проблема начинается, когда тот же уровень доверия переносят на production-код, где есть миграции данных, права доступа, восстановление после сбоев, аудит, доступность и «пользователи, делающие странные вещи в неправильном порядке». «Работает, когда я кликнул» — не доказательство, что эти системы продолжают работать.
Здесь автор цитирует наблюдение Саймона Уиллисона (май 2026): вайбкодинг и agentic engineering сближаются по мере того, как модели становятся надёжнее. Опасность не в большей автономии — в том, что повторяющиеся успехи тихо убирают контроль, который говорит вам, что следующий прогон сломан.
Четыре оси надёжности: context, scope, validation, evidence
Вся практическая часть гайда строится вокруг четырёх осей. Спенс предупреждает: универсального стека нет, правка документации не требует той же обвязки, что миграция базы. Ниже — как он формулирует каждую ось.
context — правильный контекст, а не максимальный
Свежая сессия агента знает только промпт и то, что вставил в контекст каркас (harness). Она не знает автоматически, почему существует архитектурное решение, что сломалось на прошлой неделе и какая правка пользователя изменила задачу. Поэтому Спенс начинает с восстановления фактов: осмотр репозитория и локальных инструкций, поиск текущей реализации и её тестов, прошлых сессий, исследование внешних API по первоисточникам — и только потом формулирует допущения.
Ключевая оговорка:
The goal is not maximum context. A giant instruction file can crowd out the task it is supposed to help with. The goal is relevant context that the agent can retrieve again when it needs it.
Цель не в максимальном контексте. Огромный файл инструкций вытесняет задачу, которой должен помогать. Цель — релевантный контекст, который агент может достать снова, когда он ему нужен.
— Scott Spence, там же
Под это он построил инструменты: pirecall для истории сессий и SQLite-сайдкар для больших выводов инструментов. Оба превращают «стену текста» в нечто поисковой — агент получает сфокусированные факты, а не каждое сообщение и строку лога. Как управлять контекстом агента в целом — отдельная тема блога, разбор в статье «Контекст ИИ-агента».
scope — границы рисковых задач держать вне разговора
Промпты хороши для намерения, но слабое место, чтобы хранить в них границу доверия:
Prompts are good for intent. They are a weak place to keep a trust boundary.
Промпты хороши для намерения. Они — слабое место для границы доверия.
— Scott Spence, там же
Для работы с материальным риском Спенс использует внешний каркас задачи (task harness), который хранит разрешённые пути, запрещённые операции, команды проверки, статус задачи и собранные доказательства вне рабочего контекста исполнителя. Агент может адаптировать план реализации, когда появляются новые факты, но не может тихо расширить собственные права или убрать неудобные проверки.
Разделение тонкое, и автор объясняет его прямо:
A static plan can be wrong. An editable outer policy is barely a policy at all.
Статичный план может быть неверным. Но редактируемая агентом внешняя политика — это уже почти не политика.
— Scott Spence, там же
Хороший каркас, по Спенсу, отвечает на пять вопросов: что может меняться? чего не должно случиться? как проверяется успех? какие доказательства собраны? когда агенту стоит остановиться и спросить? Не каждой задаче нужен каркас — «оборачивать исправление опечатки в миниатюрную фабрику программ — это церемония, а не строгость». Детальный дизайн — в отдельном посте «Coding agent harnesses with my-pi».
validation — вернуть проверки агенту
Агент не может исправить сбой, которого не видит. Спенс отдаёт агенту ту же обратную связь, что использует разработчик: ошибки типов, юнит- и интеграционные тесты, браузерные проверки, вывод линта, результаты сборки и диагностику языкового сервера. Добавление LSP в my-pi он называет изменением, которое дало больше, чем ожидал: агент может запросить диагностику только изменённого файла, а не гонять полную проверку проекта после каждой правки, а также находить определения и ссылки вместо того, чтобы угадывать происхождение символа.
Критично другое: проверка завершения — не «агент говорит, что выглядит хорошо», а независимая команда или наблюдаемый результат. Для пользовательского сценария — загрузить страницу и использовать её; для миграции — осмотреть получившуюся схему и данные.
A green test that only asserts a mocked fallback is not proof that the feature works.
Зелёный тест, который проверяет только замоканный fallback, — не доказательство, что функция работает.
— Scott Spence, там же
evidence — записывать следы и оценивать по результату, а не по резюме
Работу агента трудно улучшать, если каждая сессия исчезает в транскрипте. Спенс добавил локальную телеметрию (сессия, модель, использование инструментов), поисковую историю сессий и точечные эвалы при смене промпта, инструмента или стратегии поиска. Вопросы, на которые это позволяет отвечать: использовал ли агент новый инструмент? нашёл ли правильный источник? сократило ли изменение бесполезный вывод? поймал ли защитник сбой, ради которого был построен?
И здесь — важный принцип про эвалы:
Evals are not only checks against the final paragraph an agent writes. The outcome matters. Anthropic uses the useful example of a flight-booking agent: the transcript may say the flight was booked, but the real outcome is whether the reservation exists.
Эвалы — не только проверки финального абзаца, который написал агент. Важен исход. Anthropic приводит полезный пример агента бронирования авиабилетов: в транскрипте может быть сказано, что билет забронирован, но реальный исход — существует ли бронь.
— Scott Spence, там же
Для кода это значит: оценивать состояние репозитория и пользовательский путь, а не уверенность резюме. Методологии эвалов для агентов Anthropic разбирает в отдельной заметке «Demystifying evals for AI agents».
Секреты и права — системная забота, а не пункт в промпте
У кодинг-агента с доступом к shell, файловой системе и сети «зона поражения» больше, чем у чат-бокса. Промпт-инъекция приходит не только от того, что печатает пользователь, — она может приехать с веб-страницы, из issue, из README зависимости или из ответа инструмента. Правило Спенса простое: агенту — минимум доступа, нужный для задачи, а деструктивные и публичные действия — за границей человеческого подтверждения.
Под это он написал nopeek — утилиту, которая позволяет агенту запустить дочерний процесс с зависимостью от credentials, не печатая предварительно весь .env в его разговор:
It does not make arbitrary child output safe, but it removes one common and unnecessary exposure path.
Она не делает произвольный вывод дочернего процесса безопасным, но убирает один частый и ненужный путь утечки.
— Scott Spence, там же
Это продолжение линии безопасности недели: общий разбор поверхности атаки — в гайде по безопасности ИИ-агентов, а как ограничить сам инструмент — в разборе Claude Code --restricted.
Больше агентов — только когда работа реально параллельна
Мультиагентность полезна, когда задачи независимы: один агент исследует API, другой картографирует текущую реализацию, или агенты работают в изолированных worktree, а лид проверяет результаты. Она бесполезна, когда пять агентов нуждаются в одних и тех же файлах, контексте и решениях — тогда вы создали проблему координации и назвали её масштабом. Итог Спенс формулирует жёстко:
Delegation does not transfer accountability to a swarm-shaped cloud.
Делегирование не переносит ответственность на облако в форме роя.
— Scott Spence, там же
Лид обязан понимать объединённый результат. Паттерны владения модулями и изоляции контекста разобраны в статье «Агенты-мейнтейнеры».
Что не работает: четыре анти-паттерна
Спенс перечисляет паттерны, которые «продолжают проваливаться независимо от модели».
1. Давить промптом («prompting harder»). Повторение «не отклоняйся», «будь осторожен», «убедись, что тесты проходят» помогает на один ход, но не создаёт устойчивого контроля. Правило, которое действительно важно, надо превратить в тест или вынести за пределы полномочий исполнителя.
2. Загружать в контекст всё. Больше контекста — не значит лучше. Огромные файлы инструкций, все доступные MCP-инструменты и полные транскрипты сессий делают релевантный сигнал менее заметным. Нужны прогрессивное раскрытие и поисковые источники.
3. Позволять агенту ревьюить себя. Селф-ревью полезно, но это не независимое доказательство. Нужно запускать проверки, смотреть diff и для рисковых работ использовать отдельный путь ревью. Одно и то же ошибочное допущение может пережить планирование, реализацию и селф-ревью, если все три стадии делят общий контекст.
4. Автоматизировать неясное. Если люди не могут объяснить желаемый исход, передача задачи большему числу агентов даёт больше вывода, а не больше ясности. Исследование, обсуждение и маленький прототип могут быть правильным следующим шагом.
Цифры из реальной эксплуатации
Спенс честно признаёт: у него нет чистого бенчмарка, доказывающего, что его процесс ускоряет каждую задачу — разные проекты, модели и задачи делают такое утверждение трудно защитимым. Зато есть операционные свидетельства за период 28 июня — 25 июля 2026:
- агенты создали 173 записанных каркаса задач в 104 сессиях и 10 реальных рабочих пространствах проекта;
- из них 144 хотя бы раз дошли до состояния «завершено»;
- 155 записали доказательства проверки или ревью;
- механизм принуждения (enforcement) заблокировал действие 133 раза в 69 сессиях.
Эти числа не доказывают, что каждое завершённое изменение было хорошим. Они показывают, что система использовалась не в демо, агенты регулярно производили проверяемые доказательства, а enforceable-границы ловили реальное поведение.
Та же эксплуатация вскрыла слабые места самого подхода: некоторые паттерны запрещённых команд были слишком широкими; планам требовались легитимные правки чаще, чем ожидалось; устаревшее состояние задач путало поздние сессии; провалившиеся каркасы всё равно требовали человека для интерпретации результата; низкорисковые задачи замедлялись, когда их гнали через ту же церемонию. Вывод автора:
Agentic engineering is not “add more harness”. It is designing enough system for the risk and complexity in front of you.
Agentic engineering — это не «добавь больше каркасов». Это проектирование ровно той системы, которой требуют риск и сложность перед вами.
— Scott Spence, там же
С чего начать: минимальный контур
Вам не нужно строить my-pi или перенимать инструменты Спенса. Начать можно с одного реального сбоя, который повторяется. Чек-лист из гайда:
- Запишите условие успеха. Опишите наблюдаемый результат, а не только файлы, которые ожидаете изменить.
- Добавьте самую дешёвую детерминированную проверку. Существующий тест, проверка типов, линт-правило, браузерный путь или граничный скрипт.
- Покажите проверку агенту. Давайте сфокусированную обратную связь во время работы и требуйте полную проверку перед завершением.
- Держите инструкции маленькими. Стабильные правила проекта — в репозитории, ссылки — на более глубокие, извлекаемые документы.
- Ограничьте доступ. Пути, команды, credentials и внешние побочные эффекты — только те, что нужны задаче.
- Записывайте доказательства. Команды, результаты, решения и оставшиеся риски для ревью.
- Ревьюйте систему после сбоя. Спрашивайте, какой возможности или контроля не хватало, вместо того чтобы просто велеть следующей модели стараться сильнее.
После этого добавляйте механизмы только тогда, когда повторяющиеся сбои или риск задачи оправдывают их. Цель — не максимум автоматизации, а наименьший рабочий процесс, который делает результат заслуживающим доверия. Смежный материал о том, как оформить каркас своего агента, — в статье о создании собственных ИИ-агентов и в разборе тестирования как навыка агента.
Как это связано с выбором инструментов
Отдельный слой гайда — невидимые решения, которые агент принимает по ходу: какой инструмент или библиотеку выбрать. Если правила проекта не выражены механически, агент сам решает, что ему использовать, и это решение не всегда совпадает с вашим стеком. Как агенты выбирают инструменты и как направлять их выбор — разбор в статье «Как агенты выбирают инструменты: уроки из 17 000 сессий».
Честные ограничения
- Гайд — опыт одного человека. Спенс прямо пишет, что это его определение и его рабочий процесс, собранный вокруг my-pi на базе Pi. Чистого бенчмарка «работает быстрее» у него нет.
- Числа показывают использование, а не качество. 173 каркаса и 133 блокировки доказывают, что система применялась, а не что каждое изменение было хорошим.
- Каркасы сами создают издержки. Низкорисковые задачи через ту же церемонию замедлялись; устаревшее состояние задач путало поздние сессии.
- Каркас не отменяет человека. Провалившиеся задачи всё равно требовали человеческой интерпретации. Автор не утверждает, что инженерия заменяет ревью.
- Термин ещё устоялся не до конца. «Agentic engineering» используют для разных вещей; стандарта нет — это признаёт и сам автор.
- Инструменты специфичны. pirecall, nopeek и SQLite-сайдкар собраны под связку my-pi + Pi и его сценарии; перенос на другие агенты потребует адаптации.
Российские реалии
Отдельного русскоязычного разбора именно этого гайда на момент публикации нет — тема agentic engineering в рунете только начинает оформляться, поиск по Хабру по «agentic engineering» и «агентный инжиниринг» даёт общие материалы, а не переводы. Ближайшие по теме русскоязычные материалы — про контекст и поведение агентов:
- «Проблема не в промпте: как Claude Code плывёт на длинных задачах» (Habr, март 2026) — деградация длинных сессий и инженерия контекста;
- «Как правильно начинать новую сессию в Claude Code?» (vc.ru) — практика работы с сессиями;
- «Как стать вайбкодером» (spryt.ru) — реальный опыт старта с агентами из РФ.
Сами инструменты Спенса — открытые репозитории на GitHub (my-pi, pirecall, nopeek), лицензия my-pi — MIT, так что их можно запускать в России свободно, без VPN и зарубежных карт. Ограничение другое: агент, вокруг которого построен my-pi, — это Pi (pi.dev); доступность Pi из РФ и способы оплаты на момент публикации отдельно не проверялись. Сам подход (проверки вне решения модели, доказательства, ревью человеком) от региона не зависит и применим к любому агенту, включая доступные из РФ локальные и open-source варианты.
Вывод
Гайд Спенса ценен не новой терминологией, а рабочим критерием: пока «агент сказал, что готово» считается завершением задачи, у вас вайбкодинг с рисками production. Инженерия начинается там, где успех определяется внешними проверками, рамки задачи лежат вне промпта, доказательства записаны, а человек остаётся ответственным за результат.
«Лучшая модель для кодинга поменяется, — пишет Спенс в финале, — полезный рабочий процесс должен пережить эту смену». Модель — быстрый вероятностный работник; репозиторий, инструменты, проверки и ревью — инженерная система. Доверять стоит системе, а не работнику.
Дальше по теме: свои ИИ-агенты: как создать и настроить, как агенты выбирают инструменты, агенты-мейнтейнеры и модули кода, контекст ИИ-агента, ИИ-агент для тестирования и чистки тестов, безопасность ИИ-агентов.
