SDD+ фреймворки против хаоса: Spek-Kit, OpenSpec и Kiro — кто наведет порядок в вашем AI-проекте?

Проблема: ваш AI-ассистент превратился в золотую рыбку

Вы начинаете новый проект с Cursor или Claude Code. Первые недели — магия. ИИ генерирует код, вспоминает контекст, предлагает гениальные решения. Потом проект растет. Появляется 50 файлов, 3 разных архитектуры (потому что вы меняли мнение), 10 недокументированных API. И ваш когда-то умный ассистент начинает спрашивать: "А что это за функция process_data()?" и "Какой формат должен возвращать этот эндпоинт?".

Вы платите за контекстное окно в 128к токенов, но ИИ все равно забывает. Это не баг — это фундаментальная проблема того, что я называю вайбкодинг: разработка через поток сознания без структуры.

Решение: SDD+ — это не просто мода, это выживание

Spec-Driven Development плюс — это следующий шаг после обычного SDD. Если SDD заставляет вас писать спецификации для людей, то SDD+ делает их машиночитаемыми и исполняемыми для ИИ.

Зачем? Потому что ИИ-ассистенты — не люди. Они не "понимают" проект интуитивно. Им нужна явная, структурированная, постоянно доступная память. Без нее вы просто переплачиваете за повторное обучение модели на каждом сеансе.

Три претендента на трон: краткий разбор

На рынке сейчас три основных игрока, каждый со своей философией. Давайте без воды — только факты и личный опыт.

Spek-Kit: для тех, кто любит контроль (и страдает от перфекционизма)

Spek-Kit — это военный устав для вашего проекта. Вы определяете все: от структуры API до формата ошибок, от naming conventions до лимитов rate limiting.

Установка проще некуда:

npm install -g spek-kit
# Или через pip, если используете Python
pip install spek-kit

Базовый пример спецификации:

project:
  name: "user-management-service"
  version: "1.0.0"

api:
  endpoints:
    - path: "/users"
      method: "POST"
      request:
        schema:
          type: "object"
          properties:
            email: { type: "string", format: "email" }
            name: { type: "string", minLength: 2 }
      response:
        success:
          status: 201
          schema:
            id: { type: "string" }
            created_at: { type: "string", format: "date-time" }

Сила Spek-Kit в том, что эту спецификацию можно использовать для:

• Генерации кода (сервер, клиент, типы TypeScript)
• Валидации в runtime
• Документации (автоматически)
• Тестирования (контрактное тестирование)

Но есть и обратная сторона: вы становитесь заложником своей же спецификации. Любое изменение требует обновления YAML-файла. Для быстрого прототипирования это убийственно.

OpenSpec: умная память, которая не забывает

Если Spek-Kit — это устав, то OpenSpec — это умный секретарь, который следит за всем проектом и шепчет контекст ИИ на ухо.

Основная проблема, которую решает OpenSpec, — амнезия AI-ассистентов. Вместо того чтобы загружать весь контекст в промпт (и платить за токены), OpenSpec создает "memory bank" — базу знаний о проекте, которая динамически обновляется.

Установка:

# Клонируем репозиторий
git clone https://github.com/openspec/openspec.git
cd openspec
pip install -e .

Конфигурация в .openspec/config.yaml:

memory:
  storage: "chroma"  # или pinecone, qdrant
  embedding_model: "text-embedding-3-small"
  update_strategy: "on_change"  # или scheduled, manual

context:
  include_patterns:
    - "**/*.py"
    - "**/*.js"
    - "**/*.md"
    - "architecture.md"
  exclude_patterns:
    - "**/node_modules/**"
    - "**/.git/**"

Как это работает? OpenSpec мониторит изменения в файлах, создает embedding'ы для важных частей кода и документации, и когда ИИ задает вопрос вроде "Как работает аутентификация?", фреймворк находит релевантные фрагменты и инжектит их в промпт.

Результат: ИИ "помнит" проект даже через месяц простоя. Вы экономите на контекстном окне и получаете более релевантные ответы.

Kiro: ленивый гений

Kiro для тех, кто ненавидит писать документацию, но понимает, что без нее ИИ бесполезен. Его подход: "Дайте мне код, а спецификации я напишу сам".

Установка через Cursor (он родной для Kiro):

