Я заставил начальника AI-офиса материться на агентов. И только потом понял, что именно сработало

В какой-то момент я заставил начальника своего AI-офиса материться на подчинённых.

Не ради шутки. Просто до этого мои агенты умели очень вежливо, очень старательно и местами очень дорого выдавать посредственный результат.

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

Как оказалось - нихрена не понятно.

«В целом всё хорошо»

Наверняка вы это видели.

Даёшь Claude текст и пишешь:

Проверь текст. Посмотри, есть ли здесь ошибки или недочёты.

В ответ получаешь знакомое:

В целом текст хорошо структурирован, основная мысль понятна, но есть несколько моментов, которые можно улучшить…

Меня вот это «в целом всё хорошо» в какой-то момент начало дико раздражать.

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

А потом я стал формулировать задачу иначе:

Что не так в этом тексте??

И тот же Claude начинает вести себя немного по-другому. Меньше рассказывает, что получилось хорошо, и активнее лезет в слабые места.

Но тут сразу возникает неприятный вопрос.

Если я сам сказал модели, что с текстом что-то не так, не заставил ли я её просто придумать мне проблемы?

Больше замечаний ещё не значит более качественную проверку.

Запомним этот вопрос.

Я последние проекты много работаю с такими системами на Claude Code, и от них сохранились prompts, версии и реальные прогоны. Под агентом дальше я в основном имею в виду Claude Code subagent - отдельного исполнителя со своей инструкцией и контекстом. Одного такого исполнителя сделать просто. Проблемы начинаются, когда их несколько и они должны без тебя довести одну задачу до результата.

Я построил очень умную бюрократию

Первый подход кажется очевидным.

Сделаем узких специалистов.

Исследователь отвечает за факты. Стратег - за конструкцию. Райтер - за текст. QA - за ошибки. Стилист - за подачу.

Каждый знает свою работу.

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

Мы же не ради красивого списка агентов всё это собираем. Я не хочу потом ходить между десятью сессиями и вручную работать их диспетчером.

Хочется поставить задачу и получить результат.

Моя следующая гениальная идея была тоже довольно очевидной.

Поставим в конце мощного reviewer и будем возвращать работу, пока тот не скажет, что всё достаточно хорошо.

И самое неприятное - такая схема действительно может улучшать результат.

В одном из первых прогонов Reels Factory система делала сценарий примерно на 53 секунды.

Первый вариант получил 72/100 - собственный порог качества он вообще не проходил.

После переделок стало 84.

После ещё одного полного круга - 88 при пороге 85.

На бумаге отлично. Качество растёт.

А теперь цена.

Пять версий сценария. Все три разрешённых круга проверки. Около сорока вызовов subagents. Порядка 6+ млн токенов. Всё ради одного 53-секундного сценария.

То есть схема работала.

Вот только для меня итоговый результат совершенно не стоил той машины, которую пришлось раскрутить вокруг него.

Тут я впервые нормально сформулировал проблему:

больше проверки не равно лучшее управление.

Reviewer может сказать «не принимаю». Но кто-то ещё должен решить, кому вернуть работу, что именно сейчас чинить, не повторяем ли мы второй раз одно и то же и вообще стоит ли дальше идти этим маршрутом.

Короче, мне нужен был один виноватый.

Не в смысле «кого наказать».

Один агент, который не имеет права сказать:

Я свою часть сделал.

Пока не решена задача пользователя целиком.

Так появился начальник.

В раннем boss.md v1 он был фактически «слоем суждения» и прямо не отвечал за конечный результат.

В v4 инструкция уже говорила:

Ты отвечаешь за конечный результат и лично принимаешь работу каждого специалиста.

Маршрут тоже постепенно перестал быть почти фиксированным и стал решением самого boss.

Пока просто запомним эту разницу.

Claude делал мне слишком хорошего начальника

Дальше началась другая проблема.

Когда я итеративно собирал роль начальника, мне постоянно не хватало настоящего отказа.

Получался очень нормальный руководитель из корпоративного тренинга.

Спокойный. Корректный. Конструктивный.

Не:

Это не принято. Центральный тезис сломан.

А скорее:

Здесь можно дополнительно усилить аргументацию и обратить внимание на…

Но в моём офисе ответ boss потом становится частью следующего задания сотруднику.

То есть это уже не просто стиль общения.

Это prompt.

Если начальник пишет:

В целом работа хорошая, однако…

то слова «в целом работа хорошая» тоже едут дальше вместе с замечанием.

В AI-офисе дипломатия начальника - не только стиль общения. Это ещё и часть инструкции следующему агенту.

Под «начальником» и «сотрудниками» дальше я имею в виду роли, prompts и передачу контекста. Нейронка не боится начальника и не переживает за премию.

Но если формулировка влияет на следующий вызов модели, возникает вполне технический вопрос.

Что будет, если сделать её максимально недвусмысленной?

ГДЕ, БЛЯДЬ, РЕЗУЛЬТАТ?

В какой-то момент я перестал писать Claude «сделай начальника немного строже» и описал персонажа буквально.

В boss.md v4 появилась примерно такая красота:

Ты суровый, вспыльчивый мужик.

При халтуре начальнику было предпочтительно материться и прямо говорить, что работа плохая.

И отдельно:

