AI विकास में ऐसे मानव समीक्षा चेकपॉइंट्स जो दिनों बचाते हैं

क्यों 5 मिनट की मानव समीक्षा बहुत समय बचाती है

AI-सहायता प्राप्त बिल्डिंग तुरंत लग सकती है। आप एक फीचर बताएँ, काम करता स्क्रीन मिले, और ऐप तैयार दिखे। समस्या यह है कि छोटे-छोटे विवरण अक्सर एज़ केस में फेल होते हैं: असली डेटा, असली परमिशन, असली प्रोडक्शन सेटिंग्स। ये “छोटी” चूकें अक्सर एक हफ्ते के क्लीनअप में बदल जाती हैं।

एक चेकपॉइंट वह छोटा मानव विराम है जो आप किसी बदलाव को स्वीकार या शिप करने से पहले लेते हैं। यह मीटिंग नहीं है और न ही लंबा QA साइकिल। यह एक जानबूझकर 5-मिनट स्कैन है जिसमें आप पूछते हैं: अगर यह गलत है, सबसे बुरा क्या टूटेगा?

सबसे दर्दनाक क्लीनअप चार उच्च-जोखिम क्षेत्रों से आते हैं:

• डेटा स्कीमा: गलत टाइप्स, गुम शर्तें, भ्रमित नाम, गायब इंडेक्स।
• ऑथ और परमिशन: यूज़र वह देख या बदल सकते हैं जो उन्हें नहीं करना चाहिए, या एडमिन अपना काम नहीं कर पाते।
• डेस्ट्रक्टिव एक्शन्स: डिलीट/ओवरराइट/बल्क अपडेट जो बहुत आसानी से चल जाते हैं, बिना रीकवरी के।
• डिप्लॉयमेंट सेटिंग्स: गलत env vars, dev/prod डेटा मिलना, सीक्रेट्स का ढीला हैंडलिंग, डोमेन मिसकॉनफिग।

एक छोटा विराम मदद करता है क्योंकि ये समस्याएँ क्रॉस-कटिंग होती हैं। छोटा स्कीमा-मिस्टेक APIs, स्क्रीन, रिपोर्ट और माइग्रेशंस में फैल जाता है। एक परमिशन-मिस्टेक सुरक्षा घटना बन सकती है। गलत डिप्लॉय सेटिंग डाउनटाइम का कारण बन सकती है।

चाहे आप हाथ से कोड लिखें या Koder.ai जैसे vibe-coding टूल का उपयोग करें, नियम वही है: तेज़ी से आगे बढ़ें, लेकिन उन जगहों पर छोटे गार्डरेल जोड़ें जहाँ नुकसान बड़ा है।

एक साधारण 5-मिनट चेकपॉइंट रूटीन

चेकपॉइंट तब सबसे अच्छे काम करते हैं जब वे अनुमानित हों। सब कुछ की समीक्षा न करें। उन कुछ चीज़ों की समीक्षा करें जिन्हें पलटाना महंगा होगा।

उन पलों को चुनें जो हमेशा चेकपॉइंट ट्रिगर करें: फीचर खत्म करने के बाद, डिप्लॉयमेंट से ठीक पहले, और उस रिफैक्टर के तुरंत बाद जो डेटा, ऑथ, बिलिंग या किसी भी प्रोडक्शन-फेसिंग चीज़ को छूता हो।

5 मिनट का टाइमर सेट करें। टाइमर खत्म होते ही रुकें। अगर आपने असली जोखिम पाया, लंबा फॉलो-अप शेड्यूल करें। नहीं तो अधिक आत्मविश्वास के साथ शिप करें।

रूटीन

1. एक वाक्य में बदलाव का नाम बताएं (यूज़र्स अब क्या कर सकते हैं)।
2. ब्लास्ट रेडियस देखें (कौन सा डेटा, रोल्स और एन्वायरनमेंट टच होते हैं)।
3. रिस्की एजेस स्कैन करें (स्कीमा, ऑथ रूल्स, डेस्ट्रक्टिव एक्शन्स, डिप्लॉय सेटिंग्स)।
4. एक रियलिटी टेस्ट चलाएँ (सबसे सरल फ्लो जो साबित करे कि यह काम करता है)।
5. निर्णय लें: आगे बढ़ें, प्रॉम्प्ट एडजस्ट कर के पुनः जनरेट करें, या रोलबैक करें।

