विषय-सूची

जिस युग में कोड AI लिखता है, वहाँ ज़्यादा मूल्यवान कौशल "कोड लिखने" से बदलकर "spec लिखने" की ओर जा रहा है। इस बदलाव को सबसे अच्छी तरह दर्शाने वाला तरीका है Spec-Driven Development (SDD)। 2026 में प्रमुख टूल — Claude Code, GitHub, AWS और अन्य — सभी ने इसे अपना लिया है, और यह vibe coding के बाद के "अगले कदम" के रूप में ध्यान आकर्षित कर रहा है।

यह लेख शुरुआती लोगों के लिए स्पष्ट करता है कि Spec-Driven Development क्या है, अभी इसकी ज़रूरत क्यों है, बुनियादी चार चरण, प्रमुख टूल, और इसे vibe coding के बजाय कब इस्तेमाल करना चाहिए।

SPEC-DRIVEN DEVELOPMENT · spec मुख्य भूमिका में

"Specify → Plan → Tasks → Implement"

— हर चरण एक दस्तावेज़ छोड़ता है, इसलिए AI को कभी अनुमान नहीं लगाना पड़ता

STEP 1

Specify

आप क्या बना रहे हैं, उसे शब्दों में स्पष्ट करें।

STEP 2

Plan

डिज़ाइन, तकनीक और बाधाएँ जोड़ें।

STEP 3

Tasks

इसे छोटे, समीक्षा-योग्य हिस्सों में तोड़ें।

STEP 4

Implement

AI इसे spec के अनुसार बनाता है।

1. Spec-Driven Development (SDD) क्या है?

Spec-Driven Development एक ऐसा दृष्टिकोण है जिसमें "spec" परियोजना का मुख्य पात्र (केंद्रीय दस्तावेज़) होता है, और AI उसी से इम्प्लीमेंटेशन निकालता है। AI से तुरंत कोड लिखवाने के बजाय, आप पहले "क्या और कैसे बनाना है" को एक संरचित दस्तावेज़ में दर्ज करते हैं, और एक AI agent उस spec को पढ़कर डिज़ाइन करता है, उसे टुकड़ों में बाँटता है और इम्प्लीमेंट करता है।

"घर बनाने से पहले के नक्शे" की कल्पना कीजिए। किसी बढ़ई से बिना नक्शे के "बस कुछ अच्छा बना दो" कहेंगे तो नतीजा अलग-अलग होगा और बहुत बार दोबारा काम करना पड़ेगा। AI agent भी वैसा ही है: एक अस्पष्ट निर्देश अनुमान को जन्म देता है। नक्शा यानी spec पहले तय कर लीजिए, तो आप AI के भटककर अपनी मनमानी इम्प्लीमेंटेशन करने की गुंजाइश घटा देते हैं।

💡 एक पंक्ति में: SDD = "कोड से पहले spec लिखो।" spec ही सत्य का स्रोत है, और कोड उसी से उत्पन्न एक व्युत्पन्न है। context engineering के नज़रिए से देखें तो spec वह सबसे बेहतरीन "context" भी है जो आप AI को सौंप सकते हैं।

2. अभी क्यों? vibe coding की "तीन महीने की दीवार"

vibe coding (विचारों के साथ बातचीत करते हुए बनाना) बेहद तेज़ रफ़्तार से प्रोटोटाइप तैयार कर सकती है, लेकिन यह बड़े पैमाने पर टूट जाती है। रिपोर्ट और अनुभवी लोग अक्सर बताते हैं कि जोश में बनाया गया कोड लगभग तीन महीने बाद "तकनीकी ऋण की दीवार" से टकरा जाता है और रखरखाव की लागत बेतहाशा बढ़ जाती है। AI से बना कोड वैसे ही पड़ा रहता है, प्रोडक्शन में जमा होता जाता है और बाद में उसे ठीक करना असंभव हो जाता है।

Spec-Driven Development इस "आवश्यकताओं के खिसकने (requirements drift)" को डिज़ाइन चरण में ही ख़त्म कर देता है। पहले spec तय करने से शुरुआती मेहनत बढ़ती है, पर बाद के दोबारा काम में भारी कटौती होती है। GitHub बताता है कि अपने टूल का इस्तेमाल करने पर "शून्य से दोबारा बनाने" वाले चक्रों की संख्या लगभग दस गुना कम हो गई (वेंडर द्वारा बताया गया आँकड़ा)।

VIBE CODING

तेज़ · खोजबीन के लिए अच्छा

  • प्रोटोटाइपिंग और सत्यापन बिजली की रफ़्तार से
  • बातचीत करते-करते दिशा खोजें
  • पर बड़े पैमाने पर टूट जाती है
  • आवश्यकताएँ खिसकती हैं और ऋण जमा होता है
SPEC-DRIVEN DEVELOPMENT

