GSD (Get Shit Done) — подробный разбор

GSD или Get Shit Done – это слой оркестрации для AI-разработки, который ставится поверх Claude Code, Codex, Gemini CLI и других AI окружений разработки.

Его задача – превращать работу с ИИ-моделью в более управляемый инженерный процесс.

Если описывать GSD одной фразой, то это система, которая берет сырую идею, превращает ее в требования, разбивает проект на фазы, планирует исполнение и пытается довести результат до рабочего состояния без того хаоса, который обычно возникает в длинных AI-сессиях.

После первого использования мы в команде быстро сошлись во мнении, что GSD заметно упрощает разработку крупных проектов:

• помогает сдвинуть с места зависшие проекты
• делает этапы разработки более понятными и прозрачными
• позволяет без лишних усилий возвращаться к проекту даже спустя недели
• переводит мысль из головы в четкую и понятную для ИИ задачу

Почти любая разработка с помощью ИИ имеет одну и ту же проблему: модель может быть очень сильной на короткой дистанции, но по мере роста проекта начинает терять качество.

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

GSD называет это context rot – деградацией качества из-за переполненного или зашумленного контекста.

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

Однако, context rot – только половина проблемы. Вторая половина в том, что обычный вайбкодинг часто начинается сразу с команды «сделай мне проект, с такой-то идеей», а дальше идет длинная цепочка импровизаций. Где-то по пути теряются границы задачи, забываются какие решения были приняты пользователем, а какие модель додумала.

GSD закрывает и этот пробел, создавая вокруг проекта набор постоянных артефактов: видение, требования, дорожная карта, состояние проекта, планы, результаты и верификацию.

Принцип работы

GSD превращает разработку в последовательный цикл:

• сначала он помогает собрать и прояснить замысел проекта
• затем формирует требования и дорожную карту
• после этого разбивает проект на фазы, а каждую фазу – на маленькие исполнимые задачи
• дальше эти задачи могут выполняться отдельными агентами, с проверкой, фиксацией состояния и атомарными коммитами в Git

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

• где вы находитесь
• что уже решено
• что осталось
• какие есть блокеры
• какая логика стоит за структурой проекта

Именно такую систему навигации GSD и пытается дать.

Разработка на основе спецификаций

Классические модели состоят из сессий, память между которыми контролируется пользователем через различные плагины или методы переноса контекста. Это требует множество действий и промптов чтобы передать идею разработки.

Система GSD самостоятельно определяет, что именно строится, какие есть границы, что входит в первую версию, а что остается за рамками.

Оркестрация субагентов

Это также доступно и с классическими моделями, но тоже требует первоначальной настройки.

Вам не надо самостоятельно создавать агентов под задачи, GSD разделяет роли из коробки:

• исследователи изучают стек, фичи, риски и архитектуру
• планировщик формирует задачи
• проверяющий валидирует план
• исполнители пишут код
• валидатор сверяет результат с целями фазы

Контроль контекста

GSD очень серьезно относится к контексту. Много внимания уделяется тому, какие документы читаются перед командой, что считается памятью проекта и как не заполнить контекст лишними данными.

Атомарность задач

Если задача слишком большая для одного качественного контекстного окна, ее нужно дробить.

Это один из самых практичных принципов GSD: если модель не может стабильно сделать часть задачи за один проход, значит эта задача слишком длинная и она будет разделена на более мелкие.

При работе с GSD в папке проекта создается достаточно много .md-файлов, которые являются неотъемлемой частью GSD.

Он выносит память проекта из головы пользователя и из истории чата в файловую структуру.

Ключевые артефакты выглядят так:

• PROJECT.md – видение проекта
• REQUIREMENTS.md – требования и рамки
• ROADMAP.md – фазы проекта
• STATE.md – текущее положение, решения и блокеры
• CONTEXT.md – контекст по фазе
• RESEARCH.md – исследование перед планом
• PLAN.md – атомарные исполнимые задачи
• SUMMARY.md – история выполненной работы
• VALIDATION.md – связь между требованиями и результатом

Именно поэтому GSD полезен при возвращении к проекту спустя любое время после начала разработки.

Использование XML-планов

Одна из интересных особенностей GSD – использование структурированных XML-подобных планов вместо markdown-описания.

<Image id="001">
    <FileName>street_view_04.jpg</FileName>
    <Resolution width="1920" height="1080" />
    
    <!-- Аннотации объектов для компьютерного зрения -->
    <Annotations>
        <Object label="Car">
            <BndBox xmin="150" ymin="400" xmax="320" ymax="550" />
            <Confidence score="0.98" />
        </Object>
        
        <Object label="Pedestrian">
            <BndBox xmin="450" ymin="380" xmax="480" ymax="520" />
            <Confidence score="0.85" />
        </Object>
    </Annotations>
    
    <Metadata>
        <CaptureDate>2024-05-15</CaptureDate>
        <Weather>Sunny</Weather>
    </Metadata>
</Image>

<!-- Настройки гиперпараметров модели -->
<TrainingSettings>
    <ModelArchitecture>YOLOv8</ModelArchitecture>
    <LearningRate>0.001</LearningRate>
    <Epochs>50</Epochs>
    <BatchSize>16</BatchSize>
</TrainingSettings>

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

XML удобен в ИИ потому что:

1. Удобно вкладывать объекты (аннотации) внутрь конкретных изображений
2. Разработчик может легко открыть файл и проверить, правильно ли размечены координаты объектов
3. Многие инструменты разметки (например, LabelImg) сохраняют данные именно в формате Pascal VOC XML, который является стандартом в компьютерном зрении

