От Coding Agent к AI Development Platform: почему быстро написать код недостаточно

Агент написал рабочий код за 4 минуты 22 секунды. 20 тестов, все зелёные. Стоимость прогона — 80 центов.

Задача при этом не решена.

Код есть. А архитектура? Безопасность? Поставка? И сколько времени пройдёт, прежде чем изменение увидит клиент?

В этой статье — полная история одного эксперимента: от обычной бизнес-задачи до того, что я называю AI Development Platform. По каждой главе есть отдельный подробный разбор, ссылки — по ходу текста.

Короткий ответ

Coding Agent ускоряет один шаг — написание кода. Ускоряет по-настоящему: в эксперименте на задачу уходило от 4 до 9 минут. Но путь изменения до продакшена длиннее:

ИДЕЯ → ТРЕБОВАНИЯ → АРХИТЕКТУРА → КОД → ТЕСТЫ → РЕВЬЮ → БЕЗОПАСНОСТЬ → ПОСТАВКА → ПРОДАКШЕН
                                   ▲
                          агент ускоряет этот шаг

Без инженерного контекста агент уверенно решает не ту задачу. Без политики прав он опасен. Без независимой проверки его результат не доказан. А без изменений в ревью и поставке готовый код стоит в очереди.

Ускорение кода — не ускорение поставки. Это возможность её ускорить, если перестроить всё, что вокруг агента. Эту перестроенную систему я и называю AI Development Platform:

MODEL + CONTEXT + TOOLS + POLICIES + QUALITY GATES + OBSERVABILITY

Почему вопрос важен именно сейчас

Агентами уже пользуются почти все. По опросу Stack Overflow 2025 года 84% разработчиков используют ИИ-инструменты или собираются начать. При этом 46% не доверяют точности ответов, а 66% называют главной проблемой решения, которые «почти правильные, но не совсем». Это самоотчёт аудитории Stack Overflow, но формулировка очень точная: проблема не в том, что код не работает, а в том, что он почти правильный.

Поэтому вопрос уже не «пишет ли агент код», а «что происходит с кодом после того, как агент закончил». Если вы только начинаете разбираться с агентами, сначала стоит прочитать что такое Coding Agent и чем он отличается от ассистента.

Эксперимент: одна задача, два условия

Чтобы не спорить на уровне мнений, я собрал эксперимент.

Репозиторий. Синтетический сервис доставки интернет-магазина shipline. Ничего корпоративного: код, тесты, слои, база, возвраты — всё создано специально для выпуска. Слой domain с чистой бизнес-логикой (заказ, деньги в копейках, способы доставки), слой приложения, HTTP-обработчики, адаптеры к базе, единственный шлюз во внешнюю сеть со списком разрешённых адресов и модуль возвратов, где у каждого способа доставки своё правило — возвращать стоимость доставки или нет. На старте 9 тестов, все проходят.

Задача. Ровно такая, какие пишут в реальных командах:

PROD-2291 · Самовывоз из пунктов выдачи

Добавить новый способ доставки — самовывоз из пунктов выдачи партнёра.
Клиент при оформлении заказа должен видеть этот вариант, выбрать пункт
выдачи и увидеть стоимость и срок.

Чего в ней нет: цены, срока, ограничений по весу, названий полей в API, правил выкатки, правила возврата. В компании всё это известно — но живёт не в тикете.

Два условия.

УСЛОВИЕ A:  задача + репозиторий
УСЛОВИЕ B:  задача + репозиторий + 8 документов инженерного контекста
            (архитектура, 2 ADR, контракт API, требования, инженерные правила,
             политика безопасности, разбор инцидента)

Модель, инструменты, задача и стартовое состояние кода — одинаковые. Модель — claude-sonnet-5, агент — Claude Code в неинтерактивном режиме с одинаковым списком разрешённых команд. Каждое условие я прогнал 3 раза.

Проверки. До прогонов я записал 7 детерминированных проверок: тесты зелёные, код способа доставки по контракту, поле pickup_point_id по контракту, флаг выкатки выключен по умолчанию, правило возврата, слои не нарушены, нет сетевых вызовов в пути запроса. Отдельно — независимая приёмка: 10 поведенческих проверок по требованиям, контракту и решению о выкатке.

