От vibe coding к продакшену: мой spec-driven workflow с Claude Code

2 февраля 2025 года Андрей Карпатый ввёл термин "vibe coding": "полностью отдайся вибрациям, прими экспоненциалы и забудь, что код вообще существует". Через год, 4 февраля 2026 года, он от этого термина отказался. На смену пришло "agentic engineering" — потому что, как он сам выразился, теперь по умолчанию вы не пишете код напрямую 99% времени. Вы оркестрируете агентов. Оригинальный твит про vibe coding — здесь.

Двенадцать месяцев. Из мема в дисциплину. Большинство команд, с которыми я общаюсь, разницы пока не заметили.

Между этими двумя твитами вышло исследование METR — контролируемый эксперимент на сеньорных open source разработчиках, использовавших Cursor и Claude на зрелых кодовых базах, тех самых, где знаешь все углы. Разработчики прогнозировали ускорение на 24%. После выполнения задач они оценивали, что ускорились на 20%. Замеры показали реальное замедление на 19%. Сеньоры. На коде, который они писали годами.

В одном из ранних постов я говорил, что AI ускоряет мою клиентскую работу на 30-40%. Обе цифры могут быть правдой одновременно. Дело не в инструменте. Дело в workflow вокруг инструмента.

Этот пост — про этот workflow.

Это не теория. Это то, что я каждый день запускаю на продакшен-коде в sundr. Claude Code — двигатель; небольшой набор open source инструментов — ограждения. Вместе они превращают AI из энтузиаста-стажёра, который выкатывает 70% фичи, в сеньорного парного программиста, который доделывает оставшиеся 30%.

Если вы хоть раз смотрели, как Claude генерирует чистый на вид pull request, нажимали merge с улыбкой, а потом наблюдали, как этот же код ломается через три дня под реальным трафиком — этот пост для вас.

AI — это усилитель

Самое полезное предложение про AI, которое я прочитал в 2025 году, пришло из 2025 DORA report от Google, опросившего почти пять тысяч разработчиков в сентябре: "AI не чинит команду; он усиливает то, что уже есть".

Из того же отчёта: 90% разработчиков уже используют AI в работе, и больше 80% сообщают о росте продуктивности. Около 30% — о малом доверии или его полном отсутствии к AI-сгенерированному коду. Последняя цифра — то, ради чего и существует spec-driven workflow.

Через три месяца Stack Overflow 2025 developer survey подкинул ещё более резкие цифры. Доверие к точности AI упало с 40% в 2024 году до 29% в 2025-м. Сорок шесть процентов теперь активно ему не доверяют. Шестьдесят шесть процентов сообщают, что их раздражает вывод, который "почти правильный, но не совсем". А именно этот failure mode и убивает вас на код-ревью через полгода — когда баг уже ваш и его надо дебажить, а изначальный промпт давно забыт.

Adoption растёт. Trust падает. Разрыв между этими двумя линиями — это и есть discipline gap. AI усилит любой workflow, который у вас уже есть. Если ваш workflow — "печатай, пока не скомпилируется", то именно его вы и усиливаете.

Остальная часть поста — про workflow, который усиливаю я.

70%-проблема и математика накопления

Эдди Османи чётко сформулировал ловушку ещё в декабре 2024-го: "AI быстро выдаёт 70% решения, но оставшиеся 30% — крайние случаи, безопасность, интеграция с продакшеном — остаются такими же сложными, как и были".

Я вижу это на каждом клиентском ревью. Демо работает. Pull request выглядит чисто. Тесты проходят — потому что Claude и тесты тоже написал, что само по себе отдельная проблема. А потом баг всплывает через три дня в продакшен-трафике. Null-проверка, которая нигде не подключилась. Смещение часовых поясов, которое никто не заметил. Auth-заголовок, который работал в dev-окружении, потому что dev был слишком толерантным. Правдоподобный код, который на самом деле не делает того, что должен.

Почему так происходит? Не потому что Claude тупой. Это накопительная вероятность.