एक रिव्युअर रोल असाइन करें, भले ही वह "भविष्य का आप" ही क्यों न हो। कल्पना करें कि आप इसे उस टीममेट के लिए अप्रूव कर रहे हैं जिसे आप बाद में परेशान नहीं कर पाएँगे।

एक छोटा टेम्पलेट आपको सुसंगत बने रहने में मदद करता है:

Change:
Risky areas touched:
1 quick test to run:
Decision (proceed / adjust prompt / rollback):

अगर आप Koder.ai में बिल्ड कर रहे हैं, तो आखिरी स्टेप को जानबूझकर आसान रखें। स्नैपशॉट और रोलबैक “मुझे यकीन नहीं है” को सुरक्षित निर्णय बना देते हैं।

स्कीमा सैनीटी: डेटा समस्याएँ जल्दी पकड़ें

दिन खोने का सबसे तेज़ तरीका है ऐसा डेटाबेस स्कीमा स्वीकार करना जो केवल “आधा-सा” वही हो जो आपने सोचा था। छोटे डेटा मिस्टेक हर स्क्रीन, API, रिपोर्ट और माइग्रेशन में फैल जाते हैं।

शुरूआत करें यह देखकर कि कोर एंटिटीज़ असल दुनिया से मेल खाती हैं या नहीं। एक सरल CRM में आमतौर पर Customers, Contacts, Deals, और Notes चाहिए होते हैं। अगर आप vague नाम जैसे “ClientItem” या “Record” देख रहे हैं तो आप पहले ही भटक रहे हैं।

एक 5-मिनट स्कीमा स्कैन:

• नाम वास्तविकता से मेल खाएं: टेबल उन चीज़ों का प्रतिनिधित्व करें जिनके बारे में आप वाकई बात करते हैं (users, invoices, subscriptions)।
• नाम पठनीय और सुसंगत हों: एक स्टाइल चुनें (created_at vs createdAt) और उस पर टिके रहें।
• रिलेशनशिप पूरी हों: जहाँ एक-से-कई चाहिए वहाँ हो, और जहाँ रोल या सदस्यता मायने रखती है वहाँ many-to-many।
• कॉन्स्ट्रेंट्स इरादतन हों: आवश्यक फ़ील्ड nullable न हों, जहां डुप्लीकेट हानि पहुँचाते हैं वहाँ रोकें (email, invoice_number), स्टेटस फ़ील्ड्स की मान्य सेट हो।
• ग्रोथ ऐप को नहीं तोड़े: सामान्य लुकअप्स पर इंडेक्स हों, और आप बड़े ब्लॉब्स गलत जगह स्टोर न कर रहे हों।

एक छोटा उदाहरण: Invoices टेबल बिना unique invoice_number के डेमो में ठीक दिख सकती है। एक महीने बाद डुप्लीकेट आ जाते हैं, पेमेंट्स गलत रिकॉर्ड पर लाग जाती हैं, और आप क्लीनअप स्क्रिप्ट और माफ़ीनामों के साथ फँस जाते हैं। समीक्षा में पकड़ना 30-सेकंड का फिक्स हो सकता है।

अगर आप केवल एक सवाल पूछें, तो यह पूछें: क्या आप स्कीमा को किसी नए टीममेट को दो मिनट में समझा सकते हैं? अगर नहीं, तो उस पर टाइट करें इससे पहले कि आप उस पर बिल्ड करें।

ऑथ रूल्स: कौन क्या कर सकता है (और कैसे जाँचे)

ऑथ बग महंगे होते हैं क्योंकि हैप्पी-पाथ डेमो उन्हें छिपाते हैं। दो आम विफलताएँ हैं: “हर कोई सब कुछ कर सकता है” और “कोई भी कुछ नहीं कर सकता”।

रोल्स साधारण शब्दों में लिखें: admin, staff, customer। अगर ऐप में टीम्स हैं, तो workspace member और workspace owner भी जोड़ें। अगर आप किसी रोल को एक वाक्य में समझा नहीं सकते, तो नियम फैलेंगे।

फिर एक नियम लागू करें: डिफ़ॉल्ट रूप से कम से कम एक्सेस। नए रोल्स को नो-एक्सेस या रीड-ओनली से शुरू करें और जितनी जरुरत हो उतनी पहुँच दें। AI-जनरेटेड कोड अक्सर परमिसिव शुरू होता है क्योंकि इससे टेस्ट पास हो जाते हैं।

त्वरित सत्यापन के लिए एक छोटा एक्सेस मैट्रिक्स बनाएं और इसे UI और API दोनों में आज़माएँ:

• हर रोल के लिए मुख्य ऑब्जेक्ट्स पर create/read/update/delete की पुष्टि करें।
• ओनरशिप चेक करें: यूज़र्स को केवल अपने रिकॉर्ड दिखने चाहिए जब तक स्पष्ट रूप से शेयर न किया गया हो।
• एक अनुमान लगाने की कोशिश करें: किसी आइटम का ID बदल कर दूसरे यूज़र का आइटम खोलें।
• सुनिश्चित करें कि केवल एडमिन-ऑनली क्रियाएँ वास्तव में एडमिन-ओनली हैं (billing, exports, user management)।
• "छुपा हुआ" एक्सेस न छोड़ें: लिस्ट एंडपॉइंट्स, सर्च, डाउनलोड्स भी जाँचें।

ओनरशिप चेक्स विशेष ध्यान के पात्र हैं। “User can read Task” काफी नहीं है। इसे होना चाहिए “user can read Task where task.ownerId == user.id” (या यूज़र workspace का सदस्य हो)।

एज़ केस जहाँ लीक होते हैं: invited-but-not-accepted यूज़र्स, deleted अकाउंट्स, पुरानी सेशन्स के साथ हटाए गए workspace सदस्य। एक छोड़ी हुई एज़ केस एक हफ्ते के क्लीनअप में बदल सकती है।

अगर आप Koder.ai का उपयोग कर रहे हैं, तो असिस्टेंट से कहें कि बदलाव स्वीकार करने से पहले रोल्स और एक एक्सेस टेबल आउटपुट करे, फिर हर रोल के लिए दो टेस्ट अकाउंट से सत्यापित करें।

डेस्ट्रक्टिव एक्शन्स: आकस्मिक डेटा नुकसान रोकें

डेस्ट्रक्टिव एक्शन्स सबसे तेज़ रास्ता हैं एक छोटी गलती से दिनों के क्लीनअप तक पहुंचने का।

पहले सूचीबद्ध करें जो कुछ भी डेटा मिटा या ओवरराइट कर सकता है। यह केवल डिलीट बटन नहीं है। यह रीसेट, सिंक, इम्पोर्ट/रिप्लेस, रीबिल्ड इंडेक्स, सीड एक्शन्स, और ब्रॉड एडमिन टूल्स भी हैं।

कुछ स्पष्ट सुरक्षा संकेत खोजें:

• खतरनाक क्रियाओं के लिए स्पष्ट कन्फर्मेशन (type-to-confirm सबसे अच्छा)।
• स्कोप्ड इम्पैक्ट (एक रिकॉर्ड, एक यूज़र, एक वर्कस्पेस), न कि आसान "सब"।
• किसने ट्रिगर किया और क्या प्रभावित हुआ इसका लॉगिंग।
• सेफ डिफ़ॉल्ट्स जैसे dry run, preview, या डिलीट की बजाय archive।

अधिकांश यूज़र-जनरेटेड डेटा के लिए सॉफ्ट-डिलीट पसंद करें। एक सरल deleted_at फ़ील्ड और फिल्टरिंग रीकवर की सुविधा देती है और यदि बाद में कोई बग दिखे तो समय खरीद लेती है।

स्कीमा बदलावों को भी संभवतः डेस्ट्रक्टिव माना जाना चाहिए। कॉलम ड्रॉप करना, टाइप बदलना, और कॉन्स्ट्रेंट्स कसेना डेटा खो सकता है भले ही कोई डिलीट एंडपॉइंट कॉल न करे। अगर AI ने माइग्रेशन सुझाया है, तो पूछें: मौजूदा रो पर क्या होगा, और हम उसे कैसे बहाल कर सकते हैं?

अगर आप रोलबैक प्लान एक वाक्य में समझा नहीं सकते, तो डेस्ट्रक्टिव बदलाव अभी शिप न करें।

डिप्लॉयमेंट सेटिंग्स: छोटी कॉन्फ़िग गलतियाँ जो नुकसान पहुँचाती हैं

अधिकांश क्लीनअप कहानियाँ एक ही तरह से शुरू होती हैं: ऐप डेव में काम कर रहा था, फिर प्रोडक्शन अलग व्यवहार करने लगा।

