Мы прошли путь от первых пользователей LLM-инструментов до массового использования чатов и кодинг-агентов. На дашбордах всё выглядело правильно: люди заходили, пробовали, возвращались, приносили примеры, показывали демо, техлиды учили команды.
Метрики потока при этом долго не двигались.
Lead Time не снижался системно. Throughput не рос так, чтобы это было видно на уровне инженерной организации. Defect Rate не давал уверенного сигнала, что качество стало лучше.
Эта статья — большая версия двух моих постов на Habr: части 1 про рост использования и метрики результата и части 2 про Agentic Engineering и AI-first команды. Здесь я собираю логику целиком: от первых LLM-чатов до следующего слоя измерения, который оказался важнее обычного дашборда внедрения.
Два маршрута чтения
Если вы пришли за Agentic Engineering — прыгайте в раздел «Что тогда должен менять Agentic Engineering». Там главный тезис: ускорять нужно не пользователя AI, а путь задачи через систему.
Если хотите понять, почему мы к этому пришли, читайте с начала. Первые разделы показывают, почему рост MAU LLM и кодинг-агентов выглядел хорошо, но не двигал Lead Time и Throughput.
Считать пользователей AI полезно. Этого уже мало. В какой-то момент главный вопрос становится другим: сколько реальных задач проходят свои этапы с участием агентов, где агент входит в рабочий поток и сколько задач доходят от идеи до результата с агентной поддержкой на всём пути.
Зачем вообще внедрять AI в инженерные команды
AI легко внедрять как модный инструмент: выдать доступы, провести обучение, собрать первые восторженные отзывы, нарисовать график активных пользователей. Через месяц уже можно показать, что внедрение идёт.
Для инженерной организации этого мало.
В разработке важнее понять, стала ли задача быстрее проходить путь от решения «делаем» до продакшена. Пользователь, клиент, бизнес и регулятор видят не количество промптов. Они видят скорость, качество и предсказуемость изменений.
Поэтому мы смотрели на три метрики потока.
Lead Time — сколько времени проходит от момента, когда команда взяла задачу в работу, до релиза клиенту.
Throughput — сколько задач команда действительно доводит до результата за период.
Defect Rate — не ухудшается ли качество по пути.
Ожидание от AI было простым: если он действительно помогает инженерной системе, Lead Time должен снижаться или Throughput должен расти, а Defect Rate должен оставаться под контролем.
Это важная рамка. Дашборд внедрения показывает, что люди начали трогать инструмент. Метрики доставки показывают, изменилась ли система работы. Результат для бизнеса объясняет, зачем всё это было нужно: быстрее выпускать изменения, дешевле проходить операционные шаги, безопаснее работать с риском и быстрее проверять продуктовые гипотезы.
Первая попытка: LLM-чаты
Первый шаг был очевидным. Дать людям доступ к LLM-инструментам, объяснить пользу, провести обучение, показать сценарии.
Внедрение AI всё равно остаётся изменением привычек: сначала человек понимает смысл, затем пробует, учится и закрепляет новый способ работы.
Это сработало на уровне использования. Люди начали применять AI для текстов, объяснений, поиска идей, разбора небольших вопросов, подготовки черновиков. Месячная активная аудитория выросла. Появились регулярные пользователи. Внутри организации стало проще говорить про AI без ощущения, что это игрушка для энтузиастов.
Метрики потока не изменились.
Тогда появилась простая формулировка: чат — это туризм.
Человек зашёл, посмотрел, спросил, получил пользу, вернулся обратно в старый рабочий поток. Он мог сэкономить 15 минут, быстрее разобраться с незнакомой темой, написать письмо без мучений, накидать черновик документа.
Задача в системе продолжила ехать тем же маршрутом: аналитика, разработка, тестирование, ревью, согласования, релиз, сопровождение.
LLM жил рядом с работой. В путь задачи до продакшена он почти не попал.
Поэтому рост MAU LLM стал хорошим сигналом интереса и привычки. Сигналом ускорения инженерной системы он не стал.
Вторая попытка: кодинг-агенты
Следующая гипотеза выглядела сильнее: AI должен попасть туда, где появляется код, тесты, документация и pull request.
Кодинг-агенты ближе к реальной инженерной работе. Они могут искать места в коде, готовить первый вариант изменения, писать тесты, обновлять README, помогать с терминалом, разбирать наследованный код, собирать контекст для pull request.
Мы начали двигаться в эту сторону.
Лучше всего работали форматы, где человек сразу решал свою настоящую задачу. Реальный тикет из трекера. Мини-группа. Участник за рулём. Эксперт рядом как штурман. Техлид показывает сценарий на своей задаче. Команда регулярно делится находками на внутренних AI Labs.
Хакатоны хорошо работали как первая воронка. Они давали охват, снижали страх, помогали быстро завести людей в инструмент. Воркшопы работали глубже: участник приходил со своей задачей, сам проходил через настройку, промпты, ошибки, уточнения и результат. Так появлялась мышечная память.
Кодинг-агенты начали встраиваться в рабочий день части инженеров. Люди перестали воспринимать агента как отдельную игрушку. Появились локальные истории: код появился быстрее, тесты написались раньше, документация обновилась без обычного сопротивления.
Метрики потока снова не изменились системно.
Это был самый неприятный момент. Мы сделали более правильный шаг, ближе к инженерной работе. Получили привычку у части людей. Увидели хорошие локальные истории.
Маршрут задачи до продакшена целиком почти не сдвинулся.
Где была настоящая проблема
Мотивация людей оказалась не главным ограничением. Они поняли AI достаточно, чтобы начать пользоваться. Ограничение было в устройстве потока работы.
Разработчики быстрее встроили агентов в работу. Тестировщики двигались медленнее. DevOps и аналитики подключались с другой скоростью и в других сценариях. Один участок потока стал быстрее, остальные участки продолжили жить в прежнем режиме.
Lead Time редко сводится к разработке. В живой организации задача ждёт уточнения требований, ревью, тестового окружения, окна релиза, бизнес-валидации, соседней команды, решения по риску.
Представим обычную продуктовую задачу: изменить правило расчёта комиссии.
Разработчик с агентом быстрее нашёл нужные места в коде, собрал черновик изменения, написал тесты и подготовил pull request. Его часть работы сократилась с двух дней до половины дня.
Затем задача два дня ждала уточнения от аналитика. Потом зависла на тестовом окружении. Потом ждала ревью. Потом попала в ближайшее окно релиза. Потом бизнес попросил ещё одну проверку, потому что правило касается денег.
В локальной метрике разработчик стал быстрее. В Lead Time задачи почти ничего не изменилось.
Короче: ускоренный этап просто довёз задачу до следующего места ожидания. Скорость системы определяется не самым быстрым человеком. Скорость системы определяется тем местом, где работа ждёт.
Поэтому локальное ускорение разработки быстро упирается в требования, тестирование, ревью, релиз или бизнес-валидацию.
Дашборд внедрения начинает обманывать, когда становится главной картиной
Дашборд внедрения нужен. Без него непонятно, дошёл ли инструмент до людей. MAU, регулярное использование, доля пользователей кодинг-агентов, активность техлидов, посещаемость воркшопов — всё это полезные сигналы.
Проблема начинается, когда этот дашборд начинают читать как результат.
Рост пользователей показывает, что люди открыли дверь. Он не показывает, изменилась ли доставка. Регулярное использование говорит, что привычка формируется. Оно не показывает, где в потоке стало меньше ожидания. Количество запросов к модели показывает активность. Оно не отвечает, какая бизнес-цель сдвинулась.
После первых волн внедрения мы стали смотреть на AI через путь задачи: где он появляется, что делает и какой участок работы реально меняет.
Так появился следующий слой измерения. Нас стали интересовать задачи: в каких из них агенты действительно работали, на каких этапах участвовали, где их участие заканчивалось и какой участок оставался ручным узким местом.
Это меняет разговор. Команда перестаёт спорить про общую любовь к AI и начинает смотреть на маршрут задачи. Агент участвовал в анализе? Помог собрать требования? Сверил ограничения? Нашёл места в коде? Написал тесты? Подготовил документацию? Помог с проверками? Остался след в pull request, тикете, тестовом отчёте, README или другом рабочем артефакте?
Так мы переходим от учёта использования к покрытию этапов задачи агентами. Видно уже задачи, где AI действительно встроен в работу, а не только людей, которые открывают инструмент.
Что тогда должен менять Agentic Engineering
После двух попыток следующая гипотеза стала понятнее.
Чтобы сокращать Lead Time, агенту мало ускорять отдельного специалиста. Он должен помогать самой задаче проходить через систему.
Так появляется Agentic Engineering.
Для меня Agentic Engineering начинается там, где агент становится участником потока задачи. Он собирает контекст из тикета, кода и документации, предлагает изменение, запускает проверки, пишет тесты, обновляет README, документацию или описание API и готовит следующий шаг для человека.
Человек держит рамку: задаёт цель, ограничения и критерии качества, принимает решения, проверяет риск и отвечает за последствия.
Это важная граница. Агент может быстро предлагать варианты. Ответственность за инженерное решение остаётся у человека и команды.
Метафора простая: агенты могут быть быстрыми помощниками, но им нужны цель, контекст, ограничения и проверка результата.
В этой логике Agentic Engineering перестраивает маршрут задачи. Меньше пустых передач между этапами. Больше готового контекста. Больше автоматических проверок. Больше артефактов, которые появляются сразу в рабочем месте, без отдельного напоминания.
Теперь мы смотрим на задачи, а не только на пользователей
Следующий практический сдвиг для нас — считать задачи, в которых агенты работают внутри потока.
Раньше основной вопрос звучал проще: сколько людей пользуются AI. Теперь он стал точнее: сколько задач прошли анализ, разработку, тестирование, документацию, релизную подготовку или валидацию с участием агента.
Это меняет объект управления.
Когда мы считаем людей, мы управляем внедрением инструмента. Когда считаем задачи, мы начинаем управлять системой доставки. В первом случае видно, кто открыл AI. Во втором — где AI вошёл в работу, какой этап ускорил и где задача всё ещё ждёт человека, окружение, проверку или решение.
Например, задача может быть агентной только на этапе разработки. Агент помог найти нужные места в коде, подготовить изменение, написать тесты и собрать pull request. Это полезно. Дальше задача может поехать старым маршрутом: ждать уточнения требований, тестового окружения, ревью, релизного окна или бизнес-валидации.
Другая задача проходит с агентом больше этапов: анализ, подготовку спецификации, изменение кода, тесты, документацию и часть проверок. Здесь уже появляется шанс повлиять на Lead Time, потому что агент работает на нескольких участках и помогает задаче двигаться по маршруту.
Поэтому нам важна глубина участия агента, а не один факт использования. Один этап. Два этапа. Несколько этапов. Почти весь путь до результата.
Так видно, где агентность остаётся привычкой отдельной роли, а где начинает менять прохождение задачи через систему.
Для управленческого разговора это полезнее общего MAU. Если в команде много пользователей AI, а почти все задачи получают помощь только в коде, следующее узкое место, скорее всего, будет в требованиях, тестировании, ревью или бизнес-валидации. Если растёт доля задач, где агент работает на нескольких этапах, можно ждать движения в метриках потока.
Логика становится такой: дашборд внедрения показывает вход, покрытие этапов показывает проникновение AI в реальную работу, задачи с агентной поддержкой на нескольких этапах показывают изменение маршрута, а Lead Time, Throughput, Defect Rate и результат для бизнеса отвечают, был ли в этом смысл.
Почему отсюда появляются AI-first и AI-native команды
В этой логике становится понятнее интерес к AI-first и AI-native командам.
Их часто описывают как маленькие группы из двух-трёх человек, которые с помощью агентов берут ответственность за весь путь задачи: от понимания до релиза и наблюдения за результатом.
Вокруг этого много хайпа. Рациональное зерно простое.
Если большая часть Lead Time уходит на передачи между этапами, маленькая команда со сквозной ответственностью сокращает эти передачи. Меньше переходов из рук в руки. Меньше ожиданий. Быстрее координация. Больше ответственности за результат целиком.
AI-native команда — это гипотеза про поток работы: меньше передач, больше сквозной ответственности, быстрее обратная связь.
В такой модели команда пытается держать весь путь задачи: от понимания до реализации, проверок и наблюдения за результатом.
Проверка конкретная: даёт ли сквозная ответственность вместе с агентной работой меньший Lead Time, больший Throughput и стабильное качество.
У нас был такой пилот: небольшая команда, новый контур без тяжёлого наследия, ответственность за сквозной результат, работа через агентов. Первый месяц ушёл на формирование привычки. Люди учились работать на уровне спецификаций, использовать агентские фреймворки, раскладывать задачу на роли и проверки.
Сначала команда не стала резко быстрее по Lead Time. Зато меньшим составом она смогла делать сопоставимый объём работы, а затем начала делать больше. Throughput вырос, качество сохранилось. Это важный сигнал: первый эффект AI-first подхода иногда проявляется сначала в способности меньшей команды удерживать и увеличивать поток результата, а уже потом — в падении Lead Time.
Дальше начинаются ограничения.
Цена подхода
На слайде маленькая AI-native команда выглядит почти идеально. В живой организации она быстро упирается в систему.
Первое ограничение — когнитивная нагрузка. Сквозная ответственность за весь цикл разработки давит на человека. Нужно понимать задачу, код, тесты, релиз, риски, доменные ограничения и последствия. Если человек выходит за пределы роли без поддержки, он получает больше работы вместо большего рычага.
Второе ограничение — валидация. Агенты генерируют быстрее, чем человек успевает проверять. Без тестов, наблюдаемости, канареечных релизов, отката, критериев качества и понятных ограничений скорость превращается в очередь ручной проверки.
Третье ограничение — предметная область. Бизнес-эксперт часто оказывается единственным носителем знаний: где есть исключения, где нельзя ошибиться, почему формально правильное решение ломает реальную операцию. Если весь поток постоянно упирается в одного человека, он становится новым узким местом.
Четвёртое ограничение — соседние команды и общие процессы. Быстрая команда всё равно живёт внутри организации. Её работа упирается в безопасность, архитектурные комитеты, данные, инфраструктуру, общий релизный процесс, подразделения с другой зрелостью AI.
Поток снова начинает ждать.
Ускорение одной команды даёт эффект только до того места, где задача встречает более медленный внешний этап.
Обвязка важнее героизма
Если агентная работа держится только на сильных людях, она плохо масштабируется.
Нужна обвязка: правила, контекст, скиллы, шаблоны, проверки, база знаний, критерии качества, безопасные сценарии, понятные границы автономности. В англоязычной практике это часто называют harness или AI engineering platform. Название вторично. Суть в том, что агенту нужен рабочий контур, где он может брать контекст, выполнять задачу и проверять результат воспроизводимо.
Эксперты в этой логике не исчезают. Они меньше отвечают на одни и те же вопросы руками и больше превращают своё знание в правила, примеры, проверки и контекст для агентов.
Тестировщик помогает агенту работать с матрицей проверок, критериями качества и рисками. Аналитик превращает предметную область, исключения и ограничения в контекст, с которым агент может работать. DevOps описывает безопасный инфраструктурный сценарий, чтобы агент не угадывал путь через терминал.
В агентизации роли человек не исчезает из процесса. Он получает дополнительные руки и остаётся держателем стандарта качества.
Так меняется роль человека. Он становится держателем стандарта качества на своём участке и постепенно учит агента выполнять всё больше работы внутри этого стандарта.
Что проверять перед экспериментом
Agentic Engineering плохо начинается с приказа «с понедельника работаем как AI-native». Лучше начать с диагностики потока.
Перед экспериментом важно увидеть путь задачи целиком: от решения «делаем» до продакшена и проверки результата. Где задача ждёт? Где теряется контекст? Где нужен эксперт? Где проверка полностью ручная? Где команда уже умеет работать с агентами? Где есть тесты, наблюдаемость и безопасная выкладка?
Дальше полезно выбрать узкую гипотезу. Например: «увеличим долю задач, где агент помогает с кодом, тестами и документацией». Или «проверим, сокращается ли ожидание на этапе анализа, если агент заранее собирает контекст из тикета, вики и кода». Или «посмотрим, сколько задач проходят путь с агентной поддержкой на нескольких этапах».
Так эксперимент становится проверяемым. У него есть рабочая метрика, метрика потока и связь с бизнес-целью.
Куда это ведёт
После нескольких волн внедрения стало понятно: использование AI само по себе не ускоряет путь задачи до продакшена.
LLM-инструменты дают личную пользу. Кодинг-агенты усиливают разработчиков и отдельные роли. Agentic Engineering начинает менять путь задачи через систему.
Из этого не следует, что каждой организации срочно нужны маленькие AI-native команды. Рабочая гипотеза спокойнее: AI должен попадать туда, где задача реально ждёт, теряет контекст или проходит ручную проверку.
Поэтому следующий этап измерения для нас — смотреть на задачи. Сколько задач получили агентную помощь на одном этапе. Сколько прошли несколько этапов с агентами. Сколько дошли почти до сквозного пути. Где агент остановился. Где человек стал контролем качества, а где превратился в очередь ручной проверки.
После этого разговор про Agentic Engineering становится предметным.
Вопрос звучит так: какую часть пути задачи мы изменили — и стало ли от этого быстрее, качественнее или полезнее для бизнеса.
Agentic Engineering начинается не с агента. Он начинается с маршрута задачи, который мы наконец-то научились видеть.