AI пишет больше кода. Почему поставка не ускоряется?

Локальная оптимизация не устраняет ограничение системы, а перемещает очередь дальше по потоку. Если кодирование ускорилось, новым пределом могут стать согласование, проверка, интеграция или способность человека вести несколько агентных задач параллельно. Поэтому ведущие предлагают начинать от принятого пользовательского результата и двигаться назад: описать полный путь изменения, найти текущее узкое место и заранее спросить, куда оно сдвинется после автоматизации. Скорость одного этапа имеет смысл только вместе с cycle time всей поставки. Иначе команда получает больше pull request, чем способна осмысленно принять, а видимый рост активности скрывает увеличение незавершённой работы. Теория ограничений здесь даёт практический вопрос: какое звено теперь определяет выпуск ценности и что произойдёт, если ускорить его следом?

Алексей приводит анонимизированный пример компании примерно из десяти человек, которая перестроила работу вокруг агентов: сделала собственные трекер задач, память и инструменты инцидентов, чтобы контекст и действия были доступны программно. Система дала небольшой команде высокую автономность, но проявила следующий предел — объём разговоров и решений, который человек способен удерживать в голове. Оркестрация и когнитивная нагрузка стали важнее скорости генерации. Этот случай не универсальный рецепт переписывать всё, а наглядный пример системного поиска ограничения. Собственные инструменты оправданы здесь не модой, а совпадением интерфейса с новым способом работы: агенту нужен структурированный контекст и возможность действовать без ручного копирования. Но каждое такое решение добавляет обязанности по сопровождению, поэтому выигрыш надо считать на всём жизненном цикле.

Позднее ревью делает ошибку дорогой: работа уже прошла несколько передач, прежде чем юрист, специалист по безопасности, редактор или владелец API увидит отклонение. Альтернатива — явно описать правила и дать их агенту в коротком внутреннем цикле. Тогда человек подключается по исключению, а найденная проблема возвращается в систему как правило, обновление промпта или eval-кейс. Такой human-by-exception не исключает эксперта; он меняет его работу с исправления результата на улучшение механизма, который предотвращает повторение ошибки. Ключевой сдвиг — превратить неявное знание проверяющего в исполняемый сигнал как можно ближе к моменту действия. Часть решений всё равно останется человеческой, но повторяемые дефекты перестанут каждый раз ждать одной и той же ручной проверки.

Для сквозного агентного процесса недостаточно добавить ассистента в каждый продукт. Wardley Mapping помогает решить, что покупать, адаптировать или строить; bounded contexts и Team Topologies — провести границы и выбрать взаимодействие команд. При этом старые интерфейсы платформ могут быть непригодны агентам: API или MCP, отдающий огромный JSON для человеческого UI, расходует токены и ломает автоматизацию. Владельцам платформ нужны компактные машинные контракты и совместимые интеграции, иначе набор быстрых локальных агентов не складывается в быстрый поток. Граница команды одновременно становится границей контекста, полномочий и ответственности. Если агент пересекает её через нестабильный или избыточный интерфейс, локальное ускорение оплачивается ошибками интеграции и дорогим восстановлением общего состояния.

Покупка лицензий не заменяет изменение процесса. Пилоту нужны внутренняя экспертиза, пространство временно обойти часть старых ритуалов и спонсор с полномочиями довести изменение до результата. Инерция бывает рациональной для отдельных людей и подразделений: ускорение угрожает привычной роли, влиянию или стабильности. Поэтому AI-трансформация требует не только технической глубины, но и change management. Внешний консультант может найти системную причину, однако без внутреннего владельца организация после аудита возвращается к прежним стимулам и привычкам. Спонсор нужен не для символической поддержки: он снимает межкомандные блокировки и меняет правила, которые пилот доказал устаревшими. Внутренний владелец, в свою очередь, удерживает контекст после ухода временной экспертной группы и отвечает за превращение опыта в обычную работу.

Исследование и эксплуатацию нельзя оценивать одинаково. На раннем этапе полезнее портфель ограниченных гипотез с понятным направлением и критериями перехода к масштабированию, чем требование немедленной окупаемости каждого опыта. Когда практика стабилизируется, измерять нужно не потребление токенов, число лицензий или процент AI-сгенерированного кода: это аналоги Lines of Code, показывающие активность. Ценность видна в сроке от идеи до принятого результата, качестве, частоте возвратов и бизнес-эффекте. Если эти показатели не меняются, больше кода остаётся лишь новой формой запасов в системе. Метрика должна охватывать и последствия после выпуска: инциденты, сопровождение и повторную работу. Иначе стоимость ускорения незаметно переносится с разработчика на проверяющих, эксплуатацию или пользователя.