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

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

В повседневной работе это выглядит как спринт в никуда. Просишь агента сгенерировать функциональность — он возвращает код, который кажется правдоподобным. Просишь другого проверить его — он одобряет, потому что разделяет ту же ошибочную ментальную модель. Добавляешь третьего, чтобы он написал тесты, и тесты проходят, подтверждая неправильное поведение. Весь цикл ощущается продуктивным, пока кто-то не читает требования — или то, что от них осталось.

Корень проблемы — не агенты. А то, что никто не заставляет сверять результат с чем-то стабильным. Когда требования размыты, агенты заполняют пробелы допущениями. Больше агентов — больше допущений, и каждое допущение для следующего агента выглядит как решение.

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

Проверка должна быть конкретной. Вопроса «ты уверен?» недостаточно. Агенту нужно сравнить свой ответ с исходным запросом, вскрыть противоречия и указать недостающие детали. Когда требования нечётки, самая важная проверка — первая: «Что именно ты предположил насчёт того, что я тебя попросил?» Этот вопрос заставляет агента выложить на стол требования, которые были скрыты.

Как только применяешь этот паттерн, мутация закона теряет зубы. По-прежнему можно добавлять агентов, но они уже не могут свободно выдавать результат без проверки. У каждого агента есть обязательная контрольная точка, где проверяется его собственное рассуждение. Это меняет динамику: вместо ускорения к неверному ответу агенты начинают сходиться к общему исправленному пониманию.

Практический эффект: проект становится медленнее в первые минуты и быстрее после. Самый медленный шаг — тот, где агент останавливается и пересматривает свою работу. Именно этот шаг не даёт каскаду правдоподобных недопониманий превратиться в финальный результат.

Тебе захочется пропустить проверку: кажется, что это потерянное время. Агент уже дал ответ, и он звучит убедительно. Но если требования неясны, каждый ответ — это допущение с меткой времени. Проверка — не формальность; это единственный способ превратить агентов в детекторы путаницы, а не в её умножители.

Паттерн достаточно прост, чтобы использовать его уже сегодня: заставь ИИ проверять себя. Не доверяй первому результату, не добавляй новых агентов в надежде, что одному повезёт; сделай самопроверку обязательным шагом в цикле каждого агента. Это путь через боль. Он не определяет недостающие требования магическим образом — он их вскрывает и даёт тебе возможность исправить их, прежде чем неверный ответ станет результатом работы.