Spec-Driven Development बड़े पैमाने पर क्यों विफल होता है और इसका समाधान क्या है

यह पोस्ट तर्क देती है कि Spec-Driven Development (स्पेसिफिकेशन-आधारित विकास) AI एजेंटों की मदद से कोडिंग के लिए आशाजनक है, लेकिन global product context में natural language specs की अस्पष्टता के कारण बड़े पैमाने पर फैलने पर विफल हो जाता है। लेखक इसका समाधान कोड और conversational AI को एकीकृत करने वाली "living specifications" की एक hierarchical और evolutionary system के रूप में प्रस्तावित करता है, जो product decisions के लिए feedback loop बनाकर असंगतियों को कम करती है और प्रभावी बड़े पैमाने की AI-सहायित development को संभव बनाती है.

Spec-Driven Development बड़े पैमाने पर विफल होने के मुख्य कारण

पारंपरिक Spec-Driven Development में global product specs के साथ निम्न कारणों से समस्या आती है:

• Natural language specs की अस्पष्टता: बड़े पैमाने के specs natural language में लिखे जाते हैं, इसलिए वे अनिश्चित और अस्पष्ट होते हैं। AI spec के अनुरूप लगातार code generate कर सकता है, लेकिन वह developer की वास्तविक मंशा से अलग हो सकता है। उदाहरण के लिए, यदि पूरे website product का spec लिखा जाए और AI agent उसे 2 दिनों में बना दे, तो परिणाम spec से मेल खा सकता है लेकिन इरादे से नहीं। इसे ठीक करने के लिए यदि अस्पष्टताओं को साफ करने हेतु लगातार और अधिक detail sections जोड़े जाएँ, तो दस्तावेज़ इतना लंबा और बोझिल हो जाता है कि spec लिखने का लाभ खत्म हो जाता है, और अंततः वह code से बहुत अलग न रहने वाली एक औपचारिक भाषा बन जाता है।

• Shared context और world understanding की कमी: AI के पास public data के आधार पर व्यापक ज्ञान होता है, लेकिन वह कंपनी-विशेष practices, codebase conventions और internal "काम करने के तरीके" नहीं समझता। इसके विपरीत, इंसान trial and error, PR reviews, meetings और अनौपचारिक बातचीत के माध्यम से यह समझ विकसित करते हैं। एक अकेला context document इसे पकड़ नहीं सकता।

• Clarification handling की अक्षमता: इंसान shared context के आधार पर केवल प्रासंगिक अस्पष्टताओं को कुशलतापूर्वक सुलझाते हैं (जैसे library selection जैसी स्पष्ट चीज़ों पर सवाल नहीं करते), लेकिन AI में context की बारीक समझ की कमी के कारण वह अनावश्यक प्रश्न पूछ सकता है, या उसकी clarification capability अभी शुरुआती चरण में है। इससे AI एक "ज़रूरत से ज़्यादा महत्वाकांक्षी intern" जैसा बन जाता है, जिसे लगातार मार्गदर्शन चाहिए।

इन समस्याओं के कारण global Spec-Driven Development अतिरिक्त mechanisms के बिना अव्यावहारिक है और यह human collaboration की सहजता की बराबरी नहीं कर पाता।

ठोस उदाहरण

• चरम Spec-Driven scenario: developer पूरे website का spec लिखता है और AI 2 दिनों में एक पूरा product बना देता है, लेकिन अस्पष्टता के कारण वह इरादे से अलग निकलता है।
• मानव learning process: developer शुरुआती code changes, PR reviews, meetings और hallway conversations से कंपनी के norms सीखता है, जबकि AI ऐसा tacit knowledge संचित नहीं कर पाता।
• पुराना होता codebase: पारंपरिक workflow में developers बिना spec के code पढ़ते और बदलते रहते हैं, जिससे codebase एक असंगत "patchwork quilts" जैसा बन जाता है और खो चुके product decisions "रौंदे" जाते रहते हैं।

लेखक पिछले पोस्ट (roaming RAG से संबंधित) का उल्लेख करते हुए कहता है कि AI hierarchical link structures को navigate करने में अच्छा है। इसमें कोई औपचारिक case study नहीं है; यह मुख्यतः hypothetical और explanatory उदाहरणों पर आधारित है।

प्रस्तावित समाधान

यह पोस्ट ambiguity handling, context building और code integration पर केंद्रित एक interconnected solution प्रस्तावित करती है:

Conversational clarification के जरिए स्पष्टता सक्रिय करना

• AI और developer के बीच back-and-forth interaction (जैसे chat experience) लागू किया जाए ताकि spec की अस्पष्टताओं की पहचान कर उन्हें स्पष्ट किया जा सके। छोटे tasks में AI spec के कई implementation versions बनाकर ambiguity को उजागर कर सकता है, जिनकी फिर developer के साथ तुलना और चर्चा की जाए।

Hierarchical specs के जरिए agent की worldview बनाना

• कंपनी और codebase norms को समझने के लिए hierarchical structure वाले global specs का उपयोग किया जाए। एक विशाल single document के बजाय main spec को sub-spec documents से link किया जाए:
  • file-by-file specs (directory rollup versions की तरह), जो code structure से सख्ती से जुड़े हों।
  • free-form wiki style, लेकिन अत्यधिक जटिलता से बचते हुए।
• AI की link navigation capability का लाभ उठाया जाए (जैसा पिछले पोस्ट में बताया गया था)।

अंतिम spec के रूप में code की भूमिका

• मौजूदा code को low-level assumptions के स्पष्ट "leaf-level" spec की तरह माना जाए। master spec से पूर्ण regeneration के बजाय वर्तमान codebase पर आधारित changes का लक्ष्य रखा जाए। यह स्वीकार किया जाए कि natural language हर बार एक जैसा output सुनिश्चित नहीं कर सकती, इसलिए असंभव precision की मांग से बचना चाहिए।

Living specs: उपयोग और विकास

• specs को codebase के साथ विकसित होने वाले "living documents" बनाया जाए:
  • AI global specs को navigate करके implementation को aligned रखे, और product decisions को human workflows से बेहतर तरीके से preserve करे।
  • developer AI के साथ बातचीत के माध्यम से प्रासंगिक spec information निकाले, बिना सब कुछ पढ़े; scoping के दौरान mismatches को flag किया जाए।
  • code changes होने पर spec updates trigger हों: changes की existing specs से तुलना और संपादन किया जाए, और PR में spec changes शामिल हों।
• लाभ: engineers के लिए change impact समझना आसान होता है, product managers की भागीदारी बढ़ती है (क्योंकि वे आसानी से पढ़े जाने वाले specs संपादित कर सकते हैं), और executives product evolution पर query कर सकते हैं। पारंपरिक दस्तावेज़ों की तरह updates छूट जाने की समस्या को AI automate कर सकता है।

निष्कर्ष और सिफारिश

Spec-Driven Development का भविष्य natural language specs को परिपूर्ण बनाने में नहीं, बल्कि conversation, hierarchical context और code-आधारित systems के जरिए ambiguity को संभालने में है। असली breakthrough उन living specs में है जिन्हें AI maintain करे, ताकि product decisions सुरक्षित रहें, context बना रहे और spec-implementation gap समाप्त होने लगे। सिफारिश यह है कि code और conversational AI को जोड़ने वाले hierarchical और evolving specs अपनाए जाएँ, ताकि ऐसे scalable AI workflows संभव हों जो पारंपरिक human development से आगे निकल सकें.

[raykim]

यह पोस्ट काफ़ी हद तक GPT से चलाकर सीधे फेंकी हुई लगती है।