Сіздің ИИ-көмекшіңіз әр минут сайын нашарлайды

Жақында GSD (“Get Shit Done”) деп аталатын ИИ-көмекшілермен жасақтауға арналған қызық тәсілге кездестім. Білесіз бе? Ол мені үнемі кездестіретін мәселені шешеді: бір чатта Claude немесе GPT-мен ұзақ қарым-қатынас жасағанда, модель “дәйексіз” болып, маңызды мәліметтерді ұмытып кетеді. Классикалық context rot мәселесі - контекст терезесі толған сайын сападың төмендеуі.

Архитектор ретінде мен ИИ-ды код генерациясы үшін жиі қолданамын, бірақ әрқашан қарсылыққа кезігемін: анық талаптармен бастайсың, бір сағаттан кейін қайшылықты шешімдердің қотанын аласың. GSD радикалды шешімді ұсынады: чатты жоба құрастыру жүйесі ретінде қарауды тоқтату.

Context rot - барлық разработчиктердің ауруы

Шынын айтсақ: біз барымыз осыдан өттік. ИИ-көмекшісімен жобаны бастайсың, алғашқы итерациялар - өте жақсы. Модель архитектураны дәл түсінеді, паттерндерді ұстанады, таза код жазады. Ал бірнеше сағаттан кейін мынаны аласың:

• Long-session drift - агент бастапқы шектеулерді баяу ұмытады
• Invisible decision loss - паттерн туралы келістіңдер, бірақ агент оны ұстануды тоқтатады
• Unreviewable diffs - түсіндірмесіз және кері қайтаруға болмайтын бір алып коммит
• Fake progress - көп код, аз жұмыс істейтін өнім

Таныс естіледі ме? Менде мұндай сессиялар көп болды. Менің тәжірибем бойынша, жоба аяқталуға жақын болғанда, содан кейін кодтың жартысы бастапқыда айтылған архитектуралық принциптерді бұза отырып жазылғандығы анықталғанда әсіресе ауыр болады.

GSD дегеніміз не және бұл кезекті wrapper емес неліктен

GSD - бұл Claude немесе GPT үстіндегі қарапайым wrapper емес. Бұл context rot мәселесін мына арқылы шешетін spec-driven разработканың толық философиясы:

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
  }
}

Ad-hoc тапсырмалар үшін Quick mode

Бір реттік тапсырмалар үшін толық зерттеу→жоспар→тексеру→верификация циклісіз кепілдіктер (күй бақылау, атомдық коммиттер) беретін /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