27 अक्टू॰ 2025·8 मिनट
Joel Spolsky की सॉफ़्टवेयर सच्चाइयाँ — AI-सहायित विकास के लिए
जब AI तेज़ कोड लिखता है तब भी Joel Spolsky की सॉफ़्टवेयर सच्चाइयाँ काम आती हैं। जानिए कैसे टेस्ट, हायरिंग और सादगी पर ध्यान कर के करेक्टनेस बनाए रखें।
जब AI तेज़ कोड लिखता है तब भी Joel Spolsky की सॉफ़्टवेयर सच्चाइयाँ काम आती हैं। जानिए कैसे टेस्ट, हायरिंग और सादगी पर ध्यान कर के करेक्टनेस बनाए रखें।
AI मिनटों में दिखने में काम करता कोड बना सकता है। इससे प्रोजेक्ट की गति बदल जाती है, पर सफल सॉफ़्टवेयर क्या बनाता है वह नहीं बदलता। Joel Spolsky की “software truths” कभी सिर्फ टाइपिंग स्पीड के बारे में नहीं थीं—वे जजमेंट, फीडबैक लूप, और खुद बनायी गई जटिलता से बचने के बारे में थीं।
जो बदल गया है वह कोड बनाने की कीमत है। आप तीन approaches, पाँच वेरिएंट, या पूरा री-राइट माँग सकते हैं और तुरंत कुछ वापस पा सकते हैं। जो नहीं बदला वह सही तरीका चुनने, उसे चेक करने, और महीनों तक उसके साथ रहने की कीमत है। लिखने में बचाया गया समय अक्सर यह तय करने में लग जाता है कि आपका मतलब क्या था, किन किन एज़ केसों को वैलिडेट करना है, और यह सुनिश्चित करने में कि आज की त्वरित जीत कल का मेंटेनेंस टैक्स न बने।
कर्रेक्टनेस, सुरक्षा, और मेंटेनबिलिटी अभी भी असली समय लेती हैं क्योंकि वे आत्म-विश्वास पर नहीं बल्कि सबूत पर निर्भर करते हैं। एक लॉगिन फ़्लो तब पूरा नहीं होता जब वह कंपाइल हो जाए; वह तब पूरा होता है जब वह भरोसेमंद तरीके से गलत इनपुट रिजेक्ट करे, अजीब स्टेट्स संभाले, और डेटा लीक न हो। AI निश्चित सुनाई दे सकता है पर एक क्रूशियल डिटेल, जैसे किसी एंडपॉइंट पर permissions चेक या पेमेंट अपडेट में race condition, चूक सकता है।
AI सबसे ज़्यादा उपयोगी तब है जब आप उसे एक तेज़ ड्राफ्ट मशीन की तरह ट्रीट करते हैं। यह boilerplate, दोहराव वाले पैटर्न, त्वरित रिफैक्टर और विकल्पों के एक्सप्लोरेशन में चमकता है। अच्छे उपयोग पर यह “खाली पन्ना” चरण को संकुचित कर देता है।
AI सबसे ज़्यादा हानि पहुँचाता है जब आप उसे vague लक्ष्य देते हैं और आउटपुट को बिना जाँचे स्वीकार कर लेते हैं। वही फ़ेल्योर पैटर्न बार-बार दिखते हैं: छिपी हुई धारणाएँ (अनकही बिजनेस रूल्स), अनटेस्टेड पाथ्स (एरर हैंडलिंग, retries, empty states), आत्म-विश्वासी गलतियाँ (ऐसी कोड जो दिखने में सही पर सूक्ष्म रूप से गलत है), और “क्लेव्हर” सॉल्यूशंस जिन्हें बाद में समझाना मुश्किल होता है।
अगर कोड सस्ता है, तो नया दुर्लभ संसाधन भरोसा है। ये सच्चाइयाँ इसलिए मायने रखती हैं क्योंकि वे उस भरोसे को बचाती हैं: उपयोगकर्ताओं के साथ, टीम के साथ, और आपके भविष्य के स्वयं के साथ।
जब AI मिनटों में फीचर जनरेट कर सकता है, तो टेस्टिंग को धीमा हिस्सा मानकर खत्म करने की इच्छा हो सकती है। Spolsky का पॉइंट अभी भी लागू है: धीमा हिस्सा ही सच है। कोड बनाना आसान है; सही व्यवहार बनाना नहीं।
एक उपयोगी बदलाव यह है कि टेस्ट्स को रन करने योग्य आवश्यकताएँ समझें। अगर आप अपेक्षित व्यवहार को जाँचे जाने योग्य तरीके से बयान नहीं कर सकते, तो आप सोचने का काम पूरा नहीं कर रहे। AI-सहायित काम में यह और भी ज़्यादा महत्वपूर्ण है, क्योंकि मॉडल आत्म-विश्वास से कुछ ऐसा दे सकता है जो थोड़ा सा गलत हो।
टेस्टिंग उस चीज़ से शुरू करें जिसका टूटना सबसे ज़्यादा नुक़सान पहुँचाएगा। अधिकांश प्रोडक्ट्स के लिए यह core flows (signup, checkout, save, export), permissions (कौन देख/एडिट/डिलीट कर सकता है), और डेटा इंटीग्रिटी (डुप्लिकेट न हों, सही टोटल्स, सुरक्षित माईग्रेशन) होते हैं। फिर वे एज जो देर रात की घटनाओं का कारण बनते हैं: खाली इनपुट, लंबा टेक्स्ट, टाइमज़ोन, retries, और flaky बाहरी सीमाएँ जैसे payments, emails, और file uploads।
AI टेस्ट केस सुझाने में बेहतरीन है, पर वह यह नहीं जान सकता कि आपने उपयोगकर्ताओं से क्या वादा किया था। इसे ब्रेनस्टॉर्मिंग पार्टनर की तरह उपयोग करें: गुम हुए एज केस, दुर्व्यवहार स्थितियाँ, और permission संयोजनों के लिए पूछें। फिर इंसानी काम करें: कवरेज को अपनी वास्तविक नियमों से मिलाएँ और उन टेस्ट्स को निकाल दें जो केवल “इम्प्लीमेंटेशन” को टेस्ट करते हैं बजाय व्यवहार के।
फेल्योर को actionable बनाइए। एक फेलिंग टेस्ट को बताना चाहिए कि क्या टूटा, आपको खोज में नहीं भेजना चाहिए। टेस्ट्स छोटे रखें, उनका नाम वाक्य जैसा रखें, और एरर मैसेज विशिष्ट बनाएं।
मान लीजिए आप एक साधारण “team notes” ऐप बनाते हैं AI की मदद से। CRUD स्क्रीन जल्दी बन जाती हैं। करेक्टनेस रिस्क UI में नहीं है; यह access control और डेटा नियमों में है: एक यूज़र को दूसरी टीम के नोट्स नहीं दिखने चाहिए, एडिट्स को नए चेंजेस ओवरराइट नहीं करना चाहिए, और नोट डिलीट करने पर orphaned attachments नहीं छोड़ने चाहिए। इन नियमों को लॉक करने वाले टेस्ट्स बोतलगर्दी जैसा महसूस हो सकते हैं, पर वे आपकी सुरक्षा जाल हैं।
जब टेस्टिंग बोतलगर्दी होती है, तो वह स्पष्टता मजबूर करती है। वही स्पष्टता तेज़ कोड को तेज़ बग में बदलने से रोकती है।
सबसे टिकाऊ सच्चाइयों में से एक यह है कि सादा कोड चालाक कोड से जीतता है। AI से पॉलिश और तेज़ रूप में फैंसी एब्स्ट्रैक्शन स्वीकार करने का प्रलोभन आता है। लागत बाद में दिखती है: बग छिपने के और स्थान, फ़ाइलें बढ़ना, और “यह क्या कर रहा है?” के पल।
जब कोड सस्ता है, तो आप जटिलता के लिए भुगतान करते हैं। एक छोटा, उबाऊ डिज़ाइन टेस्ट करने में आसान, बदलने में आसान, और समझाने में आसान होता है। यह उस समय और भी ज़्यादा मायने रखता है जब पहला ड्राफ्ट किसी ऐसे मॉडल से आया हो जो आत्म-विश्वासी सुनाई दे सकता है पर सूक्ष्म रूप से गलत हो।
व्यावहारिक नियम यह है कि फंक्शन्स, कंपोनेंट्स, और मॉड्यूल इतने छोटे रखें कि कोई टीममेट उन्हें मिनटों में रिव्यू कर सके, घंटों में नहीं। अगर एक React कंपोनेंट को कई कस्टम hooks, एक लोकल स्टेट मशीन, और एक generic “smart renderer” लेयर चाहिए, तो रुकें और पूछें कि क्या आप असल में एक असली समस्या हल कर रहे हैं या बस आर्किटेक्चर को स्वीकार कर रहे हैं क्योंकि AI ने यह सुझाया।
कुछ “सादगी परीक्षण” आपको पीछे धकेलने में मदद करेंगे:
प्रॉम्प्ट्स यहाँ मायने रखते हैं। अगर आप “सबसे अच्छा आर्किटेक्चर” माँगते हैं, तो अक्सर आपको ओवरबिल्ट आर्किटेक्चर मिलता है। सीमाएँ माँगें जो कम मूविंग पार्ट्स की ओर धकेलें। उदाहरण: सबसे कम फ़ाइलों के साथ सबसे सरल तरीका; नई एब्स्ट्रैक्शन से बचें जब तक वह तीन या अधिक स्थानों पर डुप्लीकेशन न हटाए; जनरिक हेल्पर्स की जगह स्पष्ट कोड पसंद करें।
एक ठोस उदाहरण: आप AI से admin पेज में role-based access जोड़ने के लिए कहते हैं। क्लेव्हर वर्ज़न में permission framework, decorators, और config DSL आ जाता है। सरल वर्ज़न में एक जगह पर user role चेक होता है, रूट्स एक जगह पर गेट होते हैं, और denied access लॉग किया जाता है। सरल वर्ज़न रिव्यू करने में आसान, टेस्ट करने में आसान, और गलत व्याख्या के लिए कठिन है।
अगर आप chat-based टूल में जैसे Koder.ai काम कर रहे हैं, तो सादगी snapshots और rollback को भी अधिक मूल्यवान बना देती है। छोटे, स्पष्ट बदलावों की तुलना, रख-रखाव या वापस ले पाना आसान होता है।
जब कोड बनाना आसान हो जाता है, तो दुर्लभ कौशल यह तय करना बन जाता है कि क्या होना चाहिए और यह सुनिश्चित करना कि यह सही है। पुराना “बेहतरीन प्रोग्रामर हायर करो” सलाह अभी भी लागू है, पर काम बदल गया है। आप कोई ऐसा नहीं चाह रहे जो तेज़ी से टाइप करे; आप चाहते हैं जो जज करे, सुधार करे, और प्रोडक्ट का बचाव करे।
AI-सहायित विकास में सबसे मूल्यवान लोग आमतौर पर चार गुण साझा करते हैं: जजमेंट (क्या मायने रखता है), टेस्ट (अच्छा कैसा दिखता है), डिबगिंग स्किल (असल कारण ढूँढना), और कम्युनिकेशन (ट्रेडऑफ़्स स्पष्ट करना)। वे AI-लिखित फीचर को जो “लगभग काम करता है” उसे भरोसेमंद बनाने में बदल सकते हैं।
पूर्ण समाधान माँगने के बजाय उम्मीदवार को एक AI-जनरेटेड pull request (या पेस्ट किया गया diff) दें जिसमें कुछ वास्तविक समस्याएँ हों: अस्पष्ट नामकरण, एक छिपा हुआ एज केस, मिसिंग टेस्ट, और एक छोटी सुरक्षा गलती।
उनसे कहें कि वे कोड का उद्देश्य सादे शब्दों में बताएं, सबसे जोखिम भरे हिस्सों की पहचान करें, फिक्स सुझाएँ, और ऐसे टेस्ट जोड़ें (या रूपरेखा दें) जो रीग्रेशन पकड़ सकें। यदि आप मजबूत सिग्नल चाहते हैं, तो उनसे पूछें कि अगली AI कोशिश को बेहतर बनाने के लिए वे निर्देश कैसे बदलेंगे।
यह दर्शाता है कि वे असली परिस्थितियों में कैसे सोचते हैं: अपूर्ण कोड, सीमित समय, और प्राथमिकताएँ चुनने की आवश्यकता।
AI अक्सर आत्म-विश्वासी लगता है। अच्छे हायर किए गए लोग पीछे धकेलने में सहज होते हैं। वे जटिलता बढ़ाने वाले फीचर को ना कह सकते हैं, सुरक्षा कमजोर करने वाले चेंज को ना कह सकते हैं, और बिना सबूत के शिप करने को ना कह सकते हैं।
एक ठोस संकेत यह है कि वे “क्या आप इसे मर्ज करेंगे?” पर कैसे प्रतिक्रिया देते हैं। मजबूत उम्मीदवार केवल एक आभास से जवाब नहीं देते; वे निर्णय देते हैं और आवश्यक बदलावों की एक छोटी सूची देते हैं।
उदाहरण: आप “quick” access-control अपडेट माँगते हैं और AI सुझाव देता है कि चेक हैंडलर्स में बिखेर दिए जाएँ। एक मजबूत उम्मीदवार उस अप्रोच को अस्वीकार करता है और एक स्पष्ट authorization लेयर प्रस्तावित करता है, साथ में admin और non-admin पाथ्स के लिए टेस्ट।
अंत में, साझा मानक बनाइए ताकि टीम AI आउटपुट को एक ही तरीके से एडिट करे। इसे सरल रखें: एक definition of done, सुसंगत रिव्यू अपेक्षाएँ, और एक टेस्टिंग बेसलाइन।
जब AI मिनटों में बहुत सारा कोड जनरेट कर सकता है, तो सोच को छोड़कर बस इटरेट करना लुभावना होता है। डेमो के लिए यह काम कर सकता है। वह टूटता है जब आपको करेक्टनेस, अनुमानित व्यवहार, और कम सरप्राइज़ चाहिए।
एक अच्छा प्रॉम्प्ट आमतौर पर एक छोटा स्पेक होता है। कोड मांगने से पहले अस्पष्ट लक्ष्य को कुछ एक्सेप्टेंस क्राइटेरिया और स्पष्ट नॉन-गोल्स में बदल दें। यह AI (और आपकी टीम) को चुपचाप स्कोप बढ़ाने से रोकेगा।
स्पेक को छोटा पर विशिष्ट रखें। आप उपन्यास नहीं लिख रहे; आप उन सीमाओं को सेट कर रहे हैं:
"डन" को जनरेशन के बाद नहीं बल्कि पहले परिभाषित करें। "डन" केवल "यह कंपाइल होता है" या "UI सही दिखता है" से अधिक होना चाहिए। टेस्ट अपेक्षाएँ, बैकवर्ड कम्पैटिबिलिटी, और रिलीज के बाद क्या मॉनिटर किया जाएगा शामिल करें।
उदाहरण: आप चाह रहे हैं “पासवर्ड रिसेट जोड़ो।” एक साफ स्पेक कह सकता है: उपयोगकर्ता ईमेल के जरिए रिसेट का अनुरोध करते हैं; लिंक 15 मिनट में एक्सपायर हो; चाहे ईमेल मौजूद हो या नहीं, वही संदेश दिखे; प्रति IP rate limit; टोकन प्लेन टेक्स्ट में न स्टोर किए जाएँ बल्कि रिसेट प्रयास लॉग किए जाएँ। नॉन-गोल: लॉगिन पेज का redesign नहीं। अब आपका प्रॉम्प्ट गार्डरेल्स के साथ है और रिव्यू आसान हो जाते हैं।
फैसलों का एक हल्का चेंज-लॉग रखें। हर निर्णय के लिए एक पैराग्राफ पर्याप्त है। बताइए कि आपने कोई अप्रोच क्यों चुना और वैकल्पिक अप्रोच को क्यों नकारा। जब कोई दो हफ्ते बाद पूछे "यह ऐसा क्यों है?" तो आपके पास जवाब होगा।
AI के साथ सबसे बड़ा बदलाव यह है कि कोड बनाना आसान हो गया है। कठिन हिस्सा यह तय करना और साबित करना है कि कोड क्या करना चाहिए।
शुरुआत इस बात से करें कि लक्ष्य और सीमाएँ सादे शब्दों में लिखें। बताइए कि क्या कभी नहीं होना चाहिए, क्या धीमा हो सकता है, और क्या आउट-ऑफ़-स्कोप है। एक अच्छा constraint टेस्टेबल होना चाहिए: “कोई यूज़र दूसरे यूज़र का डेटा न देखे,” या “टोटल्स फाइनेंस एक्सपोर्ट से सेंट तक मेल खाये।”
कोड माँगने से पहले सरल डिज़ाइन और tradeoffs माँगें। आप चाहते हैं कि AI अपना तर्क एक ऐसी फ़ॉर्म में दिखाए जिसे आप जज कर सकें: यह क्या स्टोर करेगा, क्या वैलिडेट करेगा, और क्या लॉग करेगा। अगर यह कुछ क्लेव्हर सुझाता है, तो पीछे धकेलों और उस सबसे सरल वर्ज़न को माँगें जो अभी भी constraints को पूरा करे।
दोहराने योग्य लूप इस तरह दिखता है:
एक छोटा परिदृश्य: आप ऑर्डर स्क्रीन में “refund status” जोड़ते हैं। AI UI जल्दी बना सकता है, पर करेक्टनेस एज केसों में रहती है। अगर refund partial है तो क्या होता है? पेमेंट प्रोवाइडर webhook retries करे तो क्या? पहले ये केस लिखिए, फिर एक स्लाइस (डेटाबेस कॉलम + वैलिडेशन) इम्प्लीमेंट करें और टेस्ट के साथ वेरिफाई करें।
अगर आप Koder.ai का उपयोग करते हैं, तो planning mode, snapshots, और rollback इस लूप में स्वाभाविक रूप से फ़िट होते हैं: पहले योजना बनाइए, स्लाइस में जनरेट करिए, और हर महत्वपूर्ण परिवर्तन के लिए एक सुरक्षित restore पॉइंट कैप्चर करिए।
जब कोड जनरेशन तेज़ होता है, तो कोड को ही काम समझ लेने की लत लग जाती है। यह काम नहीं है—काम व्यवहार है: ऐप सही तरीके से काम करे, भले ही चीज़ें गलत हो जाएँ।
AI अक्सर निश्चित सुनाई देता है, भले ही वह अनुमान लगा रहा हो। विफलता बोरिंग हिस्से को छोड़ देने में है: टेस्ट चलाना, एज केस चेक करना, और असली इनपुट्स को वैलिडेट करना।
एक सरल आदत मदद करती है: किसी चेंज को स्वीकार करने से पहले पूछें “हमें कैसे पता चलेगा कि यह सही है?” अगर जवाब “यह सही दिखता है” है तो आप जुआ खेल रहे हैं।
AI एक्स्ट्रा चीज़ें जोड़ना पसंद करता है: caching, retries, और अधिक सेटिंग्स। कुछ अच्छे विचार हो सकते हैं, पर वे रिस्क बढ़ाते हैं। कई बग “नाइस-टू-हैव” फीचर्स से आते हैं जिन्हें किसी ने नहीं माँगा।
एक कठोर सीमा रखें: वही समस्या सॉल्व करें जो आपने तय की थी, फिर रुकें। अगर कोई सुझाव मूल्यवर्धक है तो उसे अलग टास्क बनाकर रखें और उसके अपने टेस्ट हों।
एक बड़ा AI-जनरेटेड कमिट दर्जनों असंबंधित निर्णय छिपा सकता है। रिव्यू rubber-stamping बन जाता है क्योंकि कोई भी उसे पूरी तरह पकड़ नहीं सकता।
चैट आउटपुट को ड्राफ्ट मानें। इसे छोटे चेंजेस में बाँटें जिन्हें आप पढ़ सकें, चला सकें, और revert कर सकें। snapshots और rollback तभी उपयोगी हैं जब आप उन्हें समझदारी से लेते हैं।
कुछ सरल सीमाएँ अधिकांश दर्द रोकेंगी: एक फीचर प्रति चेंज सेट, एक migration प्रति चेंज सेट, एक high-risk एरिया (auth, payments, data deletion) पर काम, टेस्ट उसी चेंज में अपडेटेड, और एक स्पष्ट “कैसे वेरिफाई करें” नोट।
AI प्रशिक्षण डेटा से पैटर्न दोहरा सकता है या dependencies सुझा सकता है जिन्हें आप नहीं समझते। लाइसेंस ठीक होने पर भी बड़ा जोखिम सुरक्षा है: हार्ड-कोडेड सीक्रेट्स, कमजोर टोकन हैंडलिंग, या unsafe फ़ाइल/क्वेरी ऑपरेशन।
अगर आप किसी स्निपेट को समझा नहीं सकते तो उसे शिप मत कीजिए। सरल वर्ज़न माँगें या उसे खुद फिर से लिखें।
कई "मेरा मशीने पर काम कर रहा है" बग असल में डेटा या स्केल बग होते हैं। AI स्कीमा चेंज बना सकता है बिना मौजूदा रोज़, बड़े टेबल्स, या डाउनटाइम के बारे में सोचे।
एक वास्तविक उदाहरण: मॉडल PostgreSQL टेबल में नया NOT NULL कॉलम जोड़ता है और उसे slow loop में backfill करता है। प्रोडक्शन में यह टेबल लॉक कर सकता है और ऐप बिगड़ सकता है। हमेशा सोचें कि एक मिलियन रोज़, धीमा नेटवर्क, या डिप्लॉय के बीच में फेल होने पर क्या होगा।
कल्पना कीजिए एक छोटा internal request tracker: लोग अनुरोध सबमिट करते हैं, मैनेजर अप्रूव/रिजेक्ट करते हैं, और finance आइटम को paid के रूप में मार्क करता है। यह सरल लगता है, और AI की मदद से आप स्क्रीन और endpoint जल्दी बना सकते हैं। जो चीज़ आपको धीमा करती है वह वही पुरानी सच्चाई है: नियम, न कि टाइपिंग।
शुरू करें उन न्यूनतम चीजों को लिखकर जो सही होने चाहिए। अगर आप इसे सादे शब्दों में समझा नहीं सकते तो आप टेस्ट नहीं कर सकते।
एक सख्त पहली-वर्ज़न परिभाषा अक्सर ऐसी दिखती है: फील्ड्स (title, requester, department, amount, reason, status, timestamps); रोल्स (requester, approver, finance, admin); स्टेटस (draft, submitted, approved, rejected, paid)। फिर ट्रांज़िशन बताइए जो मायने रखते हैं: केवल एक approver ही submitted को approved या rejected में बदल सकता है; केवल finance ही approved को paid कर सकता है।
AI को नियंत्रित क्रम में उपयोग करें ताकि आप गलतियाँ जल्दी पकड़ सकें:
सबसे उच्च मूल्य वाले टेस्ट्स “पेज लोड होता है” नहीं होते। वे permission checks और state transitions होते हैं। उदाहरण के लिए साबित करें कि एक requester अपने ही अनुरोध को approve नहीं कर सकता, approver कुछ paid नहीं मार्क कर सकता, rejected अनुरोधों को paid नहीं किया जा सकता, और (अगर आपका नियम है) submission के बाद amounts edit नहीं किए जा सकते।
सबसे ज़्यादा समय एज केस स्पष्ट करने में लगता है। क्या approver rejection के बाद अपना मन बदल सकता है? अगर दो approvers एक ही समय में approve पर क्लिक करें तो क्या होगा? क्या finance partial payment कर सकती है? AI किसी भी उत्तर के लिए कोड बना सकता है, पर वह उन उत्तरों को आपके बजाय नहीं चुन सकता। करेक्टनेस उन कॉल्स को करने और फिर कोड को उन्हें मानने के लिए मजबूर करने से आती है।
AI बहुत तेज़ी से कोड बना सकता है, पर आख़िरी मील अभी भी इंसानी काम है: यह साबित करना कि कोड वही करता है जो आपने चाहा, और अगर नहीं करता तो सुरक्षित तरीके से फेल होना।
चेक्स शुरू करने से पहले, वह सबसे छोटा “डन” परिभाषित करें जो मायने रखता है। छोटे फीचर के लिए वो एक हैप्पी पाथ, दो फेल्योर पाथ, और एक त्वरित पठनीयता पास हो सकता है। पेमेंट्स या auth के लिए मानक ऊँचा रखें।
मान लीजिए AI ने admin स्क्रीन में “bulk invite users” जोड़ा। हैप्पी पाथ काम करता है, पर असली रिस्क एज केस हैं: डुप्लिकेट ईमेल, आंशिक फेल्यर, और rate limits। एक ठोस शिप निर्णय हो सकता है: डुप्लिकेट के लिए एक automated टेस्ट, आंशिक फेल्यर मैसेजिंग के लिए एक मैनुअल चेक, और रोलबैक प्लान।
जब कोड सस्ता हो जाता है, तो रिस्क निर्णय गुणवत्ता में शिफ्ट हो जाता है: आपने क्या माँगा, आपने क्या स्वीकार किया, और आपने क्या शिप किया। इन सच्चाइयों को AI-सहायित काम में लागू कराने का सबसे तेज़ तरीका है गार्डरेल जोड़ना जो “लगभग सही” चेंज्स को फिसलने से रोके।
अगले फीचर के लिए एक पन्ने का स्पेक लिखने से शुरुआत करें। इसे सादा रखें: किसके लिए है, क्या करना चाहिए, क्या नहीं करना चाहिए, और रोजमर्रा की भाषा में कुछ एक्सेप्टेंस टेस्ट। ये एक्सेप्टेंस टेस्ट तब आपका एंकर बनते हैं जब AI कोई आकर्षक शॉर्टकट सुझाता है।
एक गार्डरेल सेट जो बहुत ज़्यादा प्रक्रिया ओवरहेड के बिना स्केल कर सके:
प्रॉम्प्ट्स अब आपके प्रोसेस का हिस्सा हैं। एक हाउस स्टाइल पर सहमति बनाइए: कौन सी लाइब्रेरी की अनुमति है, एरर कैसे हैंडल होते हैं, “डन” क्या मतलब है, और कौन से टेस्ट पास होने चाहिए। अगर एक प्रॉम्प्ट किसी और साथी द्वारा फिर से उपयोग नहीं किया जा सकता, तो वह शायद बहुत vague है।
अगर आप चैट-फर्स्ट तरीका पसंद करते हैं वेब, बैकेंड, और मोबाइल ऐप बनाने के लिए, तो Koder.ai (koder.ai) एक ऐसा उदाहरण है जहाँ planning mode, snapshots, और source code export इन गार्डरेल्स का समर्थन कर सकते हैं। टूल ड्राफ्ट्स को तेज़ कर सकता है, पर अनुशासन वही है जो इंसानों को करेक्टनेस का नियंत्रण में रखता है।
AI आउटपुट को एक फास्ट ड्राफ्ट समझें, तैयार फीचर न मानें। पहले 3–5 पास/फेल एक्सेप्टेंस चेक लिखें, फिर एक छोटा हिस्सा जनरेट करवाएँ (एक endpoint, एक स्क्रीन, या एक migration) और उसे टेस्ट और फेल्योर केस पर वेरिफाई करें।
क्योंकि टेस्ट यही बताते हैं कि कोड सचमुच क्या करता है। AI संभवत: एक पैदावार दे सकता है जो दिखने में ठीक लगे पर वह एक मुख्य नियम (permissions, retries, edge states) छोड़ दे। टेस्ट आपकी उम्मीदों को चलने योग्य, दोहराने योग्य और भरोसेमंद बनाते हैं।
पहले उन चीज़ों से शुरू करें जिनके टूटने पर सबसे ज़्यादा नुकसान होगा:
ऊपर की चीज़ें लॉक होने के बाद कवरेज बढ़ाएँ।
सबसे सरल समाधान माँगें और स्पष्ट सीमाएँ दें, फिर अतिरिक्त परतें तभी रखें जब वे वास्तविक लाभ दें। एक नियम: नई एब्स्ट्रैक्शन तभी जोड़ें जब वह 3+ जगहों पर डुप्लीकेशन हटाए या करेक्टनेस साबित करना आसान करे।
एक छोटा स्पेक लिखें: इनपुट, आउटपुट, एरर, constraints और नॉन-गोल्स। ठोस उदाहरण शामिल करें (नमूना request/response, edge cases)। फिर “डन” को पहले परिभाषित करें: ज़रूरी टेस्ट, बैकवर्ड-कम्पैटिबिलिटी, और कैसे वेरिफाई करना है।
इसे छोटे हिस्सों में बाँट दें:
इससे रिव्यू असल बनता है न कि बस rubber-stamp।
आगे की चीज़ों पर भरोसा न करें—साबिती पर भरोसा करें। टेस्ट चलाएँ, malformed inputs आज़माएँ, और permission boundaries वेरिफाई करें। AI की आम गलतियाँ: मिसिंग auth checks, unsafe query building, कमजोर टोकन हैंडलिंग, और साइलेंट एरर स्वालोइंग।
साफ़, स्पष्ट ट्रांज़िशन endpoints पसंद करें बजाय किसी generic “update anything” रूट के। उदाहरण: submit, approve, reject, pay — और फिर टेस्ट लिखें जो यह एन्फोर्स करें कि कौन कौन सा ट्रांज़िशन कर सकता है और कौन नहीं।
उम्मीदवारी के लिए एक AI-जनरेटेड diff दें जिसमें असली समस्याएँ हों: अस्पष्ट नामकरण, मिसिंग टेस्ट, एक edge case और एक छोटा सुरक्षा मसला। उनसे bedoeling समझाने, उच्चतम जोखिम वाले हिस्सों की पहचान करने, फिक्स सुझाने और जो टेस्ट जोड़ेंगे उनका आउटलाइन देने को कहें।
एक अनुशासित लूप अपनाएँ: पहले प्लान करें, छोटे हिस्से जनरेट करें, हर रिस्की चेंज से पहले snapshot लें, और अगर वेरिफिकेशन फेल हो तो रोलबैक करें। चैट-बेस्ड प्लेटफ़ॉर्म में planning mode, snapshots और rollback इस लूप के साथ अच्छी तरह काम करते हैं।