[Перевод] 8 уровней агентной инженерии

Способности AI в написании кода растут быстрее, чем наше умение этими способностями пользоваться. Поэтому рост баллов на SWE-bench не коррелирует с метриками продуктивности, которые волнуют инженерных руководителей. Когда команда Anthropic выкатывает продукт вроде Cowork за 10 дней, а другая команда не может довести до ума сломанный POC на тех же моделях, разница в одном: первые закрыли разрыв между возможностями моделей и практикой, вторые — нет.

Этот разрыв не закрывается за одну ночь. Он закрывается по уровням. Их 8. Большинство читающих эту статью, скорее всего, уже прошли первые несколько, и стоит стремиться к следующему, потому что каждый новый уровень — это резкий скачок производительности, а каждое улучшение моделей усиливает этот эффект ещё больше.

Есть и вторая причина: мультиплеерный эффект. Ваша продуктивность зависит от уровня коллег больше, чем кажется. Допустим, вы на уровне 7, поднимаете несколько хороших PR фоновыми агентами, пока спите. Если в репозитории нужен approve от коллеги, а коллега на уровне 2 и ревьюит руками, ваша эффективность упирается в него. Поэтому в ваших интересах тянуть команду вверх.

По итогам разговоров с несколькими командами и отдельными разработчиками, практикующими AI-кодинг, вот прогрессия уровней, которую я наблюдал (не строго последовательная).

Уровни 1 и 2: Tab Complete и Agent IDE

Два уровня коротко, в основном для полноты картины.

Всё началось с Copilot и tab complete. Нажимаешь tab — код дописывается. Многие уже забыли, новички в агентной инженерии и вовсе пропустили. Лучше всего это работало для опытных разработчиков, которые могли набросать скелет кода, а AI заполнял пробелы.

AI-ориентированные IDE вроде Cursor изменили расклад: чат, подключённый к кодовой базе, сделал мультифайловые правки радикально проще. Но потолком всегда оставался контекст. Модель могла помочь только с тем, что видела, и раздражающе часто она либо не видела нужный контекст, либо видела слишком много лишнего.

На этом уровне многие также экспериментируют с plan mode в своём кодинг-агенте: переводят грубую идею в структурированный пошаговый план для LLM, итерируют этот план, потом запускают реализацию. На этом этапе это работает хорошо и помогает сохранять контроль. Хотя на более поздних уровнях зависимость от plan mode снижается.

Уровень 3: Context engineering

Buzz-фраза 2025 года. Context engineering стал актуален, когда модели начали надёжно следовать разумному количеству инструкций при правильном объёме контекста. Шумный контекст был так же плох, как недостаточный, поэтому основные усилия шли на повышение информационной плотности каждого токена. Мантра: «Каждый токен должен заслужить своё место в промпте».

На практике context engineering связан с бóльшим количеством вещей. Это системный промпт и rules-файлы (.cursorrules, CLAUDE.md). Это описания инструментов, потому что модель читает эти описания, решая, какой инструмент вызвать. Это управление историей диалога, чтобы долгоживущий агент не терял нить через десять шагов. Это решение, какие инструменты вообще показывать на каждом шаге, потому что избыток вариантов перегружает модель так же, как перегружает людей.

Сейчас о context engineering говорят меньше. Баланс сместился в сторону моделей, которые прощают более шумный контекст и рассуждают на более грязных данных (большие контекстные окна тоже помогают). Но следить за тем, что съедает контекст, по-прежнему важно. Несколько примеров:

• Маленькие модели более чувствительны к контексту. Голосовые приложения часто используют маленькие модели, а размер контекста коррелирует с time to first token, что влияет на latency.

• Токеноёмкие инструменты и модальности. MCP вроде Playwright и image inputs сжигают токены быстро, выталкивая вас в «compact session» в Claude Code гораздо раньше ожидаемого.

• Агенты с доступом к десяткам инструментов, где модель тратит больше токенов на парсинг tool schemas, чем на полезную работу.

Общий вывод: context engineering не исчез, а эволюционировал. Фокус сместился с фильтрации плохого контекста на обеспечение правильного контекста в правильное время. Этот сдвиг готовит почву для уровня 4.

Уровень 4: Compounding engineering

Context engineering улучшает текущую сессию. Compounding engineering улучшает каждую последующую. Популяризированный Кираном Классеном, compounding engineering стал переломным моментом: и для меня, и для многих других стало ясно, что «вайб-кодинг» способен на гораздо больше, чем просто прототипирование.

Это цикл: спланировать, делегировать, оценить, зафиксировать результат. Вы планируете задачу с достаточным контекстом для успеха LLM. Делегируете. Оцениваете результат. И затем, что критично, фиксируете полученные выводы: что сработало, что сломалось, какому паттерну следовать в следующий раз.