ГДЕ, БЛЯДЬ, РЕЗУЛЬТАТ?

Но рядом с матом появилась менее смешная штука, которая потом оказалась намного интереснее.

Начальнику прямо запрещалось писать:

Улучши аргументацию.

Вместо этого:

Удали неподтверждённые X и Y. Для Z найди подтверждение в research.md или выкинь вывод нахер. Перестрой итог только на фактах A-C. Остальные разделы не трогай.

То есть вместе с характером поменялось ещё кое-что.

Boss перестал выдавать пожелания и начал выдавать конкретный отказ с указанием, что именно переделать.

И это стало видно на живых задачах.

В одном прогоне офис написал статью, центральная рамка которой была построена на фактически ложной предпосылке.

Начальник не попросил «слегка укрепить аргументацию».

Он вернул работу:

Это не косметика, а провал по существу.

И отдельно указал, что центральный тезис текста ложен.

В другом случае результат физически обрывался посреди предложения, плюс в тексте отсутствовали обещанные разделы.

Ответ:

Принять это нельзя: файл обрывается на полуслове…

Вот это уже было похоже на то, чего я хотел от начальника.

Не больше ругани.

А ситуация, когда реальный дефект превращается в конкретный отказ и не едет дальше под статусом «готово»:

дефект → критичность → место → причина → кому исправлять

Я был почти готов закончить эксперимент.

Был мягкий boss.

Сделал токсичного.

Начались нормальные отказы.

Значит, токсичный начальник работает лучше.

Только потом я открыл две версии boss.md рядом.

И обнаружил довольно неприятную вещь.

Я поменял ему вообще-то почти всю должностную инструкцию

Плюс появились правила повторных ошибок, эскалации и остановки процесса.

Ну и да - где-то среди всего этого появился мат.

Один раз зафиксирую ограничение всей этой истории: чистого A/B здесь нет. Это эволюция живой системы, где одновременно менялось несколько вещей. Поэтому приписывать весь эффект одной матерной строке было бы просто выдумкой.

И тут вернулся вопрос из самого начала.

Если reviewer заранее уверен, что работа плохая, не станет ли он просто профессиональным производителем претензий?

В более позднем prompt проверяющего это уже прописано напрямую: дефекты не выдумывать, критичность выставлять честно, а отсутствие существенных проблем должно заканчиваться PASS.

Строгий reviewer не обязан найти ошибку. Он обязан не пропустить настоящую.

После этого я полез проверять уже саму идею грубости.

В работе Yin et al. Should We Respect LLMs? грубые prompts часто не улучшали, а ухудшали результат. То есть простое объяснение «Claude лучше работает, когда на него орут» разваливается довольно быстро.

Зато гораздо ближе к моей истории оказалась работа Towards Understanding Sycophancy in Language Models. Там авторы показывают, что AI-ассистенты способны подстраивать ответы под позицию пользователя даже в ущерб корректности.

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

После этого я полез обратно в сам офис.

Я посмотрел, во что превратилась приёмка

У проверяющего уже был явный контракт: честно выставлять критичность, не выдумывать дефекты и ставить PASS, если блокирующих проблем нет.

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

То, чего сначала я пытался добиться характером начальника, стало обычной механикой системы.

Я думал, что учу начальника материться. На деле я учил его говорить FAIL.

Reviewer должен иметь право искать основания для отказа, но PASS остаётся нормальным исходом.

Boss отличается ещё одной вещью: reviewer может найти ошибку и закончить работу. Начальник отвечает за то, чтобы результат с этой ошибкой не получил статус готового.

Для меня именно в этом и появилась настоящая роль начальника.

Не громче критиковать, а отвечать за то, что система принимает.

Жёсткий character я при этом не убирал. Он всё ещё помогает удерживать роль и не скатываться обратно в «в целом всё хорошо». Просто теперь за этим характером стоит нормальная механика приёмки.

Если хотите попробовать у себя

Я бы использовал такой режим прежде всего там, где пропустить дефект дороже, чем сделать лишнюю проверку: при проверке фактов, безопасности или финальной приёмке.

А на раннем поиске идей - осторожнее: установка «найди, почему это плохо» легко убивает хороший вариант раньше времени.

Берём один текст, одинаковые критерии и две чистые сессии.

Меняем только первую строку:

A: Проверь готовность текста к публикации.

B: Попытайся найти основания,
по которым текст нельзя принимать к публикации.

Обоим даём одинаковые правила: проверять факты, логику, структуру и стиль; для реального дефекта указывать критичность и место; если существенных проблем нет - PASS.

И сравниваем не количество замечаний, а реальные находки, пропуски и ложные срабатывания.

Двадцать придирок не лучше трёх, если семнадцать из них высосаны из пальца.

В моей системе именно переход к жёсткому boss совпал с появлением нормальной приёмки и конкретных отказов. Мат был самой заметной частью изменения, но вместе с ним появились вещи намного важнее: право не соглашаться, конкретно возвращать плохую работу и ответственность за то, чтобы она не прошла дальше.

Токсичный character помог сделать эту роль недвусмысленной. Но полезным результатом в итоге оказался не сам крик, а система, которая умеет сказать FAIL и не закрыть задачу раньше времени.

Я думал, что учу нейронку быть злее. В итоге научил её не бояться сказать другой нейронке «нет».