Шизофрения LLM, или Поваренная книга вайбкодера

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

Каждый, кто пробовал вайбкодить, знает две фазы этого занятия. Первая: агент за десять минут делает то, на что у тебя ушёл бы вечер, и ты немного чувствуешь себя обманщиком. Вторая: задача становится чуть больше — и тот же агент к середине чата забывает ^[1], с чего всё началось, чинит код, который сам написал час назад, и рапортует «готово» про то, чего не существует.

Из второй фазы обычно делают вывод: модель не тянет большие задачи. Вывод неверный. Не тянет не модель — не тянет конфигурация, в которой одна сессия обязана быть всеми сразу: архитектором, разработчиком, критиком собственного кода и тестировщиком. Люди так не работают. Модели, как выяснилось, тоже.

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

Шизофрения как метод

Лекарство от деградации на больших задачах называется «субагент». Технически это до смешного просто — markdown-файл из трёх вещей: роль (системный промпт), модель и список разрешённых инструментов:

---
name: reviewer
description: Ревью кода — изменений в рабочем дереве или конкретного диффа.
  Возвращает вердикт и список находок с приоритетами.
model: opus
tools: Read, Grep, Glob, Bash
---

Ты — придирчивый ревьювер кода. Каждую находку верифицируй:
найди конкретный сценарий, при котором она ломается.
Не смог — либо выкинь, либо пометь как предположение.
...

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

Теперь парадокс ^[2], ради которого написана эта статья. Разработчик сдаёт фичу — ревьювер находит в ней баги. Настоящие, с конкретными сценариями поломки. Пикантность в том, что это может быть одна и та же модель. Тот же самый набор весов, который десять минут назад писал этот код и был им совершенно доволен, в другой роли разносит его в пух и прах. Как разные люди. Почему?

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

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

В-третьих — и это моё любимое — инструменты определяют характер. У моего ревьювера в списке инструментов нет Edit и Write. Он не правит код не потому, что воспитанный, а потому, что физически не может. Роль, ограниченная текстом промпта, — пожелание. Роль, ограниченная набором инструментов, — факт.

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

• архитектор — проектирует до кода: варианты, компромиссы, план. Кода не пишет.

• разработчик — единственный, кто пишет продуктовый код.

• ревьювер — read-only. Возвращает находки с приоритетами и сценариями поломки.

• тестировщик — пишет тесты, продуктовый код не трогает.

• безопасник — смотрит на дифф глазами злоумышленника. Каждая его находка обязана отвечать на вопрос «кто и как это эксплуатирует».

• dba — аудит схемы и миграций, когда меняется база.

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

И одна неочевидная настройка, к которой я пришёл не сразу: дешёвая модель — исполнителю, дорогая — критику. Инстинкт требует наоборот: лучшую модель тому, кто пишет. Но ошибку ^[3] разработчика поймает ревьювер. Ошибку ревьювера не поймает никто.

Скилл: процесс, записанный в файл

Роли — это половина рецепта. Вторая половина отвечает на вопрос «а кто всем этим дирижирует».

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

Скилл — это процесс, ставший файлом. Устроен он тоже просто, в три слоя:

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

2. Тело — сам процесс: шаги, правила, лимиты. Загружается в контекст только когда скилл сработал.

3. Детали — вспомогательные файлы и скрипты, которые подтягиваются по мере надобности.

Обратите внимание ^[4]: это тот же принцип, что у субагентов, — в контексте живёт только то, что нужно сейчас.

Мой главный скилл — дирижёр разработки. Сам он не пишет ни строчки. Его партитура по заголовкам:

1. Разобраться в задаче
2. Построить план и нарезать на шаги
3. Каждый шаг: исполнитель → ревьювер → доработка
   (лимит — 3 итерации, дальше к человеку)
4. Финал: полный прогон проверок + аудиты по всему диффу

Лимит в три итерации появился не из теории: без него разработчик и ревьювер способны спорить бесконечно — или, что хуже, тихо сойтись на плохом компромиссе.

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