Представьте, что каждое решение AI в нетривиальной задаче — это шаг с успехом 99%. Выбрать правильную библиотеку. Понять форму данных. Обработать пустой случай. Назвать переменную. Правильно вызвать API. Перехватить нужную ошибку. У реальной фичи десятки таких решений последовательно.

Сто решений с успехом 99%: 0,99 в сотой степени. Это около 37%. Тридцать семь процентов вероятности, что вся цепочка сходится от начала до конца.

Это не пессимизм. Это умножение. Вы видите это в собственных pull request'ах. Большая часть кода по строкам — нормальная. Агрегат сломан, потому что обязан быть сломан — даже при 99% на каждое решение, цепочка из ста шагов проваливается чаще, чем нет.

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

CLAUDE.md — где живёт память Claude

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

По документированной Anthropic иерархии памяти, CLAUDE.md-файлы каскадируются — есть один в ~/.claude/CLAUDE.md для ваших глобальных настроек, один в корне проекта, который видит каждый, кто работает в репо, и опциональные пер-директорные файлы для модуль-специфичных правил. Я коммичу проектный. Свой персональный — не коммичу.

Я держу файл в районе двадцати-пятидесяти строк, разбитых на пять коротких секций:

# {Project Name}

## What this is
{2-3 sentences: what the product does, what stack it runs on}

## Key directories
- src/domain/  — pure business logic, no framework imports
- src/infrastructure/  — Express, DB, external services
- tests/  — unit + integration + characterization

## Code standards
- TypeScript strict mode; type hints required
- Test framework: vitest
- Imports: external, then internal, then relative

## Common commands
- pnpm test  — run all tests
- pnpm dev   — start dev server
- pnpm build — production build

## Anti-patterns
- Do NOT use console.log — use logger from src/infrastructure/logger
- Do NOT mutate objects — spread {...obj, key: value}
- Never use a double-hyphen in user-facing text; use em dash with spaces
- Do NOT import infrastructure/ from domain/

Самая важная секция — последняя. Anti-patterns с конкретными // DO NOT примерами читаются как ограничения. Абстрактные правила читаются как пожелания. Claude реагирует на разницу. Люди тоже, но у людей есть опция забыть — у Claude её нет. В этом и leverage.

Держите файл коротким. Длинные файлы размывают внимание. Если правило не оправдывает свою строку — вырежьте. Я начал удалять пункты из CLAUDE.md, когда замечаю, что сам их нарушаю — не потому что правило неправильное, а потому что если оно не выжило в моих собственных привычках, Claude точно его не интернализует.

Борис Черный — создатель Claude Code — публично говорит, что его собственная конфигурация "удивительно ванильная" и что он почти ничего не кастомизирует в Claude Code (см. его тред на Threads о том, как он использует Claude Code). Это сходится с тем, что я вижу на практике. Большинству проектов нужно двадцать-пятьдесят строк, а не двести. Файл работает за счёт того, что его читают, а не за счёт того, что он раздут.

Эффект накапливается сильнее, чем кажется. Claude начинает каждую сессию с этим файлом в голове. Именно это позволяет ему следовать конвенциям с первого раза, писать команды так, как вы их реально запускаете, и отказываться от anti-patterns без напоминаний. Без CLAUDE.md AI — гениальный амнезиак, который представляется заново каждое утро. С ним — у вас есть преемственность. А преемственность — это то, что превращает "работает в этом промпте" в "работает в этой кодовой базе".

Четыре фазы: Specify, Plan, Tasks, Implement

Рекомендуемый Anthropic workflow для Claude Code — четыре фазы: Explore, Plan, Implement, Commit. Это фундамент. Поверх него я выстраиваю четырёхфазовую артефактную дисциплину, которая превращает размытое намерение в готовый к выкатке код: Specify, Plan, Tasks, Implement — с шагом Commit, свёрнутым в TDD-коммиты внутри каждой задачи. Та же форма, что и EPCC, но с явными гейтами между фазами, на которых человек читает артефакт до того, как AI берётся за следующий.

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

