Когда производить дешевле, узким местом становится проверка. Вопрос в том, что с этим делать: отвечают по-разному.

1. Автор, наблюдающий команды с ИИ-агентами, пишет: продуктивность сначала растёт, потом падает, потому что человек перестаёт делать и начинает проверять, а каждый завершивший агент его прерывает. Если скорость завершения задаёт проверяющий, новые потоки лишь растягивают уже открытые. В иллюстрации автора пять агентов на пять дел дают за день 24 переключения и одно законченное дело, порядок со спецификацией и двумя полосами просмотра — 9 переключений и два законченных. На своём сайте сессии агентов снесли вкладку панели администратора: агенты не ошиблись в порученном, но потоков было слишком много, чтобы знать, что происходит в каждом. Его правило: параллелизм работает, когда проверять дёшево.

2. Выступлению в ИТ-компании открывается словами её технического директора: оптимизировать скорость и строки кода — значит оптимизировать «вчерашнее ограничение». Далее во вступлении: реализация перестаёт быть узким местом, важнее суждение; ускорение одной части не обязательно ускоряет целое, а обнажает следующее ограничение, например неясные требования и медленную обратную связь.

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

Выводы разные: практик подстраивает число потоков под ёмкость человека, теоретик переносит проверку в точки эскалации. Прямого противоречия нет — практик сам оговаривает, что параллелизм работает, когда проверять дёшево. Но в одном случае меняют нагрузку на проверяющего, в другом — сам предмет проверки.