Твой ИИ-ассистент тупеет каждую минуту

Недавно наткнулся на интересный подход к разработке с ИИ-помощниками под названием GSD (“Get Shit Done”). И знаете что? Он решает проблему, с которой я сталкиваюсь постоянно: когда долго общаешься с Claude или GPT в одном чате, модель начинает “съезжать” и забывать важные детали. Классическая проблема context rot - деградация качества по мере заполнения окна контекста.

Как архитектор, я часто использую ИИ для генерации кода, но всегда испытываю фрустрацию: начинаешь с четких требований, через час получаешь кашу из противоречивых решений. GSD предлагает радикальное решение: перестать относиться к чату как к системе сборки проекта.

Context rot - боль всех разработчиков

Давайте честно: мы все проходили через это. Начинаешь проект с ИИ-ассистентом, первые итерации - огонь. Модель точно понимает архитектуру, следует паттернам, пишет чистый код. А через несколько часов работы получаешь:

• Long-session drift - агент медленно забывает изначальные ограничения
• Invisible decision loss - вы договорились о паттерне, но агент перестает ему следовать
• Unreviewable diffs - один гигантский коммит без пояснений и точек отката
• Fake progress - много кода, мало работающего продукта

Звучит знакомо? У меня таких сессий было предостаточно. По моему опыту, особенно болезненно, когда проект близок к финишу, а потом выясняется, что половина кода написана с нарушением архитектурных принципов, о которых говорили в начале.

Что такое GSD и почему это не просто очередная обертка

GSD - это не просто обертка над Claude или GPT. Это целая философия spec-driven разработки, которая решает проблему context rot через:

1. Externalized state - вся память системы выносится в файлы
2. Fresh contexts - каждая задача выполняется в чистом контексте
3. Atomic commits - каждый коммит привязан к одной атомарной задаче
4. Explicit verification - каждый этап имеет четкие критерии проверки

По сути, это система оркестрации ИИ-агентов с жесткой дисциплиной по управлению контекстом.

Установка и первые шаги

Начинается все просто:

npx get-shit-done-cc@latest

Инсталлятор поддерживает Claude Code, OpenCode, Gemini CLI, и Codex. Для Claude Code рекомендуется запуск с флагом:

claude --dangerously-skip-permissions

Да, название флага говорящее. Это компромисс между безопасностью и продуктивностью - тема для отдельного разговора.

Фазы разработки: discuss → plan → execute → verify

Самое интересное в GSD - четкая структура процесса. Каждый этап имеет конкретную цель и артефакты.

1. Initialize - создание костяка проекта

/gsd:new-project

Система задает вопросы, понимает идею проекта и создает базовые артефакты:

• PROJECT.md - видение проекта
• REQUIREMENTS.md - требования с разделением на v1/v2
• ROADMAP.md - план фаз разработки
• STATE.md - текущие решения и блокеры

Для существующих проектов есть команда /gsd:map-codebase, которая анализирует архитектуру и конвенции кода.

2. Discuss Phase - недооцененный этап

Вот здесь кроется главная фишка GSD. Перед планированием идет фаза обсуждения:

/gsd:discuss-phase 1

Система явно выделяет серые зоны, которые обычно приводят к недопониманию:

• Визуальные особенности: плотность компоновки, интерактивность, пустые состояния
• API/CLI: формат ответов, флаги, обработка ошибок, уровень детализации
• Контентные системы: структура, тон, глубина проработки
• Организационные задачи: критерии группировки, именование, дубликаты

Результат - файл {phase}-CONTEXT.md, который питает исследователя и планировщика.

Если честно, это золото! Сколько проектов я видел, где разработчик и ИИ говорили на разных языках именно из-за недопроговоренных деталей.

3. Plan Phase - структурирование работы

/gsd:plan-phase 1

Планирование включает три этапа:

1. Research - исследование на основе контекста фазы
2. Plan creation - создание 2-3 атомарных задач
3. Plan verification - проверка планов до успеха, но не больше лимита

Планы описываются в XML-формате:

<task type="auto">
  <name>Create login endpoint</name>
  <files>src/app/api/auth/login/route.ts</files>
  <action>
    Use jose for JWT (not jsonwebtoken - CommonJS issues).
    Validate credentials against users table.
    Return httpOnly cookie on success.
  </action>
  <verify>curl -X POST localhost:3000/api/auth/login returns 200 + Set-Cookie</verify>
  <done>Valid credentials return cookie, invalid return 401</done>
</task>

Это убирает двусмысленность и дает четкие критерии готовности.

4. Execute Phase - свежий контекст для каждой задачи

/gsd:execute-phase 1

Выполнение организовано волнами с учетом зависимостей:

┌─────────────────────────────────────────────────────────────────────┐
│  PHASE EXECUTION                                                    │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  WAVE 1 (parallel)          WAVE 2 (parallel)          WAVE 3       │
│  ┌─────────┐ ┌─────────┐    ┌─────────┐ ┌─────────┐    ┌─────────┐  │
│  │ Plan 01 │ │ Plan 02 │ →  │ Plan 03 │ │ Plan 04 │ →  │ Plan 05 │  │
│  │    ↑    │ │    ↑    │    │    ↑    │ │    ↑    │    │    ↑    │  │
│  │ User    │ │ Product │    │ Orders  │ │ Cart    │    │ Checkout│  │
│  │ Model   │ │ Model   │    │ API     │ │ API     │    │ UI      │  │
│  └─────────┘ └─────────┘    └─────────┘ └─────────┘    └─────────┘  │
│       │           │              ↑           ↑              ↑       │
│       └───────────┴──────────────┴───────────┘              │       │
│                                                              │       │
│       Dependencies: 01,02 → 03,04 → 05                      │       │
└─────────────────────────────────────────────────────────────────────┘

Ключевое: каждый план выполняется в свежем контексте, что исключает накопление “мусора” в памяти модели.

5. Verify Phase - ручное тестирование с поддержкой

/gsd:verify-work 1

Система извлекает тестируемые результаты и проводит вас через проверку каждого (“Можете ли вы войти с email?”). При обнаружении проблем запускаются debug-агенты для создания планов исправления.

Nyquist Validation - спорная но интересная идея

Одна из самых интригующих концепций GSD - Nyquist validation. Во время исследования планов система может создать карту автоматизированного тестового покрытия для каждого требования до написания кода, создавая файл {phase}-VALIDATION.md с контрактом обратной связи.

План-чекер считает отсутствие команд верификации условием провала.

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

Конфигурация: от YOLO до production-ready

GSD позволяет настроить процесс под разные сценарии. Стандартная конфигурация:

{
  "mode": "interactive",
  "depth": "standard",
  "model_profile": "balanced",
  "workflow": {
    "research": true,
    "plan_check": true,
    "verifier": true,
    "nyquist_validation": true
  },
  "planning": {
    "commit_docs": true,
    "search_gitignored": false
  },
  "git": {
    "branching_strategy": "none"
  }
}

А для быстрого прототипирования:

{
  "mode": "yolo",
  "depth": "quick",
  "model_profile": "budget",
  "workflow": {
    "research": false,
    "plan_check": false,
    "verifier": false,
    "nyquist_validation": false
  },
  "planning": {
    "commit_docs": false
  }
}

Quick mode для ad-hoc задач

Для разовых задач есть режим /gsd:quick, который дает гарантии (отслеживание состояния, атомарные коммиты) без полного цикла исследование→план→проверка→верификация.

Что реально полезно, а что вызывает сомнения

Полезно:

• Атомарные коммиты - git bisect становится суперсилой для отладки
• Файловая система артефактов - код становится обозримым и ревьюируемым
• Фаза discuss - решает большинство проблем недопонимания с ИИ
• Свежий контекст - качество кода не деградирует со временем

Спорно:

• Накладные расходы планирования - много артефактов для простых задач
• Безопасность - флаг --dangerously-skip-permissions говорит сам за себя
• Кривая обучения - нужно время, чтобы освоить всю систему команд

Откровенно сомнительно:

• Генерация документации в git - может быть как фичей, так и проблемой для истории
• Жесткая структура - не всегда подходит для исследовательских проектов

Философский вопрос: кто вы?

GSD заставляет задуматься о фундаментальном вопросе: кто вы в отношениях с ИИ?

Вариант 1: Разработчик, который чатится с инструментом Вариант 2: Разработчик, который управляет системой сборки с недетерминированным генератором кода

GSD исходит из второго варианта. Отсюда кажущаяся “тяжеловесность” по сравнению с простым промптом, но и большая надежность по сравнению с сырым чатом.

Практические выводы

В эпоху ИИ-ассистентов нужны новые инженерные практики. Классические принципы остаются актуальными:

• Короткие циклы обратной связи
• Явная верификация
• Атомарные изменения
• Трассируемость решений

GSD - попытка адаптировать эти принципы к реалиям работы с ИИ. Стоит ли использовать именно GSD? Зависит от проекта. Но идеи, которые он продвигает, точно стоят внимания:

1. Контекст - исчерпаемый ресурс
2. Память должна жить в файлах, а не в чате
3. Работу нужно резать под размер свежего контекста
4. Верификация должна быть привязана к задачам
5. История git - часть наблюдаемости системы

Если вы серьезно работаете с ИИ-помощниками в разработке, эти принципы помогут избежать многих граблей. А GSD - один из инструментов, который делает их применение систематическим.

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

---

Оригинальная статья: GET SH*T DONE: Meta-prompting and Spec-driven Development for Claude Code and Codex

---

Читайте также

• Agentic Reality Check: только 11% компаний используют AI-агентов в рабочей среде
• AI-инференс и cloud-native: Kubernetes как центр ИИ
• Amazon и OpenAI: $50 млрд и архитектура AI-агентов