रखरखाव-योग्य · डिलीवरी के लिए अच्छा

  • spec ही सत्य का स्रोत है, इसलिए कम भटकाव
  • आवश्यकताओं के खिसकने को डिज़ाइन से रोकता है
  • शुरुआती मेहनत ज़्यादा
  • दोबारा काम बहुत कम, रखरखाव आसान

लोग तो यहाँ तक कहते हैं कि "2026 में इंजीनियर की बढ़त कोड लिखने की क्षमता से ज़्यादा spec लिखने की क्षमता है।" आप जितना ज़्यादा AI को सौंपते हैं, इंसान का काम उतना ही "वास्तव में क्या बनाना है, इसे ठीक-ठीक परिभाषित करने" की ओर खिसकता जाता है।

3. बुनियादी प्रवाह — चार चरण

टूल के अनुसार नाम थोड़े बदलते हैं, पर Spec-Driven Development मोटे तौर पर वही चार चरण अपनाता है। अहम बात यह है कि हर चरण एक दस्तावेज़ (अक्सर एक Markdown फ़ाइल) छोड़ता है जिसे अगला चरण पढ़ता है। चाल यह है कि जानकारी अकेले AI के दिमाग़ में न रखी जाए।

① Specify

क्या बनाना है उसका वर्णन — सुविधाएँ, उद्देश्य, उपयोगकर्ता, स्वीकृति मानदंड — शब्दों में।

② Plan (डिज़ाइन)

कैसे बनाना है यह जोड़ें: आर्किटेक्चर, जो लाइब्रेरी इस्तेमाल करेंगे, और बाधाएँ।

③ Tasks (विभाजन)

योजना को छोटे, समीक्षा-योग्य हिस्सों में तोड़ें जिन्हें एक-एक करके जाँचा जा सके।

④ Implement

AI हर task को spec के अनुसार बनाता है। इंसान समीक्षा और स्वीकृति पर ध्यान देते हैं।

⚠️ इंसानी समीक्षा अनिवार्य है: spec-driven काम में भी AI से बने कोड की जाँच कभी न छोड़ें। SDD "बना कर भूल जाने" का औज़ार नहीं है — यह एक ऐसी व्यवस्था है जो इंसान के लिए दिशा संभालना आसान बनाती है।

4. प्रमुख टूल (Spec Kit, Kiro और अन्य)

2026 तक अधिकांश प्रमुख coding agent SDD का समर्थन करते हैं। यहाँ अग्रणी उदाहरण दिए गए हैं।

GitHub Spec Kit

एक ओपन-सोर्स CLI (GitHub पर 90,000+ स्टार)। यह Specify → Plan → Tasks → Implement का समर्थन करता है और Claude Code तथा GitHub Copilot सहित 30 से ज़्यादा agent के साथ काम करता है।

AWS Kiro

यह कोई कोड बनाने से पहले Requirements → Design → Tasks चलाता है, और एक Auto router होता है जो हर task के लिए सबसे अच्छा मॉडल चुनता है; यह CLI और वेब दोनों में उपलब्ध है।

अन्य

BMAD, OpenSpec, Tessl, Google Antigravity और Cursor भी अपने-अपने SDD प्रवाह देते हैं। अधिकांश प्रमुख टूल इसे किसी न किसी रूप में समर्थन देते हैं।

आपको किसी समर्पित टूल की भी ज़रूरत नहीं है — आप बस "पहले spec को Markdown में लिखो, फिर इम्प्लीमेंट करने से पहले AI से उसे पढ़वाओ" करके इस सोच का अभ्यास कर सकते हैं। इससे AI द्वारा आपके नियम अनदेखा करने की समस्या की संभावना भी कम होती है, क्योंकि आप spec को एक स्पष्ट दस्तावेज़ के रूप में सौंपते हैं।

5. इसका उपयोग कब बनाम vibe coding

मायने यह नहीं रखता कि "कौन सा सही है" बल्कि "कब कौन सा इस्तेमाल करना है।" 2026 के लिए व्यावहारिक जवाब है हाइब्रिड — खोजबीन के लिए vibe, डिलीवरी के लिए spec-driven।

  • जब vibe coding फिट बैठती है: किसी विचार को परखना, फेंक देने वाले प्रोटोटाइप, अकेले कुछ छोटा आज़माना। वह चरण जहाँ आप बस तेज़ी से "कुछ" तक पहुँचना चाहते हैं।
  • जब spec-driven फिट बैठता है: प्रोडक्शन सिस्टम जिन्हें आप दीर्घकाल तक संभालेंगे, टीम का विकास, ऐसे उत्पाद जहाँ spec मायने रखता है। जब आप पूरे डेवलपमेंट लाइफ़साइकल को देख रहे हों।

तो: दिशा जल्दी ढूँढने के लिए vibe से शुरू करें, फिर जब आप आगे बढ़ने का फ़ैसला कर लें, तो उसे एक spec में उतारें और पूरा बनाएँ। दोनों विरोधी नहीं हैं — समझदारी इन्हें अलग-अलग चरणों के लिए इस्तेमाल करने में है।

