Всем привет, меня зовут Сергей Прощаев, и в этой статье расскажу про то, почему AI‑агенты нельзя внедрять как ещё один инструмент разработчика. Руковожу направлением Java | Kotlin разработки в FinTech & E‑commerce, работаю Tech Lead и преподаю на курсах разработки и архитектуры в ОТУС.

Ситуация, в которой сейчас находится половина знакомых мне тимлидов, выглядит так. Агентов в команде уже используют — кто‑то официально, кто‑то втихаря. Задачи вроде закрываются быстрее. А в трекере при этом растёт очередь на ревью, в ретро всплывают инциденты со странными причинами, и на вопрос «мы стали быстрее или нет» никто не может ответить цифрой. Спросишь разработчиков — скажут, что стали. Посмотришь на lead time — не факт. И где‑то на фоне маячит вопрос, который никто не хочет задавать вслух: а что вообще будет, если агент дотянется до боевого контура.

Отвечаю сразу: уже отвечали, и публично.

Что именно я разбираю

Три источника.

• Первый — два задокументированных инцидента с агентами в проде, где видна механика отказа, а не просто факт «сломалось».

• Второй — исследования, которые меряют эффект замерами, а не опросами.

• Третий — контур управления с гейтами, который я в итоге собрал у себя: он здесь приведён схемой, фрагментом инструкций, куском SQL и таблицей уровней риска. Всё это можно забрать целиком, никуда не переходя.

Наблюдение 1. Инцидент выглядит как сбой модели, а оказывается дырой в процессе

Летом 2025 года основатель SaaStr Джейсон Лемкин двенадцать дней собирал B2B‑приложение через агента Replit. На девятый день, во время объявленного код‑фриза, агент выполнил разрушающую миграцию и снёс продовую базу — данные примерно по 1200 компаниям и руководителям.

Дальше начинается та часть, ради которой я эту историю и привожу: согласно опубликованному разбору, агент выдал отчёты, создававшие впечатление работоспособности системы, и изменил результаты проверок так, что они выглядели зелёными, а в первом извинении масштаб проблемы был занижен. CEO Replit публично назвал случившееся недопустимым и пообещал sandbox‑ограничения.

Оговорюсь: это реконструкция по рассказу пострадавшего и по репликам самого агента, а не выводы независимого расследования. Была ли там осознанная фальсификация, галлюцинация или просто некорректная самооценка — снаружи не определить, и я не берусь.

Но для управленческого вывода это, если честно, неважно. Разложите инцидент на условия: агент имел доступ к боевой базе, staging‑контура не было, ключ был не read‑only, гейта на разрушающие операции не существовало.

Каждое из четырёх условий — управленческое решение, точнее непринятое управленческое решение. Модель тут вообще ни при чём: очень быстрый стажёр с правами root и нулевым страхом последствий повёл бы себя ровно так же.

История не единичная. В марте 2026 года разошёлся разбор случая, где разработчик делегировал агенту управление инфраструктурой и одобрил сгенерированный план деплоя, не восстановив контекст, из которого агент исходил. Итог — снесённые RDS, VPC, ECS‑кластер, балансировщики и автоматические бэкапы, порядка 1,9 млн строк данных.

Что до массовости, тут надо аккуратно с цифрами.

В опросе Gravitee “State of AI Agent Security 2026” (919 руководителей и технических специалистов) 88% организаций сообщили о подтверждённых или предполагаемых инцидентах безопасности с агентами за год.

Слово «предполагаемых» многие пропускают, и зря — без него цифра звучит громче, чем есть. Но и подтверждённая часть немаленькая: в декабрьской волне 2025 года это 59,3%, в апрельской 2026 — 34,9%, причём авторы объясняют падение скорее недовыявлением, чем ростом защищённости.

Косвенно это подтверждается там же: runtime‑видимость того, что агенты реально делают, есть лишь у 21% организаций.

Наблюдение 2. Самоотчёт команды не работает как источник данных

Здесь отрезвляет контролируемый эксперимент METR (июль 2025). Шестнадцать опытных open‑source разработчиков выполнили 246 реальных задач в своих же репозиториях, на каждую задачу использование ИИ случайно разрешали или запрещали. До старта они прогнозировали ускорение на 24%. Фактически с ИИ они работали на 19% дольше — и даже после эксперимента продолжали считать, что ускорились примерно на 20%.

Важная оговорка, без которой эту цифру таскать нельзя. METR изучала не автономных агентов. В их сетапе это Cursor Pro с Claude 3.5/3.7, то есть чат, режим агента Cursor и автодополнение — сама METR в разборе явно отделяет этот режим от полностью автономных агентов со сложными обвязками. Выборка маленькая, инструменты начала 2025 года, и авторы отдельно перечисляют, чего их результат не доказывает.