Шаг фиксирования результатов (codify) — то, что создаёт компаундинг. LLM не имеют состояния. Если модель вчера добавила зависимость, которую вы явно удалили, завтра она сделает это снова, если вы ей не скажете. Самый распространённый способ замкнуть этот цикл — обновить CLAUDE.md (или аналогичный rules-файл), чтобы урок был вшит в каждую будущую сессию.

Практикующие compounding engineering обычно остро осознают, какой контекст получает их LLM. Когда модель ошибается, они инстинктивно думают о недостающем контексте, а не о некомпетентности модели. Именно этот инстинкт делает возможными уровни с 5 по 8.

Уровень 5: MCP и Skills

Уровни 3 и 4 решают проблему контекста. Уровень 5 решает проблему возможностей. MCP и кастомные skills дают вашей LLM доступ к базе данных, API, CI-пайплайну, дизайн-системе, Playwright для браузерного тестирования, Slack для нотификаций. Вместо того чтобы просто думать о вашей кодовой базе, модель теперь может на ней действовать.

Материалов по MCP и skills уже достаточно, так что не буду пересказывать, что это такое. Но вот примеры использования: моя команда делит общий PR review skill, над которым мы все итерируем (и продолжаем), — он условно запускает подагентов в зависимости от характера PR. Один отвечает за интеграционную безопасность с базой данных. Другой запускает анализ сложности, чтобы отловить избыточность или оверинжиниринг. Третий проверяет качество промптов на соответствие стандартному формату команды. Плюс линтеры и Ruff.

Зачем столько вкладывать в review skill? Потому что когда агенты начинают генерировать PR в объёмах, человеческий ревью становится узким местом, а не гарантией качества. Latent Space убедительно доказывает, что code review в привычном виде мёртв. На его место приходит автоматизированный, консистентный, skills-driven review.

Со стороны MCP: я использую Braintrust MCP, чтобы LLM могла запрашивать логи eval-ов и вносить изменения напрямую. DeepWiki MCP даёт агенту доступ к документации любого опенсорсного репозитория без ручного подтягивания в контекст.

Когда несколько человек в команде пишут свои версии одного и того же skill, имеет смысл объединить их в общий реестр. Block (мои соболезнования) опубликовал хороший материал об этом: они построили внутренний маркетплейс skills с более чем 100 скиллами и курированными бандлами для конкретных ролей и команд. Skills проходят тот же процесс, что и код: pull requests, ревью, история версий.

Ещё одна тенденция: LLM всё чаще используют CLI-инструменты вместо MCP (и, кажется, каждая компания выпускает свой: Google Workspace CLI, Braintrust скоро запустит свой). Причина — эффективность по токенам. MCP-серверы инжектируют полные tool schemas в контекст на каждом шаге, использует их агент или нет. В случае с CLI подход меняется: агент запускает целевую команду, и только релевантный вывод попадает в контекстное окно. Я активно использую agent-browser именно по этой причине вместо Playwright MCP.

Прежде чем двигаться дальше. Уровни 3-5 — фундамент для всего последующего. LLM непредсказуемо хороши в одних вещах и плохи в других, и нужно выработать интуицию, где проходят эти границы, прежде чем наращивать автоматизацию. Если контекст шумный, промпты недо- или неверно специфицированы, а инструменты плохо описаны, уровни 6-8 просто усиливают хаос.

Уровень 6: Harness engineering и автоматические feedback loops

Тут начинается самое интересное.

Context engineering — это курирование того, что модель видит. Harness engineering — это построение всей среды, инструментов и feedback loops, которые позволяют агентам делать надёжную работу без вашего вмешательства. Дайте агенту feedback loop, а не просто редактор.

Команда OpenAI Codex подключила Chrome DevTools, инструменты observability и навигацию по браузеру к рантайму агента, чтобы тот мог делать скриншоты, проходить UI-пути, запрашивать логи и валидировать собственные исправления. По одному промпту агент может воспроизвести баг, записать видео и реализовать фикс. Затем он валидирует, взаимодействуя с приложением, открывает PR, отвечает на review-комментарии и мёржит, эскалируя только когда требуется человеческое суждение. Агент не просто пишет код. Он видит, что код производит, и итерирует — как это делал бы человек.

Моя команда строит голосовых и чат-агентов для техподдержки, и я сделал CLI-инструмент converse, который позволяет любой LLM общаться с нашим бэкенд-эндпоинтом и вести пошаговые диалоги. LLM вносит изменения в код, использует converse для тестирования разговоров на живой системе и итерирует. Иногда эти циклы самоулучшения работают по несколько часов подряд. Это особенно круто работает, когда результат верифицируем: разговор должен идти по такому-то флоу, или вызывать такие-то инструменты в таких-то ситуациях (например, эскалация на человека).

