Уровни зрелости ИИ в разработке: от рутины до автономных агентов-сотрудников
Более 80% разработчиков, по данным Stack Overflow Developer Survey, регулярно используют ИИ-инструменты. При этом почти половине приходится перепроверять и переписывать сгенерированный код: он выглядит правдоподобно, но ломается в реальном окружении.
Причина не в качестве моделей. Большинство команд запускает автономных агентов поверх таск-трекеров, спроектированных пятнадцать лет назад под совсем другую задачу: фиксировать, что сделал человек, а не проверять, что сделал агент. Генерация кода подешевела в разы, а координация, проверка и безопасность подорожали ровно на столько же.
Что такое зрелость ИИ в разработке и почему это не только про качество моделей
Зрелость здесь не про то, насколько умна модель, а про то, насколько процесс вокруг неё способен верифицировать результат без постоянного участия человека. Это разделение удобно описывать через три уровня.
| Уровень | Роль ИИ | Что проверяется |
|---|---|---|
| 1. Пассивная автоматизация | Устраняет рутину: отчёты, статусы, черновики | Ничего не блокирует, работает в фоне |
| 2. Сопровождение решений | Аналитик и фасилитатор: находит узкие места, предлагает варианты | Решение принимает человек, ИИ готовит контекст |
| 3. Автономные агенты | Полноценный участник команды со своим доступом | Сам доступ ограничен и отзываем, а не просто под наблюдением |
Уровень 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: правка принимается только если версия документа не изменилась с момента, когда агент её прочитал. Конфликт не откатывает чужие правки молча, а возвращает ошибку с актуальной версией.
- Стоимость и время видны по задаче, а не по подписке. Записи времени уже сегодня привязаны к конкретному тикету, над которым работал агент или человек, а стоимость по задаче выходит поверх того же учёта, поэтому стоимость фичи, сделанной агентом, можно будет напрямую сопоставить с человеко-часами на неё же, а не гадать по общему счёту за токены.
Сравнение подходов к внедрению ИИ в разработку
| Критерий | Jira/Linear + AI-плагины | Chat-first инструменты (Cursor, Claude Code сами по себе) | TAM |
|---|---|---|---|
| Уровень зрелости | 1: ручной ввод, автодополнение поверх старой доски | 3 без рамок: агент автономен, но без границ доступа | Полный спектр 1→3 в одной системе |
| Проверка результата | На основе того, что написал человек | На основе текста ответа в чате | На основе кода, пайплайна и приложенных доказательств, с принудительным контролем на подходе |
| Контроль доступа | Обычные роли для людей, агенты вне модели прав | Ограничен локальным терминалом разработчика | Отдельные аккаунты агентов, allowlist на инструменты и проекты, отзыв по каждому агенту отдельно |
| Видимость затрат | Не считается отдельно | Не считается отдельно | Время фиксируется по задаче уже сейчас, стоимость по задаче выходит следующей |
Как TAM меняет расстановку сил, а не просто ускоряет старый процесс
TAM не добавляет ИИ поверх доски, спроектированной для людей, а строит доску вокруг того, что ИИ и человек проверяют друг друга по одним и тем же артефактам: коммитам, PR, тестам, версиям документов.
Уровень 1 держится на том, что статус задачи устроен так, чтобы двигаться от факта в GitHub, привязанного автоматически, а не от клика в интерфейсе. Уровень 2 выходит через @tam, который видит граф зависимостей и предлагает решения вместо того, чтобы присылать очередное уведомление. Уровень 3 держится не на доверии, а на протоколе: у агента свой аккаунт, токен с конкретным списком прав, вики, которую нельзя молча затереть, и видимость стоимости, которая выходит поверх уже работающего учёта времени по задаче.
Так что если следующий агент, которого вы подключаете к своей команде, до сих пор работает через общий API-ключ и общую очередь тикетов, вопрос не в том, готов ли он к автономии. Вопрос в том, готов ли к ней трекер, к которому он подключён.