Мы все привыкли строить производство софта как конвейер. Продакт берёт идею, отдаёт аналитику. Аналитик пишет требования, отдаёт разработчику. Разработчик пишет код, отдаёт QA. QA проверяет, отдаёт DevOps. DevOps выкатывает в прод.

Каждый знает свой участок. Каждый передаёт результат дальше. Лента сама довозит результат до пользователя.

Так работало 30 лет. И вот в каждый из этих участков пришёл AI-агент. И конвейер начал барахлить.

Симптом: AI вроде работает, а результата нет

Все вооружены AI. Аналитику отдали Claude или ChatGPT — он быстрее пишет user stories. Разработчику дали Cursor / Copilot / Claude Code — pull request'ы летят пачками. QA подключил AI-test-generator — coverage растёт. Документация генерируется автоматически.

По метрикам — праздник. Lead time падает. Throughput растёт. Все довольны на демо.

А потом в прод приезжает фича, которая не работает. Или работает, но не то. Или работает то, но никто не помнит зачем её делали. Или работает идеально, но в техдоке написано про другую систему.

Что случилось?

Сценарий 1: люди вооружены, но ленивы

Каждый участник конвейера может проверить результат своего агента. Прочитать сгенерированное требование. Поревьюить код. Сверить тест с бизнес-смыслом.

Может. Но не делает. Потому что:

• На участке конвейера ты отвечаешь за участок, а не за продукт. Если требование кривое — это проблема следующего звена. Тебе главное закрыть тикет.

• AI выдал результат за минуту вместо часа. Соблазн отправить дальше за вторую минуту — огромный. Вычитывать = терять выигранное время.

• Брукс ещё в семидесятых сказал: главный bottleneck производства софта — не работа, а передача результата между людьми. Сегодня этот bottleneck не делся никуда — а скорость на участках выросла. Связи сопряжения трещат под объёмом.

Итог: shit in → shit out. AI просто ускорил конвейер дерьма. Каждый формально молодец — закрыл свой участок. Продукт — формально готов. Качество — нет.

Со сроками тоже не сошлось: люди работают меньше, агенты работают больше, передач между звеньями стало в разы больше, и каждая передача — потенциальная потеря смысла.

Сценарий 2: уберём Васю совсем

Логичный следующий шаг для оптимизатора: «раз люди ленивы и всё равно не проверяют — давайте заменим участок целиком на агента. Вася больше не нужен». Сэкономим зарплату Васи. Цикл ускорится ещё.

Что происходит?

Раньше Вася при всей своей лени был точкой ответственности. К нему можно было прийти и спросить «что ты сделал?». Он бы что-то ответил — пусть невнятно, но ответил.

Агент-Вася ничего никому не ответит. Он отработал по запросу. Он не помнит почему сделал так а не иначе. Он не знает что было полгода назад. Он не помнит контекст соседних участков.

И как только агент-Вася передаёт результат дальше по конвейеру — мы получаем то самое. Передача состоялась формально (контракт, JSON, валидация прошли). Передача состоялась содержательно — нет. Потому что раньше передача происходила не за счёт контракта, а за счёт того, что на стыке стоял человек, не желавший принимать брак.

Заменили Васю — потеряли стык. А таких стыков в конвейере штук восемь. Уберите всех — получите ускоренный поток шума с зелёными метриками на выходе.

Диагноз: handoff никто не проверяет

Конвейер держится на одной не-формализованной вещи. Контроле передачи. Это происходило само собой, потому что на каждом стыке стоял человек, который не хотел принять брак — иначе на следующем шаге это становилось его проблемой.

AI-агент эту функцию не несёт. Ни как помощник (потому что человек рядом ленится). Ни как замена (потому что у него самого нет skin in the game).

Критическое мышление в конвейере — это не правило и не функция отдельного участка. Это то, что живёт на стыках. Уберите людей или дайте им повод не вчитываться — стыки рассыпаются.

Где должно быть критическое мышление?

В классическом конвейере оно размазано тонким слоем по всем участникам. Каждый чуть-чуть проверяет вход. Каждый чуть-чуть проверяет выход. И система держится не потому что кто-то проверяет всё, а потому что у каждого есть skin in the game.

Когда участок отдан агенту — skin in the game испаряется.

Соблазн поставить «супервайзера-агента» над агентами не работает. Супервайзер-агент имеет ту же проблему: он знает, что задано в его prompt'е. Если в prompt'е не написано «остановись, если ты видишь, что фича бесполезна с точки зрения продукта» — он не остановится. А такая инструкция не пишется заранее, потому что мы не знаем какой именно вид дичи случится.

Критическое мышление — это не правило. Это способность распознать, что ты сейчас наблюдаешь дичь, даже если до этого никогда такую дичь не видел. Этого пока нет ни у одной модели.

Решение: переходим от конвейера к дирижёру

Конвейер построен на принципе «каждый делает свой участок, целое складывается само». Это работает, когда участники взаимозаменяемы, дисциплинированы и одинаково мотивированы.

AI-агенты дисциплинированы, но не взаимозаменяемы с человеком в важном смысле — у них нет ответственности и здравого смысла.

Значит, нам нужна другая модель. Не конвейер из исполнителей, а дирижёр над оркестром инструментов.

Дирижёр держит в голове целое. Он не сам играет ноты — он понимает что играют скрипки, что играют ударные, и в какой момент они расходятся. Если барабанщик начал играть Моцарта в Бетховене — дирижёр останавливает оркестр. Не потому что в нотах написано «остановись если играют Моцарта». А потому что дирижёр понимает что слышит.

