Привет. Меня зовут Никита, сейчас я PO, был и аналитиком, и PO, и CPO — но вы тут не за этим. Я искренне люблю процессы, схемы, декомпозицию. Пять лет назад я начал делать свой проект — микросервисный fullstack в финтехе, потому что наивно хотел наконец собрать "как надо": с нормальной архитектурой, контрактами API, тестами до кода. Классический пет-проект, который никогда не закончится.

Потом появился Claude Code. И я подумал: вот оно. AI напишет код, а я буду заниматься тем, что люблю — проектировать, анализировать, выстраивать процессы. Первый месяц — восторг. Описываешь задачу, получаешь код, быстро, удобно, магия. Второй месяц — отвращение.

Но вы и сами всё знаете, если читаете про разработку с Claude. Моя система — финтех, 25 микросервисов. Управлять этим зоопарком в одного было дико неудобно ещё до всякого AI. А с Claude стало одновременно и лучше, и хуже.

И лучше и хуже

Хочу немного объяснить (для топ-менеджеров, которые трогают процесс не руками, а процессами и статьями с Хабра), что значит "и лучше и хуже":

Лучше — потому что код он пишет быстро и в целом нормально. Хуже — потому что он не держит в голове систему целиком. Он читает коммиты, может пробежаться по файлам, но он не помнит почему всё устроено именно так. Почему PostgreSQL, а не MongoDB. Почему API спроектирован так, а не иначе. Почему мы отказались от Redis. Каждую сессию он видит код (и то "не полностью"), но не видит решения, которые за ним стоят.

Любая LLM начинает принимать архитектурные решения заново. Сегодня шифрование через AES-256-GCM. Завтра, в другой сессии — AES-256-CBC. Послезавтра один сервис шифрует данные одним алгоритмом, другой пытается расшифровать другим. И это в финтехе при том, что ты "помогаешь" LLM не сбиваться со стека)) Сидишь, разбираешь, почему транзакции не проходят. А они не проходят, потому что Claude в двух разных сессиях принял два противоположных решения и даже не в курсе.

При 25 микросервисах такие конфликты множатся. Один сервис вызывает другой с одним контрактом, второй ожидает другой. Без единого источника правды об архитектуре это превращается в хаос — и неважно, пишет код AI или человек.

Первопричины

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

Полюс 1: документация догоняет. Сначала пишем код, потом (если останется время, настроение и бюджет) описываем, что сделали. Через месяц документация отстаёт от кода. Через три — противоречит ему. Через полгода — её проще удалить, чем обновить. Знакомо каждому, кто хоть раз открывал Confluence/Сферу или что-то подобное.

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

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

И тут становится очевидно, что это единственно верный путь: нужна и документация (для управляемости), и скорость (чтобы не утонуть в бюрократии). AI (очевидно) может не только потреблять документацию — но и генерировать, и поддерживать её в актуальном состоянии. То, что было слишком дорого для людей, становится дешёвым, когда агент делает это автоматически.

Спецификации — не для людей, а для AI

Я по образованию инженер-электронщик. Спеки на микросхемы делаются до того, как кто-то что-то сделает физически, никто не идёт травить плату с мыслью "сейчас сделаем, а потом как-нибудь разберёмся". С кодом (очевидно) должно быть так же.

Менее очевидно — почему существующие SDD-фреймворки (GitHub Spec Kit, Kiro, OpenSpec) не решают проблему. Они сделаны разработчиками для разработчиков. Решают задачу "как структурировать промпты для AI". Но бизнес — это не промпты. Бизнес — это полная цепочка от идеи до реализации: управляемость процессов, контроль, формализация требований, трассируемость решений. Ни один из этих инструментов не закрывает цикл целиком.

Поэтому я сел и запилил свой.

FullSpec фреймворк

FullSpec — фреймворк, который организует разработку с Claude Code через цепочку формальных документов. Под капотом там 71 скилл, 23 агента, 80+ скриптов валидации и 8 фаз процесса. Звучит страшно, но вход простой.

Ты открываешь Claude Code и вызываешь /chain "сделать OAuth2 авторизацию". Дальше под капотом всё крутится само: агенты генерируют документы, ревьюеры проверяют, тебе прилетают вопросы на уточнение и подтверждени�� — обычный диалог, только структурированный.

Цепочка агентов последовательно создаёт 4 уровня спецификаций:

  • Discussion — что и зачем? Требования, критерии успеха, scope, риски.

  • Design — как изменится система? Сервисы, API-контракты, модели данных, интеграции.

  • Plan Tests — как проверяем? Сценарии тестирования пишутся до кода.

  • Plan Dev — какие задачи, в каком порядке? Зависимости, блоки выполнения, маппинг на тесты.

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

После спецификаций /chain продолжает: генерация документации → GitHub Issues → реализация (код, тесты, коммиты) → финальная валидация → code review → PR → merge → release. Весь цикл от идеи до production.

23 AI-агента работают параллельно. Не один Claude, который делает всё последовательно, а специализированные агенты. Один генерирует Design, другой создаёт план тестов, третий пишет код, четвёртый ревьюит. При синхронизации документации запускаются N агентов параллельно — по одному на сервис.

80+ скриптов валидации и 30 pre-commit хуков. Каждый коммит проверяется: формат документов, консистентность структуры, отсутствие секретов, формат commit message (да, я написал валидатор для валидаторов, я так люблю).

16 контекстных правил. Когда Claude открывает .ts файл — автоматически загружается стандарт TypeScript. Открывает .py — стандарт FastAPI. Работает через файлы в .claude/rules/. Claude применяет их без дополнительных промптов.

