𝗦𝗽𝗲𝗰-𝗗𝗿𝗶𝘃𝗲𝗻 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗺𝗲𝗻𝘁 ने असली समस्या का समाधान नहीं किया

Spec-driven development (SDD) AI एजेंट्स द्वारा गलत कोड लिखने की समस्या का नया समाधान है।

इसका वर्कफ़्लो सरल है। आप एक स्ट्रक्चर्ड spec लिखते हैं। एक एजेंट उस योजना को लागू करता है। आप परिणाम की समीक्षा करते हैं। GitHub Spec Kit, OpenSpec, और Kiro जैसे टूल्स इस बदलाव का नेतृत्व कर रहे हैं।

यह दृष्टिकोण raw prompting की तुलना में बेहतर काम करता है। लेकिन इसमें एक बड़ी खामी है।

यह इस बात पर निर्भर करता है कि spec ही 'source of truth' बना रहे। यह एक झूठ है।

20 वर्षों से, हमने docs को code के साथ सिंक में रखने की कोशिश की है। Design docs, wikis, और READMEs सभी विफल रहे। क्यों? क्योंकि कोड को एडिट करना तेज़ है और इससे वैल्यू मिलती है। एक doc को एडिट करना धीमा है और इससे कुछ भी दृश्यमान नहीं मिलता। डॉक्यूमेंटेशन हमेशा गति (speed) के सामने हार जाता है।

SDD को भी इसी समस्या का सामना करना पड़ता है।

एक एजेंट किसी बाधा (constraint) का सामना करता है। वह उसे काम करने लायक बनाने के लिए कोड को ठीक कर देता है। अब कोड और spec मेल नहीं खाते। कुछ ही दिनों में spec बेकार हो जाता है। अधिकांश frameworks इसे ठीक करने के लिए "अनुशासन" (discipline) का उपयोग करने की सलाह देते हैं। अनुशासन हमें पहले भी हर बार विफल कर चुका है।

कोडिंग से पहले एक पूरा spec लिखना यह मान लेता है कि आप implementation के दौरान कुछ भी नहीं सीखते हैं। यह feedback loop को तोड़ देता है। यह agile development को एक भारी और पहले से की जाने वाली (upfront) प्रक्रिया में बदल देता है।

एक डेवलपर ने SDD का उपयोग करके कई महीनों तक चलने वाला एक प्रोजेक्ट चलाया। एजेंट ने हर spec का पूरी तरह से पालन किया। फिर भी सिस्टम विफल रहा। spec उस ज्ञान को कैप्चर नहीं कर सका जो केवल निर्माण (building) के दौरान सामने आता है। एक छोटे से infra बदलाव ने पूरे spec graph को तोड़ दिया।

एक अन्य टीम ने SDD आज़माया और पाया कि यह 10 गुना धीमा था। उनके पास अधिक औपचारिकताएं (ceremony) थीं लेकिन बग्स की संख्या उतनी ही थी।

लक्ष्य अधिक दस्तावेज़ (documents) बनाना नहीं होना चाहिए।

असली समस्या यह है कि specs को जीवित कैसे रखा जाए। हमें ऐसे specs की आवश्यकता है जो खुद को अपडेट करें। हमें ऐसे टूल्स की आवश्यकता है जो code और चलते हुए सिस्टम से spec का अनुमान (infer) लगा सकें। इसे एक lockfile की तरह काम करना चाहिए। यह स्वचालित (automatic) होना चाहिए।

मुझे यकीन नहीं है कि यह अभी संभव है या नहीं। मैं प्रोडक्शन में काम करने वाले लोगों से सुनना चाहता हूँ।

  • क्या आपका spec तीसरे सप्ताह के बाद भी टिक पाता है?
  • जब इसमें विचलन (drift) आता है, तो टूटने का कारण क्या होता है?
  • क्या आपने code या telemetry से specs जेनरेट करने की कोशिश की है?
  • क्या यह कठोरता (rigor) वैल्यू जोड़ती है या सिर्फ औपचारिकता (ceremony)?

Source: https://dev.to/sam_curatedmcp/spec-driven-development-renamed-an-old-problem-it-didnt-solve-it-tags-ai-productivity-347a

Optional learning community: https://t.me/GyaanSetuAi