Spec-Driven Development: उत्पत्ति, पद्धति, टूल्स और हाइप जो नहीं बताता

tl;dr — SDD, AI एजेंट्स की एक वास्तविक समस्या का वैध जवाब है। अवधारणा समझ में आती है, टूल्स अपरिपक्व हैं, लागत अधिक है और ROI के साक्ष्य अभी भी लगभग पूरी तरह किस्से-कहानी जैसे हैं। इसे समझना ज़रूरी है। इस पर संदेह करना भी ज़रूरी है।

वह समस्या जिसने इस सबको जन्म दिया

यह समझने के लिए कि Spec-Driven Development क्यों उभरा, एक कदम पीछे जाना ज़रूरी है।

2025 में, Claude Code, Cursor और Codex जैसे AI एजेंट्स महज़ glorified autocomplete नहीं रहे — वे स्वायत्त रूप से जटिल कार्य करने लगे। इसी के साथ vibe coding का phenomenon सामने आया: आप प्राकृतिक भाषा में बताते हैं कि क्या चाहिए, एजेंट सैकड़ों लाइनें कोड जेनरेट करता है, और आप बिना पूरी तरह समझे उसे स्वीकार कर लेते हैं।

नतीजा? ऐसा कोड जो तब तक काम करता है जब तक उसे maintain नहीं करना पड़ता। अदृश्य architectural निर्णय। औद्योगिक गति से जमा होता technical debt।

इस विषय का सबसे कठोर अध्ययन — जो 2025 में METR ने वास्तविक open source प्रोजेक्ट्स पर अनुभवी डेवलपर्स के साथ किया — यह निष्कर्ष निकाला कि AI टूल्स का उपयोग करने वाले डेवलपर्स औसतन 19% धीमे थे, न कि तेज़। कारण: असंरचित prompts ने debugging loops बनाए जो कोड जेनरेशन में बचाए गए पूरे समय को खा गए।

Spec-Driven Development, उद्योग का इस समस्या को जड़ से हल करने का प्रयास है।

यह विचार कहाँ से आया

कोड लिखने से पहले specifications लिखने का विचार नया नहीं है। यह सॉफ्टवेयर इंजीनियरिंग जितना ही पुराना है।

1963: NASA के Apollo मिशन का सॉफ्टवेयर संभालने वाली Margaret Hamilton ने “software engineering” शब्द गढ़ा, क्योंकि प्रोग्राम इतने बड़े हो गए थे कि कोई भी उन्हें पूरी तरह समझ नहीं सकता था। उन्होंने महसूस किया: यह इंजीनियरिंग है, इसे प्रक्रिया की ज़रूरत है।

1968: NATO ने Berlin में एक सम्मेलन आयोजित किया जिसने औपचारिक रूप से Software Crisis को पहचाना: कंप्यूटर अब इतने जटिल प्रोग्राम की अनुमति देते थे जिन्हें ठीक से manage नहीं किया जा सकता था। कोड की मात्रा मानव की तर्क क्षमता से आगे निकल चुकी थी।

1972: Dijkstra ने अपने Turing Prize लेक्चर में सारांश दिया: “जब तक कोई मशीन नहीं थी, प्रोग्रामिंग कोई समस्या नहीं थी। जब हमारे पास कुछ कमज़ोर कंप्यूटर थे, प्रोग्रामिंग एक हल्की समस्या बन गई। अब हमारे पास विशाल कंप्यूटर हैं, और प्रोग्रामिंग उतनी ही विशाल समस्या बन गई है।”

उस समय का जवाब था प्रक्रिया: DoD मानक के रूप में Waterfall, फिर 2001 में Agile, फिर cloud पर CI/CD जिसने Agile को बड़े पैमाने पर संभव बनाया।