GitHub Spec Kit — артефактная половина. Он задаёт файловую структуру: constitution.md фиксирует операционные принципы, spec.md — намерение и acceptance criteria, plan.md — технический подход, tasks.md разбивает работу на ограниченные единицы. У каждого артефакта своя slash-команда — /speckit.specify, /speckit.plan, /speckit.tasks, /speckit.implement — задающая Claude правильные вопросы в правильном порядке. Open source, фреймворк-агностичен, работает с Claude Code, Copilot, Cursor и Gemini.

Официальный плагин Anthropic superpowers — половина дисциплины. Он собирает набор скиллов, которые приводят в порядок ритуалы вокруг артефактов: brainstorming настаивает на дизайн-разговоре до любого кода, writing-plans декомпозирует работу на 2-5-минутные задачи до начала имплементации, test-driven-development навязывает RED → GREEN → REFACTOR, verification-before-completion требует доказательств — реального вывода команд — прежде чем мне разрешено сказать, что что-то починено.

Spec Kit — это что. Superpowers — это как. Любой из них в одиночку течёт. Полно команд, которые используют Spec Kit и при этом vibe-кодят имплементацию, потому что никто не навязывает test-first привычку. Полно других — гоняют superpowers и пропускают спеку, потому что никто не сделал её написание условием. Вместе они закрывают щели, в которые AI обычно убегает.

Что каждая фаза реально делает на практике.

Specify отвечает на что мы строим и зачем. Пять компонентов, по порядку: функциональные требования, acceptance criteria, примеры вход/выход, ограничения и — тот, который большинство пропускает — out of scope. AI расширяет скоуп по умолчанию. Линия, которую вы не провели — это линия, которую AI пересечёт. Я пишу явный список "не имплементировать X, Y, Z в этой фиче" до того, как пишу что-то ещё, даже если Z кажется очевидным.

Acceptance criteria — в EARS notation (Easy Approach to Requirements Syntax) — структурированный способ писать требования по пяти фиксированным шаблонам, опубликованный в IEEE-статье в 2009 году Алистером Мэвином. На практике это короткие, машиночитаемые строки вроде WHEN the user submits a checkout form without a payment method, the system SHALL reject the order AND display a recoverable error. EARS к AI отношения не имеет; просто оказалось, что эта нотация однозначна, а однозначность — это то, что AI и нужно.

Plan отвечает на какую техническую форму это должно принять. На выходе — plan.md с архитектурным эскизом, моделью данных, точками интеграции, рисками и явным "если это не сработает, вот откат". Это самый высокоприоритетный гейт во всём workflow — последний дешёвый момент сменить направление, прежде чем будут нарезаны задачи.

Tasks разбивает план на единицы AI-работы по 30-60 минут, каждая независимо тестируемая. Маркеры вроде [P] помечают параллелизуемые задачи. Список упорядочен. Никаких "TBD" — если я не знаю, как ограничить задачу, значит, неправильна спека, а не список задач.

Implement — единственная фаза, где AI за рулём, и только внутри одной задачи за раз, с тестом, который запускается до и после каждого изменения. Specify, Plan и Tasks — всё в человеческих руках. Артефакт мой; имплементация — Claude'а. Эта инверсия и заставляет workflow работать. Каждый гейт между фазами — это место, где я могу остановиться, отредактировать, перезапустить или откатиться, не теряя больше, чем работу одной последней задачи.

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

Две бесплатные тактики, которые накапливаются

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

Первая — Plan Mode. У Claude Code есть read-only режим, в котором AI может видеть любой файл и запускать любой поиск, но не может ничего редактировать, запускать shell-команды или писать на диск. Включаешь, вставляешь задачу — и Claude читает, планирует и пишет тебе обратно markdown-план, не трогая кодовую базу. Потом выключаешь и даёшь Claude выполнить план.