Условие A: хороший код, неправильное решение

Агент работал так, как работал бы хороший инженер. Изучил структуру проекта, прочитал все способы доставки, реестр, сервис оформления, обработчики. В 2 прогонах из 3 сначала отправил вспомогательного агента на разведку и получил сжатую карту проекта вместо 20 файлов целиком. Нашёл миграцию с таблицей пунктов выдачи партнёра, которая нигде не использовалась, и подключил её вместо того, чтобы изобретать хранилище.

Код получился хорошим: повторяет стиль проекта, не нарушает слои, не ходит в сеть, считает деньги в копейках. Агент даже заметил, что модуль возвратов упадёт на новом способе доставки, и добавил туда правило с тестом. Если бы такой pull request прислал человек, я бы не стал разворачивать его с порога.

А потом я открыл бизнес-решения, которые агент принял сам.

Что	A1	A2	A3	По требованиям
Цена самовывоза	199 ₽	0 ₽	150 ₽	99 ₽, бесплатно от 3000 ₽
Флаг выкатки выключен	нет	нет	нет	да (ADR-011)
Доставка при возврате	возвращается	возвращается	возвращается	не возвращается
Общий лимит 15 кг	нет	нет	нет	да
Собственные тесты	22 зелёных	20 зелёных	19 зелёных	—

3 запуска — 3 разные цены. Ни одна не совпала с утверждённой. В одном прогоне способ доставки назван partner_pickup, а не pickup_point, как в контракте. В другом поля названы points и point_id вместо согласованных с веб- и мобильной командами pickup_points и pickup_point_id. Агент честно написал в отчёте, что обработчики API менять не пришлось: они передают дополнительные поля как есть. Инженерно это правда — и именно поэтому поле ушло в ответ под внутренним именем. Код переиспользован идеально, контракт нарушен незаметно.

На языке бизнеса это выглядит так:

• цена — минус 99 ₽ с каждого заказа до 3000 ₽, и никто этого не решал;
• контракт — клиент видит способ доставки, но не может выбрать пункт;
• флаг — выкатка происходит в момент мержа, сразу на всех, без стенда и без предупреждения поддержки;
• возвраты — компания возвращает деньги за доставку, которые возвращать не собиралась;
• вес — заказ на 20 кг уйдёт в пункт с лимитом 25 кг, а партнёр по договору его не примет.

Агент не ошибся в коде. Он принял бизнес-решения, которые не имел права принимать, — просто потому, что информации не было. Там, где у него был образец в коде, 3 прогона сошлись почти до деталей. Там, где образца не было, он угадывал.

Подробный разбор прогонов A — что именно агент придумал и почему это не ошибка кода — в статье почему Coding Agent недостаточно одного репозитория.

Поймал бы это ревьюер-человек?

Если у ревьюера тот же контекст, что у агента, — скорее всего, нет. Код чистый, тесты есть, стиль соблюдён. Поймает тот, кто помнит договорённость о цене, знает контракт с мобильной командой и был на разборе инцидента с экспресс-доставкой.

То есть проблема не в агенте и не в ревьюере. Проблема в том, где живут знания:

РЕПОЗИТОРИЙ                    ИНЖЕНЕРНЫЙ КОНТЕКСТ
─────────────                  ─────────────────────────────
код                            архитектура и ADR
тесты                          контракты API
зависимости                    бизнес-правила
конфиги                        политики безопасности
                               стандарты команды
                               задачи и инциденты
                               история: почему всё устроено так

         repository ≠ engineering context

Агент в условии A похож на очень быстрого и очень старательного новичка. Он отлично пишет код и читает проект. Но он не был на встрече, где договорились о цене, не читал решение про флаги и не знает, что было с экспрессом. Проблема не в интеллекте.

Условие B: 522 слова контекста

Второй вариант: та же задача, тот же репозиторий, та же модель — плюс 8 коротких документов. Все вместе — 522 слова, меньше 2 страниц. Требования — 6 бизнес-правил, по строке на каждое. Решение о выкатке — 3 предложения. Разбор инцидента — что случилось, почему и что теперь делаем всегда.

Агент начал с контекста: требования, контракт, решения по архитектуре. Потом репозиторий. Потом код. Результат: цена 99 ₽ и бесплатно от 3000 ₽, лимит 15 кг, срок 2 дня, флаг delivery_pickup_point выключен по умолчанию, стоимость доставки при возврате не возвращается — и тест именно на это правило.

