Я пишу код больше двадцати лет. В этом стаже было всё: говнокод, красивый код, снова говнокод — и сквозь всё это стремление к прекрасному, которое то побеждало, то сдавалось под дедлайном. Сейчас тот период вспоминается как другая жизнь. Не потому, что я разлюбил программирование — а потому, что код руками я больше почти не пишу. Я пишу роли, правила и планы. Код пишут агенты.
Каждый, кто пробовал вайбкодить, знает две фазы этого занятия. Первая: агент за десять минут делает то, на что у тебя ушёл бы вечер, и ты немного чувствуешь себя обманщиком. Вторая: задача становится чуть больше — и тот же агент к середине чата забывает, с чего всё началось, чинит код, который сам написал час назад, и рапортует «готово» про то, чего не существует.
Из второй фазы обычно делают вывод: модель не тянет большие задачи. Вывод неверный. Не тянет не модель — не тянет конфигурация, в которой одна сессия обязана быть всеми сразу: архитектором, разработчиком, критиком собственного кода и тестировщиком. Люди так не работают. Модели, как выяснилось, тоже.
Всё, что описано ниже, — не эксперименты на выходных. Это рабочий процесс, которым написан большой продакшен-проект: сотни коммитов, фронтенд и бэкенд, и почти ни одной строки, написанной человеком. Инструмент у меня — Claude Code, но в любом агентном харнессе у этих механизмов есть аналоги: суть переносится, названия меняются.
Шизофрения как метод
Лекарство от деградации на больших задачах называется «субагент». Технически это до смешного просто — markdown-файл из трёх вещей: роль (системный промпт), модель и список разрешённых инструментов:
--- name: reviewer description: Ревью кода — изменений в рабочем дереве или конкретного диффа. Возвращает вердикт и список находок с приоритетами. model: opus tools: Read, Grep, Glob, Bash --- Ты — придирчивый ревьювер кода. Каждую находку верифицируй: найди конкретный сценарий, при котором она ломается. Не смог — либо выкинь, либо пометь как предположение. ...
Четвёртая вещь в файле не видна, и она важнее трёх остальных: у субагента свой чистый контекст. Он не видит ни основной разговор, ни других агентов, ни истории проекта. Он рождается, получает задачу, делает её, возвращает отчёт и умирает.
Теперь парадокс, ради которого написана эта статья. Разработчик сдаёт фичу — ревьювер находит в ней баги. Настоящие, с конкретными сценариями поломки. Пикантность в том, что это может быть одна и та же модель. Тот же самый набор весов, который десять минут назад писал этот код и был им совершенно доволен, в другой роли разносит его в пух и прах. Как разные люди. Почему?
Во-первых, чистый контекст — это отсутствие владения. У ревьювера нет «я это писал, я знаю, что имелось в виду». Для него код буквально чужой — а чужой код, как известно любому программисту, всегда написан идиотом.
Во-вторых, роль сдвигает вероятности. LLM — вероятностная машина, и промпт «сделай фичу» включает режим «дописывать до работающего», а промпт «найди, где это ломается» — режим «искать дыры». Это не имитация разных людей. Это буквально разные распределения.
В-третьих — и это моё любимое — инструменты определяют характер. У моего ревьювера в списке инструментов нет Edit и Write. Он не правит код не потому, что воспитанный, а потому, что физически не может. Роль, ограниченная текстом промпта, — пожелание. Роль, ограниченная набором инструментов, — факт.
Получается не команда из нескольких моделей, а один актёр, играющий несколько ролей, — но у каждой роли свой сценарий, свой реквизит и своя гримёрка. Моя труппа выглядит так:
архитектор — проектирует до кода: варианты, компромиссы, план. Кода не пишет.
разработчик — единственный, кто пишет продуктовый код.
ревьювер — read-only. Возвращает находки с приоритетами и сценариями поломки.
тестировщик — пишет тесты, продуктовый код не трогает.
безопасник — смотрит на дифф глазами злоумышленника. Каждая его находка обязана отвечать на вопрос «кто и как это эксплуатирует».
dba — аудит схемы и миграций, когда меняется база.
Из всех промптов труппы процитирую одно правило — тестировщика, потому что оно стоило мне дороже прочих, пока я до него не дошёл: тест, который проходит при сломанном коде, хуже отсутствия теста. Поэтому каждый написанный тест он проверяет на убийственность: ломает проверяемый код и убеждается, что тест краснеет. Не краснеет — тест переписывается.
И одна неочевидная настройка, к которой я пришёл не сразу: дешёвая модель — исполнителю, дорогая — критику. Инстинкт требует наоборот: лучшую модель тому, кто пишет. Но ошибку разработчика поймает ревьювер. Ошибку ревьювера не поймает никто.
Скилл: процесс, записанный в файл
Роли — это половина рецепта. Вторая половина отвечает на вопрос «а кто всем этим дирижирует».
Сначала дирижировал я: в каждом новом чате заново объяснял, что сначала план, потом разработчик, потом ревьювер, и не забудь тесты. На третьем десятке повторений стало понятно, что я сам превратился в копипасту. Процесс, который живёт в голове человека, — не процесс, а фольклор.
Скилл — это процесс, ставший файлом. Устроен он тоже просто, в три слоя:
Описание — пара предложений, которые модель видит всегда: что это за процесс и когда его запускать. Это триггер. Скилл с плохим описанием не срабатывает никогда — или срабатывает на всё подряд.
Тело — сам процесс: шаги, правила, лимиты. Загружается в контекст только когда скилл сработал.
Детали — вспомогательные файлы и скрипты, которые подтягиваются по мере надобности.
Обратите внимание: это тот же принцип, что у субагентов, — в контексте живёт только то, что нужно сейчас.
Мой главный скилл — дирижёр разработки. Сам он не пишет ни строчки. Его партитура по заголовкам:
1. Разобраться в задаче 2. Построить план и нарезать на шаги 3. Каждый шаг: исполнитель → ревьювер → доработка (лимит — 3 итерации, дальше к человеку) 4. Финал: полный прогон проверок + аудиты по всему диффу
Лимит в три итерации появился не из теории: без него разработчик и ревьювер способны спорить бесконечно — или, что хуже, тихо сойтись на плохом компромиссе.
И ещё одно свойство скилла, самое важное: он пишется не заранее. Он растёт из инцидентов. Однажды ревьювер завернул четыре блокера, разработчик отчитался «всё исправлено» — а перед коммитом выяснилось, что три исправления из четырёх лежат в рабочем дереве мимо индекса. Коммит уехал бы ровно с теми регрессами, которые ревью только что поймало. Агент не врал — он искренне считал сделанным то, о чём отчитался. С того дня в скилле живёт правило: проверяй фактом, а не отчётом — с конкретной командой, как именно проверять. Скилл — это шрамы, оформленные как инструкция.
Если совсем коротко, разница такая: скилл — это «как готовим», субагенты — «кто у плиты».
План: нарезка под размер головы
На маленьких задачах всё вышеописанное уже работает. На больших не хватает последнего ингредиента — и он скучнее всех предыдущих. Это план.
План здесь — не дань процессу, а физическая необходимость. Задача на пятьдесят файлов не помещается в контекст ни одного агента — её нельзя «сделать», её можно только нарезать. Хороший шаг плана: помещается в голову исполнителя (ориентир — до пяти файлов), имеет проверяемый критерий готовности и оставляет репозиторий в рабочем состоянии. «Добавить поле и прокинуть его до интерфейса» — шаг. «Сделать раздел настроек» — не шаг, а мечта.
Дальше правило, которое экономит больше всего денег: план читает человек — до того, как агенты начнут писать код. Ревьюить план на порядок дешевле, чем ревьюить код. Неверное направление, пойманное на этапе плана, стоит пять минут чтения; то же направление, пойманное в готовом диффе, — день работы труппы.
У планов есть неприятное свойство: они протухают. План, написанный неделю назад, ссылается на код, которого уже нет, и на решения, которые уже отменены. Поэтому перед каждым крупным куском работы у меня прогоняется архитектор — сверить план с реальностью: те ли файлы, те ли имена, живы ли предпосылки. Дёшево, быстро, и регулярно находит устаревшее.
И общее правило, на котором держатся и планы, и всё остальное: не записано — значит не существует. У агентов нет памяти между сессиями. Агент завтрашней сессии не был на вчерашнем совещании, каким бы содержательным оно ни было. Решение, оставшееся в чате, умерло вместе с чатом; решение, записанное в файл, будет доставлено в контекст любого будущего агента за одно чтение. Поэтому архитектурные решения у меня живут в доках, а каждая находка ревью — отдельной задачей в трекере, со статусом и причиной, если её отклонили. Это не бюрократия. Это память труппы — единственная, которая у неё есть.
Клей: правила и проверки
Два ингредиента, без которых конструкция разваливается, — по абзацу на каждый.
Первый — файл правил проекта (в Claude Code это CLAUDE.md), который каждый агент видит всегда. Туда идёт только то, что нельзя вывести из кода: запреты с причинами и грабли, на которые уже наступали. Мои правила датированы, и у самых выстраданных стоит честная пометка «после нарушения» — правило появилось, потому что было нарушено, и я хочу, чтобы это было видно. Файл правил — это не спецификация, написанная в начале проекта. Это прецедентное право: нарушение → разбор → строка с датой.
Второй — проверки. Один скрипт, который гоняет всё: типы, линтеры, тесты, архитектурные ограничения — и возвращает честный код выхода. Он висит на pre-commit и в CI, и для агентов сформулировано дословно: чекеры не отключать, не ослаблять, не обходить; падение чекера — сигнал чинить код, а не проверку. Потому что «готово» от агента — это мнение, а зелёный прогон — факт, и путать их нельзя. Ревьювер ловит смысловые ошибки, проверки — механические; друг друга они не заменяют.
С чего начать
Хорошая новость: ничего из описанного не нужно писать руками. Файл субагента — это markdown, а markdown лучше всех пишет сама модель, тем более про себя.
Мой рецепт первого шага — одна фраза в обычном чате: «Сделай мне субагента-ревьювера: read-only, придирчивый, каждая находка — со сценарием поломки». Claude Code знает собственный формат: создаст файл, положит в нужную папку, сам предложит модель и набор инструментов. Вам останется прочитать роль и поправить характер под себя. Начинать стоит именно с ревьювера: он ничего не может сломать и окупается с первого же диффа.
Второй шаг наступает сам. В какой-то момент вы поймаете себя на том, что третий раз подряд диктуете один и тот же порядок: сначала план, потом разработчик, потом ревьювер, не забудь тесты. Это сигнал: процесс созрел для файла. Скажите «давай сделаем из этого скилл» — и модель развернёт ваш устный ритуал в описание-триггер и шаги. Вычитайте внимательно: это будет закон, по которому дальше пойдёт вся работа.
Дальше труппа достраивает себя сама. Понадобился взгляд злоумышленника — «сделай субагента-безопасника». Случился инцидент — «допиши в скилл правило, чтобы это не повторилось, с сегодняшней датой». Каждый следующий кирпич кладётся одной фразой — главное заметить момент, когда он нужен.
Цена
Теперь ложка дёгтя, без которой это была бы реклама.
Токенов уходит кратно больше, чем в одном чате: труппа из нескольких агентов, где критики сидят на дорогих моделях, ест соответствующе. Я осознанно плачу за это как за качество — но платить приходится реально.
Время человека никуда не делось — оно сместилось. Я не пишу код, но пишу роли, правила и планы, читаю отчёты и разбираю споры ревьювера с разработчиком. Из программиста я превратился в смесь техлида, продакта и арбитра. Мне нравится, но это работа, а не кнопка «сделать хорошо».
Правила нарушаются — в том числе дирижёром. Тогда в файле правил появляется ещё один датированный абзац. Это не поражение, это нормальный цикл: система не бывает настроена — она настраивается.
И главное: всё это не нужно для скрипта на вечер, прототипа на выброс или правки в два файла — там один чат быстрее и дешевле. Труппа окупается ровно на задачах, которые не помещаются в один контекст. Зато на них она окупается с лихвой.
Выводы
Большие задачи ломает не модель, а монолитный контекст, который обязан быть всем сразу.
Роль агента = промпт + чистый контекст + инструменты. Роль без ограничения инструментов — пожелание, с ограничением — факт.
Дорогую модель — критику, дешёвую — исполнителю. Ошибку исполнителя поймают, ошибку критика — никто.
Не записано — не существует: планы, решения и правила живут в файлах, потому что другой памяти у труппы нет.
Отчёту агента не верить. Верить проверке.
Напоследок признание: «шизофрения» в заголовке — конечно, кликбейт, и психиатры справедливо заметят, что расщепление личности — это вообще не про неё. Тем более что расщепляться у модели нечему: личности у неё нет. Но в этом и состоит весь рецепт. Личность агента — это то, что вы кладёте ему в контекст. Один раз научившись собирать её из роли, инструментов и плана, вы перестаёте быть пользователем чат-бота. Вы становитесь режиссёром труппы — и спектакль, наконец, ставите вы.