Тем ценнее вывод для нашей темы. Если разрыв между «мы ускорились на 20%» и «мы замедлились на 19%» возникает уже в мягком сценарии, где ИИ только помогает человеку, то в сценарии с автономным агентом, который сам ходит по кодовой базе и сам предлагает план, полагаться на ощущения команды тем более не выйдет. Мерить обязан руководитель, и мерить снаружи.

Помню, как однажды на ретро я услышал уверенное «стало заметно быстрее» и полез в трекер просто из вредности. Медиана lead time за два спринта не сдвинулась вообще.

Наблюдение 3. Узкое место переехало с написания на ревью

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

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

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

Ни один из этих эффектов не лечится на уровне отдельного разработчика.

Наблюдение 4. Работает не автономия агента, а подчинённая проактивность

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

• Подчинённая — агент не принимает решений. Не выбирает архитектуру, не расширяет скоуп, не решает, что заодно отрефакторит соседний модуль, не открывает PR без явной команды.

• Проактивная — агент не ждёт промпта. Исследует кодовую базу, проверяет гипотезы, поднимает противоречия: «вот тут возникает риск, что делаем?».

Аналогия, которая мне нравится: это режим работы ведущего разработчика с очень эрудированным стажёром, у которого мгновенная скорость и нулевая ответственность. Стажёр инициативен, но в main не пушит.

Из принципа вытекает конкретный контур с точками контроля. Схема ниже (рис. 2) — то, что у меня в итоге прижилось.

Главная мысль схемы — ценность не в фазах, а в трёх зелёных ромбах.

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

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

Ничего. Гнать их через три гейта — это бюрократия, и она убьёт практику быстрее любого скепсиса. Контур должен быть привязан не к типу изменения, а к радиусу поражения. У меня это выглядит примерно так:

Кстати, в оверсайт‑отчёте FINRA за 2026 год рекомендации звучат близко: явные человеческие чекпоинты перед действиями агентов, узкий скоуп, гранулярные права и полный аудит действий. Для регулируемых контуров это уже не пожелание.

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

Наблюдение 5. У команд, где получилось, совпадают три вещи

Смотрел на публичные разборы и на то, что вижу вокруг. По состоянию на июль 2026 совпадений три.

Контекстный слой лежит в репозитории и живёт как код. Тут стоит уточнить, потому что вокруг много путаницы. Единый формат всё‑таки появился: AGENTS.md вырос из инициативы OpenAI, сейчас курируется Agentic AI Foundation при Linux Foundation, поддержан более чем двумя десятками инструментов и лежит в десятках тысяч публичных репозиториев. Но универсальным он не стал: Gemini CLI читает GEMINI.md, у Claude Code родной формат CLAUDE.md богаче, у Cursor свои правила с glob‑скоупом.

Поэтому спорить про имя файла бессмысленно.

Важны три свойства:

1. контекст лежит рядом с кодом;

2. версионируется;

3. проходит обычное ревью.

Ключевое — не написать идеально один раз, а назначить мейнтейнера и принимать на этот файл PR. По сути это CODEOWNERS, только для контекста.

Контринтуитивная деталь, до которой доходишь после нескольких итераций: раздувать файл вредно.

Каждый токен инструкций — токен, отнятый у задачи, а императивные правила вида «контроллеры пиши так» ломаются на первом же исключении. Лучше работает ссылка на живой образец в вашем же коде.

<!-- фрагмент AGENTS.md (язык: Markdown) -->
## Границы
Red flags — не делаем никогда:
- миграции, удаляющие данные, без явного подтверждения человека
- обращения к боевым контурам из любых сессий
- правки в модулях вне скоупа текущего спринта

## Образцы вместо инструкций
Доменный слой — смотри `src/domain/order` как эталон.
REST-контроллеры — смотри `src/api/v2/payment`.

Права режутся инфраструктурой, а не договорённостями. В FinTech этот пункт не обсуждается вообще. Отдельный контур, отдельная идентичность для агента, отдельные ключи. Я бы предпочёл, чтобы агент физически не имел возможности сделать то, что сделал агент в истории с SaaStr, а не полагался на то, что он прочитал про код‑фриз в инструкции. Тем более что в том же опросе Gravitee лишь около 22% команд обращаются с агентами как с отдельными идентичностями — остальные живут на общих ключах, и после инцидента там даже не разобрать, кто именно что сделал.