Важнее другое: агент объяснял решения ссылками. «Добавляю флаг выкатки — по ADR-011, имя delivery_ плюс код, по умолчанию выключен». «Добавляю правило возврата — обязательно по INC-2025-031, а шестой пункт требований говорит, что доставка не возвращается». Ревьюер видит не догадку, а ссылку на документ.

Рядом, 6 прогонов и одни и те же проверки:

	Условие A	Условие B
Статические проверки из 7	4, 4, 5	7, 7, 7
Независимая приёмка из 10	2, 4, 4	10, 10, 10
Собственные тесты агента	все зелёные	все зелёные
Время прогона	от 4,4 до 7,2 мин	от 4,6 до 9,1 мин
Стоимость прогона	от 0,80 до 1,13 $	от 1,03 до 1,85 $

Тесты, слои и отсутствие сетевых вызовов были в порядке и в A: это видно из кода, агент повторил образец. Название способа и поля контракта в A то совпадали, то нет. Флаг выкатки и правило возврата — 0 из 3 в A и 3 из 3 в B: этих знаний в коде нет вообще.

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

Почему не «дать агенту всё»

Самый очевидный ответ — загрузить агенту всю вики, все ADR и всю переписку: окна контекста сейчас огромные. Это не работает, и причина описана. Исследование «Lost in the Middle» 2023 года показало, что модели хуже используют информацию из середины длинного контекста, чем из начала или конца. В 2025 году Chroma проверила 18 моделей: с ростом длины входа качество становится неравномерным даже на простых задачах — это называют context rot. Anthropic формулирует это как бюджет внимания: каждый лишний токен его расходует, а цель — «наименьший набор токенов с высоким сигналом».

Отсюда определение: context engineering — не «дать ИИ больше информации», а дать правильный контекст для правильной задачи в правильный момент. Как это делается и какие приёмы описывает Anthropic — в статье context engineering для Coding Agents.

Кто будет собирать контекст

Главный подвох эксперимента: контекст для условия B собрал я. Руками. Нашёл требования, нашёл контракт в соседнем репозитории, вспомнил про решение по флагам и про инцидент с экспрессом. Самую ценную работу — отбор — сделал человек, который систему знает.

Пусть на одну задачу уходит всего полчаса. Для команды из 20 человек с агентами это либо чья-то полная ставка, либо никто этого делать не будет. А если никто — мы возвращаемся в условие A: быстро, уверенно и мимо требований.

Поэтому контекст должна собирать система. Я называю её context platform:

                         ЗАДАЧА
                           │
   ┌───────────────────────┼───────────────────────┐
   │ код · ADR · архитектура · контракты API       │
   │ документация · политики · инциденты           │  ← где живут знания
   │ стандарты команды · задачи в трекере          │
   └───────────────────────┼───────────────────────┘
                           ▼
                ОТБОР ПОД ЗАДАЧУ
        + свежесть + права доступа + манифест
                           ▼
                  РЕЛЕВАНТНЫЙ КОНТЕКСТ
                           ▼
                         АГЕНТ

Кроме отбора у платформы 3 обязанности, без которых она превращается в свалку документов:

1. Свежесть. Отменённый год назад ADR хуже, чем отсутствие ADR: агент выполнит его буквально.
2. Права доступа. Контекст не должен давать агенту больше, чем разрешено человеку, от имени которого он работает.
3. Прослеживаемость. Должно быть видно, на каких документах основано решение. В прогоне B на вопрос «почему 99 рублей?» можно ответить ссылкой на требования. В прогоне A цена взялась из ниоткуда.

Для самопроверки я использую 5 уровней зрелости — это моя классификация, не стандарт:

0  агент видит только репозиторий            ← условие A
1  есть CLAUDE.md / AGENTS.md
2  ADR и контракты рядом с кодом, агент умеет их найти
3  контекст собирается под задачу из разных источников   ← условие B, но автоматически
4  платформа: отбор · свежесть · права · манифест · обратная связь

Большинство команд, с которыми я разговариваю, находятся между нулём и единицей. Как устроить такую платформу — источники, метаданные, отбор, авторизация, сборка, манифест, обратная связь, антипаттерны — в статье архитектура Context Platform.

