Spec-Driven Development क्या है?

अधिकांश AI कोडिंग एक ही तरह से शुरू होती है। आप एक एजेंट को एक छोटा प्रॉम्प्ट देते हैं। आप उसे कोड लिखते हुए देखते हैं। यह तेज़ लगता है। फिर आपको एहसास होता है कि एजेंट ने गलत चीज़ बना दी है। आप उसे ठीक करने में एक घंटा बिता देते हैं।

एजेंट को कोड लिखने में संघर्ष नहीं करना पड़ा। उसे आपके इरादे (intent) को समझने में संघर्ष करना पड़ा।

Spec-driven development इसे ठीक करता है। कोड के लिए प्रॉम्प्ट देने के बजाय, आप पहले एक spec बनाते हैं। यह spec एक लिखित योजना है। आप योजना को तब तक सुधारते हैं जब तक कि वह सही न हो जाए। उसके बाद ही आप एजेंट को निर्माण करने देते हैं।

AWS Kiro और GitHub spec-kit जैसे नए टूल्स इसे आसान बनाते हैं। लेकिन यह विचार पुराना है। यह बस अच्छी इंजीनियरिंग है।

एक अच्छे spec के तीन भाग होते हैं:

• Requirements: फीचर क्या करता है और सफलता को कैसे मापा जाए। यह व्यवहार (behavior) का वर्णन करता है, कोड का नहीं। • Design: तकनीकी योजना। इसमें आर्किटेक्चर, डेटा मॉडल और बाधाएं (constraints) शामिल हैं। • Tasks: छोटे, परीक्षण योग्य (testable) यूनिट्स। ये इतने सरल होते हैं कि एक एजेंट इन्हें एक बार में ही पूरा कर सके।

प्रत्येक भाग अगले भाग को आधार प्रदान करता है। Requirements, design का मार्गदर्शन करती हैं। Design, tasks बनाती है। Tasks, एजेंट का मार्गदर्शन करती हैं।

अतीत में, कोड लिखना धीमा था। Specs लिखना समय की बर्बादी जैसा लगता था। अब, AI मिनटों में कोड लिख देता है। अब बाधा टाइपिंग नहीं है। बाधा यह तय करना है कि वास्तव में क्या बनाना है।

एक spec आपकी गलतियों को एक सस्ते स्थान पर ले जाता है। दस्तावेज़ में एक गलत वाक्य को ठीक करना आसान है। कोडबेस में एक गलत कार्यान्वयन (implementation) को सुधारना महंगा होता है।

कोड की समीक्षा करना कठिन है। आपको यह समझने के लिए रिवर्स-इंजीनियरिंग करनी पड़ती है कि लेखक का क्या मतलब था। Spec की समीक्षा करना आसान है। कोड अस्तित्व में आने से पहले ही आप इरादे (intent) पर सहमत हो जाते हैं।

यह तरीका आपको स्केल करने में भी मदद करता है। आप अलग-अलग एजेंटों को अलग-अलग कार्य दे सकते हैं। Spec उन्हें एक साथ बनाए रखने के लिए एक अनुबंध (contract) के रूप में कार्य करता है।

यह दृष्टिकोण हमेशा सही समाधान नहीं होता है।

  • छोटे सुधारों के लिए यह overkill है। एक लाइन के बदलाव के लिए spec न लिखें।
  • Specs पुराने (stale) हो सकते हैं। यदि कोड बदलता है लेकिन spec नहीं, तो spec एक झूठ बन जाता है।
  • एजेंट हमेशा आज्ञा नहीं मानते। एक spec भ्रम को कम करता है, लेकिन आपको अभी भी आउटपुट की समीक्षा करनी होगी।

अपने इरादे को स्पष्ट करने के लिए spec का उपयोग करें। गलतियों को तब पकड़ने के लिए इसका उपयोग करें जब वे केवल शब्द हों।

Source: https://dev.to/jcamarate/what-is-spec-driven-development-with-ai-coding-agents-56mc

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