Если совсем коротко, разница такая: скилл — это «как готовим», субагенты — «кто у плиты».

План: нарезка под размер головы

На маленьких задачах всё вышеописанное уже работает. На больших не хватает последнего ингредиента — и он скучнее всех предыдущих. Это план.

План здесь — не дань процессу, а физическая необходимость. Задача на пятьдесят файлов не помещается в контекст ни одного агента — её нельзя «сделать», её можно только нарезать. Хороший шаг плана: помещается в голову исполнителя (ориентир — до пяти файлов), имеет проверяемый критерий готовности и оставляет репозиторий в рабочем состоянии. «Добавить поле и прокинуть его до интерфейса» — шаг. «Сделать раздел настроек» — не шаг, а мечта.

Дальше правило, которое экономит больше всего денег: план читает человек — до того, как агенты начнут писать код. Ревьюить план на порядок дешевле, чем ревьюить код. Неверное направление, пойманное на этапе плана, стоит пять минут чтения; то же направление, пойманное в готовом диффе, — день работы труппы.

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

И общее правило, на котором держатся и планы, и всё остальное: не записано — значит не существует. У агентов нет памяти ^[5] между сессиями. Агент завтрашней сессии не был на вчерашнем совещании, каким бы содержательным оно ни было. Решение, оставшееся в чате, умерло вместе с чатом; решение, записанное в файл, будет доставлено в контекст любого будущего агента за одно чтение. Поэтому архитектурные решения у меня живут в доках, а каждая находка ревью — отдельной задачей в трекере, со статусом и причиной, если её отклонили. Это не бюрократия. Это память труппы — единственная, которая у неё есть.

Клей: правила и проверки

Два ингредиента, без которых конструкция разваливается, — по абзацу на каждый.

Первый — файл правил проекта (в Claude Code это CLAUDE.md), который каждый агент видит всегда. Туда идёт только то, что нельзя вывести из кода: запреты с причинами и грабли, на которые уже наступали. Мои правила датированы, и у самых выстраданных стоит честная пометка «после нарушения» — правило появилось, потому что было нарушено, и я хочу, чтобы это было видно. Файл правил — это не спецификация, написанная в начале проекта. Это прецедентное право: нарушение → разбор → строка с датой.

Второй — проверки. Один скрипт, который гоняет всё: типы, линтеры, тесты, архитектурные ограничения — и возвращает честный код выхода. Он висит на pre-commit и в CI, и для агентов сформулировано дословно: чекеры не отключать, не ослаблять, не обходить; падение чекера — сигнал чинить код, а не проверку. Потому что «готово» от агента — это мнение, а зелёный прогон — факт, и путать их нельзя. Ревьювер ловит смысловые ошибки, проверки — механические; друг друга они не заменяют.

С чего начать

Хорошая новость: ничего из описанного не нужно писать руками. Файл субагента — это markdown, а markdown лучше всех пишет сама модель, тем более про себя.

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

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

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

Цена

Теперь ложка дёгтя, без которой это была бы реклама.

Токенов уходит кратно больше, чем в одном чате: труппа из нескольких агентов, где критики сидят на дорогих моделях, ест соответствующе. Я осознанно плачу за это как за качество — но платить приходится реально.

Время человека никуда не делось — оно сместилось. Я не пишу код, но пишу роли, правила и планы, читаю отчёты и разбираю споры ревьювера с разработчиком. Из программиста я превратился в смесь техлида, продакта и арбитра. Мне нравится, но это работа, а не кнопка «сделать хорошо».

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

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

Выводы

1. Большие задачи ломает не модель, а монолитный контекст, который обязан быть всем сразу.

2. Роль агента = промпт + чистый контекст + инструменты. Роль без ограничения инструментов — пожелание, с ограничением — факт.

3. Дорогую модель — критику, дешёвую — исполнителю. Ошибку исполнителя поймают, ошибку критика — никто.

4. Не записано — не существует: планы, решения и правила живут в файлах, потому что другой памяти у труппы нет.

5. Отчёту агента не верить. Верить проверке.

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