AI-агенты программирования сделали генерацию кода дешёвой. Но они не сделали дешёвой поставку ПО. Команды, масштабирующие использование агентов, постоянно натыкаются на одну и ту же стену: всплеск производительности в начале, затем очереди ревью, растущие быстрее, чем кто-либо успевает их разбирать, конфликты слияния между параллельными сессиями агентов и люди, превращающиеся в самый медленный и уставший компонент конвейера. Проблема не в агентах и не в рецензентах. Мы проталкиваем генерацию на машинной скорости через архитектуры и рабочие процессы, созданные для команд на человеческой скорости. Законы Конвея и Брукса всё ещё действуют, и теперь они бьют сильнее. Решение структурное. Проектируйте явные границы до того, как развернёте агентов. Заменяйте ad-hoc координацию контрактами. Переносите человеческое ревью с вывода на намерение. Сделайте проверку соответствия механической. То же самое относится к инфраструктуре как коду, где монолитное состояние и неявные связи превращают конкурентность агентов в генератор инцидентов.
1. Узкое место переместилось. Оно не исчезло.
Закон Брукса гласит, что добавление людей в запаздывающий проект делает его ещё более поздним, потому что накладные расходы на коммуникацию и интеграцию растут квадратично с размером команды. Закон никогда не касался скорости печати. Он касался координации.
Агент программирования — это способ добавить десять инженеров в ваш проект за одну ночь. Печать бесплатна. Координация — нет. Каждое сгенерированное изменение всё ещё должно быть понято, интегрировано, проверено и одобрено кем-то. Если пропускная способность генерации увеличивается в 5–10 раз, а пропускная способность проверки остаётся прежней, система не становится в 5–10 раз быстрее. Она получает очередь. Эта очередь — ваш бэклог ревью, и человек, который его разбирает, выгорает.
Это закон Амдала в применении к поставке: общее ускорение ограничено той частью, которую вы не ускорили. Генерация никогда не была доминирующей стоимостью разработки ПО. Понимание, принятие решений и проверка были. Агенты сделали это очевидным.
Если вы запускали несколько сессий агентов против одного репозитория, вы знаете симптомы. PR поступают быстрее, чем кто-либо может их нормально прочитать. Два агента касаются одного модуля и создают конфликтующие изменения. Кто-то одобряет diff на 1500 строк, потому что на его реальное чтение ушёл бы целый день. Интерфейсы дрейфуют, потому что никто больше не держит целостную картину. Всё это не ново. Это то, что происходит, когда вы нанимаете десять подрядчиков на проект без архитектуры и с одним техлидом, который должен читать всё. Мы переоткрыли Брукса на машинной скорости.
2. Закон Конвея теперь — инструмент проектирования
Закон Конвея: системы отражают коммуникационные структуры организаций, которые их создают. Десятилетиями вы наследовали оргструктуру и получали архитектуру, которую она подразумевала. Проектирование организации для получения желаемой архитектуры (обратный манёвр Конвея) было продвинутым приёмом. Команды двух пицц от Amazon — самый известный пример.
Стоит уточнить, почему модель Amazon сработала, потому что большинство помнят неправильную половину. Пицца — известная часть: команды достаточно малы, чтобы внутренняя координация оставалась дешёвой. Несущей частью был мандат на интерфейсы 2002 года. Каждая команда предоставляет функциональность через сервисные интерфейсы. Никаких общих баз данных. Никаких бэкдоров. Никакого чтения хранилищ данных другой команды. Ограничение размера ограничивало коммуникацию внутри команд. Мандат ограничивал коммуникацию между ними. Компании, которые скопировали маленькие команды, но пропустили правило интерфейсов, получили маленькие команды, которые всё равно топтали друг друга.
С агентами закон Конвея перестаёт быть ограничением и становится свободной переменной. У агента нет карьерных амбиций и подчинения. Вы строите его коммуникационную структуру с нуля, и делать это нужно до масштабирования, а не после. Отображение почти один к одному. Ограниченный контекст с опубликованным контрактом заменяет команду сервиса с её API. Эксклюзивное право записи заменяет владение кодом команды. Объём контекста (то, что когерентно помещается в рабочий контекст агента) заменяет численность как ограничивающий фактор. Мандат на интерфейсы становится правилом CI вместо управленческой угрозы: агент, импортирующий что-то через границу, не проходит сборку. Без права апелляции.
Принцип: помехи — это отказ архитектуры, а не отказ агента. Если два агента могут конфликтовать, граница между их доменами никогда не была реальной.
3. Ревью намерения, а не вывода
Глубочайшая причина усталости от ревью в том, что мы проверяем не тот артефакт. Сгенерированный код — это дешёвый вывод дорогого решения. Читать его построчно — значит тратить дефицитное человеческое внимание на то, что ничего не стоило произвести, в то время как важное (намерение, изменение интерфейса, проектное решение) проносится мимо, погребённое в стене diff'а.
Перенесите человеческое суждение выше по потоку, где у него есть рычаги воздействия. Для этого и существуют спецификация-ориентированные рабочие процессы, такие как OpenSpec и Architecture Decision Records, и теперь они важнее, чем когда были изобретены.
Разделение труда прямое. ADR содержат медленно меняющиеся решения: границы контекстов, технологический выбор, инварианты, правила, которые агенты никогда не должны нарушать. Они меняются редко, и каждый агент читает их как действующую доктрину. Спецификации содержат намерение каждого изменения: что меняется, почему, какие интерфейсы затронуты, каковы критерии приёмки. Человек проверяет и утверждает спецификацию до начала генерации. Это чтение одной страницы вместо diff'а на две тысячи строк. Затем сгенерированный код проверяется на соответствие утверждённой спецификации, и соответствие — это вопрос, на который в основном могут ответить машины.
В этой модели человеческое ревью плавно деградирует от шлюзования к выборочной проверке. Вы утверждаете намерения, выборочно проверяете результаты и вмешиваетесь, когда шлюз что-то сигнализирует. Вопрос на каждый PR смещается с «это хороший код?» (субъективный и безграничный) на «соответствует ли это тому, о чём мы договорились?» (проверяемый).
4. Сделайте проверку соответствия механической
Выборочное ревью безопасно только при сильных механических шлюзах. Реальные инвестиции, которых требует внедрение агентов, — это не лучшие промпты. Это инфраструктура верификации.
Контрактные тесты фиксируют каждый опубликованный интерфейс, так что агент не может изменить границу без явного изменения. Функции пригодности архитектуры обеспечивают соблюдение правил зависимостей в CI: контекст A не импортирует внутренности контекста B, точка. Свойственные тесты проверяют инварианты вместо примеров, что важно, потому что агенты очень хорошо проходят тесты на примерах по неправильным причинам. Валидация схемы и контрактов данных выполняет ту же работу на уровне данных. Политика как код (OPA, Sentinel и другие) кодирует правила безопасности и соответствия, которые раньше жили в головах рецензентов.
Полезный ментальный сдвиг: в кодовой базе с большим количеством агентов тесты и контракты являются спецификацией по умолчанию. Код — производный артефакт. Уделите самое пристальное ревью тестам и контрактам. Пусть производный артефакт проходит через шлюзы.
Второй механический рычаг — дисциплина diff'ов. Изменение на 200 строк с одним намерением проверяемо за минуты. Изменение на 2000 строк, затрагивающее четыре аспекта, вообще не проверяемо — только утверждаемо. Агенты склонны к разрастанию, если их не ограничивать, поэтому сделайте доктриной: одно намерение на изменение, обеспечиваемое соглашениями и, где возможно, инструментарием.
5. Инфраструктура как код: та же болезнь, худшие симптомы
Всё вышесказанное применимо к IaC, но с более высокими ставками, потому что ошибки в инфраструктуре измеряются не багами, а простоями.
Монолитный корневой модуль Terraform — антипаттерн эпохи агентов. Один большой файл состояния — это глобальная блокировка и глобальный радиус поражения. Два конкурентных плана агентов против него будут конфликтовать, и любая ошибка может затронуть всё. Лекарство — логика ограниченного контекста, применённая к состоянию: декомпозиция на маленькие, слоистые стеки по доменам, окружениям, аспектам, каждый со своим состоянием. Конкурентность агентов тогда отображается на параллелизм файлов состояния, а не на конкуренцию за один файл.
Интерфейсы модулей — это контракты, и они заслуживают того же обращения, что и сервисные API. Явные переменные и выходные данные, семантическое версионирование, назначенный владелец. Потребители фиксируют версии и код относительно опубликованного интерфейса. Только владелец изменяет модуль. Неявные связи, такие как чтение одним стеком состояния другого или зависимость от ресурсов, которыми он не управляет, — это версия IaC для проникновения в чужую базу данных. Запретите их с той же жёсткостью, с какой мандат Amazon запретил бэкдоры.
terraform plan заслуживает признания как оригинальный спецификация-ориентированный рабочий процесс: машинно-сгенерированное заявление о намерении, проверяемое перед выполнением. Используйте это. Люди проверяют планы и отчёты о политиках, а не HCL diffs. Шлюзы «политика как код» кодируют суждение, которое раньше требовало глаз старшего инженера на каждом изменении: запретить публичные корзины, требовать теги, ограничивать типы инстансов, ограничивать дельты затрат. Обнаружение дрейфа замыкает цикл, потому что в многопользовательском мире агентом самое опасное состояние — то, которое никто не контролирует.
Эфемерные превью-окружения дают агентам место для эмпирического доказательства изменений. Агент, развёртывающийся в изолированном окружении и выполняющий проверки соответствия, превращает ревью из чтения в доказательства.
6. Иерархия автономии по радиусу поражения
Не каждое изменение заслуживает одинакового контроля. Притворяться иначе — именно то, что истощает рецензентов. Эффективная работа агентов требует явной лестницы автономии, согласованной заранее и закодированной в инструментарии.
Нижняя ступень: изменения с малым радиусом поражения, такие как внутренние рефакторинги, добавление тестов и документация. Если они проходят все шлюзы, они сливаются автоматически, с выборочной проверкой людьми после факта. Средняя ступень: всё, что касается опубликованного контракта, схемы или производственной инфраструктуры, требует утверждения спецификации и diff'а человеком. Верхняя ступень: изменения самих границ. Новые контексты, удалённые интерфейсы, состояние безопасности, всё необратимое. Они требуют ADR и решения человека каждый раз.
Агент должен знать, в какой полосе он находится, и останавливаться на краю. Дисциплинированный агент, действующий в рамках своего мандата, спрашивающий на границе и отказывающийся от того, что не может проверить, стоит больше, чем блестящий агент, который делает всё и поэтому его нужно проверять во всём.
Асимметрия, которую нужно спроектировать: быстро внутри границы, обдуманно на границе. Эта асимметрия и есть вся модель эффективности. Внутренняя скорость — это выгода. Трение на границе — цена безопасности. Усталость от ревью — это то, что вы получаете, когда отказываетесь выбирать и применяете среднее трение ко всему.
7. Что делать, начиная с этого квартала
Реалистичный путь внедрения начинается не с увеличения числа агентов. Он начинается с фундамента.
Во-первых, нанесите на карту ваши ограниченные контексты и запишите их в виде ADR: границы, контракты, владение. Если вы не можете нарисовать границы, агенты найдут их за вас, дорого. Во-вторых, выберите один контекст и укрепите его стыки контрактными тестами, правилами зависимостей в CI и опубликованным интерфейсом. В-третьих, внедрите спецификацию до кода для изменений агентов в этом контексте, с утверждением человеком на этапе спецификации. В-четвёртых, развивайте набор шлюзов до тех пор, пока не будете достаточно доверять, чтобы позволить зелёным низкорисковым изменениям сливаться с выборочной проверкой вместо шлюзования. В-пятых, разделите ваше состояние IaC по тем же границам и поставьте политику как код перед каждым apply. Затем масштабируйте количество параллельных агентов. На этом этапе каждый дополнительный агент добавляет пропускную способность, а не глубину очереди.
8. Заключение
Неудобная правда эпохи агентов: ограничивающий фактор больше не в том, как быстро мы можем писать ПО, а в том, как быстро мы можем ответственно его принимать. Закон Конвея говорит, что помехи — это проблема архитектуры, поэтому решайте её с помощью границ, спроектированных до появления агентов. Закон Брукса говорит, что координация — реальная стоимость, поэтому решайте её заменой коммуникации на контракты. Усталость от ревью говорит, что мы тратим человеческое суждение на неправильный артефакт, поэтому решайте это утверждением намерения один раз вместо бесконечной проверки вывода.
Ничто из этого не экзотично. Это команда двух пицц, мандат на API, дисциплина trunk-based и политика как код. Лучшие идеи последних двадцати лет организации ПО, применённые к рабочей силе, которая оказалась синтетической. Команды, которые выиграют с агентами, будут не теми, у кого лучшие промпты. Они будут теми, у кого лучшие границы.