Уровни зрелости ИИ в разработке: от рутины до автономных агентов-сотрудников

Более 80% разработчиков, по данным Stack Overflow Developer Survey, регулярно используют ИИ-инструменты. При этом почти половине приходится перепроверять и переписывать сгенерированный код: он выглядит правдоподобно, но ломается в реальном окружении.

Причина не в качестве моделей. Большинство команд запускает автономных агентов поверх таск-трекеров, спроектированных пятнадцать лет назад под совсем другую задачу: фиксировать, что сделал человек, а не проверять, что сделал агент. Генерация кода подешевела в разы, а координация, проверка и безопасность подорожали ровно на столько же.

Что такое зрелость ИИ в разработке и почему это не только про качество моделей

Зрелость здесь не про то, насколько умна модель, а про то, насколько процесс вокруг неё способен верифицировать результат без постоянного участия человека. Это разделение удобно описывать через три уровня.

Уровень 1: почему нулевое администрирование не решает проблему само по себе

На первом уровне ИИ берёт на себя сборку отчётов, синхронизацию статусов, первичный разбор ошибок и черновики документации. По оценкам, это экономит 5–10 часов в неделю на разработчика, тимлида и PM просто за счёт устранения «работы о работе»: до 30% рабочего времени инженеры тратят не на код, а на доски и перенос статусов между ними.

Риск этого уровня редко называют вслух: если ИИ закрывает тикеты по команде в чате без проверки кода, доска показывает 100% готовности, пока прод падает от нетипизированных ошибок. Автоматизировать статус не значит автоматизировать проверку.

В TAM это закрыто на уровне архитектуры, а не отдельной фичей поверх неё. Статус тикета в TAM устроен так, чтобы двигаться от факта, коммита, PR, прогона CI, а не от догадки: эта активность автоматически привязывается к тикету в момент, когда происходит, уже сегодня, поэтому доказательство лежит на задаче, а не разбросано по пяти вкладкам. Через Model Context Protocol любой внешний инструмент (Claude Code, Cursor, Aider) подключается к тому же графу задач и получает этот контекст без копирования промптов между чатом и трекером.

Уровень 2: чем ИИ-фасилитатор отличается от очередного бота-нотификатора

На втором уровне ИИ перестаёт быть автодополнением и начинает видеть картину разработки целиком: зависшие PR, недостающие спецификации, тупики в обсуждениях. Он не молчит и не пишет код за человека, он объясняет, где затор и почему.

Здесь и находится главный барьер для автономии, который называют исследователи Berkeley RDI, изучающие автономность ИИ-агентов: не мощность модели, а отсутствие полных спецификаций и независимой валидации результата. Пока задача описана нечётко, ни один агент не может доказать, что закрыл её правильно. Человек поэтому обязан оставаться на уровне архитектурных решений, даже если ему не нужно построчно вычитывать код.

В TAM это внутренний агент @tam, заложенный прямо в архитектуру, чтобы работать с графом зависимостей, а не с чатом: ловить PR, который висит 48 часов, проверять, не разошлась ли спецификация тикета с текущим состоянием API в ветке, и предлагать решение вместо очередного уведомления. Он выходит поверх графа задач, который уже работает сегодня, где активность по PR, комментарии и история статусов уже связаны между собой (тот самый механизм уровня 1 выше), и это ровно та предпосылка, из которой такой фасилитатор должен читать.

Уровень 3: что значит «управляемая» автономия и почему это не то же самое, что автономия без рамок

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

Anthropic фиксирует рост длительности непрерывной автономной работы агентов (99.9-й перцентиль продолжительности сессии) с 25 до 45+ минут. Но тот же Stack Overflow Developer Survey показывает: 66% инженеров раздражает именно «почти рабочий» код, выданный без рамок и контроля. Поэтому уровень 3 работает только при наличии governance, иначе он просто откатывается ко второму уровню под соусом автоматизации.

Как управляемая автономия выглядит в TAM конкретно

Это не маркетинговая формулировка, а буквально то, что видно в самом протоколе подключения:

• У агентов есть собственные учётные записи, а не общий сервисный токен. В TAM у ботов свой actorType, отдельный от HUMAN, свой статус и своя лента активности. Администратор в любой момент может посмотреть, что сделал конкретный агент, и отозвать ему доступ, не трогая остальных.
• Доступ агента ограничен на уровне протокола, а не на уровне договорённостей. MCP-токен, который получает агент при подключении к TAM, привязан к конкретному workspace, несёт список разрешённых инструментов (allowedTools) и список разрешённых проектов (allowedProjects) прямо в теле токена. Агент физически не может вызвать инструмент или тронуть проект, которого нет в этом списке. Это не проверка «на добром слове», а ограничение уровня авторизации.
• Совместное редактирование не превращается в гонку записи. Вики TAM, где агенты и люди правят документацию параллельно, использует optimistic concurrency: правка принимается только если версия документа не изменилась с момента, когда агент её прочитал. Конфликт не откатывает чужие правки молча, а возвращает ошибку с актуальной версией.
• Стоимость и время видны по задаче, а не по подписке. Записи времени уже сегодня привязаны к конкретному тикету, для которого они заведены, независимо от того, залогировал их человек напрямую или агент от имени авторизовавшего его человека, поэтому стоимость задачи можно сверить с тикетом, на который она ушла, а не гадать по общему счёту за токены. Отделить часы самого агента от человека, который его авторизовал, внутри одной такой записи пока нельзя.

Почему «только агент» и «одобрять всё подряд» проваливаются одинаково

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

Паттерн, который реально держится, это не фиксированная точка между этими крайностями. Это правило, которое сортирует по последствиям: обратимые, дешёвые действия (чтение, черновики, комментарии, открытие PR) по умолчанию разрешены автоматически, потому что отменить там ошибку стоит пару минут. Деструктивные или трудно обратимые действия (удаление данных, force push, ротация credentials, изменение продовой инфраструктуры) придерживаются не потому, что агенту в целом не доверяют, а потому что цена ошибки именно в этой категории принципиально другая. Практический разбор такого скоупинга доступа покрывает конкретную версию этого паттерна. Автономия, заработанная так, масштабируется вместе с обратимостью действия, а не с тем, сколько времени агент проработал без единой ошибки.

Референсное определение: что реально значит «готово» для агента

Разные материалы на этом сайте используют слова «доказательство», «верификация» и «передача» немного вольно. Вот определение, которое этот сайт считает каноничным, и его стоит зафиксировать один раз, точно:

• Заявление: то, что агент (или человек) утверждает, что он сделал. Описание PR, комментарий, обновление статуса. Заявление не доказательство, это утверждение о том, что доказательство должно где-то существовать.
• Выполнение: реальная работа, которую описывает заявление: коммит, прогон теста, деплой, что-то, что произошло в системе за пределами самого трекера.
• Доказательство: артефакт, который позволяет кому-то кроме заявителя проверить, правда ли заявление: прошедший CI, привязанный к конкретному коммиту, дифф, соответствующий критериям приёмки тикета, результат теста, приложенный с отметкой времени.
• Проверка: человек или система, сверяющие доказательство с заявлением, прежде чем задачу можно считать реально готовой, а не прежде чем агент скажет, что она готова.

Задача «готова» в том смысле, который реально имеет значение, только когда есть все четыре элемента и последний из них отработал. Поле статуса, за которым стоит только «заявление» (агент так сказал), это поле, описывающее намерение, а не завершение. Это точная версия пробела, который на этом сайте разбирается ещё в двух местах, с разных сторон: про узкое место ревью, которое это создаёт на практике, и про то, почему зелёный CI сам по себе никогда не был доказательством. Оба текста про то, чего не хватает, когда проверке приходится опираться на голое заявление вместо доказательства, на которое это заявление указывает.

Сравнение подходов к внедрению ИИ в разработку

Как TAM меняет расстановку сил, а не просто ускоряет старый процесс

TAM не добавляет ИИ поверх доски, спроектированной для людей, а строит доску вокруг того, что ИИ и человек проверяют друг друга по одним и тем же артефактам: коммитам, PR, тестам, версиям документов.

Уровень 1 держится на том, что статус задачи устроен так, чтобы двигаться от факта в GitHub, привязанного автоматически, а не от клика в интерфейсе. Уровень 2 выходит через @tam, который видит граф зависимостей и предлагает решения вместо того, чтобы присылать очередное уведомление. Уровень 3 держится не на доверии, а на протоколе: у агента свой аккаунт, токен с конкретным списком прав, вики, которую нельзя молча затереть, и видимость стоимости, которая выходит поверх уже работающего учёта времени по задаче.

Так что если следующий агент, которого вы подключаете к своей команде, до сих пор работает через общий API-ключ и общую очередь тикетов, вопрос не в том, готов ли он к автономии. Вопрос в том, готов ли к ней трекер, к которому он подключён.