Я гоняю Plan Mode перед каждым нетривиальным изменением. Это стоит шестьдесят секунд и экономит мне — по консервативной оценке — двадцать минут уборки в неделю. План, который возвращается, ещё и отличный вход для Spec Kit-овской /speckit.plan, потому что вытаскивает файлы и риски, о которых я не подумал.

Вторая тактика — Writer-Reviewer с /clear. Сетап: попросите Claude сделать что-то. Когда он говорит, что сделал — пишете /clear, чтобы стереть контекст, и в той же сессии просите Claude отревьюить диф. Ревьюер технически — та же модель, но без памяти о рассуждениях и предположениях писателя.

Это ловит специфический класс багов, которые in-session ревью пропускает — случаи, когда ментальная модель писателя была неправильной с шага один, и каждое последующее решение усугубляло ошибку. Писатель эти баги увидеть не может, потому что ментальная модель писателя и есть баг. Свежеконтекстный ревьюер приходит к дифу холодным и спрашивает: "погоди, почему ты приводишь userId к числу, если в схеме это UUID?"

По моему опыту, post-/clear ревью ловит ощутимую долю проблем, которые in-session ревью пропустил — примерно тот лифт, который вы получили бы от второй пары глаз, только эта пара никогда не устаёт и у неё не бывает пятничного синдрома. Это не магия. Это просто другая голова, читающая код. Если вы возьмёте из этого поста только одну тактику — возьмите эту.

Plan Mode и трюк с /clear к тому же бесплатны от любых плагинов и дополнительных инструментов. Они идут в комплекте с Claude Code как есть.

Задачи размером в тридцать минут AI-работы, а не в три часа

Самый большой рычаг внутри Implement-фазы — размер задачи. Слишком маленькая — overhead на старт и коммит каждой топит ценность. Слишком большая — Claude дрейфует: контекст забивается, прогоны тестов становятся ненадёжными, и в конце вы оказываетесь над разросшимся дифом.

Размер, который у меня работает — тридцать-шестьдесят минут AI-работы на задачу. Каждая задача поставляется своим коммитом и независимо проверяется. Реальный tasks.md выглядит так:

- [ ] T1: Add /api/health endpoint  [P]
- [ ] T2: Wire health check to monitoring  [P]
- [ ] T3: Write characterization test for legacy /api/order  [blocks T4]
- [ ] T4: Refactor /api/order — extract validation helper
- [ ] T5: Add e2e test for /api/order happy path

Маркеры [P] показывают, какие задачи можно гнать параллельно. [blocks Tx] выражают зависимости. T3 должна выйти раньше T4, потому что нельзя рефакторить то, что вы не охарактеризовали.

Внутри каждой задачи я гоняю плотный цикл: пишу падающий тест, смотрю, как он падает, пишу минимальный код, чтобы он прошёл, смотрю, как он проходит, коммичу. Это просто TDD; superpowers-овский скилл test-driven-development навязывает цикл, когда я разогнался и хочу пропустить шаги. Цикл важен, потому что каждый закоммиченный шаг — это известная-хорошая точка отката. Если задача уходит с рельс, я теряю минуты, а не часы.

Одно операционное правило: я слежу за утилизацией контекста. Когда у Claude контекст переваливает примерно за 70%, качество вывода падает — рассуждения становятся неаккуратными, код начинает повторять предыдущие паттерны неправильно. Когда я вижу, как полоска лезет вверх, я либо запускаю /compact (или соглашаюсь на авто-compact), либо начинаю новую сессию, либо останавливаюсь. Лезть дальше — это потраченные токены и потраченное время.

Как это выглядит на реальном проекте

Чтобы было конкретно: в прошлом месяце я выкатил систему турнирного стейкинга для MTT Tracker — продукта по покерной аналитике, который я веду параллельно. Игроки продают доли своего турнирного экшена бэкерам; трекер теперь моделирует всю экономику — наценки, расчёты, свопы, P&L с поправкой на стейкинг.

