Восемь уровней инженерии интеллектуальных агентов

Автор: Bassim Eledath

Перевод: Баоцюй

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

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

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

Общаясь с множеством команд и индивидуальных разработчиков, использующих ИИ для помощи в программировании, я заметил следующую последовательность повышения уровней (хотя порядок не является строго обязательным):

Восемь уровней инженерии с помощью ИИ

Уровни 1 и 2: автодополнение и IDE с ИИ

Эти уровни я быстро пройду, чтобы зафиксировать полную картину. Можно пропустить.

Автодополнение — это отправная точка. GitHub Copilot положил начало этой тенденции — один клик Tab автоматически дополняет код. Многие, возможно, уже забыли об этом этапе, новички — тем более. Этот уровень больше подходит опытным разработчикам, которые сначала создают каркас кода, а затем позволяют ИИ заполнить детали.

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

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

Уровень 3: инженерия контекста

Теперь начинается самое интересное. Инженерия контекста — это тренд 2025 года. Почему она стала концепцией? Потому что модель наконец-то научилась надежно следовать разумному количеству инструкций, при этом используя уместный контекст. Шумный или недостаточный контекст — одинаково плохи, поэтому основная задача — повысить информационную плотность каждого токена. «Каждый токен должен бороться за свое место в подсказке» — таково было кредо того времени.

Та же информация — меньше токенов, больше плотности — вот где секрет (источник: humanlayer/12-factor-agents).

На практике инженерия контекста охватывает гораздо больше аспектов, чем большинство осознает. В нее входит системное подсказка и правила (.cursorrules, CLAUDE.md). В нее входит описание инструментов, поскольку модель читает эти описания, чтобы решить, какой инструмент вызвать. В нее входит управление историей диалогов, чтобы длинные сессии не сбивали модель с толку после десятого раунда. В нее входит выбор инструментов для каждого раунда, поскольку слишком много вариантов — это перегрузка для модели, как и для человека.

Теперь уже редко слышно о «инженерии контекста». Текущая тенденция — к моделям, способным терпеть более шумный контекст и рассуждать в более хаотичных сценариях (больший окно контекста тоже помогает). Но важно помнить, что расход контекста все еще критичен. В следующих случаях он может стать узким местом:

Маленькие модели чувствительнее к контексту. Голосовые приложения обычно используют меньшие модели, и размер контекста влияет на задержку ответа.

Большие потребители токенов. MCP (Model Context Protocol) и ввод изображений быстро съедают токены, заставляя вас раньше входить в режим «сжатой сессии» в Claude Code.

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

В целом, инженерия контекста не исчезла — она эволюционирует. Сейчас акцент смещен с фильтрации плохого контекста на обеспечение появления правильного в нужное время. Именно этот сдвиг подготовил почву для уровня 4.

Уровень 4: комбинированная инженерия

Инженерия контекста улучшает текущую сессию. А концепция комбинированной инженерии (Compounding Engineering, предложенная Kieran Klaassen) — это улучшение всех последующих сессий. Для меня и многих других это стало переломным моментом — мы поняли, что «программирование на интуиции» — это далеко не только прототипирование.

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

Цикл закрепления: планирование, делегирование, оценка, закрепление — каждое повторение делает следующий цикл лучше.

Магия в шаге «закрепление». LLM — безсостояние. Если вчера оно снова внедрило зависимость, которую вы явно убрали, то и завтра оно сделает то же самое — если вы не скажете ему иначе. Самое распространенное решение — обновить CLAUDE.md (или аналогичный файл правил), зафиксировать опыт для всех будущих сессий. Но будьте осторожны: желание засовывать все в правила может иметь обратный эффект (слишком много команд — это как их отсутствие). Лучше создать среду, в которой LLM сможет легко обнаруживать полезный контекст — например, поддерживать обновляемую папку docs/ (подробнее об этом на уровне 7).

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

Уровень 5: MCP и навыки