Концепция, которая это обеспечивает, — backpressure: автоматические механизмы обратной связи (системы типов, тесты, линтеры, pre-commit hooks), позволяющие агентам обнаруживать и исправлять ошибки без человеческого вмешательства. Если хотите автономности, нужен backpressure. Иначе получите генератор слопа. Это распространяется и на безопасность. CTO Vercel аргументирует, что агенты, генерируемый ими код и ваши секреты должны жить в отдельных trust domains, потому что prompt injection, спрятанная в лог-файле, может заставить агента слить ваши креденшелы, если всё работает в одном контексте безопасности. Границы безопасности — это backpressure: они ограничивают то, что агент может сделать, когда сходит с рельсов, а не только то, что ему следует делать.

Два совета:

• Проектируйте с заделом на throughput, а не на совершенство. Когда требуется совершенство на каждый коммит, агенты наваливаются на один и тот же баг и перезаписывают фиксы друг друга. Лучше допускать мелкие неблокирующие ошибки и делать финальный quality pass перед релизом. Мы делаем то же самое с коллегами-людьми.

• Ограничения лучше инструкций. Пошаговый промптинг («сделай A, потом B, потом C») всё больше устаревает. По моему опыту, определение границ работает лучше чеклистов, потому что агенты зацикливаются на списке и игнорируют всё, что в него не входит. Лучший промпт: «Вот что я хочу, работай, пока не пройдёшь все эти тесты».

Вторая половина harness engineering — убедиться, что агент может ориентироваться в вашем репозитории без вас. Подход OpenAI: держать AGENTS.md в пределах примерно 100 строк как оглавление, ссылающееся на структурированную документацию в других местах, и сделать актуальность документации частью CI, а не полагаться на ad hoc обновления, которые устаревают.

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

Уровень 7: Background agents

Провокационный тейк: plan mode умирает.

Борис Черный, создатель Claude Code, по-прежнему начинает 80% задач в plan mode. Но с каждым новым поколением моделей процент успеха с первого раза после планирования растёт. Я думаю, мы приближаемся к точке, где plan mode как отдельный шаг с участием человека уйдёт в прошлое. Не потому что планирование не важно, а потому что модели становятся достаточно хороши, чтобы планировать самостоятельно. Важная оговорка: это работает только если вы проделали работу на уровнях 3-6. Если контекст чист, ограничения явные, инструменты хорошо описаны, а feedback loops настроены, модель может планировать без вашего предварительного одобрения. Если этой работы не было, план придётся курировать вручную.

Планирование как общая практика не уходит. Оно меняет форму. Для новичков plan mode остаётся правильной точкой входа (как описано на уровнях 1 и 2). Но для сложных фич на уровне 7 «планирование» выглядит не как пошаговый outline, а скорее как исследование: зондирование кодовой базы, прототипирование вариантов в worktrees, картирование пространства решений. И всё чаще background agents делают это исследование за вас.

Именно благодаря этим возможностям нам открывается путь к background agents. Если агент может сгенерировать хороший план и исполнить его без вашего одобрения, он может работать асинхронно, пока вы занимаетесь чем-то другим. Критический сдвиг: от «нескольких вкладок, которыми я жонглирую» к «работе, которая происходит без меня».

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

Можно запускать несколько Ralph loops параллельно, но чем больше агентов вы поднимаете, тем заметнее, на что уходит ваше время: координация, выстраивание очерёдности задач, проверка результатов, ручное вмешательство в их поведение. Вы больше не пишете код. Вы стали мидл-менеджером. Нужен агент-оркестратор, который занимается диспетчеризацией, чтобы вы могли фокусироваться на намерении, а не на логистике.

Инструмент, который я активно использую, — Dispatch, skill для Claude Code, превращающий сессию в командный центр. Вы остаётесь в одной чистой сессии, пока воркеры делают тяжёлую работу в изолированных контекстах. Диспетчер планирует, делегирует и отслеживает, сохраняя ваше основное контекстное окно для оркестрации. Когда воркер застревает, он поднимает уточняющий вопрос, а не молча ломается.

Dispatch работает локально, что идеально для быстрой разработки, когда хочется быть ближе к работе: быстрее обратная связь, проще отлаживать интерактивно, без инфраструктурных накладных. Inspect от Ramp — комплементарный подход для более долгих автономных задач: каждая сессия агента поднимается в облачной песочнице с полным dev-окружением. PM замечает UI-баг, отмечает в Slack, и Inspect подхватывает задачу, пока ваш ноутбук закрыт. Компромисс — операционная сложность (инфраструктура, снапшоты, безопасность), но вы получаете масштаб и воспроизводимость, недоступные локальным агентам. Я бы использовал оба подхода (локальные и облачные background agents).