अब हम अगले चक्र में हैं। Drew Breunig, जो शोधकर्ता 2026 में SDD शब्द को लोकप्रिय बनाने में आगे रहे, ने सटीक वर्णन किया: “हमारी मौजूदा software crisis यह है कि हम उन जटिल codebases को manage नहीं कर पा रहे जो नए models सक्षम बना रहे हैं। पहले समस्या यह थी कि हम सारा कोड दिमाग में नहीं रख सकते थे। अब हम अपना सारा कोड पढ़ भी नहीं सकते।”

AI एजेंट्स Agile की गति पर Waterfall जितना volume सक्षम करते हैं। यही वह समस्या है जिसे SDD हल करने की कोशिश करता है।

Spec-Driven Development क्या है

SDD एक development methodology है जो specification को प्राथमिक artifact मानती है — कोड को नहीं।

पारंपरिक prompt → code → iteration cycle के बजाय, flow यह बन जाता है:

Spec → Plan → Tasks → Code

Spec, किसी भी implementation से पहले intent, constraints, acceptance criteria और architecture को परिभाषित करती है। AI एजेंट तब एक अस्पष्ट विवरण की व्याख्या करने के बजाय इस structured input के विरुद्ध execute करता है।

एक महत्वपूर्ण अंतर: Spec Kit, Kiro और Tessl जैसे टूल्स के साथ, spec स्वयं AI द्वारा जेनरेट की जाती है। आप प्राकृतिक भाषा में लक्ष्य बताते हैं, और एजेंट specification फ़ाइलें तैयार करता है — आमतौर पर requirements.md, design.md और tasks.md — जिन्हें वह implementation में context के रूप में स्वयं उपयोग करेगा। Spec वह दस्तावेज़ नहीं है जो analysts पहले से मैन्युअली लिखते हैं; यह developer और एजेंट के बीच conversation से उभरती है, कोड से पहले।

यह specifications के साथ क्लासिक समस्याओं के निदान को बदलता है: spec और code के बीच की दूरी अब हफ्तों या अलग-अलग teams की नहीं है। Spec और code एक ही cycle में, एक ही टूल द्वारा, कुछ मिनटों के अंतराल में जेनरेट होते हैं। जो समस्या बनी रहती है वह temporal separation नहीं है — बल्कि upfront काम, token की लागत, iterations के दौरान context का degradation, और वह जो deploy के बाद होता है जब वास्तविकता specified से diverge हो जाती है।

SDD adoption के विभिन्न स्तर हैं:

Spec-first: spec, implementation से पहले जेनरेट की जाती है और उस task के लिए guide के रूप में उपयोग की जाती है। पूरा होने के बाद, इसे discard कर दिया जाता है।

Spec-anchored: spec को task के बाद सिस्टम के future evolution और maintenance को guide करने के लिए maintain किया जाता है। यह एक living artifact है जो code के साथ चलती है।

Spec-as-source: सबसे महत्वाकांक्षी स्तर। Spec ही source code है। जेनरेट किया गया कोड spec का एक compiled artifact मात्र है, जिस पर // GENERATED FROM SPEC - DO NOT EDIT लिखा होता है। Tessl इसे व्यावहारिक बनाने की कोशिश कर रहा है।

SDD Triangle — और cycle उससे कठिन क्यों है जितना दिखता है

इस बहस में सबसे ईमानदार योगदान Breunig से मार्च 2026 में आया, whenwords प्रोजेक्ट (एक open source library जिसमें शून्य code था — केवल spec + 750 conformance tests) बनाने और यह देखने के बाद कि इसी तरह के अन्य projects कैसे विकसित हुए।

उनकी केंद्रीय सीख: SDD एक linear equation नहीं है। यह एक feedback cycle है।

वे SDD Triangle प्रस्तावित करते हैं: spec, tests और code तीन nodes हैं जिन्हें हर समय synchronized रहना होगा। जब code आगे बढ़ता है, spec को update करना होगा। जब spec बदलती है, नए tests लिखने होंगे। जब tests fail होते हैं, code को बदलना होगा — और कभी-कभी spec भी गलत थी।