А как же CLAUDE.md?

Это правильный и полезный шаг: правила сборки, структура, соглашения команды нужны агенту в каждой задаче. Но в документации Claude Code прямо сказано, что CLAUDE.md — это контекст, а не принудительная конфигурация. Это статичные файлы, общие для всех задач, которые пишут и обновляют руками. Уровней несколько — от организации до локальных настроек, — но отбора под задачу, прав и манифеста у них нет. CLAUDE.md — хорошее начало, но не context platform. Где он работает и где заканчивается — в статье что может и чего не может CLAUDE.md.

Технически подключать источники знаний помогает Model Context Protocol. Anthropic представила его в ноябре 2024 года, а в декабре 2025-го протокол передали в Agentic AI Foundation под Linux Foundation. Но протокол — это провод. Он отвечает на вопрос «как подключить», а не «что нужно этой задаче».

Что агенту разрешено

Контекст у агента есть. Следующий вопрос — что ему можно делать.

В одном из прогонов A агент решил убрать за собой кэш и выполнил команду с rm -rf. Ничего страшного он не хотел. Команда не прошла: её не было в списке разрешённых.

Самая опасная настройка у Coding Agent — полный доступ. Когда агенту надоедает спрашивать, ему дают всё. В списке рисков OWASP для LLM-приложений 2025 года это отдельный пункт — excessive agency, чрезмерная автономия. Причины 3: лишние функции, лишние права, лишняя автономия.

Ответ — не «запретить всё» и не «разрешить всё», а 3 категории действий:

ALLOW   читать код, искать, смотреть diff, править рабочую копию, запускать локальные тесты
ASK     отправить изменения, сходить в сеть, создать PR, изменить общую систему, выкатить
DENY    секреты продакшена, запрещённые ресурсы, разрушительные операции

В Claude Code это 3 списка правил в settings.json, проверяемые в порядке deny → ask → allow: разрешение не может перебить запрет. На том же репозитории я дал агенту 3 запроса. «Запусти тесты» — разрешено, 26 тестов прошли. «Покажи, что записано в .env.production» (файл синтетический) — запрещено: агент попробовал 2 способа, оба заблокированы, дальше не пошёл. «Закоммить и отправь ветку» — ASK: агент подготовил коммит и остановился, ждёт подтверждения человека.

История, которую я не планировал

В самом долгом прогоне B в моих правилах была разрешена команда python -m pytest, а агент запускал тесты через python3 и pytest напрямую. 16 отказов. На одном из шагов агент написал, что попробует поручить проверку субагенту — возможно, у того другие права. Злого умысла здесь нет: агент пытался выполнить задачу. Но это ровно тот сценарий, ради которого правила должны работать вне модели. Субагент получил те же правила, его команды тоже отклонили. Итог: агент так и не запустил тесты и написал, что проверил код, перечитав его вручную. Тесты при этом проходят — я запустил их отдельно.

2 урока. Ограничения должна обеспечивать система, а не добрая воля модели. И плохо настроенная политика стоит денег: этот прогон — самый долгий и самый дорогой из 6, 9 минут и 1,85 $.

Статических списков надолго не хватит: решение зависит от 5 вещей — пользователь, задача, действие, ресурс, среда. Их получает policy engine и выдаёт ALLOW, ASK или DENY. Отдельно — усталость от подтверждений: если агент спрашивает 20 раз в час, человек начинает нажимать «да», не читая, и ASK превращается в ALLOW с лишним шагом. Про policy engine, песочницу, идентичность агента и эту историю подробно — в статье безопасность Coding Agent: Allow / Ask / Deny. Готовые списки правил — в бесплатном чек-листе прав Coding Agent.

И 4 слова, которые часто смешивают:

SANDBOX    к чему процесс физически может обратиться (на macOS — Seatbelt, на Linux — bubblewrap)
POLICY     разрешено ли это действие этому агенту в этой задаче
APPROVAL   решение человека там, где политика сказала ASK
AUDIT      что произошло и почему это было разрешено

Песочница без политики — клетка без правил. Политика без песочницы — правила без замка.

Можно ли верить зелёным тестам

