पिछले महीने, एक AI असिस्टेंट ने एक प्रोडक्शन प्रोजेक्ट के लिए एक Python स्क्रिप्ट तैयार की। आउटपुट बिना किसी त्रुटि के चला। डेटा भी सही लग रहा था। लेकिन मैन्युअल समीक्षा से पता चला कि डेटाबेस कॉल्स में एक N+1 क्वेरी पैटर्न छिपा हुआ था। छोटे डेटासेट के लिए, कोड ठीक से काम कर रहा था। लेकिन इसे हजारों रिकॉर्ड्स तक बढ़ा दें और एप्लिकेशन पैरेंट ऑब्जेक्ट्स के लिए एक क्वेरी जारी करेगा, और फिर संबंधित डेटा के लिए हजारों फॉलो-अप क्वेरीज़ करेगा। इसका परिणाम एक विनाशकारी परफॉरमेंस क्लिफ (performance cliff) होगा जिसे कोई भी यूनिट टेस्ट नहीं पकड़ पाएगा।
आधुनिक सॉफ्टवेयर डेवलपमेंट की यही वास्तविकता है। AI टूल्स अब कोडिंग, डिबगिंग और आर्किटेक्चरल सुझावों को उस गति से संभाल रहे हैं जिसका मुकाबला कोई इंसान नहीं कर सकता। वह गति वास्तविक है। फिर भी, यह मौलिक रूप से आपके काम के स्वरूप को बदल देता है। अब आपको मुख्य रूप से सिंटैक्स टाइप करने के लिए पैसे नहीं दिए जाते हैं। आपको ऑडिट करने, आर्किटेक्ट करने और ठीक इसी तरह के अदृश्य जाल को पकड़ने के लिए भुगतान किया जाता है।
"तार्किक लेकिन गलत" का शांत खतरा
AI द्वारा जनरेट किया गया कोड अक्सर सही लगता है क्योंकि यह कंपाइल होता है, चलता है और अपेक्षित मान (expected value) लौटाता है। सतह पर तर्क (logic) सही लगता है। लेकिन गहराई में, यह चुपचाप टूटा हुआ हो सकता है।
रेगुलर एक्सप्रेशन (regular expressions) का उदाहरण लें। एक AI आपको ऐसा पैटर्न दे सकता है जो अंग्रेजी में ईमेल एड्रेस या आइडेंटिफायर को पूरी तरह से मैच करता हो। उसी एक्सप्रेशन को जर्मन उम्लाउट्स (umlauts), अरबी स्क्रिप्ट, या यूनिकोड नॉर्मलाइजेशन एज केसेस (Unicode normalization edge cases) पर चलाएं, और यह चुपचाप विफल हो जाएगा। कोड गलत नहीं है कि वह कोई एक्सेप्शन (exception) थ्रो करे। यह बस वास्तविक दुनिया के वैध डेटा को बाहर कर देता है।
डेटाबेस क्वेरीज़ में भी इसी तरह का जोखिम होता है। एक AI ऐसी PostgreSQL क्वेरी लिख सकता है जो टेस्टिंग के दौरान सही पंक्तियाँ (rows) लौटाती है, फिर भी आपके टेबल्स को डेड टुपल्स (dead tuples) से भर सकती है, इंडेक्स उपयोग को छोड़ सकती है, या ऐसे सीक्वेंशियल स्कैन (sequential scans) को मजबूर कर सकती है जो प्रोडक्शन वर्कलोड को ठप कर दें। जो डेमो डेटासेट में काम करता है और जो वास्तविक लोड के तहत काम करता है, वे दो अलग चीजें हैं। मशीन को लेटेंसी (latency) महसूस नहीं होती। वह क्लाउड बिल नहीं भरती।
लिखने से लेकर सत्यापित करने तक
आवश्यक बदलाव "मैं इसे कैसे लिखूँ?" से "मैं इसे कैसे सत्यापित (verify) करूँ?" की ओर बढ़ना है। जब AI पहला ड्राफ्ट तैयार करता है, तो आपका संज्ञानात्मक भार (cognitive load) डाउनस्ट्रीम की ओर स्थानांतरित होना चाहिए। आपको कोड को उसी तरह पढ़ना चाहिए जैसे एक सुरक्षा ऑडिटर उसे पढ़ता है, न कि उस तरह जैसे एक थका हुआ लेखक अपने ही काम को सरसरी तौरकी से पढ़ता है।
इसके लिए एक अलग तरह के अनुशासन की आवश्यकता होती है। ऑटोमेशन बायस (Automation bias) वास्तविक है। जब कोई टूल प्रवाहपूर्ण और सिंटैक्स की दृष्टि से सटीक आउटपुट देता है, तो मानव मस्तिष्क शिथिल हो जाता है। आप सटीकता मान लेते हैं क्योंकि प्रस्तुति पॉलिश की हुई होती है। उस आवेग का विरोध करना अब मुख्य कौशल है। आपको हर सुझाव को तब तक एक परिकल्पना (hypothesis) मानना चाहिए जब तक कि वह अन्यथा सिद्ध न हो जाए।
मशीन के साथ काम करना
एक AI कोडिंग असिस्टेंट से उपयोगी आउटपुट प्राप्त करना तेज़ी से टाइप करने के बारे में नहीं है। यह मशीन के ट्रेनिंग डेटा और आपकी विशिष्ट वास्तविकता के बीच की दूरी को कम करने के बारे में है। आप कुछ ठोस अभ्यासों के साथ उस दूरी को कम कर सकते हैं।
अपने प्रॉम्प्ट्स में सटीक रहें। यहाँ अस्पष्टता कविता नहीं बनाती; यह बग्स बनाती है। "इस फंक्शन को ऑप्टिमाइज़ करें" जैसा प्रॉम्प्ट सामान्य सलाह को आमंत्रित करता है। इसके बजाय, लिखें "इस Python लूप को रिफैक्टर (refactor) करें ताकि बार-बार सेव करने के बजाय सिंगल बल्क डेटाबेस अपडेट का उपयोग किया जा सके।" विशिष्टता संभावनाओं के दायरे को सीमित करती है।
वास्तविक संदर्भ (context) प्रदान करें। AI को तब तक पता नहीं चलेगा कि आप एक सख्त 30-सेकंड के रिक्वेस्ट टाइमआउट वाले Kubernetes क्लस्टर के अंदर PostgreSQL 15 पर Django 4.2 चला रहे हैं, जब तक कि आप उसे ऐसा न कहें। उसे अपने डिपेंडेंसी वर्ज़न, अपनी इंटरनल लाइब्रेरीज़ और अपनी गैर-परक्राम्य (non-negotiable) सीमाओं के बारे में बताएं। संदर्भ सजावट नहीं है; यह सुरक्षा घेरा (guardrails) है।
अपने स्वयं के दस्तावेज़ों के साथ उत्तरों को पुख्ता करें। रिट्रीवल-ऑगमेंटेड जनरेशन (Retrieval-Augmented Generation), या RAG, केवल चैटबॉट्स के लिए एक बज़वर्ड नहीं है। अपने असिस्टेंट को अपने वास्तविक API स्पेसिफिकेशन, अपने आर्किटेक्चर निर्णय रिकॉर्ड (architecture decision records) और अपने कोडबेस कन्वेंशन की ओर निर्देशित करें। जब मॉडल ट्रेनिंग डेटा से अनुमान लगाने के बजाय आपके दस्तावेज़ों से तथ्य प्राप्त करता है, तो सामान्य सलाह और उपयोगी कोड के बीच का अंतर नाटकीय रूप से कम हो जाता है।
जटिल कार्य को अलग-अलग कार्यों में विभाजित करें। एजेंट पैटर्न तब सबसे अच्छा काम करते हैं जब प्रत्येक चरण का दायरा सीमित हो। एक ही बार में पूरा माइक्रोसर्विस रिफैक्टर करने के लिए न कहें। पहले डेटा स्कीमा मांगें। उसे सत्यापित करें। फिर माइग्रेशन स्क्रिप्ट मांगें। उसे सत्यापित करें। फिर सर्विस लेयर पर जाएँ।