Проблемы контекста решены на уровнях 3 и 4. А уровень 5 — это вопрос возможностей. MCP и пользовательские навыки позволяют вашему LLM обращаться к базам данных, API, CI/CD, системам проектирования, а также к инструментам для браузерных тестов (Playwright), уведомлений (Slack). Модель больше не просто размышляет о вашем коде — она может напрямую управлять системами.

О хороших ресурсах по MCP и навыкам уже много написано, я не буду повторять. Но приведу примеры, как я их использую: наша команда делится навыком ревью PR, мы вместе его улучшаем (до сих пор в процессе), он условно запускает подзадачи-ассистенты в зависимости от типа PR. Один проверяет безопасность интеграции с базой данных, другой — анализирует сложность, чтобы отметить избыточность или излишнюю инженерную нагрузку, третий — следит за качеством подсказок, чтобы они соответствовали стандартам команды. Он также запускает линтер и Ruff.

Почему так много внимания навыкам ревью? Потому что, когда ассистент начинает массово генерировать PR, ручная проверка становится узким местом, а не контрольным пунктом качества. Latent Space выдвинул убедительный аргумент: привычное ревью кода умерло. На смену пришла автоматизация, единообразие и навыки.

В MCP я использую Braintrust MCP, чтобы LLM мог запрашивать оценочные логи и прямо вносить изменения. Также я использую DeepWiki MCP, чтобы ассистент мог обращаться к документации любого открытого репозитория без ручного добавления документов в контекст.

Когда в команде начинают писать свои собственные навыки, их объединяют в общий реестр. Статья Block (с уважением) рассказывает, как они создали внутренний рынок навыков с более чем 100 навыками и сформировали пакеты навыков для конкретных ролей и команд. Навыки и код — на равных: pull request, ревью, история версий.

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

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

Уровень 6: Harness Engineering

Настоящий запуск ракеты.

Инженерия контекста сосредоточена на том, что видит модель. Harness Engineering — это создание всей среды — инструментов, инфраструктуры и обратных связей — чтобы ассистент мог надежно работать без вашего вмешательства. Это не просто редактор, а полноценная обратная связь.

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

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

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

Ключевая идея — механизм обратного давления (Backpressure) — автоматическая система обратной связи (типовые системы, тесты, линтеры, pre-commit хуки), которая позволяет ассистенту обнаруживать и исправлять ошибки без участия человека. Если хотите автономности — нужен механизм обратного давления, иначе вы получите конвейер мусора. Это также важно для безопасности. CTO Vercel отметил, что ассистенты, их сгенерированный код и ваши ключи должны находиться в разных доверенных зонах, потому что внедрение вредоносных подсказок в логах может заставить ассистента украсть ваши учетные данные — если все в одном контексте безопасности. Защитная граница — механизм обратного давления: он ограничивает, что ассистент может делать при сбое, а не только что должен делать.

Два принципа, делающих эту концепцию яснее:

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

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

Вторая половина Harness Engineering — это обеспечение того, чтобы ассистент мог свободно ориентироваться в репозитории без вашего участия. OpenAI рекомендует держать файл AGENTS.md в пределах примерно 100 строк, как оглавление, ссылающееся на другие структурированные документы, и включать актуальность документации в CI, а не полагаться на временные обновления.

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

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

Уровень 7: фоновый ассистент

Критика: планирование уходит в прошлое.

Создатель Claude Code Boris Cherny говорит, что 80% задач все еще начинаются с планирования. Но с каждым новым поколением моделей успех после планирования становится все выше. Я считаю, что мы приближаемся к критической точке: этап планирования как отдельный шаг исчезнет. Не потому, что он не важен, а потому что модели станут достаточно умными, чтобы самостоятельно составлять планы. Но при условии, что вы подготовили уровни 3–6. Если ваш контекст чист, ограничения ясны, описание инструментов полное, а обратная связь замкнута — модель сможет надежно планировать без вашего контроля. Если же эти условия не выполнены — придется следить за планами.

