Способности ИИ в написании кода растут быстрее, чем наше умение эффективно их применять. Именно поэтому все эти рекорды на SWE-bench не совпадают с метриками продуктивности, которые действительно волнуют инженерное руководство. Когда команда Anthropic выпускает продукт вроде Cowork за 10 дней, а другая команда не может сдвинуться дальше сломанного прототипа, используя те же модели, — разница в том, что одна команда сократила разрыв между возможностями и практикой, а другая нет.
Этот разрыв не сокращается за одну ночь. Он сокращается постепенно, по уровням. Их 8.
Большинство из вас, читающих это, скорее всего уже прошли первые несколько, и вам стоит стремиться к следующему, потому что каждый последующий уровень — это огромный скачок в продуктивности, и каждое улучшение возможностей моделей усиливает эти результаты ещё больше.
Вторая причина обратить на это внимание — мультиплеерный эффект. Ваша продуктивность зависит от уровня ваших коллег больше, чем вы думаете. Допустим, вы — маг 7-го уровня, создающий несколько качественных PR с помощью фоновых агентов, пока вы спите. Если ваш репозиторий требует одобрения коллеги перед мёржем, а этот коллега на 2-м уровне и до сих пор ревьюит PR вручную, — это душит вашу пропускную способность. Поэтому в ваших интересах подтянуть команду.
Из общения с несколькими командами и отдельными разработчиками, практикующими ИИ-ассистированную разработку, я наблюдаю следующую прогрессию уровней — не строго последовательную:
8 уровней агентной инженерии
Уровни 1 и 2: Автодополнение по Tab и агентные IDE
Эти два уровня я пройду быстро, в основном для истории. Можете листать дальше.
Всё началось с Copilot и автодополнения по Tab. Нажимаешь Tab — код дополняется. Вероятно, уже давно забыто многими и вовсе пропущено новичками в агентной инженерии. Этот подход благоприятствовал опытным разработчикам, которые умели выстраивать скелет кода до того, как ИИ заполнит пробелы.
ИИ-ориентированные IDE вроде Cursor изменили правила игры, подключив чат к вашей кодовой базе и сделав редактирование нескольких файлов кардинально проще. Но потолок всегда определялся контекстом. Модель могла помочь только с тем, что видела, и раздражающе часто она либо не видела правильный контекст, либо видела слишком много неправильного.
Большинство людей на этом уровне также экспериментируют с режимом планирования в своём агентном инструменте: переводят грубую идею в структурированный пошаговый план для LLM, итерируют над этим планом, а затем запускают реализацию. На этом этапе это работает хорошо и является разумным способом сохранять контроль. Хотя на более поздних уровнях мы увидим меньшую зависимость от режима планирования.
Уровень 3: Инженерия контекста
Модное словосочетание 2025 года. Инженерия контекста стала актуальной, когда модели научились надёжно следовать разумному количеству инструкций при достаточном, но не избыточном контексте.
Зашумлённый контекст был так же плох, как и недостаточно определённый, поэтому усилия направлялись на повышение информационной плотности каждого токена. «Каждый токен должен бороться за своё место в промпте» — таков был принцип. Тот же смысл, меньше токенов — информационная плотность стала ключевой целью.
На практике инженерия контекста затрагивает больше областей, чем люди осознают:
- Это ваш системный промпт и файлы правил (.cursorrules, CLAUDE.md).
- Это то, как вы описываете свои инструменты, потому что модель читает эти описания, чтобы решить, какие из них вызвать.
- Это управление историей диалога, чтобы долго работающий агент не терял нить через десять шагов.
- Это решение, какие инструменты вообще показывать на каждом шаге, потому что слишком много вариантов перегружают модель так же, как и людей.
Сейчас об инженерии контекста говорят реже. Баланс сместился в сторону моделей, которые прощают более шумный контекст и рассуждают на более хаотичной почве (большие контекстные окна тоже помогают). Тем не менее, осознанное отношение к тому, что поедает контекст, остаётся актуальным. Несколько примеров, где это по-прежнему критично:
- Малые модели более чувствительны к контексту. Голосовые приложения часто используют меньшие модели, и размер контекста также коррелирует со временем до первого токена, что влияет на задержку.
- Токенозатратные инструменты и модальности. MCP-серверы вроде Playwright и визуальные входные данные быстро сжигают токены, переводя вас в режим «компактной сессии» в Claude Code гораздо раньше, чем вы ожидаете.
- Агенты с доступом к десяткам инструментов, где модель тратит больше токенов на разбор схем инструментов, чем на полезную работу.
Суть в том, что инженерия контекста никуда не делась — она просто эволюционировала. Фокус сместился с фильтрации плохого контекста на обеспечение присутствия правильного контекста в правильный момент. Именно этот сдвиг готовит почву для уровня 4.
Уровень 4: Накапливающаяся инженерия
Инженерия контекста улучшает текущую сессию. Накапливающаяся инженерия улучшает каждую последующую сессию.
Популяризированная Кираном Клаассеном, накапливающаяся инженерия стала точкой перелома не только для меня, но и для многих других — осознание того, что «вайб-кодинг» способен на гораздо большее, чем просто прототипирование.
Это цикл: планируй, делегируй, оценивай, кодифицируй. Вы планируете задачу с достаточным контекстом для успешной работы LLM. Делегируете её. Оцениваете результат. И затем, что критически важно, кодифицируете полученные знания: что сработало, что сломалось, какому паттерну следовать в следующий раз.
Именно шаг кодификации создаёт эффект накопления. LLM не имеют состояния. Если модель вчера вернула зависимость, которую вы явно удалили, завтра она сделает то же самое — если вы не скажете ей не делать этого. Самый распространённый способ замкнуть этот цикл — обновить CLAUDE.md (или аналогичный файл правил), чтобы урок закрепился в каждой будущей сессии.
Предостережение: инстинкт кодифицировать всё подряд в файл правил может обернуться против вас (слишком много инструкций — всё равно что ни одной). Лучшее решение — создать среду, в которой LLM может легко находить полезный контекст самостоятельно, например, поддерживая актуальную папку docs/ (подробнее об этом на уровне 7).
Практики накапливающейся инженерии обычно гиперосознанно относятся к контексту, который подаётся их LLM. Когда LLM совершает ошибку, они инстинктивно думают о недостающем контексте, прежде чем винить компетентность модели. Именно этот инстинкт делает возможными уровни с 5 по 8.
Уровень 5: MCP и навыки (Skills)
Уровни 3 и 4 решают проблему контекста. Уровень 5 решает проблему возможностей.
MCP-серверы и пользовательские навыки дают вашей LLM доступ к вашей базе данных, вашим API, вашему CI-конвейеру, вашей дизайн-системе, Playwright для тестирования в браузере, Slack для уведомлений. Вместо того чтобы просто думать о вашей кодовой базе, модель теперь может действовать в ней.
Материалов о MCP и навыках уже достаточно, поэтому я не буду повторять, что это такое. Но вот несколько примеров, как я их использую: моя команда делит навык ревью PR, над которым мы все итерируем (и продолжаем это делать), — он условно запускает подагентов в зависимости от характера PR:
- Один отвечает за безопасность интеграции с базой данных.
- Другой проводит анализ сложности, выявляя избыточности или переусложнение.
- Третий проверяет качество промптов, убеждаясь, что наши промпты соответствуют стандартному формату команды.
- Также запускаются линтеры и Ruff.
Зачем вкладывать столько в навык ревью? Потому что по мере того как агенты начинают производить PR в большом объёме, узким местом становится человеческое ревью, а не качество кода. Автоматизированное, последовательное, навыко-ориентированное ревью — это то, что приходит на смену.
Что касается MCP, я использую Braintrust MCP, чтобы моя LLM могла запрашивать логи оценок и вносить изменения напрямую. Я использую DeepWiki MCP, чтобы дать агенту доступ к документации любого open-source репозитория без ручного подключения к контексту.
Когда несколько человек в команде пишут собственные версии одного и того же навыка, имеет смысл объединить их в общий реестр. Block подробно описал свой подход: они создали внутренний маркетплейс навыков с более чем 100 навыками и курируемыми наборами для конкретных ролей и команд. Навыки получают то же отношение, что и код: пул-реквесты, ревью, история версий.
Ещё одна тенденция, которую стоит отметить: LLM всё чаще используют CLI-инструменты вместо MCP (и, кажется, каждая компания выпускает свой: Google Workspace CLI, Braintrust скоро запустит свой). Причина — эффективность по токенам. MCP-серверы внедряют полные схемы инструментов в контекст на каждом шаге, независимо от того, использует ли их агент. CLI переворачивают это: агент выполняет целевую команду, и только релевантный вывод попадает в контекстное окно.
Важное замечание перед продолжением. Уровни с 3 по 5 — это строительные блоки для всего, что следует далее. LLM непредсказуемо хороши в одних вещах и плохи в других, и вам нужно развить интуицию, где проходят эти границы, прежде чем наращивать автоматизацию. Если ваш контекст зашумлён, промпты недоопределены или инструменты плохо описаны, уровни с 6 по 8 лишь усиливают хаос.
Уровень 6: Инженерия обвязки и автоматизированные петли обратной связи
Вот где ракета действительно начинает взлетать.
Инженерия контекста — это курирование того, что видит модель. Инженерия обвязки — это построение всей среды, инструментария и петель обратной связи, которые позволяют агентам выполнять надёжную работу без вашего вмешательства.
Дайте агенту петлю обратной связи, а не просто редактор.
Команда OpenAI Codex подключила Chrome DevTools, инструменты наблюдаемости и навигацию по браузеру прямо в среду выполнения агента, чтобы он мог делать скриншоты, управлять путями по UI, запрашивать логи и валидировать собственные исправления. По одному промпту агент может воспроизвести баг, записать видео и реализовать исправление. Затем он валидирует, управляя приложением, открывает PR, отвечает на замечания при ревью и мёржит, эскалируя только когда требуется человеческая оценка.
Агент не просто пишет код. Он может видеть, что код производит, и итерировать, — так же, как это делал бы человек.
Моя команда создаёт голосовых и чат-агентов для технической поддержки, поэтому я создал CLI-инструмент под названием converse, который позволяет любой LLM общаться с нашим бэкенд-эндпоинтом и вести пошаговые диалоги. LLM вносит изменения в код, использует converse для тестирования диалогов на живой системе и итерирует. Иногда эти циклы самоулучшения длятся по несколько часов.
Это особенно мощно, когда результат верифицируем: диалог должен следовать определённому потоку или вызывать определённые инструменты в определённых ситуациях (например, эскалация на живого оператора).
Концепция, которая это обеспечивает, — обратное давление (backpressure): автоматизированные механизмы обратной связи (системы типов, тесты, линтеры, pre-commit хуки), которые позволяют агентам обнаруживать и исправлять ошибки без вмешательства человека. Если вы хотите автономности — вам нужно обратное давление. Иначе вы получите машину по производству мусора.
Это распространяется и на безопасность. CTO Vercel аргументирует, что агенты, код, который они генерируют, и ваши секреты должны находиться в отдельных доменах доверия, потому что инъекция промпта, спрятанная в лог-файле, может обмануть агента и заставить его слить ваши учётные данные, если всё находится в одном контексте безопасности. Границы безопасности — это обратное давление: они ограничивают то, что агент может сделать, когда он сходит с рельсов, а не только то, что он должен делать.
Два совета:
- Проектируйте для пропускной способности, а не для идеальности. Когда требуется совершенство в каждом коммите, агенты наваливаются на один и тот же баг и перезаписывают исправления друг друга. Лучше допускать мелкие неблокирующие ошибки и делать финальный проход по качеству перед релизом. Мы делаем то же самое для наших коллег-людей.
- Ограничения > инструкции. Пошаговые промпты («сделай A, затем B, затем C») всё больше устаревают. По моему опыту, определение границ работает лучше, чем выдача чек-листов, потому что агенты зацикливаются на списке и игнорируют всё, что в нём не указано. Лучший промпт: «вот чего я хочу, работай над этим, пока не пройдёшь все эти тесты».
Вторая половина инженерии обвязки — убедиться, что агент может ориентироваться в вашем репозитории без вас. Подход OpenAI: держите AGENTS.md объёмом примерно в 100 строк, которые служат оглавлением, указывающим на структурированную документацию в других местах, и сделайте свежесть документации частью CI, а не полагайтесь на эпизодические обновления, которые устаревают.
Когда вы всё это построили, возникает естественный вопрос: если агент может верифицировать собственную работу, ориентироваться в репозитории и исправлять ошибки без вас, зачем вам вообще сидеть за компьютером?
Уровень 7: Фоновые агенты
Смелое утверждение: режим планирования умирает.
Борис Черны, создатель Claude Code, до сих пор начинает 80% задач в режиме планирования. Но с каждым новым поколением моделей процент успеха с первой попытки после планирования продолжает расти. Я думаю, мы приближаемся к точке, где режим планирования как отдельный этап с участием человека сойдёт на нет. Не потому что планирование не важно, а потому что модели становятся достаточно хороши, чтобы планировать самостоятельно.
Важная оговорка: это работает только если вы проделали работу на уровнях с 3 по 6. Если ваш контекст чист, ограничения явны, инструменты хорошо описаны, а петли обратной связи настроены, модель может надёжно планировать без вашей проверки. Если вы этой работы не проделали, вам всё ещё придётся контролировать план.
Уточню: планирование как общая практика никуда не уходит. Оно просто меняет форму. Для новичков режим планирования остаётся правильной точкой входа (как описано на уровнях 1 и 2). Но для сложных задач на уровне 7 «планирование» выглядит менее как написание пошагового плана и более как исследование: изучение кодовой базы, прототипирование вариантов в рабочих деревьях, картирование пространства решений. И всё чаще это исследование за вас проводят фоновые агенты.
Это важно, потому что именно это открывает возможность фоновых агентов. Если агент может сгенерировать качественный план и выполнить его без вашего одобрения, он может работать асинхронно, пока вы занимаетесь другим. Это критический переход от «нескольких вкладок, которые я жонглирую» к «работе, которая происходит без меня».
Цикл Ральфа — популярная точка входа: автономный агентный цикл, который многократно запускает CLI для кодирования, пока все пункты PRD не будут выполнены, при этом каждая итерация порождает свежий экземпляр с чистым контекстом. По моему опыту, отладить цикл Ральфа непросто, и любая недо-/неправильная спецификация PRD возвращается бумерангом. Он слишком «запусти и забудь».
Вы можете запускать несколько циклов Ральфа параллельно, но чем больше агентов вы запускаете, тем яснее видите, на что реально уходит ваше время: координация, выстраивание последовательности, проверка результатов, подталкивание процесса. Вы больше не пишете код. Вы стали менеджером среднего звена.
Вам нужен агент-оркестратор, который берёт на себя диспетчеризацию, чтобы вы могли сосредоточиться на намерении, а не на логистике.
Инструмент, который я активно использую для этого, — Dispatch, навык для Claude Code, который я создал и который превращает вашу сессию в командный центр. Вы остаётесь в одной чистой сессии, пока рабочие агенты делают тяжёлую работу в изолированных контекстах. Диспетчер планирует, делегирует и отслеживает, сохраняя ваше основное контекстное окно для оркестрации. Когда рабочий застревает, он поднимает уточняющий вопрос, а не молча проваливается. Dispatch работает локально, что делает его идеальным для быстрой разработки, когда вы хотите оставаться близко к работе: быстрая обратная связь, проще отлаживать интерактивно и никаких инфраструктурных накладных расходов.
Inspect от Ramp — комплементарный подход для более длительной, более автономной работы: каждая агентная сессия запускается в облачной песочнице — виртуальной машине с полной средой разработки. PM замечает UI-баг, отмечает его в Slack, и Inspect подхватывает и работает, пока ваш ноутбук закрыт. Компромисс — операционная сложность (инфраструктура, снапшоты, безопасность), но вы получаете масштаб и воспроизводимость, которые локальные агенты не могут обеспечить. Я бы сказал — используйте оба подхода (локальные и облачные фоновые агенты).
Один паттерн, который оказался неожиданно мощным на этом уровне: используйте разные модели для разных задач. Лучшие инженерные команды состоят не из клонов. Они состоят из людей, которые думают по-разному, обучены разным опытом, привносят разные сильные стороны. Та же логика применима к LLM. Эти модели прошли разное пост-обучение и имеют значимо разные предрасположенности. Я регулярно направляю Opus на реализацию, Gemini — на исследовательский ресёрч, а Codex — на ревью, и совокупный результат сильнее, чем любая отдельная модель, работающая в одиночку. Мудрость толпы, только для кода.
Критически важно: нужно также разделять реализатора и ревьюера. Я усвоил это на горьком опыте слишком много раз: если один и тот же экземпляр модели реализует и оценивает свою работу, он предвзят. Он будет замалчивать проблемы и говорить вам, что все задачи выполнены, когда это не так. Это не злонамеренность — это та же причина, по которой вы не проверяете собственный экзамен. Поручите ревью другой модели (или другому экземпляру с промптом для ревью). Качество сигнала резко возрастёт.
Фоновые агенты также открывают шлюз для объединения CI с ИИ. Как только агенты могут работать без человека, запускайте их из вашей существующей инфраструктуры:
- Бот документации, который регенерирует документацию при каждом мёрже и создаёт PR для обновления CLAUDE.md (мы так делаем, и это колоссально экономит время).
- Ревьюер безопасности, который сканирует PR и создаёт исправления.
- Бот зависимостей, который действительно обновляет пакеты и запускает тестовый набор, а не просто отмечает их.
Хороший контекст, накапливающиеся правила, мощные инструменты и автоматизированные петли обратной связи — теперь работающие автономно.
Уровень 8: Автономные агентные команды
Этот уровень пока никто полностью не освоил, хотя несколько команд продвигаются в этом направлении. Это активный фронтир.
На уровне 7 у вас есть LLM-оркестратор, направляющий работу LLM-рабочим по модели «звезда» (hub-and-spoke). Уровень 8 убирает это узкое место. Агенты координируются друг с другом напрямую: забирают задачи, делятся находками, отмечают зависимости и разрешают конфликты, не прогоняя всё через единственного оркестратора.
Экспериментальная функция Claude Code — Agent Teams — является ранней реализацией: несколько экземпляров работают параллельно над общей кодовой базой, при этом «напарники» работают в собственных контекстных окнах и общаются друг с другом напрямую. Anthropic использовал 16 параллельных агентов для создания с нуля компилятора C, способного скомпилировать Linux. Cursor запускал сотни одновременных агентов неделями, чтобы создать с нуля веб-браузер и мигрировать собственную кодовую базу с Solid на React.
Но присмотритесь — и вы увидите швы. Cursor обнаружил, что без иерархии агенты становились избегающими рисков и крутились без прогресса. Агенты Anthropic ломали существующую функциональность, пока не добавили CI-конвейер для предотвращения регрессий. Все, кто экспериментирует на этом уровне, говорят одно и то же: координация множества агентов — это сложная проблема, и никто ещё далеко не достиг оптимума.
Честно говоря, я не думаю, что модели готовы к такому уровню автономии для большинства задач. И даже если бы они были достаточно умны, они всё ещё слишком медленные и слишком расточительные по токенам, чтобы это было экономически оправдано за пределами грандиозных проектов вроде компиляторов и браузеров (впечатляюще, но далеко от чистоты).
Для работы, которую большинство из нас делает ежедневно, уровень 7 — вот где рычаг. Не удивлюсь, если уровень 8 в итоге станет доминирующим паттерном, но сейчас именно на уровень 7 я бы направил свою энергию (если вы не Cursor и прорыв — это и есть бизнес).
Уровень ?: Что дальше
Неизбежный вопрос — что дальше. Когда вы научитесь оркестрировать агентные команды без особых трений, нет причин, почему интерфейс должен оставаться текстовым. Голосовое взаимодействие с вашим агентом для кодирования — разговорный Claude Code, а не просто преобразование голоса в текст — это естественный следующий шаг. Смотрите на ваше приложение, описываете последовательность изменений вслух и наблюдаете, как они происходят прямо перед вами.
Есть группа людей, гоняющихся за идеальным «одним выстрелом»: сформулируйте, чего хотите, и ИИ безупречно реализует это за один проход. Проблема в том, что это предполагает, что мы, люди, точно знаем, чего хотим. Не знаем. Никогда не знали. Разработка ПО всегда была итеративной, и я думаю, так будет всегда. Просто она станет намного проще, выйдет далеко за рамки чисто текстового взаимодействия и будет чертовски быстрее.
Итак: на каком вы уровне? И что вы делаете, чтобы перейти на следующий?