Brownfield SDD: управляемый взрыв, валидация и три итерации от хаоса к системе
Ключевые идеи
🚀 Raptor 1 → 2 → 3: три итерации как нормальная модель
Первая реализация - грубая, работает. Вторая - клиенты пользуются, качество приемлемое. Третья - production-grade engineering. Как движок SpaceX Raptor: первая версия вызывала смех у инженеров, третья стала masterpiece. Закладывайте три прохода в бюджет. Сгенерировать код бесплатно, прогнать тесты тоже — итеративное улучшение дешевле, чем попытка сделать идеально с первого раза.
📊 Два горба: планирование и валидация
Execution/coding схлопнулось практически до нуля. Осталась кривая с двумя горбами: планирование (proposal → design → specs) и валидация. Второй горб — текущий bottleneck. Вещи начинают разваливаться на уровне пользовательских сценариев, которых раньше просто не было в таком количестве за такое короткое время.
⚡ Force multiplier vs. Shit multiplier
GenAI может быть force multiplier, который помогает взлететь. Либо shit multiplier, который помогает натворить огромное количество хрени и разнести по всему проекту. Ценность инженера — выбрать направление. Каждый запуск ракеты — управляемый взрыв.
🧹 Код — это обременение (liability)
Самый лучший код — тот, который не написан. С GenAI мы получили инструмент, который помогает писать слишком много кода. LLM копируют паттерны из существующего кода — и плохие тоже. Чистый код сегодня предотвращает плохую генерацию завтра. Когда rules и код расходятся, побеждает код.
Ключевые выводы
🎯 Матрица критичности 3×3. Два измерения: стадия (альфа/бета/прод) × уровень системы (критичная/важная/вспомогательная). Создание кода одинаково для всех квадрантов. Валидация — радикально разная.
📋 Inventory step — борьба с фантазиями. LLM не находит существующий функционал и пишет заново. Добавили отдельный шаг: перед реализацией явно собрать всё релевантное из кода и спек.
🔄 Error budget из парашюта. Две ошибки подряд в прод — стоп-конвейер. Половина проблем от overconfidence, вторая от усталости. Каждый месяц — bugbash вместо фичей.
🗑️ Дубликаты — враг номер один. Из 10K строк фичи — 1.5K дубликатов. LLM фантастически любит копипастить. Еженедельный анализ дубликатов обязателен.
🧪 LLM врут в тестах. Переписывают тест-кейсы, чтобы получить нужный результат. Единственный вариант — хешировать тесты и отслеживать мутации.
🏭 Smooth is fast. Не лететь слишком далеко, слишком быстро. Убирать трение в процессе — автоматически становишься быстрее (модель Navy SEALS).
Ресурсы
OpenSpec — начало работы — github.com/Fission-AI/OpenSpec — Документация по OpenSpec: от инициализации проекта до полного lifecycle с proposals, design, specs и tasks.
SDD Telegram Chat — t.me/spec_driven_development — Чат для вопросов по spec-driven development. Миша отвечает на вопросы, обсуждения продолжаются вечерами.
Основные моменты
[0:00] 🎯 Контекст: стартап из двух человек, полмиллиона строк
Вторая сессия про OpenSpec. Стартап Finsi — AI-движок агентов для маркетинга. Два человека, полмиллиона строк кода за три месяца. В декабре клиенты говорили «приходите позже», сейчас — «можно я завтра начну?». «По ощущениям, то, что мы сделали, это была бы команда из десяти человек на год. Против двоих на три месяца, которые ещё и клиентами занимаются». Триста табличек в базе, триста UI-страниц, куча интеграций. Основная технология — Node.js, два сателлитных проекта на Python (Crew AI) и Rust.
[0:10] 🧠 Ментальные модели: от ходьбы к парашюту
Как в прыжках с парашютом — рефлексы с земли в небе не работают. Двадцатилетний опыт разработки стал нерелевантен. «Весь мой опыт говорит, что такая штука — это сложно, больно, дорого. И вообще лучше не начинать. Весь этот опыт абсолютно нерелевантен стал». Распределение времени кардинально изменилось: execution/coding схлопнулось, появились два горба — планирование и валидация.
[0:18] 🚀 Raptor 1 → 2 → 3: итеративная модель разработки
Метафора движка SpaceX Raptor: первая реализация — кошмар, вторая — лучше, третья — masterpiece. То же самое происходит с кодом. «Если вы унесёте из доклада одну вещь, я хочу, чтобы вы унесли картиночку с Raptor». Перепрошивка подхода: не маленькое и качественное, а грубое → рабочее → production. Три итерации надо закладывать в бюджеты.
[0:25] 📊 Критичность систем: матрица 3×3
Две оси: стадия (альфа/бета/прод) и уровень подсистемы (life-saving/важные/вспомогательные). «Вот это вот Tier 3, вспомогательная, в альфе — сделай как-нибудь. Мне бы хотя бы понять, нравится ли это». Генерация кода одинакова для всех квадрантов, валидация — радикально разная.
[0:30] 🔍 OpenSpec: два рабочих режима — Explore и New
Explore — для моментов «ни черта не знаю, что хочу делать». Rubber duck + deep research: чатишься полчаса-час, LLM гуглит, смотрит код, находит индустриальные решения. Потом весь контекст ужимается в один пропозал — стартуешь новый чат без багажа. New — стандартный pipeline: proposal → design → tasks → apply. «Забывать — очень хороший скилл».
[0:38] 🛠️ Кастомизация OpenSpec: Inventory и Data Model шаги
Добавили два новых шага в OpenSpec-схему. Inventory — перед реализацией найди весь релевантный код, борьба с проблемой «LLM не нашла существующий функционал и написала заново». Data Model — отдельный этап для модели данных. Поймали кейс, где LLM добавила восемь столбцов вместо двух строк. «У меня даже джуны такую дичь не творили». Ключевое: в OpenSpec шаги — это граф, не последовательность. Inventory и Data Model запускаются параллельно.
[0:45] 📝 PR-FAQ: кастомная схема в стиле Amazon
Кастомная OpenSpec-схема в формате Amazon PR-FAQ: пресс-релиз, FAQ, демо-скрипт, маркетинг-брифинг. Каждая фича автоматически получает маркетинговый артефакт, который можно положить на сайт. «Как получилось, что на сайте куча всего? Да вот так вот, очень просто». Merchant Critic — скилл, который оценивает пропозал по восьми категориям (ценность, проактивность, revenue impact) и добавляет противоположное знание в контекст.
[0:55] 🧪 Валидация: где на самом деле падают системы
Код ревью — зачем? Два ответа: коллективное знание и консистентность решений. Но падает не на код ревью. Падает в проде — перформанс, дистрибуция данных, позитивный feedback loop (одна часть тянет за собой другие). Silent data corruption. «Кожаный мешок» — это постоянный процесс». Качество кода отпущено в Tier 2-3 зонах: «Я бы за это два года назад уволил. Сейчас — нормально».
[1:05] 🔄 Дубликаты: враг номер один в AI-разработке
Из 10K строк фичи — 1.5K дубликатов. «Если с этим не работать, код разрастается, продуктивность радуется, а на самом деле пять реализаций одного и того же». LLM фантастически любит копипастить — «китайский метод распространения ошибок». Еженедельные скиллы: дубликаты, связанность кода (файлы по 5000 строк), security checks, coverage. LLM ленива — пропускает файлы, если «размер показывает то же самое».
[1:12] 🧬 Код деградирует быстро — «тут так принято» в обе стороны
LLM читает код и копирует паттерны. Плохой паттерн в существующем коде → LLM повторит, несмотря на rules. Метафора Challenger: структурный риск, все знали про O-rings, запускали много раз — работало. 28 января не пронесло. «Ваши инвестиции в чистоту кода работают на то, чтобы эта штука слушалась правил». Скиллы проверки: связанность, security, unauthenticated routes.
[1:18] 🧪 LLM врут в тестах и предлагают ручное тестирование
LLM переписывает тесты, чтобы получить нужный результат. Единственный вариант — хешировать тест-кейсы и отслеживать мутации. Multi-step workflow — новая зона разрушения: ошибки на уровне взаимодействия пользователей с разными правами. «Всё сделал. E2E тесты — руками. — Нет! Иди делай на Playwright!»
[1:22] 🛡️ Error budget и maintenance
Maintenance надо планировать, иначе система планирует за вас (звонком от клиента в 8 утра). Каждый месяц — bugbash. Error budget: две ошибки в прод — стоп. Когда перестал фичи писать, пошёл баги фиксить — «кредиты простаивают, но хотя бы не создаём новых проблем». Средний перформанс: 5K строк/день (хороший день — 10K, упоротый — 35K). Скиллы регулярно обновляются ретро-форматом.
[1:28] 🏗️ Brownfield: как запустить OpenSpec на legacy
Ретроактивный режим: LLM всё равно, из текста в код или из кода в текст. Взяли код → сгенерировали спеки → переписали по спекам → сравнили тестами. Начинай с Tier 3 функциональности: admin tool, customer support, бета-фича. «Не нужно всю систему покрыть — кушайте по кусочкам. Покажите результат скептикам — распространение пойдёт натурально, снизу вверх». Git submodules в readonly для межрепозиторного контекста. Три репозитория по use case, фронтенд и бэкенд — в одном.
Q&A: Вопросы и ответы
🔍 Качество кода 🔗
Как определить, что код плохой? Кто не понимал — вы или AI?
Не столько качество самого кода, сколько запутанность инженерного решения. Код может работать, не падать, но user flow запутанный: восемь кнопок в разных местах вместо одного flow. Код нормальный (примерно как у Claude Code), но архитектурные решения — как Raptor 1.
Классическая проблема: «деливерим нашу организационную структуру клиенту в виде менюшки». Разные менюшки — потому что разные команды делали. С AI этот паттерн воспроизводится ещё быстрее.
Были ли случаи, когда из-за новых фичей система из Raptor 3 превращалась в Raptor 1?
Постоянно. Это неизбежный процесс любой системы — добавляешь сложности, она деградирует. Раньше переписывание занимало кварталы и годы: три месяца реализации, ещё три месяца клиенты пользуются, через год — переделка. Сейчас — цикл в две недели. Надо чаще делать зачистки.
⚙️ Рабочий процесс 🔗
Какие модели и с каким reasoning используете для каждого этапа?
На всё используем Opus 4.6. Безлимитные подписки по $200/чел. Хватает. В токенах — примерно $5-6K/чел в месяц. Неделю назад начали закручивать лимиты, но пока укладываемся.
Как правите пропозал, если не нравится?
Просто в чате пишем, что не так. LLM переделывает. Иногда заходишь в таски, видишь проблему — говоришь «переделывай». Руками документы OpenSpec не правим — нет необходимости. Быстрее сказать чату, он переделает. Всё это итеративно, можно возвращаться на любой шаг.
Как определили оптимальный размер спеки?
Эмпирически. Увеличиваешь размер, пробуешь, понимаешь что день потрачен впустую, стираешь, начинаешь заново. Сейчас: одна спека ≈ 2-2.5K строк кода. Если больше — разбивка на 4-5 спек.
Сколько времени на ревью?
Минут 20-30. Многое ревьюит AI через скиллы. В Tier 2-3 зонах качество кода отпущено — главное, чтобы не разваливалось и базовые кейсы покрыты.
🟤 Brownfield и организация 🔗
Где и в какой форме хранить discovery-документацию?
Отдельный репозиторий для звонков с клиентами. Оттуда дистиллируются маркетинговые вещи и roadmap. Ручками копируются в реализацию, когда нужно. Идея совместить была, но «иногда меньше контекста лучше». Merchant Critic информирован клиентским фидбэком — первая версия была из головы, вторая — из реальных разговоров.
Проект в трёх репозиториях — ехать в монорепу?
Три репо, разделены по use case. Git submodules в readonly для контекста. Frontend и backend — в одном репо (изменения целиком). «Микросервисы здорового человека»: один на 500K строк, второй на 100K, третий на 50K. Каждый с понятным use case, персоной, скопом ответственности.