Применительно к разработке: один инженер с глубокой экспертизой управляет несколькими AI-агентами. Он не пишет код руками. Но он:

• Понимает что агент сделал.

• Видит когда агент уехал не туда.

• Несёт ответственность за результат.

• Имеет вкус к продукту, а не только к коду.

Инженер-центрированная модель отдаёт агентам исполнение, а человеку оставляет архитектуру, оценку, и решение «это норма или дичь».

Почему именно инженер, а не кто-то другой

На роль дирижёра не подходит:

• Менеджер, который раньше пропускал через себя статусы команды не вчитываясь. Он не отличит «AI написал хороший код» от «AI написал код, который скомпилировался».

• Аналитик, который раньше копировал требования из шаблона. Он не поймёт когда AI собрал требование, противоречащее архитектуре.

• QA, привыкший проверять чек-лист. Он не остановится перед тестом, который зелёный, но проверяет не то.

Дирижёр AI-оркестра — это сеньор-инженер с продуктовым мышлением. Тот, кто:

• Может прочитать сгенерированный код и понять, нормально это или костыль.

• Может посмотреть на сгенерированное требование и сказать «это не та фича, которая нужна продукту».

• Может проверить тест и понять, действительно ли он проверяет то, что важно.

• Не ленится копать вглубь, когда что-то выглядит странно.

Это редкий профиль. Это дорогой профиль. И его нельзя заменить менеджером проектов с курсами по AI.

Если в команде уже есть люди, которые пропускали бумаги/таски/код не вчитываясь — на роль AI-дирижёра их сажать категорически нельзя. AI вскроет эту проблему за неделю.

Что это значит на практике

Переход от конвейера к дирижёру меняет всё:

• Профиль найма. Нужны не «10 джуниоров с Copilot» — нужны 2-3 сильных инженера-дирижёра. Соотношение «много дешёвых рук» больше не работает — это просто умножает количество дичи, которое нужно ловить.

• Структура команды. Из конвейерной (PO → A → D → QA → Ops) — в концентрическую: инженер-дирижёр в центре, агенты по периметру.

• Метрики. Lead time и throughput больше не главные. Главное — сколько раз AI попытался отдать в прод дичь, и сколько раз её поймали. Это новая ключевая метрика.

• Обучение. Сеньоров надо учить не «как использовать Cursor», а «как ставить агентам задачи, как ревьюить выход, и как распознавать когда они уехали». Это новая дисциплина.

• Культура. Lazy senior больше невозможен. Не вычитал — значит выпустил дичь. AI не прикроет.

Что мы делаем сейчас

В нашей команде мы строим pipeline именно по этой модели. Не «AI Copilot для всех», а конкретные участки производства, целиком переданные AI, с инженером-дирижёром над каждым и правом останавливать оркестр в любой момент.

Текущий рабочий инструмент — Claude Code. Сильная модель, агентный режим, нормальный код-ревью workflow. Для большинства участков delivery её достаточно: документация, генерация кода, тесты, артефакты деплоя.

Но мы в federal-financial домене. И это ставит два жёстких ограничения, которые не решает «просто Claude через API».

Первое — где живут данные. Когда агент работает с кодом и контекстом из репозитория, он отправляет фрагменты этого кода в облачную модель. Для коммерческой компании это решается NDA. Для регулируемой организации, работающей с финансами государства — нет. Кода, документации и логов, которые нельзя отдавать в cloud, — много. И отказаться от AI-агента из-за этого = откатиться обратно в конвейер.

Решение, которое мы исследуем — DLP-слой для AI на уровне рабочих станций. Конкретно смотрим на Separator AI перехватывает поток из CLI / IDE / агентов, маскирует чувствительные данные ДО того как они уходят в LLM. Никакого «доверия процессу» — техническое ограничение на уровне трафика. Plus visibility над shadow-AI: видно кто из инженеров использует какие облачные модели и что туда отправляет.

Второе — где живёт сама модель. DLP — необходимое, но не достаточное условие. Для критичных участков нужна модель в нашем периметре. Cloud-провайдер недоступен по compliance и санкционным рискам. Поэтому параллельно рассматриваем переход на on-prem платформы. Конкретно — Veai: JetBrains-интеграция, on-prem deployment, multi-LLM ensemble, SSO и enterprise-контроли. Для federal-financial с Java/Spring-стеком в JetBrains-IDE это попадание.

Итоговая архитектура, к которой идём:

• Cloud-tier (Claude Code) — для участков, где можно работать с deidentified кодом и публичной документацией. Скорость и качество модели.

• On-prem tier (Veai или аналог) — для критичных продуктов, где данные не должны покидать периметр.

• DLP-слой (Separator AI или аналог) — на всех рабочих станциях. Маскирование, контроль, аудит.

• Дирижёры — сеньоры-инженеры, которые управляют агентами на обоих tier'ах и держат критическое мышление на стыках.

Это не «automated», и не «augmented». Это conductor-driven AI development в регулируемой среде.

Конвейерная модель производства софта несовместима с автоматизацией через AI. Не потому что AI плохой. А потому что конвейер построен на ответственности на каждом стыке — а агенты эту ответственность нести не могут.

Кто это поймёт раньше — переиграет рынок. Кто продолжит набивать команду «AI-усиленными исполнителями» вместо дирижёров — будет ловить дичь в проде следующие 5 лет.

#AITransformation #AINative #CTO #EngineeringLeadership #GenAI