На практике это уменьшает число ситуаций, когда модель модель может неправильно понять задачу. Для GSD это важно, потому что он строится на повторяемом рабочем процессе.

• Репозиторий проекта
• Команда установки: npx get-shit-done-cc@latest

Проект требует Node.js 22+ и поддерживает разные ИИ-модели и IDE.

Установщик позволяет выбрать, под что именно ставить GSD и делать это глобально или локально (для всего устройства или только в определенном проекте).

Установка занимает буквально несколько минут. После этого установятся необхоимые skills, agents и тд.

В зависимости от выбранного IDE, вы его открываете и можете передавать команды.

Для различных IDE команды могут отличаться, так например в Claude Code используется "/", в Codex используется "$"

После установки базовый рабочий цикл выглядит так:

$gsd-new-project
$gsd-discuss-phase 1
$gsd-ui-phase 1
$gsd-plan-phase 1
$gsd-execute-phase 1
$gsd-verify-work 1
$gsd-ship 1

Если проект уже существует и требуется его обновить/улучшить, то лучше всего начать с изучения текущего проекта:

$gsd-map-codebase
$gsd-new-project

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

Процесс создания проекта

Работа GSD представлена на примере разработки landing-страницы. Для этого GSD избыточен, поэтому используется только в качестве демонстрации.

1. Создать проект, передать что разрабатывается

На этом этапе система:

• задает вопросы
• уточняет цели и ограничения
• при необходимости запускает исследование
• формирует базовые документы проекта
• строит roadmap по фазам

2. После сбора достаточного количества контекста, GSD приступает к созданию PROJECT.md

На этом же этапе появляются REQUIREMENTS.md, ROADMAP.md, STATE.md и исследовательские артефакты.

3. Квиз по формату workflow

4. GSD инициализирует проект и готов к работе над ним

Отправляем команду $gsd-discuss-phase 1 , GSD спросит как действовать по плану и здесь продолжается разработка.

Работа с конкретной фазой

$gsd-discuss-phase 1

Эта команда нужна для того, чтобы не дать системе самой додумать важные детали. Roadmap почти всегда слишком общий: там есть только краткая формулировка этапа, но нет точного понимания, как именно пользователь хочет это реализовать. На этапе discuss-phase GSD уточняет серые зоны и создает CONTEXT.md, который потом читают исследователи и планировщики.

Таким образом, вам довольно понятно объясняют что делают, вы почти на каждом этапе передаете свои мысли, развиваете и контролируете проект.

Если фаза связана с интерфейсом, можно отдельно прогнать:

$gsd-ui-phase 1

Это шаг, где заранее фиксируется дизайн-контракт, чтобы фронтенд не разделился с бекендом.

Планирование

$gsd-plan-phase 1

Здесь система:

• исследует реализацию
• собирает материалы
• строит несколько атомарных планов
• проверяет их на адекватность

В результате появляются RESEARCH.md (если функция была включена на этапе квиза) и набор PLAN.md, где работа описана как маленькие конкретные задачи с проверками.

Исполнение

$gsd-execute-phase 1

На этом этапе GSD:

• раскладывает задачи по зависимостям
• исполняет независимые части параллельно
• зависимые запускает последовательно
• дает каждому исполнителю свежий контекст
• делает атомарные git-коммиты

Проверка

$gsd-verify-work 1

Здесь система помогает понять, соответствует ли результат цели фазы. На более зрелом уровне workflow это может дополняться validation-логикой, тестовым покрытием и аудитом целей.

Где использовать GSD

GSD особенно силен там, где проект выходит за пределы одной-двух сессий. Если нужно собрать MVP с нуля, провести длинную работу, удерживать требования и не потерять архитектурную нить, он действительно может дать заметный прирост надежности.

Основные сценарии использования:

• запуск MVP с нуля
• большая фича в существующем продукте
• фронтенд, где важна визуальная целостность
• длинная работа с перерывами
• несколько параллельных направлений в одном проекте

Для соло-разработчиков это часто особенно ценно, потому что GSD частично берет на себя функции архитектора и координатора процесса.

Где GSD слаб или избыточен

Для лендингов, маленьких скриптов, мелких багфиксов и быстрых прототипов GSD избыточен. В таких задачах обычный Claude Code или Codex быстрее даст результат и с меньшими затратами.

Главный минус GSD – высокая цена, он:

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

То есть GSD – большой рабочий слой, поэтому вместе с качественной разработкой он приносит и новую сложность её управления.

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

Отличие от Claude Code и Codex

Обычный Claude Code или Codex выигрывает в скорости старта, дешевизне и простоте.

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

GSD устроен наоборот. Он проигрывает по скорости, зато выигрывает на длинной дистанции, когда важно не просто сгенерировать часть кода, а провести проект через несколько стадий и не потерять основную задачу.

Если упростить различие:

• вайбкодинг через CLI или расширение – быстрее и проще
• GSD – медленнее, дороже, но лучше разрабатывает большой проект

Поэтому выбирать между ними нужно не по критерию что дешевле или быстрее, а по типу задачи.

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

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

GSD – заставляет сначала формулировать, затем планировать и исполнять маленькими кусками.

• GSD про управляемость
• про уменьшение вероятности потерять развитие проекта
• для простых задач он часто избыточен
• для длинных и структурных проектов его подход наиболее ценный