समस्या यह है कि इन तीन nodes को synchronized रखना कठिन है:

• Specs लिखना कठिन है। वे कभी exhaustive नहीं होतीं और software के वास्तविक दुनिया से मिलने से पहले लिखी जाती हैं।
• Tests लिखना कठिन है। Agents से पहले भी, कोई tests लिखना पसंद नहीं करता था।
• Implementation के बाद specs और tests update करना overhead लगता है, खासकर जब आप agents का उपयोग exactly तेज़ी से आगे बढ़ने के लिए कर रहे हों।
• LLMs implementation के दौरान silent decisions लेते हैं। ये decisions शायद ही कभी spec में वापस जाती हैं।

व्यावहारिक परिणाम: spec लिखी जाती है, code जेनरेट होता है, product launch होता है। Spec दिनों में outdated हो जाती है। कोई इसे update करने नहीं लौटता। मूल समस्या — खोया हुआ intent, अदृश्य decisions — बस एक स्तर ऊपर migrate हो जाती है।

टूल्स का ecosystem

SDD टूल्स का space 2024 के अंत और 2026 की शुरुआत के बीच तेज़ी से फैला। Layers को समझना उपयोगी है:

Layer 1 — Spec frameworks: specification artifacts को परिभाषित और manage करते हैं → Spec Kit, Tessl, Kiro, BMAD, OpenSpec, cc-sdd

Layer 2 — Planning और task systems: specs को executable task graphs में convert करते हैं → Taskmaster, Agent OS, Beads, Feature-Driven-Flow

Layer 3 — Execution agents: code लिखते और modify करते हैं → Claude Code, Cursor Agent, Codex, Devika, OpenDevin, CrewAI

Layer 4 — AI IDEs: सभी layers को एक workflow में integrate करते हैं → Kiro, Windsurf, Cursor, Claude Code, Copilot

आज अधिकांश developers केवल Layer 3 का उपयोग करते हैं — यह ठीक वहीं है जहाँ vibe coding की समस्या रहती है।

प्रासंगिक टूल्स की तालिका

व्यवहार में कैसे उपयोग करें: उदाहरण के रूप में Kiro

Kiro, VS Code पहले से उपयोग करने वाले developers के लिए सबसे accessible entry point है। यह Code OSS (VS Code का open source core) का एक fork है जिसे AWS के भीतर एक छोटी team ने बनाया है, जानबूझकर AWS ecosystem से बाहर positioned — इसे उपयोग करने के लिए AWS account की ज़रूरत नहीं है।

Installation

kiro.dev पर जाएं और अपने operating system के लिए installer download करें। GitHub या Google से login करें।

तीन-चरण workflow

Step 1 — Requirements

आप प्राकृतिक भाषा में बताते हैं कि क्या बनाना है। Kiro इसे EARS (Easy Approach to Requirements Syntax) notation में translate करता है:

WHEN usuário submete formulário de login
  AND credenciais são válidas
THEN sistema deve autenticar o usuário
  AND redirecionar para o dashboard
  AND registrar o evento de login com timestamp

यह notation explicit और machine-readable constraints को enforce करती है। आप जेनरेट किए गए requirements.md को आगे बढ़ने से पहले review और adjust करते हैं।

Step 2 — Design

Kiro आपके existing codebase का विश्लेषण करता है और architectural decisions, stack choices और component structure के साथ design.md जेनरेट करता है। एक React + Node.js प्रोजेक्ट के लिए, आपको कुछ ऐसा दिखेगा:

## Architecture

Frontend: React 18 com React Router v6
Backend: Express 4.x com middleware JWT
Database: PostgreSQL via Prisma ORM
Auth: bcrypt (salt rounds: 12) + JWT (access: 15min, refresh: 7d)
Testing: Jest + Supertest para integração

