अपने AI कोडिंग एजेंट को स्पष्ट 'definition of done' कैसे दें

जब कोई इंसानी साथी एक अस्पष्ट टिकट उठाता है, तो वह अपनी समझ से खाली जगहों को भरता है और सवाल पूछता है। एक AI कोडिंग एजेंट इनमें से कुछ नहीं करता। वह आपका अनुरोध पढ़ता है, कोड लिखता है, जो जाँच वह कर सकता है वह चलाता है, और फ़ीचर को पूरा घोषित कर देता है — अक्सर एक भी स्पष्टीकरण वाला सवाल पूछे बिना। जैसा कि एक गाइड कहती है, जब आप किसी एजेंट को धुँधली आवश्यकताएँ सौंपते हैं, तो "ढीलापन सोख नहीं लिया जाता — वह बना दिया जाता है।"

यही वजह है कि आपकी definition of done वह एक चीज़ बन जाती है जिसे आप लिख सकते हैं और जिसका असर सबसे ज़्यादा होता है। यह गाइड बताती है कि ऐसी definition कैसे लिखी जाए जिस पर एक एजेंट सचमुच अमल कर सके।

Acceptance criteria बनाम definition of done

दो संबंधित विचार, जिन्हें अलग रखना ज़रूरी है:

• Acceptance criteria फ़ीचर-विशिष्ट होते हैं: सही माने जाने के लिए काम के इस ख़ास हिस्से को क्या करना चाहिए।
• Definition of done पूरे प्रोजेक्ट के स्तर पर होती है: वे क्वालिटी गेट्स जिन्हें शिप होने से पहले हर बदलाव को पार करना होता है — टेस्ट, रिव्यू, डॉक्स, कोई सीक्रेट कमिट न हो।

Acceptance criteria को "क्या हमने सही चीज़ बनाई" और definition of done को "क्या हमने इसे अपने स्तर के अनुसार बनाया" के रूप में सोचें। आपके एजेंट को दोनों चाहिए। (इस अंतर पर Atlassian की एक अच्छी शुरुआती जानकारी है।)

इसे परखने योग्य बनाएँ, महत्वाकांक्षी नहीं

एक अच्छे criterion की परख: क्या कोई स्क्रिप्ट — या ख़ुद एजेंट — जाँच सकता है कि यह सच है या नहीं? "लॉगिन फ़ॉर्म तेज़ महसूस होना चाहिए" सत्यापित नहीं किया जा सकता। इसे किसी ऐसी चीज़ में फिर से लिखें जिसकी एक साफ़ धार हो:

• मान्य क्रेडेंशियल्स सबमिट करने पर 500ms के भीतर /dashboard पर रीडायरेक्ट होता है
• ग़लत पासवर्ड सबमिट करने पर एक इनलाइन एरर दिखता है और पेज दूसरी जगह नेविगेट नहीं करता
• खाली फ़ील्ड सबमिट करना किसी भी नेटवर्क अनुरोध से पहले क्लाइंट-साइड पर ही रोक दिया जाता है
• असफल लॉगिन प्रति IP प्रति मिनट 5 प्रयासों तक रेट-लिमिटेड होते हैं

हर लाइन कुछ ऐसी है जिसकी ओर एजेंट काम कर सकता है और पुष्टि कर सकता है। AI एजेंट के लिए एक अच्छा स्पेक लिखने पर Addy Osmani की सलाह है कि लाइन-दर-लाइन कैसे पर नहीं, बल्कि क्या और क्यों पर ध्यान दें — इरादे और बाधाओं का वर्णन करें, और कार्यान्वयन एजेंट को चुनने दें।

एक ठोस उदाहरण

एक ही कार्य के लिए इन दो प्रॉम्प्ट्स की तुलना करें।

अस्पष्ट:

उपयोगकर्ताओं के लिए अपना पासवर्ड रीसेट करने का कोई तरीक़ा जोड़ें।

definition of done के साथ:

एक password-reset फ़्लो जोड़ें। Done का मतलब है:

• एक POST /auth/reset-request एंडपॉइंट एक ईमेल स्वीकार करता है और हमेशा 200 लौटाता है (कभी यह ज़ाहिर न करे कि ईमेल मौजूद है या नहीं)
• src/lib/mail.ts में मौजूदा मेलर के ज़रिए 1 घंटे के लिए मान्य एक साइंड, सिंगल-यूज़ टोकन ईमेल किया जाता है
• POST /auth/reset-confirm टोकन को मान्य करता है, मौजूदा पासवर्ड नीति लागू करता है, और उपयोग के बाद टोकन को अमान्य कर देता है
• टेस्ट इन्हें कवर करते हैं: मान्य रीसेट, समाप्त हुआ टोकन, दोबारा इस्तेमाल किया गया टोकन, अज्ञात ईमेल
• बिना पहले बताए कोई नई डिपेंडेंसी नहीं

दूसरा वर्ज़न इसलिए लंबा नहीं है कि वह नौकरशाही से भरा है — वह इसलिए लंबा है क्योंकि हर वह अस्पष्टता जिस पर एजेंट अन्यथा अनुमान लगाता, अब तय कर दी गई है। सुरक्षा-संवेदनशील विकल्प (खाते का अस्तित्व लीक न करें, टोकन समाप्त करें, एक बार उपयोग) वही हैं जिन पर आप सबसे कम चाहेंगे कि कोई एजेंट अपने से कुछ गढ़े।

'Done' को एजेंट के लूप में जोड़ें

एक परखने योग्य definition of done की असली ताक़त यह है कि वह एजेंट के फ़ीडबैक लूप को बंद कर देती है। code → test → fix → repeat का एक एजेंटिक चक्र तभी अभिसरित होता है जब निशाना लगाने के लिए एक स्पष्ट लक्ष्य हो। जब आपके criteria वास्तविक टेस्ट से मैप होते हैं, तो एजेंट उन्हें चला सकता है, विफलताएँ देख सकता है, और आपको वापस सौंपने से पहले अपने काम को ख़ुद ठीक कर सकता है।

तो केवल done का वर्णन ही न करें — एजेंट को इसे जाँचने का एक तरीक़ा दें:

• उसे टेस्ट कमांड (npm test, pytest) की ओर इशारा करें और बताएँ कि जब तक वे पास न हों, फ़ीचर done नहीं है।
• जिन चीज़ों को कोड में परखना कठिन हो — पठनीयता, किसी मौजूदा पैटर्न का पालन करना — उनके लिए एक LLM-as-a-judge पास का उपयोग करें: एक दूसरा प्रॉम्प्ट जो आउटपुट को आपके क्वालिटी बार के मुक़ाबले परखता है। Anthropic और अन्य ने इसे व्यक्तिपरक जाँचों के लिए प्रभावी पाया है।
• सुरक्षा और "कोई placeholder/mock कोड नहीं" को अपनी पूरे-प्रोजेक्ट वाली definition of done में रखें ताकि यह हर बदलाव पर लागू हो, न कि केवल उन पर जिनका ज़िक्र आपको याद रहता है।

इसे वहाँ रखें जहाँ एजेंट इसे देखेगा

अपनी पूरे-प्रोजेक्ट वाली definition of done को एक बार ऐसी फ़ाइल में लिखें जिसे एजेंट अपने आप पढ़ता है — रिपॉज़िटरी रूट पर एक AGENTS.md या CLAUDE.md। फ़ीचर-विशिष्ट acceptance criteria ख़ुद टास्क प्रॉम्प्ट में जाते हैं। इस तरह "हमारा स्तर" हमेशा कॉन्टेक्स्ट में रहता है, और आप केवल वही स्पष्ट करते हैं जो आज के काम के लिए अनूठा है।

यह बदलाव सूक्ष्म है पर यही पूरा खेल है: एक सक्षम एजेंट के साथ, आपके acceptance criteria किसी सहकर्मी के लिए एक नोट होना बंद कर देते हैं और वह specification बन जाते हैं जिसके आधार पर कोड बनाया जाता है। उन्हें इसी तरह लिखें।