उद्देश्य से डेव और प्रोड को अलग रखें: अलग डेटाबेस, कीज़, बकेट, और ईमेल प्रोवाइडर। अगर दोनों एन्वाइरनमेंट एक ही डेटाबेस की ओर इशारा करते हैं, एक टेस्ट स्क्रिप्ट असली डेटा को प्रदूषित कर सकती है, और एक "क्विक रीसेट" उसे मिटा सकता है।

अगला, सीक्रेट्स देखें। अगर आप कॉन्फ़िग फ़ाइल, प्रॉम्प्ट या कमिट संदेश में कीज़ देखते हैं, तो मान लीजिए वे लीक हो जाएंगे। सीक्रेट्स को डिप्लॉय के समय इंजेक्ट किया जाना चाहिए (env vars या सीक्रेट्स मैनेजर)। यदि प्रोडक्शन आवश्यक सीक्रेट गायब है तो स्टार्ट होने पर फेल होना चाहिए—यह साइलेंट फॉलबैक से सस्ता है।

फिर ब्राउज़र-फेसिंग सेटिंग्स चेक करें: allowed origins (CORS), redirect URLs, OAuth callback URLs। ये लगभग मेल खाने में आसान हैं, और यही कारण है कि आपका लॉगिन “टूटा” दिख सकता है जबकि कोड ठीक हो।

एक 5-मिनट डिप्लॉयमेंट चेक:

• डेव और प्रोड अलग डेटाबेस और कीज़ का उपयोग करते हैं।
• सीक्रेट्स हार्डकोड न हों, इन्हें इंजेक्ट किया गया हो।
• ऑरिजिन्स, रिडायरेक्ट्स और कॉलबैक्स असली डोमेन से मेल खाते हों।
• कस्टम डोमेन बेसिक्स सही हों (DNS सही जगह पॉइंट करता है, HTTPS अपेक्षित है)।
• प्रोडक्शन लॉगिंग और एरर रिपोर्टिंग ऑन हों (बिना संवेदनशील डेटा लॉग किए)।

अगर आप Koder.ai से डिप्लॉय कर रहे हैं, तो यह भी एक अच्छा समय है यह कन्फर्म करने का कि आपने सही एन्वायरनमेंट डिप्लॉय किया है और अगर कुछ गड़बड़ लगे तो रोलबैक उपलब्ध है।

60-सेकंड प्री-मर्ज चेकलिस्ट

AI-जनरेटेड बदलाव स्वीकार करने और शिप करने से पहले एक मिनट रुकें। आप स्टाइल की समीक्षा नहीं कर रहे; आप उन गलतियों की तलाश कर रहे हैं जो लंबे क्लीनअप में बदल जाती हैं।

• स्कीमा: क्या एंटिटीज़ तर्कसंगत हैं? रिलेशनशिप सही हैं? कॉन्स्ट्रेंट्स मौजूद हैं (unique, not null)? क्या ग्रोथ क्वेरीज़ या स्टोरेज तोड़ देगी?
• ऑथ: क्या यह default-deny है? क्या आप समझा सकते हैं कि कौन कौन सा रिसोर्स create/read/update/delete कर सकता है? क्या ownership चेक्स सर्वर-साइड लागू हैं (सिर्फ UI में नहीं)?
• डेस्ट्रक्टिव एक्शन्स: क्या अपरिवर्तनीय एक्शन्स के लिए कन्फर्मेशन है? जहाँ चाहिए वहाँ सॉफ्ट-डिलीट है? रोलबैक प्लान (स्नैपशॉट, बैकअप, reversible migration) है?
• डिप्लॉयमेंट: क्या डेव और प्रोड अलग हैं? क्या सीक्रेट्स कोड/लॉग में नहीं हैं? क्या डोमेन और रिडायरेक्ट सही हैं?

एक उदाहरण: आप "admin delete user" फीचर मर्ज कर देते हैं। 60 सेकंड में आप नोटिस करते हैं कि बैकएंड में कोई रोल चेक नहीं है, सिर्फ़ छुपा UI बटन है। एक असली यूज़र डायरेक्ट एंडपॉइंट को कॉल कर सकता है। यह एक पकड़ आपको एक घटना से बचा सकती है।

एक ऐसा सवाल पूछकर खत्म करें जो हकीकत पर जोर दे:

यहाँ एक असल यूज़र इरादतन या गलतियाँ करके सबसे बुरा क्या कर सकता है?

अगर उत्तर में "दूसरों का डेटा डिलीट करना", "निजी रिकॉर्ड देखना" या "प्रोडक्शन तोड़ना" शामिल है, तो रुकें और बदलाव को कड़ा करें।