Система создаёт сама себя. Per-tech стандарты кодирования генерируются автоматически из Design. Контекстные rules создаются автоматически при добавлении технологии. Есть инструкции по созданию инструкций, стандарт написания скиллов, формат агентов. Всё рекурсивно стандартизировано — можно создавать новые скиллы, агенты и правила по тем же стандартам, по которым построена сама система.

Когда план не переживает столкновение с реальностью

Это моя любимая часть. Спецификация говорит: "Сделай POST /users с полем email". При реализации (хотя после месяца допиливания фреймворка такое уже почти не случается) выясняется, что нужно ещё поле phone — SMS-верификация, зависимость от другого сервиса, которую не учли на этапе Design.

Что делают другие spec-driven инструменты? Spec Kit и OpenSpec — ничего, спецификации остаются статичными. Kiro умеет обнаруживать расхождения через property-based тесты, но спеки автоматически не обновляет — это остаётся на разработчике.

FullSpec делает CONFLICT-CHECK после каждого коммита. Если код противоречит спецификации — процесс приостанавливается. Система определяет, на каком уровне конфликт (Plan Dev? Design? Discussion?), и каскадно обновляет спеки сверху вниз. Спецификации получаются живыми и развиваются и до, и вместе, и "после" кода.

Что показалось важным резюмировать

Несколько фактов, которые я хочу отметить:

Порог входа на самом деле низкий. Да, под капотом 71 скилл и 23 агента. Но пользователю не нужно знать про них — он вызывает /chain, отвечает на вопросы и подтверждает шаги. Система ведёт сама. Вы же не знаете, что внутри у какого-нибудь Kubernetes — просто используете. Тут то же самое)

Только Claude Code. Может и работает с Cursor, Copilot, Windsurf — не проверял. Мне просто нравится Claude, я с ним работаю, под него и строил. Может когда-нибудь портирую, но мб это сделает и кто-то другой))

Документация на русском. Все инструкции, стандарты, спецификации — на русском. Claude понимает русский нативно, для него это не проблема. Но если нерусскоязычный разработчик захочет прочитать или изменить сами инструкции — барьер (который в целом не очень сложно решить, нужен лишь простой советский...)

Только greenfield. Пока работает только как template для новых проектов. Brownfield (внедрение в существующий проект) — в планах.

Сравнение с альтернативами

Я не в вакууме. Есть другие проекты, решающие похожую задачу. Вот честное сравнение (которое для меня сделал Claude):

FullSpec

Spec Kit (GitHub)

Kiro (AWS)

OpenSpec (Fission AI)

Тип

Фреймворк процесса

CLI-тулкит

IDE (форк VS Code)

CLI-фреймворк

Цена

Бесплатно (MIT)

Бесплатно (MIT)

$20–200/мес

Бесплатно (MIT)

Stars

новый (буду рад звёздочке)

77k

closed source

31k

Формализация требований

Discussion (REQ-N, критерии, scope)

Constitution + Spec

Requirements (EARS)

Proposal

Архитектурное проектирование

Design (SVC-N, 9 подсекций, API-контракты)

Plan

Design (markdown)

Design

Планирование тестов ДО кода

Plan Tests (TC-N)

нет

нет

нет

Планирование задач

Plan Dev (TASK-N, зависимости, блоки)

Tasks

Tasks (чеклист)

Tasks (YAML)

Обнаружение конфликтов код ↔ спеки

автоматическое + каскадное обновление

нет

нет

нет

Живая документация

автосинхронизация из спек (10 секций/сервис)

нет

нет

нет

GitHub-автоматизация

Issues, PR, Review, Release — полная

нет

нет

нет

AI-агенты

23 параллельных

0

1 (встроен)

0

Валидация

30 pre-commit хуков, 80+ скриптов

0

0

~5

AI-агностичность

только Claude Code

20+ агентов

только Claude/Bedrock

20+ агентов

Brownfield

пока нет

да

да

да (фокус)

Зрелость

новый

эксперимент (по словам авторов)

GA (enterprise)

активная разработка

Каждый решает свою часть. FullSpec пытается закрыть весь цикл — от идеи до production release. Это делает его мощнее, но и тяжелее. И да, привязка к Claude Code, отсутствие brownfield и то, что маркетинг не включён в цепочку поставки ценности — это честные минусы. С маркетингом развлекайтесь сами))

Цифры

  • 71 скилл (slash-команда для каждого шага)

  • 23 AI-агента (параллельные воркеры)

  • 80+ скриптов валидации

  • 30 pre-commit хуков

  • 16 контекстных правил (увеличивается с вашим стеком)

  • 8 фаз процесса от идеи до релиза

  • 5 лет пет-проекта, который наконец обрёл процесс

Проект open source, MIT: github.com/NSEvteev/FullSpec

Вместо заключения

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

Если у вас есть проект и вы хотите попробовать — не надо переписывать с нуля. Форкните, вызовите /chain с описанием того, что хотите сделать, и посмотрите что получится. В худшем случае — получите исследование своей задачи в виде 4 структурированных документов. В лучшем — рабочий код с тестами и PR (но это не точно).

GitHub: github.com/NSEvteev/FullSpec — форкайте, пробуйте, ломайте. Issues и звёздочки приветствуются.

P.S. Не верьте мне на слово. Скормите вашей любимой LLM вот такой промпт и составьте своё мнение:

Сделай непредвзятый сравнительный анализ этих spec-driven development инструментов. Для каждого укажи плюсы, минусы, ограничения и для кого подходит:

P.P.S. Если зашло — поделитесь с коллегами или в своих каналах. Мне поможет, вам + в карму :3