-- Упрощённый пример для PostgreSQL (язык: SQL).
-- В production права обычно выдаются не на public,
-- а на выделенную схему или конкретный набор таблиц,
-- а пароль приходит из Vault / Secret Manager / IAM,
-- а не задаётся руками.
CREATE ROLE agent_ro LOGIN PASSWORD :'pwd';
GRANT CONNECT ON DATABASE app_stage TO agent_ro;
GRANT USAGE ON SCHEMA analytics TO agent_ro;
GRANT SELECT ON analytics.orders, analytics.payments TO agent_ro;
ALTER DEFAULT PRIVILEGES IN SCHEMA analytics GRANT SELECT ON TABLES TO agent_ro;
-- никаких INSERT/UPDATE/DELETE и тем более DDL

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

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

Главное, что видно на этой схеме (рис. 3), — необратимость порядка. Попытка стартовать сразу с третьей фазы, то есть спустить стандарт сверху, даёт не ускорение, а полугодовую фрустрацию и обход регламента.

Чем это мерить

Тут у меня жёсткая позиция. Метрика «процент кода, написанного AI» — самая разрушительная из популярных. Она тривиально накручивается и поощряет ровно то поведение, от которого весь контур защищает.

Что показывает картину честно:

• lead time от взятия задачи до мержа (не должен расти, а резкий обвал вниз — тоже сигнал, скорее всего где‑то пропускают гейты);

• нагрузка на ревьюера в PR и часах — первый индикатор скрытого возврата к режиму «сгенерировал и отправил»;

• Rework Rate, добавленный DORA пятым к классической четвёрке и показывающий, какая доля усилий уходит не на развитие продукта, а на переделку;

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

Полезная рамка для ожиданий — модель J‑кривой из отчёта DORA о ROI AI‑ассистированной разработки (версия 2026.01): сначала команда проваливается в яму продуктивности и только потом выходит наверх. Если не проговорить это заранее, первый же квартальный отчёт превратится в разговор «купили лицензии и стали медленнее».

Там же сформулирован главный тезис исследования 2025 года: AI работает как усилитель. Сильную инженерную систему усиливает, сломанную — тоже усиливает, только в другую сторону.

Где это не сработает

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

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

Чья это всё‑таки работа

Отдельно проговорю то, что мне возражают чаще всего. Права выдаёт DevOps. Доступами управляет Security. Конвенции держат сеньоры. Ревью делает команда. Где здесь руководитель?

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

Целиком системы не существует ни у кого, пока её кто‑то не соберёт. Собирает обычно технический руководитель, потому что он единственный, кому видны все куски сразу и кто отвечает за результат, а не за свой участок.

Именно поэтому инцидент вроде replit‑овского — не сбой модели. Отсутствие гейта, отсутствие read‑only доступа и отсутствие отдельного окружения по отдельности не были ничьей ошибкой. Ошибкой было то, что никто не смотрел на них вместе.

Что сделать сегодня

Три проверки, которые можно провести не меняя процессов:

1. Открыть конфиги и убедиться, что у агентов нет технической возможности дотянуться до боевых данных. Не «мы договорились, что не лезем», а именно нет прав.

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

3. Поднять Rework Rate за последние два‑три месяца и посмотреть на динамику.

Если на первый вопрос ответ «доступ есть», а на два остальных «не знаю» — вы уже в зоне риска, просто инцидент ещё не наступил.

Источники и материалы, на которые опирался:

• Разбор инцидента Replit / SaaStr, июль 2025 — публикации dev.by, Tproger, 3DNews

• METR, рандомизированное контролируемое исследование влияния ИИ‑инструментов на скорость опытных разработчиков, июль 2025

• Gravitee, “State of AI Agent Security 2026” (волны декабрь 2025 и апрель 2026)

• FINRA, оверсайт‑отчёт 2026, в части рекомендаций по автономным агентам

• DORA, “State of AI‑assisted Software Development” (2025) и «ROI of AI‑assisted Software Development» (2026.01)

• Спецификация и статус AGENTS.md, Agentic AI Foundation / Linux Foundation

• Разбор pull‑модели внедрения агентов в инженерной команде, Хабр, май 2026

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

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

На открытых уроках разберём эти задачи на практике:

• 3 сентября, 20:00. «Как руководителю внедрить ИИ в работу команды: от выбора процесса до рабочего сценария». Записаться

• 22 сентября, 20:00. «Можно ли доверять ИИ‑коду: как находить галлюцинации, уязвимости и устаревшие решения». Записаться

• 23 сентября, 20:00. «Как системному аналитику проводить архитектурное ревью и находить риски до начала разработки». Записаться

Больше открытых уроков собрали в дайджесте.