Использование AI выросло, Lead Time не изменился. Что сломалось в потоке
Статус: черновик. Пишем и редактируем прямо на сайте. Текст ещё не финальный: структура, формулировки и примеры будут меняться.
Мы подняли использование LLM-инструментов примерно с 5% до 50%. Потом довели регулярное использование кодинг-агентов примерно до 35% активных пользователей в месяц.
Люди правда начали пользоваться AI.
Метрики потока при этом системно не изменились.
Lead Time не поехал вниз. Throughput не вырос так, чтобы это было видно в системе. Defect Rate не дал понятного сигнала, что качество стало лучше.
Это неприятный момент во внедрении AI. Дашборд использования выглядит хорошо: доступы выданы, обучение проведено, демо нравятся, техлиды показывают примеры, активных пользователей становится больше. По этой картинке кажется: инженерная организация уже изменилась.
Затем смотришь на путь задачи до продакшена и видишь знакомую картину. Задача ждёт уточнения, ревью, тестового окружения, окна релиза.
AI ускорил кусок работы. Маршрут задачи до продакшена остался прежним.
Что мы хотели ускорить
Использование AI было только входной метрикой. Главный вопрос был жёстче: стала ли задача быстрее проходить путь от решения “делаем” до продакшена.
Поэтому мы смотрели на метрики прохождения задачи до продакшена:
- Lead Time — сколько времени проходит от решения “делаем” до релиза;
- Throughput — сколько задач команда реально доводит до результата;
- Defect Rate — не проседает ли качество по пути.
Если AI ускоряет разработку как систему, это должно проявиться там. Использование инструмента — промежуточный сигнал. Люди открыли дверь. Быстрее задачи от этого ещё не поехали.
Первая попытка: LLM-чаты
Первый шаг был очевидным. Дать людям доступ к LLM-инструментам, объяснить пользу, провести обучение, показать сценарии.
Это сработало на уровне использования. Месячная активная аудитория LLM-инструментов поднялась примерно с 5% до 50%. Появились регулярные пользователи. Люди начали использовать AI для текстов, объяснений, поиска идей, разбора небольших вопросов, подготовки черновиков.
Метрики потока не изменились.
Тогда появилась простая формулировка: чат — это туризм.
Человек зашёл, посмотрел, спросил, получил пользу, вернулся обратно в старый рабочий поток. Иногда он сэкономил 15 минут. Иногда быстрее разобрался с незнакомой темой. Иногда написал письмо без мучений.
Задача в системе продолжила ехать тем же маршрутом: аналитика, разработка, тестирование, ревью, согласования, релиз, сопровождение.
LLM жил рядом с работой. В реальный путь задачи до продакшена он почти не попал.
Вторая попытка: кодинг-агенты
Следующая гипотеза была сильнее: AI должен попасть туда, где появляется код, тесты, документация и pull request.
Это уже инженерная работа: первый вариант правки в коде, тест, анализ легаси, pull request, команда для терминала, обновление документации.
Мы начали двигаться в сторону кодинг-агентов.
Лучше всего работали форматы, где человек сразу решал свою настоящую задачу. Реальный тикет из трекера. Мини-группа. Участник за рулём. Эксперт рядом как штурман. Техлид показывает сценарий на своей задаче. Команда регулярно делится находками на AI Labs.
Использование снова выросло. Доля активных пользователей кодинг-агентов в месяц поднялась примерно до 35%. У флагманских команд показатели были выше. Появились люди, которые перестали воспринимать агента как игрушку и начали встраивать его в рабочий день.
Метрики потока снова не изменились системно.
Это был неприятный результат. Мы сделали более правильный шаг, ближе к реальной инженерной работе. Получили привычку у части людей. Увидели хорошие локальные истории.
Маршрут задачи до продакшена целиком почти не сдвинулся.
Где была настоящая проблема
Мотивация людей оказалась не главным ограничением. Они поняли AI достаточно, чтобы начать пользоваться. Ограничение было в том, как устроен поток работы.
Разработчики быстрее встроили агентов в работу. Тестировщики — заметно слабее. DevOps — ещё слабее. Аналитики — почти не встроили.
Один участок потока стал быстрее. Остальные участки продолжили жить в прежнем режиме.
Lead Time редко сводится к разработке. Здесь Lead Time — путь задачи от решения “делаем” до продакшена, а не только время написания кода. В реальности там много ожидания: уточнения, ревью, тестового окружения, окна релиза.
Представим обычную продуктовую задачу: изменить правило расчёта комиссии.
Разработчик с агентом быстрее нашёл нужные места в коде, собрал черновик изменения, написал тесты, подготовил pull request. Его часть работы сократилась с двух дней до половины дня.
Затем задача два дня ждала уточнения от аналитика. Потом зависла на тестовом окружении. Потом ждала ревью. Потом попала в ближайшее окно релиза. Потом бизнес попросил ещё одну проверку, потому что правило касается денег.
В локальной метрике разработчик стал быстрее. В Lead Time задачи почти ничего не изменилось.
Короче: если ускорить один этап, задача быстрее доедет до следующего узкого места. Скорость системы определяется не самым быстрым человеком. Скорость системы определяется тем местом, где работа ждёт.
Что тогда должен менять Agentic Engineering
После этого следующая гипотеза стала понятнее.
Чтобы сокращать Lead Time, агенту мало ускорять отдельного специалиста. Он должен помогать самой задаче проходить через систему.
Так появляется Agentic Engineering.
Для меня Agentic Engineering, или агентная инженерия, начинается там, где агент становится участником потока задачи. Он собирает контекст из тикета, кода и документации, предлагает изменение, запускает проверки, пишет тесты, обновляет README, документацию или описание API и готовит следующий шаг для человека.
Человек держит рамку. Он задаёт цель, ограничения, критерии качества, принимает решения, проверяет риск и отвечает за последствия.
Это важная граница. Агент может быстро предлагать варианты. Ответственность за инженерное решение остаётся у человека и команды.
Почему отсюда появляются AI-native-команды
В этой логике становится понятнее интерес к AI-native-командам.
Их часто описывают как маленькие группы из 2–3 человек, которые с помощью агентов берут ответственность за весь путь задачи: от понимания до релиза и наблюдения за результатом.
Вокруг этого много хайпа. Рациональное зерно простое.
Если большая часть Lead Time уходит на передачи между этапами, маленькая команда со сквозной ответственностью становится способом эти передачи сократить. Меньше переходов из рук в руки. Меньше ожиданий. Быстрее координация. Больше ответственности за результат целиком.
AI-native-команда — это гипотеза про поток работы: меньше передач, больше сквозной ответственности, быстрее обратная связь.
Проверка конкретная: даёт ли сквозная ответственность плюс агентная работа меньший Lead Time, больший Throughput и стабильное качество.
Цена подхода
На слайде маленькая AI-native-команда выглядит почти идеально. В живой организации она быстро упирается в ограничения.
Первое — когнитивная нагрузка. Сквозная ответственность за весь цикл разработки давит на человека. Нужно понимать задачу, код, тесты, релиз, риски, доменные ограничения и последствия.
Второе — валидация. Агенты генерируют быстрее, чем человек успевает проверять. Без тестов, наблюдаемости, канареечных релизов, отката, критериев качества и ограничений скорость превращается в очередь ручной проверки.
Третье — доменное знание. Бизнес-эксперт нужен везде одновременно. Если предметная область живёт только в голове одного человека, агентная команда быстро упирается в этого человека.
Есть ещё системное ограничение. Ускорить одну команду недостаточно. Быстрая команда упрётся в соседей с другой зрелостью, общий релизный процесс, безопасность, архитектурные комитеты, данные, инфраструктуру.
Поток снова начнёт ждать.
Что проверить до эксперимента
Agentic Engineering плохо начинается с приказа “с понедельника работаем как AI-native”. Лучше начать с диагностики.
Перед экспериментом я бы проверил семь вещей:
- путь задачи от “делаем” до продакшена виден целиком;
- ожидания размечены: ревью, тесты, окружения, согласования, релиз;
- Lead Time считается из системы, без ручной магии в Excel;
- у команды есть тесты, наблюдаемость и безопасная выкладка;
- понятно, где агент действует сам, где нужен контроль, где решение остаётся за человеком;
- есть люди, которые уже используют агентов на реальных задачах;
- есть лидер, который сам прошёл этот сценарий и может показать его на живой работе.
Эти вопросы скучнее, чем обсуждение новых ролей и красивых названий команд. Они полезнее.
Куда это ведёт
После двух попыток стало понятно: использование AI само по себе не равно ускорению пути задачи до продакшена.
LLM-инструменты дают личную пользу. Кодинг-агенты усиливают разработчиков. Agentic Engineering меняет путь задачи через систему.
Из этого не следует, что каждой организации срочно нужны AI-native-команды. Рабочая гипотеза другая.
Если AI не меняет путь задачи до продакшена, он остаётся локальным усилителем. Польза есть. Системного ускорения может не появиться.
Agentic Engineering начинается с простого вопроса: какую часть системы доставки мы на самом деле хотим ускорить?