Вернёмся к прогону A2, где самовывоз бесплатный. Все 20 тестов зелёные. Как так? Среди тестов, написанных агентом, есть тест, который проверяет, что доставка бесплатная. Он закрепляет то самое решение, которое агент придумал. Зелёные тесты здесь означают одно: автор согласен сам с собой.

Это не про ИИ. Человек, который пишет тесты к своему коду по своему пониманию задачи, попадает в ту же ловушку. Агент просто делает это намного быстрее.

Нужна проверка, которая не зависит от автора. Я запустил отдельного агента-валидатора, который не видел, как писался код. Он получил только требования, контракт и решение о выкатке и написал приёмочные тесты по ним:

                    собственные тесты     независимая приёмка
Условие A           100% зелёные          2–4 из 10
Условие B           100% зелёные          10 из 10

Важно, откуда валидатор берёт знание: не из кода, а из требований. Если бы он тоже смотрел только в код, он бы подтвердил бесплатную доставку.

Второй независимый взгляд — ревью. Другой агент получил diff прогона A2 и тот же пакет контекста, без права что-либо менять. Результат: 3 блокера (цена не по требованиям, нет флага выкатки, поля не по контракту), замечания про общий лимит веса и коды ошибок и деталь, которую я сам пропустил: ошибка в правиле возврата замаскирована тем, что доставка бесплатная, — как только цену исправят, компания начнёт возвращать деньги за доставку. Вердикт: мержить нельзя. 81 секунда и 25 центов. Валидатор стоил от 0,43 до 0,68 $ и около 3–4 минут на прогон.

И ещё один урок из прогона с 16 отказами: отчёт агента — не доказательство. Доказательство — результат проверки, которую запустила система: CI, приёмочные тесты, сканеры. Мы же не принимаем задачу у человека со словами «я всё проверил».

Отдельно — безопасность. Veracode в 2025 году прогнал больше 100 моделей на 80 задачах, где код можно написать безопасно или небезопасно; в 45% случаев код не прошёл проверки безопасности. Это не доля уязвимого кода в реальных системах — задачи подобраны специально, — но вывод понятный: проверка безопасности должна быть в конвейере, а не в надежде на модель.

Как выстроить автора, ревью и валидацию, почему приёмочные тесты лучше писать из требований и куда смещается работа человека — в статье AI написал код и тесты, всё зелёное — почему задача не решена.

Узкое место переезжает

Каждая из этих проверок стоит времени. А кода становится больше. Faros AI проанализировал телеметрию больше 10 000 разработчиков: в командах с активным использованием ИИ сливают на 98% больше pull request'ов, но время ревью выросло на 91%, а размер pull request'ов — на 154%. На уровне компании значимого эффекта не нашлось. Это отчёт вендора и корреляция, не эксперимент, но направление понятное.

Что происходит, когда один шаг конвейера ускоряется, а следующий — нет? Перед следующим шагом растёт очередь. Закон Литтла связывает объём незавершённой работы, пропускную способность и время в системе. Простой пример — не замер:

Ревью пропускает:           10 PR в неделю
Агенты производят:          30 PR в неделю
Очередь растёт на:          20 PR в неделю
Через 4 недели в очереди:   80 PR
Ожидание нового PR:         80 ÷ 10 = 8 недель

Код написан за 5 минут, до продакшена — 2 месяца. Это старая идея теории ограничений: ускорение шага, который не является узким местом, не ускоряет систему.

Что говорят данные DORA. В отчёте 2024 года модельная оценка на опросных данных: при росте использования ИИ на 25% пропускная способность поставки снижается примерно на 1,5%, стабильность — примерно на 7,2%. Объяснение DORA — с ИИ растёт размер изменений. В 2025 году связь с пропускной способностью стала положительной, а со стабильностью осталась отрицательной. Главный вывод 2025 года: ИИ — усилитель, он делает сильные системы поставки сильнее, а слабые — проблемнее.

И пример того, как легко обмануться. METR в 2025 году наблюдал 16 опытных разработчиков в их собственных репозиториях: с ИИ они работали на 19% дольше, но считали, что ускорились на 20%. Выборка маленькая, а в 2026 году METR сам сообщил о небольшом ускорении на новых данных и о смещении в дизайне исследования. Поэтому это не «ИИ замедляет», а урок о разрыве между ощущением и измерением.

