- Spec-Driven Development(SDD) कोडिंग से पहले विस्तृत दस्तावेज़ लिखने वाले waterfall-style approach को फिर से जीवित करने का तरीका है, जिसका लक्ष्य AI coding assistants के लिए structured प्रक्रिया देना है, लेकिन इसमें agility को बाधित करने का जोखिम है
- open source community ने शुरुआती prompts और निर्देशों के आधार पर specifications, implementation plans, और task lists को अपने-आप जनरेट करने वाले टूल बनाए हैं; प्रमुख उदाहरण हैं Spec-Kit, Kiro, Tessl, BMad Method
- लेकिन वास्तविक उपयोग में context awareness की कमी, अत्यधिक documentation, double code review, और false sense of security जैसी कई सीमाएँ सामने आती हैं, और बड़े codebase में efficiency तेज़ी से घट जाती है
- लेख का तर्क है कि SDD डेवलपर्स को replace करने की कोशिश के रूप में waterfall model की विफलता को दोहराता है, और इसके बजाय natural language आधारित iterative development का प्रस्ताव देता है
- Agile और Lean Startup principles को मिलाने वाला approach coding agents के साथ आधुनिक development के लिए अधिक उपयुक्त है, और visual interaction tools का विकास अगली चुनौती है
Spec-Driven Development(SDD) का उभार
- Spec-Driven Development(SDD) AI coding assistants के लिए structured development process देने हेतु कोडिंग से पहले specification documents लिखने की प्रक्रिया अपनाता है
- शुरुआती prompts और निर्देशों के आधार पर LLM product specification, implementation plan, और task list तैयार करता है
- हर दस्तावेज़ पिछले चरण पर निर्भर करता है, और उपयोगकर्ता उसे संपादित करके specification को refine करता है
- तैयार दस्तावेज़ Claude Code, Cursor, Copilot जैसे coding agents को दिए जाते हैं, जो उनसे कोड लिखते हैं
- प्रमुख टूल्स में GitHub का Spec-Kit, AWS का Kiro, Tessl, BMad Method(BMM) शामिल हैं
- संबंधित comparative analysis के रूप में Birgitta Böckeler का Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl उल्लेखित है
Markdown documentation की समस्या
- SDD specifications ज़्यादातर Markdown files के रूप में होती हैं; उदाहरण के लिए GitHub Spec-Kit से एक साधारण feature implementation में 8 files, 1,300 lines लगते हैं
- Kiro का उपयोग करके Atomic CRM में “referred by” field जोड़ने का मामला भी कई दस्तावेज़ों में बँटा हुआ है
- वास्तविक उपयोग में ये कमियाँ सामने आती हैं
- context awareness की कमी(Context Blindness) : मौजूदा functions या code context छूट जाता है, इसलिए expert review अब भी ज़रूरी है
- अत्यधिक documentation(Markdown Madness) : लंबे दस्तावेज़ों के कारण साधारण errors ढूँढने में भी बहुत समय लगता है
- व्यवस्थित नौकरशाही(Systematic Bureaucracy) : अनावश्यक दोहराव और अत्यधिक detail के कारण inefficiency पैदा होती है
- नकली Agile(Faux Agile) : “User Story” की अवधारणा का दुरुपयोग होकर अव्यवस्था पैदा होती है
- double code review(Double Code Review) : specification के भीतर के code और वास्तविक implementation, दोनों की अलग-अलग समीक्षा करनी पड़ती है
- झूठी सुरक्षा की भावना(False Sense of Security) : agents specification का पूरी तरह पालन नहीं करते
- घटती उपयोगिता(Diminishing Returns) : शुरुआती प्रोजेक्ट्स में उपयोगी, लेकिन scale बढ़ने पर गति कम हो जाती है
- ज़्यादातर coding agents पहले से ही plan mode और task list features देते हैं, इसलिए SDD का अतिरिक्त लाभ सीमित है और उल्टा development cost बढ़ा सकता है
Project Manager का प्रतिशोध
- SDD की सीमाएँ टूल्स की अपरिपक्वता के कारण हो सकती हैं, लेकिन मूल समस्या गलत तरह से परिभाषित समस्या में है
- यह “सॉफ़्टवेयर development से डेवलपर को हटाने का तरीका” जैसे लक्ष्य को आधार मानता है
- इसमें डेवलपर को coding agent से replace करके उसे बारीक planning से नियंत्रित करने की संरचना बनती है
- यह waterfall model जैसा है, जिसमें भारी documentation के ज़रिए डेवलपर को केवल translator जैसी भूमिका में सीमित कर दिया जाता है
- लेकिन software development एक non-deterministic प्रक्रिया है, जहाँ केवल planning से uncertainty खत्म नहीं की जा सकती (No Silver Bullet paper का उल्लेख)
- SDD में requirements stage पर business analyst और design stage पर developer — दोनों की expertise चाहिए; इसलिए व्यवहार में इसे वही लोग इस्तेमाल कर सकते हैं जो दोनों भूमिकाएँ निभा सकें
- नतीजतन, No Code tools की तरह यह भी “डेवलपर के बिना development” का वादा करता है, लेकिन अंततः डेवलपर की ज़रूरत बनी रहती है
नया विकल्प: natural language आधारित iterative development
- Agile methodology predictability की जगह adaptability चुनकर non-deterministic development की समस्या को हल करती है
- जटिल requirements को कई सरल समस्याओं में बाँटना coding agents के प्रभावी उपयोग की कुंजी है
- Lean Startup principles पर आधारित एक सरल iterative process प्रस्तुत की गई है
- उत्पाद की सबसे जोखिमपूर्ण assumptions की पहचान करें
- उन्हें validate करने के लिए न्यूनतम experiment design करें
- experiment विकसित करें और परिणामों के आधार पर iterate करें
- उदाहरण के तौर पर, Claude Code का उपयोग करके लगभग 10 घंटे में 3D sculpting tool(sculpt-3D) बनाया गया
- specification के बिना छोटे निर्देशों से features को धीरे-धीरे जोड़ा गया
- गलत implementations को तुरंत सुधारते हुए तेज़ iteration किया गया
- यह तरीका waterfall-style documentation के बिना भी तेज़ convergence संभव बनाता है, और Agile तथा coding agents के संयोजन से real-time product building को संभव करता है
- हालांकि coding agents अभी text-centric हैं, इसलिए visual interaction की कमी है; आगे visual interface enhancement tools के विकास की ज़रूरत है
निष्कर्ष
- Agile methodology ने specification documents को पहले ही काफी हद तक अनावश्यक बना दिया था, और SDD को उन्हें फिर से जीवित करने की कोशिश माना गया है
- SDD डेवलपर्स को बाहर करने वाला theory-driven approach है, जो coding agents के माध्यम से नई पीढ़ी के डेवलपर्स को सशक्त बनाने के अवसर को चूक जाता है
- coding agents की तुलना internal combustion engine से की गई है; SDD जहाँ उन्हें केवल locomotive से बाँधकर रखना चाहता है, वहीं हमें उन्हें cars, airplanes और अन्य रूपों तक फैलाना चाहिए
- अंत में, पर्यावरण को देखते हुए coding agents का संयमित उपयोग आवश्यक है
1 टिप्पणियां
Hacker News की राय
एक डेवलपर के रूप में मुझे सबसे बड़ा productivity boost तब मिला जब मैंने हर काम को पहले से plan करने की आदत डाल ली
हर टिकट मिलने पर उसे बड़े TODO list में तोड़कर design, dependencies, और specs पहले से साफ कर लेता हूँ
इससे programming करते समय मैं ज़्यादा बार flow state में जा पाता हूँ
AI coding agent के लिए भी यह तरीका इसलिए असरदार है, क्योंकि इसमें सोचने की प्रक्रिया पहले से दर्ज हो जाती है
ज़्यादा विवरण मैंने अपनी पोस्ट में लिखा है
असल में problem को छोटे हिस्सों में बाँटना और spec लिखना अच्छी बात है
लेकिन immutable spec समस्या पैदा करता है। अगर implementation महीनों बाद शुरू हो, तो spec जड़ हो जाता है
दूसरी तरफ Agile को अक्सर strategic planning टालने के बहाने की तरह इस्तेमाल किया जाता है। नतीजा, rework बढ़ जाता है
आखिर में बात balance की है, और मुझे लगता है “It depends” ज़िंदगी और development दोनों के लिए अच्छा motto है
अगर LLM spec manage करे, तो maintenance burden कम हो सकता है
संबंधित लेख यहाँ है
जहाँ predict करना मुश्किल हो, वहाँ पहले spike करके code और libraries explore करते हैं
ideal diagram और practical constraints को दर्शाने वाला diagram दोनों बनाते हैं, ताकि लंबे समय में architectural traps से बचा जा सके
कुछ महीनों तक vibe coding करने के बाद, पिछले 6 महीनों में मैं spec-driven development पर आ गया हूँ
रोज़ 2–3 घंटे spec लिखता हूँ और उसी दिन tested feature deploy कर देता हूँ
Spec लिखने से मैं कम agile नहीं हुआ। बल्कि 8 घंटे के तेज़ iteration संभव हुए हैं
Spec prompt नहीं, बल्कि correctness का criterion है
अच्छी तरह परिभाषित end-to-end tests AI की गलतियों को काफी कम कर देते हैं
हर run पर result बदल सकता है, और आखिर में इंसान को review करना ही पड़ता है, इसलिए यह inefficient हो सकता है
एक दिन के काम को ‘spec’ कहना भ्रामक है। आखिरकार यह पुराने process को नया नाम देने जैसा है
वे साधारण logical expressions भी गलत समझ लेते हैं, इसलिए natural language spec समझाने पर भरोसा करना जोखिम भरा है
फिर agent को दे देता हूँ, वह खुद implementation कर लेता है और मैं बीच-बीच में बस review करता हूँ
AI जब काम कर रहा होता है, मैं अपनी racecar पर हाथ लगा रहा होता हूँ, तो यह पूरी तरह win-win है
आखिर में मायने सिर्फ इस बात के हैं कि code tests pass करे
यह लेख शायद उन लोगों के लिए है जिन्होंने पहले ही तय कर लिया है कि “spec-based development मेरे लिए नहीं है”
मैं spec को LLM के context entry point की तरह देखता हूँ
अगर आप project structure, models, functions, requirements वगैरह पर्याप्त दें, तो LLM context समझकर आगे बढ़ सकता है
और अगर LLM खुद spec update करे, तो Agile iteration भी संभव हो जाती है
Tests, LLM के लिए grounding का काम करते हैं और hallucination रोकते हैं
Tests documentation भी हैं और quality standard भी, और LLM को junior developer की तरह manage करना चाहिए
कई agents को parallel चलाकर, test layer से cross-check करवाएँ, तो चौंकाने वाले नतीजे मिल सकते हैं
LLM की वजह से पूरा spec सस्ते और तेज़ तरीके से iterate हो सकता है, पर मूल प्रकृति वही रहती है
बहुत लंबा spec उल्टा exploratory thinking में रुकावट डालता है
LLM deterministic system नहीं बल्कि probabilistic system हैं, इसलिए अब हमें code नहीं, spec debug करनी पड़ती है
डेवलपर को अब cognitive systems architect में evolve होना होगा
high-level specs और detailed component specs साथ-साथ मौजूद हैं
मैंने GitHub के Spec-Kit से एक CLI tool बनाने की कोशिश की, लेकिन उसमें बहुत ज़्यादा edit, analysis, rewrite चक्र लगे
Waterfall की तरह feedback loop कम था, इसलिए काफ़ी frustrating लगा
आखिरकार गलत code देखकर वजह ढूँढने से बेहतर था कि फिर से शुरू करूँ
LLM के साथ coding अच्छी लगती है, लेकिन SDD मुझे heavy और inefficient workflow जैसा लगा
LLM को context पसंद है, इसलिए उन्हें बार-बार साफ निर्देश देने पड़ते हैं
उदाहरण के लिए, NextJS app बनाते समय login, RBAC, test-first implementation जैसी बातें साफ लिखता हूँ
छोटे unit से शुरू करके धीरे-धीरे features जोड़ना ज़्यादा उपयुक्त है
Waterfall की समस्या लंबा lead time और महँगी iteration cost थी
SDD में ये दोनों चीज़ें हल हो जाती हैं, इसलिए मुझे यह ठीक लगता है
कुछ घंटों के spec को waterfall कहना बढ़ा-चढ़ाकर कहना है
अगर आप बहुत जल्दी complex solution space में उतर जाते हैं, तो simple problem-solving मुश्किल हो जाती है
Agile छोटे space से शुरू होकर धीरे-धीरे फैलता है
अगर spec काफ़ी detailed हो, तो iteration धीमी हो जाती है; अगर कम हो, तो LLM ठीक से काम नहीं करता
आखिर में वही manager-friendly waterfall contradiction रह जाती है
LLM सबसे अच्छा तब काम करते हैं जब उन्हें छोटे-छोटे unit में साफ निर्देश दिए जाएँ
वे कई सालों के spec लिखेंगे, हर 6 महीने में LLM चलाएँगे, और fail होने पर डेवलपर को दोष देंगे
मैं ही इस पोस्ट का लेखक हूँ
अब भी waterfall vs agile debate का इतना सक्रिय होना दिलचस्प है
जिन लोगों को SDD में value दिखती है, उनकी background stories पढ़ना भी मज़ेदार है
लेकिन मैं implementation से पहले पहले ही Plan mode इस्तेमाल करता हूँ, इसलिए SDD मुझे अतिरिक्त value नहीं देता
शायद ही कभी coding agent ने एक ही बार में कुछ पूरी तरह सही implement किया हो
आखिरकार iteration चाहिए ही, इसलिए Big Design Up Front का मतलब कमज़ोर पड़ जाता है
फिर भी मेरा मानना है कि coding agents एक नया development paradigm खोल रहे हैं
इससे मुझे पहले देखा हुआ एक वीडियो याद आ गया
उसमें engineer और programmer एक-दूसरे से क्या सीख सकते हैं, इस पर बात कर रहे थे, और पहले से planning की अहमियत खास लगी
कहा जाता है कि agile ने spec documents को मार दिया, लेकिन असल में उसने उन्हें बस हज़ारों Jira tickets में तोड़ दिया
AI ऐसे बिखरे हुए decisions और context को रिकॉर्ड कर सकता है, और जब वे पुराने choices से टकराएँ तो सवाल पूछ सकता है
जैसे, “Jim ने 5 साल पहले यह code इस तरह क्यों लिखा था, क्या वह वजह आज भी valid है?”
यह लेख मुझे थोड़ा अजीब लगा
अधूरी spec लेकर trial-and-error से समाधान निकालना इंसानी डेवलपर और AI, दोनों के लिए एक जैसा है
अगर आपको चीज़ साफ़ पता है, तो detail में निर्देश देना ही सही है
शायद लेख का असली point “bad specs” के बारे में है
कुल मिलाकर यह Agile industry की self-defense logic जैसा लगा
मैंने कई Markdown spec files के साथ SDD आज़माया, और जो चीज़ सच में efficient लगी, वह ** beads** थी
यह agent को task tree follow करते हुए focused रहने में मदद करती है
हर task को TDD में बाँटती है और test pass होने से पहले अगले step पर नहीं जाने देती
Agent review commands तक बता देता है, जिससे code review आसान हो जाता है
Spec-Kit बहुत heavy लगा, इसलिए beads कहीं ज़्यादा practical है
पूरी तरह vibe-based तरीके से बने zmx project को भी मैंने बाद में agent-generated code देखकर पूरी तरह rewrite किया