Claude Code пишет код быстрее меня, и это не фигура речи: тесты, рефакторинг, ревью — всё на нём. Но если дать ему задачу и отойти, то через час вы получите 2000 строк без единого теста, три файла которые не компилируются и коммит «fix stuff», и вот это вот всё уже ваша проблема, а не его. Мощность без процесса — это просто хаос, которому добавили ускорение.
Несколько недель я как раз и превращал этот хаос в нормальный конвейер, и получилось у меня две вещи: STC (формализованный процесс разработки) и Guardian MCP — сервер, который сам следит за тем, чтобы процесс соблюдался. Ниже расскажу как это работает и зачем вообще нужно, если вы вдруг тоже сидите на вайбкодинге и устали разгребать за агентом.
Проблема: мощность без дисциплины
Когда я только начал работать с Claude Code, первые дни были чистой эйфорией. Даёшь задачу — получаешь код, быстро, много, работает... иногда.
А проблемы начинались ровно тогда, когда задача была больше одного файла. Агент брался делать три вещи сразу: менял модель данных, переписывал API и тут же правил фронтенд, и всё это без тестов и без проверки, а потом коммитил одним куском. И если что-то ломалось, то откатывать приходилось вообще всё, потому что разделить уже было невозможно.
А ещё хуже то, что он пропускал шаги. Говоришь ему «напиши сначала тесты», а он пишет три кейса из двадцати и сразу несётся за код. Говоришь «проверь безопасность» — отвечает «проверил, всё ок» и идёт дальше. Формально-то выполнил. А по факту нет — как было у меня с деплоем, где тесты зелёные, а экран пустой.
И это не проблема конкретно Claude, не подумайте. Любой ai агент без ограничений ведёт себя ровно так же, потому что он оптимизирует на «быстрее закончить задачу», а не на «сделать правильно». Тесты замедляют, проверка замедляет, разбивка на шаги замедляет, и без внешнего контроля агент всегда выберет короткий путь, как ни крути.
STC: Spec-Test-Code
Расшифровывается просто: Spec-Test-Code. То есть перед тем как писать код — напиши спецификацию, перед тем как писать код — напиши тесты, и только потом уже сам код. Звучит как капитан очевидность, но именно этого агент сам по себе и не делает.
А за тремя буквами стоят семь фаз с жёстким порядком, и пропустить нельзя (ну, почти: можно skip, но с явным обоснованием, чтобы потом было видно где ты срезал угол). Перейти к следующей фазе можно только закончив текущую.
Семь фаз: от спеки до коммита
Процесс делится на две части, и первая выполняется один раз на фичу:
Specify. Тут я пишу спецификацию: что делаем, зачем, какие ограничения, какой нужен результат. Спека живёт в `.claude/specs/feature.md`, и это не формальность ради галочки, а контракт между мной и агентом. Если в спеке чего-то не написано — этого не будет и в коде. А если написано криво — то и код будет кривой, всё честно.
Clarify. Максимум два раунда вопросов по дыркам в спеке. Агент читает документ и спрашивает: «А что если пользователь отправит пустую строку? А если API вернёт 429? А что делать с миграцией существующих данных?» Иногда вопросы тупые, чего уж там, а иногда ловят реальную дыру, которую я сам бы проглядел.
Plan. Декомпозиция на атомарные шаги. Не «сделай фичу» одной строкой, а «шаг 1: добавь модель в БД, шаг 2: напиши эндпоинт, шаг 3: добавь валидацию», где каждый шаг — это пара предложений и максимум 3-5 файлов.
Опционально перед Plan можно запустить SCD-гейт — это консилиум экспертов плюс дебаты по архитектурным решениям, и для сложных фич такая штука реально спасает от ошибок проектирования, которые потом стоят недели.
Вторая часть повторяется уже на каждый атомарный шаг:
Test. Тесты из сценариев спеки. Запускаешь — они падают. Red. И так и должно быть, не пугайтесь.
Code. Агент пишет код, тесты зеленеют. Green.
Verify. Три агента параллельно проверяют код, и про это чуть ниже отдельно.
Commit. Только после Verify, и один шаг — один коммит, никаких сборных солянок.
То есть фича из 8 шагов — это 8 итераций Test-Code-Verify-Commit, и ни одной меньше.
Атомарные шаги: никогда не делать всё целиком
Большая задача разбивается на куски, каждый из которых можно описать одним предложением. «Добавить модель Account с полями name, proxy, status.» «Написать endpoint POST /accounts с валидацией.» «Прикрутить warmup-скрипт к scheduler.» Вот так, по-простому.
А почему не сделать всё сразу, спросите вы? Да потому что ai агент на большой задаче тупо теряет контекст: на третьем файле он уже забывает что решил на первом, на пятом начинает противоречить спеке, а вы этого даже не замечаете, потому что diff на 800 строк нормально проверить невозможно в принципе.
А один шаг — это 3-5 файлов, diff на 50-100 строк, и проверка занимает минуту. И если что-то пошло не так — откатываешь один шаг, а не весь день работы коту под хвост.
Guardian MCP: автоматический трекер
STC как набор правил в CLAUDE.md работал, но с дырами. Агент «забывал» вызвать проверку, или перескакивал с Test сразу в Commit минуя Verify, или делал два шага подряд вообще без фиксации между ними. И ровно ради этого я и собрал claude code mcp под себя.
Guardian MCP — это и есть MCP-сервер, который трекает процесс автоматически. Он знает текущее состояние и просто не даёт перейти дальше, пока не выполнены условия.
- Как это работает:
- Начинаю фичу: `feature_register` создаёт трекер
- Закончил этап: `phase_advance` проверяет условия и двигает дальше
- Хочу пропустить: `phase_advance` + `skip_reason`. Можно, но причина зафиксирована
- Перед коммитом: `verify_checklist` проверяет что проверка была
Каждый переход — это вызов `phase_advance`, и без него трекер просто не знает что ты продвинулся. Агент технически всё ещё может зафиксировать код мимо Verify, никто ему руки не отрубит. Но нарушение тут же осядет в логе, и я это увижу, а значит и спрошу.
А `phase_status` в любой момент показывает где ты находишься и что от тебя требуется прямо сейчас, ну а `session_log` хранит всю историю переходов, чтобы потом можно было разобрать полёты.
Verify: три агента параллельно
Verify — это самая важная часть всего процесса. Три специализированных агента запускаются параллельно, каждый со своим фокусом:
@code-reviewer смотрит на качество кода: дублирование, неиспользуемые импорты, нарушение типизации, логические ошибки. Это не линтер, это именно ревью уровня «тут ты обрабатываешь ошибку 404, но не 429, а API возвращает как раз 429 при rate limit».
@security-guard проверяет безопасность: секреты в коде, SQL-инъекции, небезопасные зависимости, открытые порты. «В строке 47 ты конкатенируешь пользовательский ввод прямо в SQL-запрос.» Вот такие вещи, на которых обычно и горят.
@spec-verifier сверяет код со спекой. Если в спеке написано «эндпоинт возвращает 201 при создании», а код возвращает 200 — он это поймает. Если спека говорит «retry 3 раза при таймауте», а retry в коде нет — тоже поймает, не отвертишься.
Три фокуса, параллельный запуск, и результаты уходят в `verify_checklist`. А без результатов всех троих фиксация просто не пройдёт — это и есть ии для автоматизации контроля качества, чтобы я не сверял глазами каждый коммит.
Как это выглядит на практике: MAKO
MAKO — это мой конвейер для автогенерации коротких видео. Подробности про сборку и этапы системы я расписал в отдельных постах, а тут именно про то, как STC и Guardian работали на живом проекте.
Stage 0 (прототип). 8 шагов, спека на pipeline из 8 модулей, 73 теста по моим сценариям и ноль написанных мной вручную. Каждый шаг шёл одинаково: тесты красные → код → тесты зелёные → проверка → фиксация.
Stage 1 (генератор контента). 11 шагов, и перед планом мы прогнали дебаты Claude vs GPT по архитектуре Prompt Contract. GPT тогда победил в вопросе разделения промптов на слои, и агент реализовал именно его решение.
Моя роль на каждом этапе простая: я формулирую спеку, модерирую дебаты если есть спорные решения, принимаю решения и проверяю результат. Агент пишет код, тесты, всё реализует, а трекер не даёт ему пропустить шаги. Вот так разработка с ии и выглядит у меня на деле — я думаю, машина пашет.
Масштаб прямо из логов: 197 переходов между этапами, 52 проверки перед фиксацией, 8 тем дебатов (26 раундов суммарно), 9 спецификаций. То есть это вам не «настроил и забыл» — это живой процесс, который работает каждый день.
А без STC Stage 1 выглядел бы примерно так: «Перепиши генератор», и на выходе один огромный кусок без тестов и с парой багов, которые всплывут через неделю на самом интересном месте. А с STC это 11 маленьких фиксаций, и каждая протестирована и проверена, и баги ловятся в Verify, а не на продакшене перед носом у юзеров.
Медленно? Нет. Дорого ошибаться
Вот что реально медленно — это быстро сделать, а потом неделю дебажить. А STC добавляет 15-20 минут на шаг, но убирает часы дебага, и тут даже считать особо нечего. На MAKO Stage 0 от первой строки до работающего конвейера прошло 2 дня — и это с тестами и проверками, не на коленке.
А почему не просто CLAUDE.md с правилами, раз уж всё равно пишешь? Да писал я, и не раз. Агент «забывает», причём не со зла — у него просто нет состояния между вызовами, он каждый раз как с чистого листа. А Guardian хранит это состояние и напоминает, и вот в этом вся разница между «правила написаны» и «правила реально enforced».
Итоги
- AI-агент без процесса оптимизирует на скорость, а не на качество. Тесты, проверки, декомпозиция — всё это он будет пропускать, если его не заставить
- STC (Spec-Test-Code): семь фаз. Specify, Clarify, Plan, Test, Code, Verify, Commit. Первые три на фичу, последние четыре на каждый шаг
- Guardian MCP трекает процесс автоматически. `phase_advance` на каждом переходе, `verify_checklist` перед фиксацией
- Verify = три агента параллельно: code-reviewer, security-guard, spec-verifier
- На MAKO это дало 73 теста, 19 шагов, 3 этапа за 2 дня. И каждый шаг протестирован и проверен
Связанные посты: как собирал MAKO за 2 дня | 3 этапа через спеки и дебаты | AI-дебаты как метод | SCD: гибрид дебатов и консилиума