Тридцать лет разработка строилась по одной схеме: продакт → аналитик → разработчик → QA → DevOps. Каждый участник отвечал за свой участок и передавал результат дальше. Система держалась не на формальных контрактах, а на том, что каждый человек на стыке не хотел принять брак — иначе на следующем шаге это становилось его проблемой.

С приходом ИИ-инструментов скорость на каждом участке выросла кратно. Аналитик генерирует user stories через Claude за минуты, разработчик закрывает pull request'ы пачками с помощью Cursor или Copilot, QA подключает ИИ-генератор тестов и рапортует о росте coverage. По метрикам — праздник: lead time падает, throughput растёт. Но в продакшн приезжают фичи, которые не работают, работают не то или работают идеально, но никто не помнит зачем их делали.

Проблема не в качестве ИИ-инструментов. Проблема в том, что конвейер держался на неформализованном контроле передачи — и ИИ его разрушил сразу двумя способами.

Агент, заменивший человека на участке, не несёт ответственности за результат и не замечает содержательных ошибок.

Первый сценарий: люди вооружены, но не проверяют. Когда агент выдаёт результат за минуту вместо часа, соблазн отправить его дальше за следующую минуту огромен. Вычитывать — значит терять выигранное время. А логика конвейера подсказывает: ты отвечаешь за свой участок, а не за продукт. Если требование кривое — это проблема следующего звена. Фредерик Брукс ещё в 1970-х описал главный bottleneck разработки: не сама работа, а передача результата между людьми. Сегодня скорость на участках выросла, а потери на стыках — нет. ИИ просто ускорил конвейер, не починив его узкие места.

Второй сценарий: убрать человека совсем. Логичный шаг для оптимизатора — заменить участок целиком агентом. Но раньше Вася при всей своей лени был точкой ответственности: к нему можно было прийти и спросить, что он сделал. Агент ничего не ответит — он не помнит, почему сделал так, а не иначе, не знает контекст соседних участков и не держит в голове, что было полгода назад. Формально передача состоялась: контракт, JSON, валидация прошли. Содержательно — нет. Стык исчез вместе с человеком.

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

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

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

На роль дирижёра не подходит менеджер, привыкший пропускать статусы не вчитываясь, аналитик, копировавший требования из шаблона, или QA, проверявший чек-лист. Нужен сеньор-инженер с продуктовым мышлением: тот, кто может прочитать сгенерированный код и отличить нормальное решение от костыля, посмотреть на требование и сказать «это не та фича», проверить тест и понять, ли он проверяет то, что важно. Это редкий и дорогой профиль, и его нельзя заменить менеджером проектов с курсами по ИИ.

Практические следствия этого перехода затрагивают всё: профиль найма смещается от «10 джуниоров с Copilot» к «2–3 сильным инженерам-дирижёрам». Структура команды из линейной становится концентрической — инженер в центре, агенты по периметру. Метрики меняются: lead time и throughput уступают место показателю того, сколько раз ИИ попытался отдать в продакшн некачественный результат и сколько раз его поймали. Автор колонки описывает, что его команда уже строит pipeline по этой модели, используя в качестве основного инструмента Claude Code.