Мой агент отправил 3 PR за один вечер. 40% моих сообщений были исправлениями.

Мой ИИ-агент для написания кода отправил три pull request за один вечер, но 40% из 30 отправленных мною сообщений были исправлениями.

В результате сессии были созданы MCP client, Azure AI Agent и M365 Copilot Agent. Автоматические проверки подтвердили все три PR, и я ни разу не отредактировал ни одной строки кода. Однако транскрипт говорит о другом: из 710 сообщений всего 30 были написаны мной, и 12 из них вернули агента в нужное русло. «Коэффициент управления» (steering rate) — доля моих сообщений, которые были исправлениями, — составил 40%.

Как был устроен конвейер

  • Claude составил высокоуровневый план реализации.
  • DeepSeek V4-Flash выступил в роли оркестратора, проверяя план.
  • Codex сгенерировал сам код.
  • Оркестратор проверил код и открыл pull request'ы.

Предполагаемая роль оркестратора была чисто связующей: он должен был разрешать конфликты между компонентами, а не писать код самостоятельно. На практике агент создал 3500 строк кода в трех PR примерно за 40 минут, но при этом допустил ошибки в двух повторяющихся категориях.

Две группы ошибок

  1. Нарушения рабочего процесса (workflow violations) — оркестратор время от времени брал на себя этап написания кода, игнорируя свою роль «связующего звена» и самостоятельно прописывая детали реализации.
  2. Ошибки извлечения контекста (context-retrieval failures) — несмотря на четкие инструкции, агент выбирал не тот SDK или версию. Правильная информация присутствовала в контексте промпта, но модель не смогла извлечь её в нужный момент.

Это не пробелы в способности к рассуждению, а инженерные баги в том, как ограничено выполнение рабочего процесса. Даже более мощной языковой модели всё равно потребовалось бы жесткое, неоспоримое правило, которое привязывало бы оркестратора к его не связанным с кодингом обязанностям и заставляло выбирать правильный SDK.

Что я изменил, чтобы обуздать агента

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

Я также ужесточил логику извлечения контекста. Когда появлялся неверный инструмент, я рассматривал это как баг в конвейере извлечения, а не как галлюцинацию, и переписал промпт, передающий детали SDK, так, чтобы правильную версию было невозможно пропустить.

Практические выводы для разработки с помощью ИИ

  • Считайте собственные сообщения. Большое количество принятых PR может маскировать сломанный процесс. Количество ваших исправлений — это опережающий индикатор того, где «система управления» дает сбой.
  • Формулируйте роль явно. Агенты не выводят свою идентичность из чек-листа; им нужна четкая, закрепленная инструкция о том, кто они и что им разрешено делать.
  • Рассматривайте ошибки выбора инструментов как инженерные баги. Если агент игнорирует указанный SDK, проблема заключается в механизме доставки контекста, а не в «знаниях» модели.
  • Превращайте ошибки в многоразовые навыки. Я позволил агенту создать процедуру валидации на основе его собственных ошибок, превратив провал в будущую страховку.

Более широкие ставки