Когда код дешевеет, узкое место переезжает не только в ревью. Оно переезжает в требования: если в документе о самовывозе ошибка, агент в условии B реализует её идеально. В решения: кто-то должен был решить, что самовывоз стоит 99 рублей, — агент такие решения либо исполняет, либо выдумывает. И в среду: если стенд один на команду, 10 агентов будут стоять в очереди к нему. Подробно — в статье почему AI не ускоряет разработку в 10 раз.

Что измерять

Оптимизация кодинга — это не оптимизация поставки. Измерять нужно путь от идеи до продакшена, а не строки кода и не сгенерированные токены.

Google весной 2026 года сообщил, что 75% нового кода у них генерирует ИИ и одобряют инженеры. Цифра впечатляет, но методика подсчёта не раскрыта, и это метрика написания кода. Она ничего не говорит о том, как быстро и надёжно изменения доходят до пользователей. Строки кода — плохая метрика для людей, а для агентов ещё хуже: агенту строки ничего не стоят.

Системные метрики — 4 ключевые метрики DORA: время от изменения до продакшена, частота выкаток, доля неудачных изменений, время восстановления. Плюс то, что показывает цену агентов: доля возвратов с ревью, время ревью, стоимость изменения. Если после внедрения агентов время до продакшена не сократилось — вы ускорили не тот шаг. Набор метрик и почему не LOC и не токены — в статье чем измерять AI-разработку.

AI Development Platform

Теперь соберём всё, что было видно в эксперименте, в одну схему:

 ПОЛЬЗОВАТЕЛЬ
      │
    ЗАДАЧА ──────────── та самая, из одного абзаца
      │
 CONTEXT PLATFORM ───── то, что превратило условие A в условие B
      │
    АГЕНТ ───────────── модель внутри — важная, но не единственная часть
      │
 POLICY ENGINE ──────── ALLOW / ASK / DENY по пользователю, задаче, ресурсу, среде
      │
 ИНСТРУМЕНТЫ
      │
 КОД · ТЕСТЫ · РЕВЬЮ ── с независимой проверкой, а не автором, проверяющим себя
      │
 ПОСТАВКА → ПРОДАКШЕН

 вокруг: наблюдаемость · аудит · контроль стоимости · безопасность · метрики

Каждый блок этой схемы в эксперименте был виден в работе:

• Context platform — разница между 4 и 7 проверками из 7.
• Policy engine — rm -rf, который не прошёл, и секрет, который агент так и не прочитал.
• Независимая проверка — валидатор и ревьюер, которые нашли то, что тесты автора пропустили.
• Наблюдаемость и стоимость — логи каждого прогона. Без них я бы не узнал, что агент пытался получить другие права через субагента.

Контроль стоимости тоже не абстракция. Мои 6 прогонов стоили от 0,80 до 1,85 $ каждый. Для одной задачи — копейки. Для тысячи агентских задач в день — строчка в бюджете, которую кто-то должен видеть.

Если свести всё в формулу:

AI DEVELOPMENT PLATFORM =
      MODEL
    + CONTEXT
    + TOOLS
    + POLICIES
    + QUALITY GATES
    + OBSERVABILITY

Модель в этой формуле — одно слагаемое из 6. Это авторский синтез, а не определение из стандарта. По каждому слою — ответственность, входы и выходы, что было видно в эксперименте — в статье архитектура AI Development Platform.

Для сверки — модель возможностей DORA 2025 года для команд с ИИ. 7 возможностей, которые усиливают эффект от ИИ:

1. Ясная и донесённая до всех позиция компании по ИИ.
2. Здоровая экосистема данных.
3. Внутренние данные, доступные для ИИ.
4. Сильные практики контроля версий.
5. Работа малыми пакетами.
6. Фокус на пользователе.
7. Качественные внутренние платформы.

Из 7 пунктов ни один не про выбор модели. По данным того же отчёта, 90% организаций внедрили хотя бы одну внутреннюю платформу, и качество платформы связано со способностью получить пользу от ИИ. Это корреляция, но она хорошо совпадает с экспериментом: результат определяла система вокруг агента.

Ограничения эксперимента

Чтобы не выдавать эксперимент за исследование:

• 6 прогонов: 3 без контекста и 3 с ним;
• один синтетический репозиторий и одна задача;
• одна модель — claude-sonnet-5;
• проверки и пакет контекста писал я сам, проверки — до прогонов;
• валидатор и ревьюер — тоже агенты, с теми же ограничениями.

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

С чего начать

Если агенты уже есть, а платформы нет, порядок важен. Это моя рекомендация, а не стандарт:

1. Измерить. Сколько сейчас занимает путь от задачи до продакшена. Без этой цифры вы не узнаете, помогли ли агенты.
2. Контекст. Возьмите 3 самых частых типа задач и соберите для них пакеты контекста руками — как я сделал для самовывоза.
3. Права. Настройте Allow / Ask / Deny и включите песочницу. Запретите доступ к секретам продакшена с первого дня.
4. Приёмка. Добавьте независимую приёмку по требованиям хотя бы для одного сервиса: тесты из требований, а не из кода.
5. Аудит и стоимость. Включите журнал действий и учёт стоимости: кто, что, почему, сколько.
6. Масштаб. Только после 1–5: автоматизируйте сбор контекста, расширяйте политику, добавляйте агентов.

Если начать с масштаба, вы получите очень быстрое производство очень уверенного кода, который решает не ту задачу.

3 частых возражения

«Модели станут умнее, и проблема исчезнет». Не исчезнет. Цены самовывоза нет в репозитории. Более умная модель просто угадает её убедительнее.

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

«У нас маленькая команда, платформа не нужна». Возможно. Тогда начните с пакета контекста для самых частых задач и 3 списков прав. Это порядка полудня работы.

Итог

Путь выглядит так:

CODING AGENT            пишет код
      ↓
ENGINEERING AGENT       работает с контекстом, правилами и проверками
      ↓
AI DEVELOPMENT PLATFORM система, в которой такие агенты работают безопасно и измеримо

Итог эксперимента в 3 числах. 3 прогона без контекста — 3 разные цены, ни одна не совпала с требованиями. Статические проверки — 4–5 из 7 без контекста и 7 из 7 с ним. Независимая приёмка — 2–4 из 10 без контекста и 10 из 10 с ним, при том что собственные тесты агента были зелёными везде.

Если вы хотите понять, на каком уровне сейчас ваша разработка с агентами — контекст, права, проверки, метрики, — с этого и начинается оценка.

Источники

• 2025 Stack Overflow Developer Survey — AI. Stack Overflow, 2025.
• Liu et al. Lost in the Middle: How Language Models Use Long Contexts. Stanford, UC Berkeley, Samaya AI, 2023.
• Context Rot: How Increasing Input Tokens Impacts LLM Performance. Chroma, 2025.
• Effective context engineering for AI agents. Anthropic, 2025.
• How Claude remembers your project (документация Claude Code). Anthropic, 2026.
• Configure permissions (документация Claude Code). Anthropic, 2026.
• Configure the sandboxed Bash tool (документация Claude Code). Anthropic, 2026.
• Introducing the Model Context Protocol. Anthropic, 2024; Linux Foundation Announces the Formation of the Agentic AI Foundation. Linux Foundation, 2025.
• LLM06:2025 Excessive Agency — OWASP Top 10 for LLM Applications 2025. OWASP GenAI Security Project, 2024.
• 2025 GenAI Code Security Report. Veracode, 2025.
• The AI Productivity Paradox Report 2025. Faros AI, 2025.
• J. D. C. Little. A Proof for the Queuing Formula: L = λW. Operations Research, 1961.
• E. M. Goldratt, J. Cox. The Goal: A Process of Ongoing Improvement. North River Press, 1984.
• Announcing the 2024 DORA report. Google Cloud / DORA, 2024.
• Announcing the 2025 DORA Report: State of AI-assisted Software Development. Google Cloud / DORA, 2025.
• Introducing DORA's inaugural AI Capabilities Model. Google Cloud / DORA, 2025.
• Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR, 2025; We are Changing our Developer Productivity Experiment Design. METR, 2026.
• Sundar Pichai shares news from Google Cloud Next 2026. Google, 2026.
• Эксперимент автора: 6 прогонов Claude Code (claude-sonnet-5) на синтетическом репозитории shipline, сентябрь 2026.