cursor://install-extension?id=kiro.spec-generator

Или через CLI:

curl -fsSL https://kiro.dev/install.sh | bash

Kiro анализирует ваш код и генерирует спецификации автоматически. Написали функцию?

def calculate_invoice_total(items: List[Item], tax_rate: float) -> float:
    subtotal = sum(item.price * item.quantity for item in items)
    return subtotal * (1 + tax_rate)

Kiro сгенерирует:

function:
  name: calculate_invoice_total
  inputs:
    - name: items
      type: List[Item]
      description: "Список товаров в инвойсе"
    - name: tax_rate
      type: float
      description: "Ставка налога (например, 0.2 для 20%)"
  output:
    type: float
    description: "Общая сумма с налогом"
  behavior: "Вычисляет сумму товаров и применяет налог"

Потом эту спецификацию можно использовать для:

• Объяснения кода новым разработчикам (или ИИ)
• Генерации тестов
• Поиска похожих функций в проекте

Проблема Kiro в точности. Автоматически сгенерированные спецификации иногда упускают нюансы бизнес-логики. Но для больших legacy-проектов, где документации нет вообще, это спасение.

Сравнительная таблица: какой фреймворк когда выбирать

Гибридный подход: как я комбинирую фреймворки

После месяцев экспериментов пришел к гибридной схеме:

1. Начинаю с Kiro — чтобы быстро получить первую версию спецификаций из существующего кода или прототипа.
2. Дорабатываю в Spek-Kit — добавляю бизнес-правила, валидации, документацию, которую Kiro упустил.
3. Подключаю OpenSpec — как memory bank для всей получившейся документации и кода.

Пример конфигурации гибридного проекта:

# .ai-project.yaml
workflow:
  - tool: kiro
    pattern: "**/*.py"
    output: ".specs/auto-generated/"
  
  - tool: spek-kit
    specs:
      - ".specs/auto-generated/**/*.yaml"
      - ".specs/manual/**/*.yaml"
    output: ".specs/compiled/project-spec.yaml"
  
  - tool: openspec
    memory_source: ".specs/compiled/project-spec.yaml"
    code_source: "."
    config: ".openspec/config.yaml"

Такая комбинация дает лучшее от всех миров: автоматизацию Kiro, точность Spek-Kit и память OpenSpec.

Чего не хватает всем фреймворкам (и что появится в 2026)

Текущее поколение SDD+ фреймворков решает проблему памяти и структуры, но упускает важные аспекты:

• Мультимодальность — спецификации только для кода, а что про дизайн, архитектурные схемы, скриншоты интерфейсов? Мультимодальные модели уже здесь, но фреймворки их не используют.
• Версионирование спецификаций — код версионируется в Git, а спецификации? Как откатиться к прошлой версии API definition?
• Коллаборация — несколько ИИ-ассистентов над одним проектом (один пишет бэкенд, другой — фронтенд) не могут синхронизировать свои memory banks.

Мой прогноз: следующий шаг — "Project Nervous System", где фреймворк становится центральной нервной системой проекта, соединяя код, документацию, дизайн, деплойменты и даже communication между разработчиками.

FAQ: ответы на частые вопросы

Какой фреймворк выбрать для стартапа из 2 человек?

OpenSpec. Он требует меньше всего обслуживания и сразу решает главную проблему — потерю контекста. Когда проект вырастет до 10к+ строк, добавите Spek-Kit для структуры.

Можно ли использовать SDD+ фреймворки с локальными LLM?

Да, и это даже эффективнее. Локальные модели имеют ограниченное контекстное окно, поэтому умный подбор релевантного контекста (как в OpenSpec) критически важен.

Стоит ли учить всю команду работать с этими фреймворками?

Начните с одного человека — того, кто больше всего работает с ИИ-ассистентами. Пусть он настроит pipeline, а остальные будут просто пользоваться результатами. Документация будет всегда актуальной, код — согласованным.

Что делать, если фреймворк сгенерировал неправильную спецификацию?

Все фреймворки позволяют ручное редактирование. Kiro — через комментирование кода, Spek-Kit — через прямое редактирование YAML, OpenSpec — через веб-интерфейс. Главное правило: спецификация важнее кода. Сначала исправьте спецификацию, потом перегенерируйте код.