2026 के एक Sonar सर्वे के अनुसार, 88% डेवलपर्स का कहना है कि AI-जनरेटेड कोड तकनीकी ऋण (technical debt) को बढ़ा रहा है, और spec-driven development के समर्थक तर्क देते हैं कि एक अनुशासित specification चरण इस भटकाव को रोक सकता है।

यह समस्या क्यों महत्वपूर्ण है

जब किसी इंसान को कोई अस्पष्ट टिकट मिलता है, तो वे स्पष्टीकरण के लिए प्रश्न पूछते हैं। इसके विपरीत, एक AI एजेंट अपने सर्वोत्तम अनुमान से रिक्त स्थानों को भर देता है और ऐसा कोड सौंप देता है जो देखने में सही लगता है। सही होने का यह भ्रम महंगा साबित होता है: उसी Sonar पोल में बताया गया है कि आधे से अधिक उत्तरदाताओं ने ऐसा कोड देखा है जो बुनियादी जांच (basic checks) में तो पास हो जाता है, लेकिन उसमें सूक्ष्म दोष (subtle defects) छिपे होते हैं। वे दोष तकनीकी ऋण के रूप में जमा होते रहते हैं, जिससे बाद में रिफैक्टरिंग (refactoring) करनी पड़ती है, फीचर डिलीवरी धीमी हो जाती है, और मेंटेनेंस बजट बढ़ जाता है।

Spec-driven development कैसा दिखता है

Spec-driven development (SDD) वर्तमान क्रम को उलट देता है। एक संक्षिप्त यूजर स्टोरी के साथ AI मॉडल को प्रॉम्प्ट देने के बजाय, टीम एक विस्तृत, एजेंट-एक्जीक्यूटेबल (agent-executable) स्पेसिफिकेशन लिखती है जो कोड के समान ही वर्जन-कंट्रोल सिस्टम में रहता है। स्पेसिफिकेशन (spec) सत्य का एकल स्रोत (single source of truth) बन जाता है—यह इरादे (intent), एज केस (edge cases), प्रदर्शन की अपेक्षाओं और उन सभी बाधाओं को रिकॉर्ड करता है जिनका AI मॉडल को पालन करना चाहिए।

यह प्रक्रिया मानवीय डिज़ाइन कार्य को प्रतिस्थापित नहीं करती; बल्कि यह उसे संहिताबद्ध (codify) करती है। निर्णयों को डेवलपर की याददाश्त से हटाकर एक ठोस दस्तावेज़ में लाकर, इंसान और भविष्य के AI एजेंट दोनों यह पता लगा सकते हैं कि कोड का कोई हिस्सा एक निश्चित तरीके से व्यवहार क्यों कर रहा है। एक spec तैयार करने में शुरुआत में प्रयास लगता है, लेकिन बाद में अस्पष्ट AI आउटपुट को डीबग करने में कहीं अधिक लागत आती है।

वर्कफ़्लो को बदलना

Product backlog – आइटम्स को छोटा रखें, केवल इरादे और उच्च-स्तरीय स्वीकृति मानदंड (acceptance criteria) को ही कैप्चर करें। यह सूची प्राथमिकता निर्धारण (prioritization) को जारी रखती है।

Sprint planning – टीमें व्यापक लक्ष्य पर चर्चा करती हैं और एक Sprint Goal पर सहमत होती हैं, लेकिन वे स्पेसिफिकेशन तैयार होने तक विस्तृत कार्यान्वयन (implementation) को रोक कर रखती हैं।

During the sprint – जो व्यक्ति कार्य (task) ले रहा है, वह एक सटीक, मशीन-पठनीय spec लिखता है। spec में इनपुट फॉर्मेट, अपेक्षित आउटपुट, एरर हैंडलिंग और किसी भी नॉन-फंक्शनल आवश्यकताओं को सूचीबद्ध किया जाता है। चूंकि spec वर्जन-कंट्रोल किया जाता है, इसलिए समीक्षक (reviewers) कोड की तरह ही कमेंट कर सकते हैं, संपादन का सुझाव दे सकते हैं और परिवर्तनों को मंजूरी दे सकते हैं।

Definition of Done – क्वालिटी गेट में “Spec reviewed and approved” जोड़ें। जब तक spec कार्यान्वयन (implementation) के समान समीक्षा मानकों को पास नहीं कर लेता, तब तक कोई भी कोड पूरा नहीं माना जाता।

Kanban adaptation – दो नए कॉलम जोड़ें: “Spec Drafted” और “Spec Approved।” अब वर्क आइटम्स इस क्रम में चलते हैं: backlog → Sprint Goal → Spec Drafted → Spec Approved → In Progress → Done। यह दृश्य परिवर्तन पहले के अदृश्य समन्वय चरण को स्पष्ट बनाता है।

ऐसे टूल्स जो पहले से ही specs लागू करते हैं

GitHub Spec Kit और AWS Kiro जैसे प्लेटफॉर्म्स ने ऐसे गेट्स (gates) जोड़ दिए हैं जो किसी भी AI कोड जनरेशन के शुरू होने से पहले आवश्यकताओं के दस्तावेज़ (requirements document) की मांग करते हैं। वे AI मॉडल को प्रतिस्थापित नहीं करते; वे शाब्दिक रूप से काम करने वाले (literal-minded) एजेंटों को मानवीय इरादे के साथ संरेखित करते हैं। spec को एक पूर्व शर्त बनाकर, ये टूल्स मौजूदा CI/CD पाइपलाइनों को तोड़े बिना इस बदलाव को स्वचालित करते हैं।

संभावित विरोध

आलोचकों का कहना है कि spec लिखना पहले से ही तेज़ गति वाले एजाइल कैडेंस (agile cadence) में घर्षण (friction) पैदा करता है। इसका जवाबी तर्क यह है कि spec तैयार करने में खर्च किया गया समय आमतौर पर एक अस्पष्ट प्रॉम्प्ट से उत्पन्न AI-निर्मित कोड को बाद में डीबग करने में लगने वाले समय का एक छोटा हिस्सा होता है।

एक अन्य चिंता यह है कि आवश्यकताएं विकसित होने के साथ स्पेसिफिकेशन पुराने हो सकते हैं। वर्जन-कंट्रोल इंटीग्रेशन इसका समाधान करता है: spec में कोई भी बदलाव एक नया कमिट (commit) बनाता है, समीक्षा को ट्रिगर करता है, और टीम को संबंधित कोड का पुनर्मूल्यांकन करने के लिए मजबूर करता है। व्यवहार में, specs को कोड की तरह मानने से दस्तावेज़ अपडेट रहते हैं।

आगे क्या देखने की आवश्यकता है

इसे अपनाने का दौर अभी शुरुआती है, लेकिन इसकी गति स्पष्ट रूप से दिखाई दे रही है। जैसे-जैसे AI कोड जनरेटर अधिक सक्षम होते जाएंगे, सटीक और मशीन-पठनीय इरादे की आवश्यकता और बढ़ती जाएगी।

Bottom line: अस्पष्ट प्रॉम्प्ट को ठोस, समीक्षा किए गए स्पेसिफिकेशन में बदलना एक अतिरिक्त कदम लग सकता है, लेकिन यह अनुमान लगाने (guesswork) को जवाबदेह निर्णयों में बदल देता है।