आप इस document को कोई code लिखे जाने से पहले review करते हैं। Project की वास्तविक architecture से असहमति यहाँ detect होती है — 400 जेनरेटेड लाइनों के बाद नहीं।

Step 3 — Tasks

Kiro dependency के अनुसार sequenced, discrete implementation steps के साथ tasks.md जेनरेट करता है:

- [ ] Task 1: Setup de banco de dados e schema de usuários
- [ ] Task 2: Endpoint POST /auth/register com validação Joi
- [ ] Task 3: Endpoint POST /auth/login com geração de tokens
- [ ] Task 4: Middleware de autenticação JWT
- [ ] Task 5: Endpoint POST /auth/refresh
- [ ] Task 6: Testes de integração para todos os endpoints

आप नियंत्रित करते हैं कि कौन से tasks execute करने हैं और कब। एजेंट एक समय में एक task implement करता है, उनके बीच review points के साथ।

Steering files

तीन spec documents के अलावा, Kiro steering files support करता है — persistent configuration files जो पूरे codebase के लिए standards define करती हैं:

# .kiro/steering/code-style.md
- Use TypeScript estrito, sem `any` implícito
- Prefira `async/await` sobre callbacks
- Nomes de variáveis em camelCase, constantes em SCREAMING_SNAKE_CASE
- Funções públicas devem ter JSDoc

Hooks

Kiro event-based hooks support करता है — agents जो defined triggers के response में automatically fire होते हैं:

{
  "hooks": [
    {
      "name": "security-audit",
      "trigger": "on-save",
      "agent": "Verifique vulnerabilidades de segurança no arquivo salvo"
    },
    {
      "name": "test-generator",
      "trigger": "on-file-create",
      "pattern": "src/**/*.ts",
      "agent": "Gere testes unitários para o novo arquivo"
    }
  ]
}

क्या अच्छा काम करता है

• Implementation से पहले design document review करना, 500 जेनरेटेड लाइनें बाद में review करने से मौलिक रूप से अलग है। समस्याएं सही स्तर पर उभरती हैं।
• Steering files style और conventions के बारे में repetitive prompts की भारी मात्रा को eliminate करती हैं।
• Sequential task flow एजेंट के context को focused रखता है — एक बार में एक समस्या, पूरा system नहीं।

क्या अच्छा काम नहीं करता

• स्वतंत्र tests में एक simple bug fix के लिए Kiro ने 16 acceptance criteria जेनरेट किए। छोटे changes के लिए, overhead वास्तविक है।
• मध्यम जटिलता की features के लिए spec generation में 30–45 सेकंड लगते हैं। यह तेज़ development flow में खलता है।
• EARS notation में learning curve है। जो लोग कभी formal specifications के साथ काम नहीं किया, उनके लिए यह intuitive नहीं है।
• Kiro Open VSX extension registry का उपयोग करता है (Microsoft का नहीं), जिसका अर्थ है C# के लिए official support अनुपस्थित है — .NET teams के लिए गंभीर सीमा।
• Autopilot mode (बिना supervision के multiple tasks execution) कम predictable results देता है। Task-by-task approval logic ही वह जगह है जहाँ असली value है।

मूल्य निर्धारण

Public preview के दौरान: निःशुल्क (interactions की सीमाओं के साथ)। GA: Free (50 interactions/माह) · Pro $19/माह (1,000 interactions) · Pro+ $39/माह (3,000 interactions)

वास्तविक समस्याएं

1. Upfront काम जो developer की प्रवृत्ति के विरुद्ध है

AI के साथ SDD का वादा यह है कि spec जल्दी जेनरेट होती है — और यह सच है। लेकिन “जल्दी” का मतलब “मुफ्त” नहीं है। किसी भी useful code की एक भी लाइन से पहले, आप review के कई cycles से गुज़रते हैं: जेनरेट की गई spec को review करते हैं, गलत समझे गए intentions को ठीक करते हैं, architectural plan को adjust करते हैं, tasks को approve या reject करते हैं। हर cycle के लिए वास्तविक human attention चाहिए।