Один proposal.md зафиксировал мотивацию и скоуп. Секция Out of Scope явно исключила бэкер-фейсинг портал, интеграцию с платежами, маркетплейс стейкинга и фичи налоговой отчётности — ни одно из этих исключений не было "очевидным", и каждое — это то, во что AI с радостью бы расширился. Прочерчивание этих линий заранее сэкономило часы детуров вида "давай заодно добавим вот это".

tasks.md разросся до 195 упорядоченных, ограниченных пунктов, разбитых на три фазы: feature flag и гейтинг, схема и расчёты, потом UI и аналитика. Каждая задача несла TDD-микроцикл — падающий тест, наблюдение, минимальный код, проход, коммит. Шесть локалей обновлялись в шаге с любым изменением UI, потому что это правило сидело в CLAUDE.md.

Интересно не то, как быстро всё это выкатилось. Интересно, что ничего не утекло за пределы спеки. (Подробнее про сам продукт — в моём кейс-стади про MTT Tracker.)

Что я бы пропустил — и что изменилось в 2026

Три вещи, которые этот пост не рекомендует, хотя они и появляются в куче agentic-engineering статей.

Тяжёлые мульти-агентные команды для саб-дневных фич. Поднимать "команду" специализированных агентов — backend, frontend, девилз-эдвокат, ревьюер — реально полезно для cross-cutting работы, занимающей пару дней. Для часовой правки одиночный EPCC плюс трюк Writer-Reviewer из предыдущей секции быстрее и шумит меньше.

Магические слова бюджета мышления. В течение всего 2025 года промпты с подмешанным ultrathink или think harder были реальным рычагом — они увеличивали глубину рассуждений Claude. С 16 января 2026 года Anthropic эти ключевые слова депрекейтнул. Современные модели управляют thinking-бюджетом адаптивно. Если вы видите их в чьём-то CLAUDE.md — этот файл не обновлялся в этом году.

Заголовок "AI ускоряет разработку" как одну цифру. Даже METR — команда, выпустившая исходное исследование с −19% в 2025-м — опубликовала апдейт в начале 2026-го: новая точечная оценка −18% имеет широкий доверительный интервал (от −38% до +9%), помечена как "очень слабое доказательство" из-за смещения выборки (часть участников не вернулась к замерам), и по итогам интервью с разработчиками METR теперь считает, что в начале 2026-го разработчики, вероятно, быстрее с AI, чем были в начале 2025-го. Честная формулировка не в том, что AI всегда замедляет. А в том, что AI без дисциплины — это бросок монетки на зрелых кодовых базах. С дисциплиной — это мультипликатор. Заголовочная цифра целиком зависит от workflow вокруг инструмента.

Эту формулировку coin-flip-vs-multiplier ThoughtWorks называет cognitive debt в своём апрельском Tech Radar 2026 года. Spec-driven development — в их коротком списке привычек, которые не дают cognitive debt накапливаться. Они правы.

Это, кстати, и ответ на загадку из начала. Один и тот же Claude может сделать сеньорного инженера на 30-40% быстрее в одной команде и на 19% медленнее в другой. Модель идентична. Workflow вокруг неё выбирает результат.

Если вы хотите, чтобы эта дисциплина применялась в вашей кодовой базе

Читать про workflow — одно. Запускать его на вашем реальном репозитории, с вашим реальным стеком, вашими реальными дедлайнами и вашим реальным техдолгом — совсем другое. Если вы строите реальный продукт и хотите, чтобы описанный здесь workflow применялся к вашей кодовой базе — не в теории, а в коде — это и есть то, чем я занимаюсь в sundr.

Два самых простых первых шага: попробуйте калькулятор проекта для быстрой оценки сроков и бюджета, или запишитесь на бесплатный 30-минутный звонок и расскажите, над чем вы работаете. Я дам прямой ответ, подходит ли этот подход — а если нет, тоже скажу. (Если хотите контекст, к каким проектам эта дисциплина применима, ближе всего — моя услуга по разработке веб-приложений; если вы ещё выбираете между фрилансером и агентством, мой честный взгляд на этот вопрос — в другом посте.)

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