उदाहरण: एक 5-मिनट समीक्षा जो एक हफ्ते के क्लीनअप को रोकती है

आप एक छोटा CRM बना रहे हैं और AI टूल से ग्राहक पेज पर "Delete customer" बटन जोड़ने को कहते हैं। मिनटों में यह UI, एक बैकएंड एंडपॉइंट, और संबंधित रिकॉर्ड हटाने के लिए एक डेटाबेस बदलाव जनरेट कर देता है।

सब कुछ काम करता दिखता है: बटन दिखता है, रिक्वेस्ट 200 लौटाता है, और ग्राहक सूची से गायब हो जाता है। कई टीमें आगे बढ़ जातीं।

एक 5-मिनट समीक्षा दो समस्याएँ पकड़ लेती है:

1. डेटाबेस बदलाव cascade delete उपयोग कर रहा है जो invoices और activity logs भी हटा देता है। टेस्ट डेटा के लिए ठीक हो सकता है, पर असली CRM में यह रिपोर्टिंग, ऑडिट और ग्राहक इतिहास को तोड़ देता है।
2. एंडपॉइंट केवल यह चेक करता है कि यूज़र साइन इन है, न कि कि वह एडमिन है। कोई भी स्टाफ सदस्य किसी भी ग्राहक को हटा सकता है।

व्यवहार में एक त्वरित समीक्षा:

• गैर-एडमिन टेस्ट यूज़र के रूप में बटन क्लिक करें और पुष्टि करें कि यह फ़ेल होना चाहिए।
• एंडपॉइंट देख कर सुनिश्चित करें कि यह बिना सही रोल के अनुरोध अस्वीकार कर दे।
• स्कीमा स्कैन करें और पुष्टि करें कि invoices, notes, और logs का क्या होता है।
• UI पुष्टि करता है कि क्या डिलीट होगा और कन्फर्मेशन माँगता है।
• यह सुनिश्चित करें कि आप सही डेटाबेस के खिलाफ टेस्ट कर रहे हैं।

एक प्रॉम्प्ट ट्वीक से ये ठीक हो जाता है:

"Make delete customer a soft delete. Keep invoices and logs. Only admins can delete. Add a confirmation step that requires typing DELETE. Return a clear error message when unauthorized."

फिर इसे दोबारा टूटने से रोकने के लिए प्रोजेक्ट नोट्स में तीन बातें डॉक्यूमेंट करें: डिलीट नियम (soft vs hard), परमिशन आवश्यकता (कौन डिलीट कर सकता है), और अपेक्षित साइड-इफ़ेक्ट्स (कौन सा संबंधित डेटा रहता है)।

ऐसी प्रॉम्प्ट्स जो बदलाव स्वीकार करने से पहले स्पष्टता मजबूर करें

AI आउटपुट आत्मविश्वासी लग सकता है जबकि वह अनुमान छुपा रहा हो। लक्ष्य उन अनुमानों को दिखाना है।

शब्द जो फॉलो-अप सवाल ट्रिगर करने चाहिए: “assume”, “default”, “simple”, “should”, “usually”. अक्सर इनका मतलब होता है "मैंने कुछ चुना बिना पुष्टि किए कि यह आपके ऐप पर फिट बैठता है।"

उपयोगी प्रॉम्प्ट पैटर्न:

"Rewrite your proposal as acceptance criteria. Include: required fields, error states, and 5 edge cases. If you made assumptions, list them and ask me to confirm."

दो और प्रॉम्प्ट जो जल्दी जोखिम उजागर करते हैं:

• "Show the data model changes as a before/after table. For each field: type, nullability, default, and migration risk."
• "List all destructive operations you introduced (drop table/column, delete endpoints, cascade rules). For each, show how to undo it and what data is lost."

ऑथ के लिए:

"Show roles and permissions for each API route and UI action. For every role: allowed actions, denied actions, and one example request that should fail."

निर्णय करें कि क्या हमेशा मानव-के द्वारा सत्यापित होना चाहिए, और इसे छोटा रखें:

• ऑथ नियम और एडमिन एक्शन्स
• डिलीट, कैस्केड्स, अपरिवर्तनीय माइग्रेशंस
• एन्वायरनमेंट और डिप्लॉयमेंट सेटिंग्स (प्रोड बनाम स्टेजिंग)
• पेमेंट, ईमेल, और यूज़र-डेटा फ्लोज़
• रोलबैक प्लान (स्नैपशॉट या रिलीज़ प्वाइंट)