मध्यम जटिलता की feature के लिए, यह overhead बाद में vibe-coded code debug करने की लागत से कम हो सकती है। एक isolated bug fix के लिए, लागत बड़े अंतर से benefit से अधिक है — independent tests में Kiro ने एक simple correction के लिए 16 acceptance criteria जेनरेट किए। Upfront काम इसलिए नहीं गायब होता क्योंकि AI spec जेनरेट करती है; यह अपनी प्रकृति बदलता है। लिखने की बजाय, आप review करते हैं और decide करते हैं। यह कम costly है, लेकिन शून्य नहीं।

2. हर phase में multiply होती token लागत

SDD का हर phase (spec → plan → tasks → implementation) production code की एक भी लाइन लिखे जाने से पहले tokens consume करता है। Reasoning models के साथ, agentic usage standard usage से 100x अधिक हो सकता है।

Claude Code के साथ heavy SDD sessions नियमित रूप से context limit तक पहुँचते हैं। Automatic compaction process में 3 से 12 मिनट लगते हैं। लागत केवल financial नहीं है — यह समय की और flow interruption की भी है। कोई भी public benchmark SDD बनाम direct development की कुल लागत (tokens + human review समय) की तुलना नहीं करता।

3. Iterations के दौरान context का degradation

यह सबसे कम चर्चित और शायद सबसे गंभीर समस्या है। AI-generated specs implementation phase में AI को वापस feed की जाती हैं। हर compaction cycle या session restart nuances खो देती है। जो एजेंट code implement करता है, उसे उन decisions तक पूर्ण access नहीं होती जो specification एजेंट ने record की थीं।

नतीजा: जैसे-जैसे context degrade होता है, code धीरे-धीरे spec से diverge होने लगता है। Spec और code के बीच loop, जो synchronous होना चाहिए, telephone games की एक series बन जाती है — हर phase पिछले phase के छोटे noise को amplify करती है।

4. Deploy के बाद Specs भ्रामक हो जाती हैं

आधुनिक SDD टूल्स के साथ, spec “code से दूर” नहीं है — यह उसी cycle में, उसी टूल द्वारा, implementation से मिनटों पहले जेनरेट होती है। Technical reality से disconnected analysts द्वारा लिखी गई specifications की classic समस्या यहाँ लागू नहीं होती।

जो समस्या बनी रहती है वह अलग है: deploy के बाद क्या होता है। Edge cases केवल production में दिखते हैं। Users का वास्तविक behavior modeled से diverge करता है। Load के तहत performance problems उभरती हैं। Spec update नहीं होती। अगर इसे future maintenance और evolution (spec-anchored) के लिए guide करने के लिए उपयोग किया जाता है, तो एक outdated spec actively भ्रामक बन जाती है: एजेंट उस पर trust करता है, एक ऐसी reality के आधार पर code जेनरेट करता है जो अब exist नहीं करती, और developer को तभी पता चलता है जब system टूट जाता है।

Breunig का Plumb टूल इसे address करने की कोशिश करता है: एक CLI जो git commit से जुड़ता है, agent traces पढ़ता है, implementation के दौरान लिए गए decisions extract करता है और spec update करने से पहले developer की approval मांगता है। यह PoC है, production नहीं — लेकिन यह सही दिशा में इशारा करता है।

5. वास्तविक curation के बिना artifacts का proliferation

हर feature कई markdown files जेनरेट करती है। यह implicit promise कि “एजेंट spec को updated रखेगा” टिकती नहीं — किसी को spec में हर बदलाव को उसी rigor से review करना होगा जितनी rigor से code review होता है। व्यवहार में, ऐसा नहीं होता। Specs जमा होती हैं, code से diverge होती हैं, और signal के बजाय noise बन जाती हैं।

6. Specifications non-determinism को eliminate नहीं करतीं