Один паттерн, который оказался на удивление мощным: использовать разные модели для разных задач. Лучшие инженерные команды не состоят из клонов. Они состоят из людей с разным мышлением, разным опытом, разными сильными сторонами. Та же логика применима к LLM. Эти модели по-разному дообучались и имеют содержательно разные склонности. Я регулярно отправляю Opus на реализацию, Gemini на исследовательский ресёрч и Codex на ревью, и совокупный результат сильнее, чем у любой одной модели. Мудрость толпы, но для кода.

Критически важно разделять реализатора и ревьюера. Я усвоил это на своём опыте: если один и тот же инстанс модели реализует и оценивает свою работу, он предвзят. Он будет замазывать проблемы и рапортовать, что все задачи завершены, когда это не так. Это не злой умысел, а та же причина, по которой вы не проверяете собственный экзамен. Пусть другая модель (или другой инстанс с промптом, заточенным под ревью) делает проверочный проход. Качество сигнала резко вырастет.

Background agents также открывают шлюзы для интеграции CI с AI. Когда агенты могут работать без человека, запускайте их из существующей инфраструктуры. Docs-бот, который перегенерирует документацию на каждый merge и поднимает PR для обновления CLAUDE.md (мы это делаем, и это огромная экономия времени). Security-ревьюер, сканирующий PR и открывающий фиксы. Dependency-бот, который реально обновляет пакеты и запускает тесты, а не просто помечает их. Хороший контекст, компаундинговые правила, способные инструменты и автоматические feedback loops — теперь работающие автономно.

Уровень 8: Автономные агентные команды

Этот уровень пока никто не освоил, хотя несколько команд продвигаются в его направлении. Это самый передовой .

На уровне 7 у вас есть LLM-оркестратор, раздающий работу LLM-воркерам по схеме hub-and-spoke. Уровень 8 убирает это узкое место. Агенты координируются друг с другом напрямую: забирают задачи, делятся находками, отмечают зависимости, разрешают конфликты без маршрутизации через единого оркестратора.

Экспериментальная фича Agent Teams в Claude Code — ранняя реализация: несколько инстансов работают параллельно на общей кодовой базе, каждый участник действует в своём контекстном окне и общается напрямую с другими. Anthropic использовала 16 параллельных агентов, чтобы с нуля написать C-компилятор, способный скомпилировать Linux. Cursor запустил сотни конкурентных агентов на несколько недель, чтобы с нуля построить браузер и мигрировать собственную кодовую базу с Solid на React.

Но если присмотреться, видны шероховатости. Cursor обнаружил, что без иерархии агенты становились risk-averse и буксовали без прогресса. Агенты Anthropic ломали существующий функционал, пока не был добавлен CI-пайплайн для предотвращения регрессий. Все экспериментирующие на этом уровне говорят одно: мультиагентная координация — сложная задача, и никто пока даже не близок к чему-то более-менее оптимальному.

Я честно не думаю, что модели готовы к такому уровню автономии для большинства задач. И даже если бы они были достаточно умны, они всё ещё слишком медленные и слишком токеноёмкие, чтобы это было экономически оправдано за пределами moonshot-проектов вроде компиляторов и браузеров (впечатляюще, но далеко от чистоты). Не удивлюсь, если уровень 8 со временем станет доминирующим паттерном, но сейчас я бы вкладывал энергию в уровень 7 (если вы не Cursor и прорыв в этой области — не ваш бизнес).

Уровень ?

Неизбежный вопрос «что дальше».

Когда вы научитесь оркестрировать агентные команды без особого трения, нет причин, по которым интерфейс должен оставаться текстовым. Голосовое (а может, мысль-к-мысли?) взаимодействие с кодинг-агентом — разговорный Claude Code, а не просто voice-to-text ввод — естественный следующий шаг.

Есть те, кто гонится за идеальным one-shot: сформулируй, что хочешь, и AI соберёт это безупречно с первого раза. Проблема в том, что это предполагает, что мы, люди, точно знаем, чего хотим. Это не так. Так никогда не было. Разработка ПО всегда была итеративной, и я думаю, всегда будет. Просто станет гораздо проще, выйдет далеко за рамки текстового взаимодействия и будет происходить значительно быстрее.

Так на каком вы уровне? И что делаете, чтобы перейти на следующий?

Русскоязычное сообщество про AI в разработке

Друзья! Перевод этой статьи подготовила команда ТГК «AI for Devs» — канала, где мы рассказываем про AI-агентов, плагины для IDE, делимся практическими кейсами и свежими новостями из мира ИИ. Подписывайтесь, чтобы быть в курсе и ничего не упустить!