Автоматизация workflow для разработчиков с ИИ: узкое место, которое никто не автоматизировал
Разработчики теперь тратят на ревью кода, сгенерированного ИИ, больше времени, чем на его написание. Опрос разработчиков 2026 года показал в среднем 11,4 часа в неделю на ревью против 9,8 часов на написание нового кода. Генерацию кода автоматизировали первой. Ревью нет, и теперь это более медленная половина цикла.
Что на самом деле показывает отчёт DORA за 2026 год
Команда DORA от Google Cloud поставила число на этот компромисс в своём отчёте 2026 года про ROI ИИ в разработке ПО. Использование ИИ коррелирует с реальным ростом индивидуальной эффективности и качества кода, но также коррелирует с ростом нестабильности поставки: в примерной модели отчёта частота сбоев при изменениях выросла с 5% до 6%, что в пересчёте на бизнес-показатели дало минус 344000 долларов.
DORA называет эту скрытую стоимость «налогом на верификацию»: дополнительным временем, которое требуется, чтобы проверить, действительно ли сгенерированный ИИ код надёжен, безопасен и согласован с остальной системой, прежде чем его выкатывать. Вывод самого отчёта не в том, чтобы замедлить генерацию кода. Он в том, что отдача от ИИ зависит от инженерной системы вокруг него, а не от самого инструмента для написания кода.
Почему пропускная способность ревью не масштабируется вместе с ИИ
Больше кода, проходящего через пайплайн, не помогает, если люди, которые его проверяют, упираются в тот же лимит, что и раньше. Тот же опрос 2026 года показал, что когда объём сгенерированного кода обгоняет пропускную способность ревью, команды попадают в один из двух паттернов: мерджат работу, которую реально не проверили, либо позволяют пул-реквестам зависать в очереди бесконечно. Оба паттерна встретились в 37% ответов, а значит больше трети опрошенных команд уже упираются в эту стену.
Ни один из этих сбоев не проблема людей. Это то, что происходит, когда одна часть пайплайна получает десятилетие ускорений, а следующая за ней часть нет.
Куда во всё это реально встраиваются ИИ-ревьюеры
Это ровно тот разрыв, который призвана закрыть категория ИИ-ревью кода, и она выросла достаточно быстро, чтобы доказать: проблема реальная, а не теоретическая. Сейчас эта категория это рынок примерно на 400-600 миллионов долларов годовой выручки, где по внедрению лидируют CodeRabbit и Greptile. Только CodeRabbit сообщает о более чем 2 миллионах подключённых репозиториев и 13 миллионах проверенных пул-реквестов на начало 2026 года. Небольшие команды (2-5 разработчиков) показывают самое высокое внедрение, что логично: переполненная очередь ревью бьёт больнее, когда подхватить нагрузку больше некому. Отдельно Gartner обнаружил, что 30% предприятий с более чем 1000 разработчиков внедрили хотя бы один инструмент ИИ-ревью кода к концу 2025 года.
ИИ-ревьюер реально закрывает часть разрыва: он читает дифф быстрее, чем это позволяет очередь людей. Чего он не делает сам по себе, так это не сообщает тому, кто смотрит на доску задач, действительно ли ревью произошло, и находится ли PR за тикетом в статусе «зелёный», «в ожидании» или «завис».
Часть, которая всё ещё ручная: связать PR обратно с тикетом
Это именно то, что мы реально встроили в TAM, и здесь важно точно сказать, что это делает, а что нет, уже сегодня. Когда PR открывают, проверяют или по нему проходит прогон CI, TAM автоматически привязывает эту активность GitHub к соответствующей задаче через вебхук, так что связь не зависит от того, вставит ли кто-то ссылку вручную. tam.github.pr.status затем даёт живой, доступный только для чтения вид реального состояния этого PR (статус ревью, прогоны CI, возможность мерджа) прямо из задачи, вместо того чтобы кто-то вручную переносил статус из GitHub.
Запрос ревью или запись доказательства к тикету (результат теста, вывод скана, заметка ревьюера) тоже фиксируется как запись с таймстампом прямо в задаче, так что появляется реальная запись того, что и когда проверили, вместо того чтобы эта информация жила только в чьей-то памяти или в треде Slack.
Чтобы было честно о том, где это сейчас находится: это видимость и аудиторский след, а не принудительный контроль. Ничто сейчас не блокирует смену статуса, если проверки не хватает. Что это реально решает, так это более базовую версию той же проблемы: при 11,4 часах в неделю, потраченных на ревью, команде меньше всего нужно ещё и вручную проверять GitHub, чтобы узнать, действительно ли PR по тикету закончили проверять.
Если вы это настраиваете, подключение Cursor или Claude Code к TAM через MCP это отправная точка, а построение собственных MCP-инструментов вокруг реального состояния задачи разбирает паттерн, чтобы собрать что-то подобное самостоятельно.