एक ही spec अलग-अलग executions में अलग-अलग implementations produce कर सकती है। अधिक precision, variation को कम करती है लेकिन लिखने की लागत बढ़ाती है। और poorly written specs — जो सबसे संभावित result है जब methodology team के लिए नई हो — well-organized code produce करती हैं जो गलत काम करता है।

7. AI के loop में waterfall का जोखिम

सबसे structural criticism Thoughtworks और independent analyses से आती है: जैसा SDD वर्तमान में practiced है, यह AI के loop में waterfall बनने का जोखिम उठाता है। आप अभी भी सब कुछ upfront define कर रहे हैं और उम्मीद कर रहे हैं कि reality cooperate करेगी। Genuinely unknown requirements के साथ exploratory development के लिए, context-driven approaches बेहतर adapt करते हैं।

कब उपयोग करना समझदारी है

वर्तमान format में SDD इनके लिए समझदारी है:

• Enterprise teams बड़े, existing codebases पर developing करते समय जहाँ architectural drift costly है
• Regulated environments जहाँ audit trails और requirements traceability अनिवार्य हैं (EU AI Act, financial sector, healthcare)
• Stable domains स्पष्ट contracts के साथ: APIs, data schemas, conformance rules
• TDD या BDD maturity वाले teams जो उस discipline को AI layer तक extend करना चाहते हैं
• Emulation और portability: वह use case जहाँ SDD सबसे अधिक चमकता है वह है किसी existing system को दूसरी language में reimplemented करना, original system के tests को specification के रूप में उपयोग करते हुए

SDD शायद इनके लिए overkill है:

• Solo projects और quick prototypes
• Exploratory development जहाँ requirements genuinely unknown हैं
• Small fixes या isolated bugs
• ऐसे teams जिनमें implementation के बाद specs को updated रखने का discipline नहीं है

ईमानदार निदान

SDD एक वास्तविक समस्या का वैध जवाब है। Vibe coding code तेज़ी से जेनरेट करता है जितनी teams govern कर सकती हैं। Specifications उस governance को restore करने का एक उपकरण हैं।

लेकिन TDD के साथ parallel instructive है। TDD को 25 साल हो गए हैं, इसके पास extensive empirical evidence है, और market में वास्तविक adoption strict sense में (tests पहले code, consistently) लगभग 8% के आसपास है। SDD hype generate कर रहा है क्योंकि यह agents के युग की एक visible समस्या solve करता है, लेकिन वही fundamental challenge inherit करता है: developers deliver करना prefer करते हैं। कोई भी methodology जो upfront काम जोड़ती है उस instinct से लड़ेगी।

आसानी से मिलने वाली public criticism की अनुपस्थिति खुद एक signal है। जब benefits trivially मिलते हों और tradeoffs नहीं, तो कोई methodology अभी भी marketing phase में है, maturity phase में नहीं। Spec-Driven Development ने अभी वह ticket नहीं चुकाया।

जिन tools पर ध्यान देना worth है: Spec Kit open source flexibility और IDE independence के लिए, Kiro IDE में structured workflows के लिए, Tessl spec-as-source की सबसे ambitious vision के लिए (अभी भी unproven), और Plumb सबसे कठिन और unsolved समस्या के reference के रूप में — initial implementation के बाद specs को alive रखना।

संदर्भ

• The Rise of Spec Driven Development — Drew Breunig
• The Spec-Driven Development Triangle — Drew Breunig
• Spec-Driven Development Is Eating Software Engineering — Vishal Mysore
• Spec-Driven Development: Unpacking 2025’s key new practice — Thoughtworks
• Spec-Driven Development: When Architecture Becomes Executable — InfoQ
• Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl — Martin Fowler’s blog
• The Limits of Spec-Driven Development — Isoform
• GitHub Spec Kit
• Kiro IDE
• Tessl
• Measuring AI Impact on Experienced Developer Productivity — METR, 2025