QuantumBlack: двухуровневая архитектура агентных процессов разработки

QuantumBlack, AI-подразделение McKinsey & Company, опубликовало эту статью в феврале 2026 года, чтобы задокументировать, что сработало — и что не сработало — при попытке масштабировать AI-агентов в производственных процессах разработки ПО. Центральный вывод: агенты, которым предоставляется право самоорганизации, предсказуемо деградируют при масштабировании — пропускают фазы, создают циклические зависимости и склонны анализировать ситуацию вместо того, чтобы действовать.

Двухуровневая модель

Описанное решение разделяет две разные задачи. Первый уровень — детерминированный движок оркестровки, основанный на правилах (не AI), который задаёт последовательность фаз разработки (requirements → architecture → implementation), управляет зависимостями задач и отслеживает состояние артефактов через frontmatter. Агенты в этой модели выполняют назначенные задачи — но не решают, что идёт следующим и где должны располагаться артефакты.

Второй уровень — ограниченное агентное исполнение. Вместо одного универсального агента система использует специализированных агентов для конкретных ролей: анализ требований, архитектурный дизайн, написание кода, запросы к базе знаний. Каждый агент работает в рамках явно заданных инструкций, оформленных как переиспользуемые «скиллы» — модульные наборы правил, функционирующие как микросервисы для AI-работы. Сама файловая система становится машиночитаемой спецификацией: структура директорий и соглашения по именованию задают связи детерминировано, без интерпретации агентом.

Валидация и участие человека

Валидация проходит в два этапа: сначала детерминированные проверки (линтинг, структурная валидация), затем отдельный агент-критик оценивает экспертные суждения. Агенты итерируют до пяти раз, после чего workflow эскалирует к человеку.

Практический результат: полный цикл фичи — требования, архитектура, реализация, тесты — может быть сгенерирован на одной ветке и проверен человеком в виде готового pull request’а. Команды, использующие такой подход, могут запускать несколько продуктовых экспериментов в день — что авторы позиционируют как workable вариант водопадной модели на скорости агентов.

Что требуется организационно

Глубинная мысль статьи — организационная: этот паттерн требует, чтобы решения документировались, а не оставались имплицитными в экспертизе конкретных людей или переписке в Slack. Институциональные знания, существующие только в головах сотрудников, не могут быть закодированы как агентные скиллы. Для product manager’ов, работающих с инженерными командами, строящими агентные системы, фреймворк даёт конкретный словарь для обсуждения того, где необходимо человеческое суждение, а где нет, — различие, которое становится важнее по мере роста автономного исполнения.