6. आज से कैसे आज़माएँ

आप बिना कोई समर्पित टूल इंस्टॉल किए छोटे स्तर पर शुरू कर सकते हैं।

  • पहले एक-पन्ने का spec लिखें: जो सुविधा आप चाहते हैं, उसके लिए "उद्देश्य, इनपुट/आउटपुट, स्वीकृति मानदंड" को Markdown में बुलेट के रूप में लिख लें।
  • कोड माँगने से पहले AI से spec पढ़वाएँ: उसे कहें "इस spec के अनुसार ही इम्प्लीमेंट करो; जो भी अस्पष्ट हो उसके बारे में मुझसे पूछो।" बस "बना दो" मत कहिए।
  • task को छोटे टुकड़ों में बाँटें: सब कुछ एक साथ नहीं — एक सुविधा इम्प्लीमेंट करें, समीक्षा करें, फिर अगली। प्रक्रिया को Claude Skills में दर्ज करने से पुनरावृत्ति-क्षमता बढ़ती है।
  • spec को अद्यतन रखते रहें: जब कुछ बदले, तो कोड से पहले spec को ठीक करें। spec को सत्य का स्रोत बनाए रखना ही SDD का मर्म है।

💡 शुरुआती लोगों के लिए भी फ़ायदेमंद: जब आप AI से कोई ऐप बनाते हैं, तो सिर्फ़ पहले spec लिख लेने से नतीजे की गुणवत्ता उल्लेखनीय रूप से बढ़ जाती है। यह एक ऐसी टिप है जिसका इस्तेमाल आप प्रोग्रामिंग में मज़बूत न होने पर भी कर सकते हैं।

सारांश

Spec-Driven Development पर तीन मुख्य बातें।

  • यह क्या है: कोड से पहले "spec" लिखना और उसे सत्य का स्रोत मानकर AI से उसी के अनुसार इम्प्लीमेंट करवाना। spec ही केंद्रीय दस्तावेज़ है।
  • क्यों: क्योंकि यह vibe coding के "आवश्यकताओं के खिसकने और तकनीकी ऋण" को डिज़ाइन चरण में ही रोक देता है और दोबारा काम घटाता है।
  • कब: एक हाइब्रिड — खोजबीन के लिए vibe, डिलीवरी के लिए spec-driven। इंसानी समीक्षा अनिवार्य है।

"बनाने से पहले एक-पन्ने का spec लिखो" से शुरुआत कीजिए। AI के युग में वे लोग आगे नहीं बढ़ते जो सबसे तेज़ कोड लिखते हैं, बल्कि वे जो ठीक-ठीक परिभाषित कर सकते हैं कि क्या बनाना है। पूरी तस्वीर पाने के लिए इसके साथ vibe coding और context engineering भी पढ़ें।

FAQ

Q. क्या एक प्रोग्रामिंग शुरुआती Spec-Driven Development कर सकता है?

A. हाँ — यह शायद शुरुआती लोगों के लिए ही सबसे प्रभावी है। कोई कोड लिखने से पहले बस "क्या बनाना है" को शब्दों में व्यवस्थित कर लेना AI के आउटपुट को स्थिर करता है और गुणवत्ता बढ़ाता है। आप किसी समर्पित टूल के बिना Markdown नोट्स से शुरू कर सकते हैं।

Q. क्या vibe coding अब पुरानी पड़ गई है?

A. नहीं। खोजबीन और प्रोटोटाइपिंग के लिए vibe coding आज भी सबसे तेज़ है। यह पुराना-बनाम-नया का मामला नहीं है — इन्हें चरण के अनुसार इस्तेमाल करना ही 2026 का मुख्य चलन है: खोजबीन के लिए vibe, प्रोडक्शन की ओर बढ़ते हुए spec-driven।

Q. spec कितना विस्तृत होना चाहिए?

A. मार्गदर्शक नियम यह है कि "उद्देश्य, इनपुट/आउटपुट, स्वीकृति मानदंड" पहुँचाने जितना विस्तार पर्याप्त है। बहुत बारीक हो तो कठोर हो जाता है; बहुत अस्पष्ट हो तो AI अनुमान लगाता है। जैसे एक अच्छे prompt के छह हिस्से होते हैं, वैसे ही ठोस-फिर-भी-लचीले बीच को साधने का लक्ष्य रखें।

Q. क्या SDD कोड समीक्षा को अनावश्यक बना देता है?

A. नहीं। Spec-Driven Development के साथ भी इंसानी समीक्षा अब भी अनिवार्य है। SDD AI को सही दिशा में ले जाने की एक व्यवस्था है, जाँच छोड़ने का औज़ार नहीं। आप तभी सुरक्षित रूप से डिलीवर करते हैं जब कोई व्यक्ति spec और इम्प्लीमेंटेशन दोनों की समीक्षा करता है।