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