Чтобы было яснее: планирование как универсальная практика не исчезнет, оно просто изменит форму. Для новичков план — правильный старт (уровни 1 и 2). Но для сложных задач уровня 7 «план» — это уже не пошаговая схема, а исследование: изучение репозитория, прототипирование в рабочем дереве, поиск решений. И все чаще — это делают фоновый ассистент, а не человек.

Это важно, потому что именно оно открывает возможности для фона. Если ассистент может генерировать надежные планы и выполнять их без вашего подтверждения — он может работать асинхронно, пока вы заняты другими делами. Это ключевое изменение — от «я одновременно работаю с несколькими вкладками» к «работа идет сама по себе».

Ralph — популярный цикл для начинающих: автономный цикл, многократно запускающий CLI для программирования, пока все пункты из ТЗ не будут выполнены, каждый раз создавая новую сессию с новым контекстом. На практике запускать Ralph сложно: любые неточности или неполные описания в ТЗ могут привести к сбоям. Он слишком «выбросил и забыл».

Можно запускать несколько Ralph одновременно, но чем больше их — тем больше времени уходит на координацию, планирование очереди, проверку результатов и контроль прогресса. Вы уже не пишете код — вы становитесь менеджером среднего звена. Вам нужен оркестратор ассистентов, чтобы управлять задачами, чтобы сосредоточиться на целях, а не на логистике.

Dispatch — параллельный запуск 5 воркеров через 3 модели — ваш диалог остается компактным, ассистенты работают

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

Dispatch работает локально, идеально подходит для быстрого прототипирования и разработки: обратная связь быстрее, отладка проще, инфраструктура не нужна. Инструмент Ramp Inspect — это дополнение для более длительных и автономных задач: каждая сессия ассистента запускается в облачном виртуальном окружении с полным набором инструментов. Менеджер обнаружил баг UI — отметил в Slack, а Inspect продолжает работу, когда вы закрываете ноутбук. Стоимость — сложность инфраструктуры (серверы, снимки, безопасность), зато масштаб и воспроизводимость — не сравнить с локальными ассистентами. Я советую использовать оба варианта — локальные и облачные.

На этом уровне появляется удивительный режим: использование разных моделей для разных задач. Лучшие инженерные команды — не однородные. У каждого свои подходы, опыт, сильные стороны. Аналогично и с LLM: разные модели после дообучения имеют разные характеры. Я часто делю работу между Opus для реализации, Gemini для исследований, Codex — для ревью. Такой коллективный разум дает результат лучше, чем любой один модельный экземпляр.

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

Фоновые ассистенты также открывают двери для интеграции CI и AI. Когда ассистент может работать автономно — его можно запускать из существующей инфраструктуры. Например, бот по документации после каждого слияния обновляет документацию и создает PR для CLAUDE.md (мы так делаем — экономим время). Бот по безопасности проверяет PR и исправляет уязвимости. Менеджер зависимостей не только отмечает проблемы — он реально обновляет пакеты и запускает тесты. Хороший контекст, закрепленные правила, мощные инструменты, автоматическая обратная связь — все это теперь работает автономно.

Уровень 8: автономная команда ассистентов

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

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

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

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

Честно говоря, я не считаю, что модели уже готовы к такой степени автономии по большинству задач. Даже если они достаточно умны, для задач уровня «посадка на Луну» — сборки компиляторов или браузеров — они слишком медленные, слишком много токенов расходуют, и экономически невыгодны (хотя впечатляют, но еще далеки от зрелости). Для большинства наших повседневных задач уровень 7 — это настоящий рычаг. Не удивлюсь, если уровень 8 станет доминирующим, но сейчас я сосредоточен на уровне 7 — разве что вы не Cursor, ведь прорыв — это ваш бизнес.

Уровень ? (следующий)

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

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

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

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