Дирижёр вместо конвейера: как AI ломает классический pipeline разработки

Мы все привыкли строить производство софта как конвейер. Продакт берёт идею, отдаёт аналитику. Аналитик пишет требования, отдаёт разработчику. Разработчик пишет код, отдаёт 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 лет.

---

Если вы строите AI-native pipeline в своей организации — расскажите в комментариях, как вы решаете handoff-проблему. Особенно интересны кейсы из regulated/financial доменов.

Версия на LinkedIn: https://www.linkedin.com/pulse/дирижёр-вместо-конвейера-как-ai-ломает-класс

#AITransformation #AINative #CTO #EngineeringLeadership #GenAI