सामान्य गलतियाँ जो क्लीनअप को दिनों का बनाए रखती हैं

ज्यादातर लंबे क्लीनअप की शुरुआत एक ही छोटी पसंद से होती है: आउटपुट पर भरोसा करना क्योंकि वह अभी काम कर रहा है।

"It works on my machine" क्लासिक जाल है। फीचर लोकल टेस्ट्स पास कर सकता है और फिर भी असली डेटा साइज, असली परमिशन, या थोड़ा सा अलग एन्वायरनमेंट होने पर फेल कर सकता है। फिक्स आपातकालीन पैचों की ढेर बन जाता है।

स्कीमा ड्रिफ्ट एक और चुंबक है। जब टेबल्स बिना स्पष्ट नामों, कॉन्स्ट्रेंट्स और डिफॉल्ट्स के विकसित होते हैं, तो आप वन-ऑफ माइग्रेशंस और अजीब वर्कअराउंड्स के साथ फँस जाते हैं। बाद में कोई पूछता है, "status का क्या मतलब है?" और कोई जवाब नहीं देता।

ऑथ को बाद में जोड़ना कष्टकर है क्योंकि यह अनुमान बदल देता है। अगर आप सब कुछ इस तरह बनाते हैं कि हर यूज़र सब कुछ कर सके, तो आप कई एंडपॉइंट्स और स्क्रीन में सुराख़ भरने में हफ्तों बिता देंगे।

डेस्ट्रक्टिव एक्शन्स सबसे ज़ोरदार तबाहियाँ कराते हैं। "Delete project" या "reset database" लागू करना आसान है और पछताना आसान है जब तक सॉफ्ट-डिलीट, स्नैपशॉट्स या रोलबैक प्लान न हो।

कुछ बार-बार होने वाले कारण जो बहु-दिवसीय क्लीनअप पैदा करते हैं:

• कॉन्स्ट्रेंट्स के बिना स्कीमा बदलाव (unique, not null, foreign keys)
• सिर्फ UI-स्तर पर परमिशन नियम न रख कर, सर्वर-साइड चेक्स न करना
• कन्फर्मेशन और रीकवरी के बिना डिलीट एंडपॉइंट्स
• स्टेजिंग और प्रोडक्शन को "आधारभूत रूप से एक जैसा" मानना
• किसने क्या बदला इसका कोई रिकॉर्ड न रखना

अगले कदम: चेकपॉइंट्स को अपने निर्माण के तरीके में शामिल करें

चेकपॉइंट्स को टिकाने का सबसे आसान तरीका है उन्हें उन पलों के साथ जोड़ना जो आपके पास पहले से हैं: फीचर शुरू करते समय, मर्ज करते समय, डिप्लॉय करते समय, और सत्यापित करते समय।

एक हल्का वजन वाला रिद्म:

• बिल्ड करने से पहले: डेटा आकार (टेबल्स, की फ़ील्ड्स) और रोल्स (कौन read/create/update/delete कर सकता है) पर सहमति बनाएं।
• मर्ज से पहले: ऑथ, डेस्ट्रक्टिव एक्शन्स, और जो कुछ भी प्रोडक्शन डेटा को छूता है उसके लिए 60-सेकंड पास करें।
• डिप्लॉय से पहले: एन्वायरनमेंट सेटिंग्स (डोमेन, सीक्रेट्स, ईमेल, स्टोरेज, रीजन) लक्षित के अनुरूप हैं यह कन्फर्म करें।
• डिप्लॉय के बाद: एक असली यूज़र फ्लो एंड-टू-एंड चलाएँ।

अगर आप Koder.ai में काम करते हैं, तो उसकी planning mode "बिल्ड करने से पहले" चेकपॉइंट के रूप में काम कर सकता है: जिन निर्णयों को आपने लिखा है (जैसे “orders signed-in users बना सकते हैं, पर status केवल admins बदल सकते हैं”) उन्हें जनरेट करने से पहले नोट कर लें। स्नैपशॉट्स और रोलबैक भी इसे आसान बनाते हैं ताकि “मुझे यकीन नहीं है” का अर्थ तुरंत revert कर के बेहतर प्रॉम्प्ट के साथ फिर से जनरेट करना हो सके।

पाँच मिनट हर चीज़ को पकड़ नहीं पाएगा। पर यह महँगी गलतियों को तब पकड़ता है जब वे अभी भी सस्ती हों।