जब AI कहे "हो गया", तो उस पर भरोसा न करने वाला तंत्र
AI कोडिंग एजेंट काम पूरा किए बिना ही कह देते हैं कि पूरा हो गया। टेस्ट चलाए बिना कहते हैं कि पास हो गया, बग को दोबारा दिखाए बिना कहते हैं कि ठीक कर दिया। लगभग सारा कोड AI के साथ लिखने वाले एक अकेले डेवलपर की कहानी, जिसने "पूरा हुआ" को शब्दों से नहीं, सिर्फ़ सबूत से मानने वाला एक वेरिफ़िकेशन गेट बना डाला।
मुख्य सारांश
AI एजेंट की सबसे खतरनाक आदत है अधूरे काम को पूरा बताकर रिपोर्ट करना। हल यह नहीं कि इंसान हर बार शक करे, बल्कि यह कि "पूरा हुआ" को सिर्फ़ सबूत से मानने वाला एक द्वार सिस्टम में ही ठोक दिया जाए। टर्न को रुकने से रोकने वाला हुक, सबूत के प्रकार (कमांड आउटपुट, diff, री-प्रोडक्शन, क्रॉस-वेरिफ़िकेशन), और यह क्यों AI युग की मूल मांसपेशी है।
इस पेज पर
AI कोडिंग एजेंट के साथ काम करते हुए एक वाक्य है जिससे मैं सबसे ज़्यादा धोखा खाता हूँ। "हो गया।"
एजेंट यह बात बहुत आसानी से कह देता है। टेस्ट को असल में चलाए बिना कहता है "टेस्ट पास हो जाएगा", और बग को दोबारा दिखाए बिना कहता है "मूल कारण ठीक कर दिया"। कोड पढ़ो तो सब ठीक-ठाक लगता है। पर असल में जब कमांड चलाओ तो आधा काम अधूरा पड़ा होता है। यह लंबे समय तक झेलने के बाद मैंने एक नतीजा निकाला। समस्या यह नहीं कि AI झूठ बोलता है, समस्या यह है कि उसकी बात मानूँ या न मानूँ, यह फ़ैसला हर बार इंसान कर रहा था।
भरोसे का नहीं, सबूत का सवाल
अकेले काम करते हुए मैं लगभग सारा कोड AI के साथ लिखता हूँ। ऐसे में दिन में दर्जनों बार तय करना पड़ता है कि "इस बदलाव को स्वीकार करूँ या नहीं"। शुरू में हर बार एजेंट की रिपोर्ट पढ़ता, और शक होने पर खुद कमांड चलाकर जाँचता था। इस तरीके की दिक्कत यह है कि जाँच मुझ पर टिकी है। थके हुए दिन, जल्दी वाले दिन, दसवीं बार वैसा ही काम करने वाले दिन "कह रहा है हो गया तो हो ही गया होगा" कहकर आगे बढ़ जाता हूँ। और ठीक ऐसे ही टाल दिए गए काम में हादसा होता है।
इसलिए मैंने दिशा बदल दी। मैं हर बार शक करने के बजाय, मैंने सिस्टम को ही सबूत माँगने वाला बना दिया। एजेंट सिर्फ़ "हो गया" कहकर अपना टर्न ख़त्म न कर सके, ऐसा एक द्वार मैंने हार्नेस में ठोक दिया। पूरा होना अब एक घोषणा नहीं, बल्कि एक ऐसी जाँच बन गया जिसे पास करना ज़रूरी है।
इस सोच की जड़ सीधी है। AI कोड जितने सस्ते में उगलता है, अड़चन उतनी ही उत्पादन से हटकर वेरिफ़िकेशन की तरफ़ खिसक जाती है। कोड बनाने की लागत जब शून्य के करीब पहुँच जाए, तो "यह सही है या नहीं, इस पर भरोसा करना" तुलनात्मक रूप से सबसे महँगा काम बन जाता है। तो फिर उस महँगे काम को इंसान के उस-उस पल के मूड पर छोड़ने के बजाय, अपने-आप लागू होने वाली प्रक्रिया बना देना चाहिए।
टर्न को रोकने वाला हुक
ठोस रूप में मैं टर्न ख़त्म होने के पल पर बीच में दख़ल देने वाला एक हुक इस्तेमाल करता हूँ। एजेंट काम पूरा होने की घोषणा करके अपना टर्न ख़त्म करने की कोशिश करे, तो ठीक उससे पहले एक जाँच चलती है। यह जाँच एक ही चीज़ माँगती है। "पूरा हुआ, इसका सबूत दो।"
सबूत न हो तो टर्न ख़त्म करना अस्वीकार हो जाता है। एजेंट को वापस भेज दिया जाता है - इस संदेश के साथ कि "पूरा होना साबित नहीं किया, इसलिए काम जारी रखो।" तब जाकर एजेंट टेस्ट चलाता है, कमांड चलाता है, और आउटपुट चिपकाता है। मज़ेदार बात यह है कि इस प्रक्रिया में आधी बार वह खुद ही कहता है "अरे, अभी तो पूरा नहीं हुआ" और सचमुच बचा हुआ काम पूरा कर देता है। जब उसने "हो गया" कहा था, तब असल में हुआ नहीं था।
असल बात यह है कि यह द्वार इंसान नहीं, मशीन है। मैं थका हूँ या जल्दी में, द्वार उतना ही सख़्त रहता है। मेरा अनुशासन डगमगाता है, पर हुक का अनुशासन नहीं डगमगाता। मैंने वेरिफ़िकेशन को आदत नहीं, बल्कि इन्फ़्रास्ट्रक्चर बना दिया।
किसे सबूत माना जाए
तो फिर किसे "सबूत" माना जाए। मैं चार प्रकार इस्तेमाल करता हूँ।
- कमांड आउटपुट। अगर टेस्ट पास हुआ है तो असली टेस्ट रनर का आउटपुट होना चाहिए। "पास हो जाएगा" नहीं, बल्कि पास हुआ हुआ लॉग। बिल्ड हुआ है तो बिल्ड लॉग, लिंट साफ़ है तो लिंट आउटपुट।
- diff. क्या बदला, यह diff में दिखना चाहिए। शब्दों में "यह फ़ंक्शन ठीक किया" नहीं, बल्कि बदली हुई लाइनें जैसी की तैसी। बदलाव का दायरा रिपोर्ट से मेल खाता है या नहीं, यह यहीं छनकर सामने आता है।
- री-प्रोडक्शन। बग ठीक किया है तो, ठीक करने से पहले वह बग असल में दोबारा दिखा - इसका सबूत, और ठीक करने के बाद वह ग़ायब हो गया - इसका सबूत, दोनों जोड़े में होने चाहिए। before/after न हो तो "ठीक कर दिया" महज़ अटकल है।
- क्रॉस-वेरिफ़िकेशन। ज़रूरी बदलावों की समीक्षा मैं किसी दूसरे मॉडल से करवाता हूँ। Claude का लिखा हुआ Codex देखता है, और दोनों एक-दूसरे के अंधे कोने पकड़ते हैं। एक ही मॉडल के अपने काम को खुद जाँचने से यह कहीं बेहतर पकड़ में आता है।
इन चारों में एक बात साझा है - ये सब दोबारा जाँचे जा सकने वाले तथ्य हैं। राय नहीं, बल्कि चिपकाया जा सकने वाला आउटपुट। AI आख़िरी जज नहीं बन सकता, इसकी वजह यहीं है। "अच्छा" का मानक तय करना, और कौन-सा आउटपुट उस मानक को पूरा करता है यह तय करना, अंततः इंसान के ही ज़िम्मे रहता है। बस, उस फ़ैसले को हर बार हाथ से करने के बजाय, फ़ैसले की प्रक्रिया को कोड में जड़ देना है।
यह इंसान के लिए भी अच्छा क्यों है
द्वार खड़ा करने के बाद एक असर हुआ जिसकी उम्मीद नहीं थी। सिर्फ़ एजेंट का अनुशासन नहीं बँधा, मुझे भी राहत मिली।
पहले रिपोर्ट पढ़कर "यह सचमुच हो गया क्या" शक करना मेरा काम था। अब वह काम हुक करता है। मुझ तक जिस पल काम पहुँचता है, उसमें पहले से ही सबूत जुड़ा होता है। मैं सबूत की जाँच करता हूँ, यह नहीं कि पहले सबूत है भी या नहीं। फ़ैसले की शुरुआती रेखा एक क़दम आगे खिसक गई है।
और यह मेरे भविष्य के अपने-आप के लिए छोड़ा गया रिकॉर्ड भी है। कोई बदलाव क्यों सुरक्षित है, यह उस समय के कमांड आउटपुट के साथ दर्ज रह जाता है। एक महीने बाद "यह ऐसा क्यों किया था" सोचने पर, कारण कमिट के बगल में जुड़ा मिल जाता है।
जो एक ही नई मांसपेशी बनानी है
AI के साथ काम करने के तरीक़ों पर तरह-तरह के कौशल की बात होती है, पर मेरे लिए सबसे बड़ी बात जो बची वह यह है। वेरिफ़िकेशन को अपने-आप पर मत टिकाओ, उसे सिस्टम को सौंप दो।
प्रॉम्प्ट अच्छा लिखने का हुनर मॉडल बदलते ही पुराना पड़ जाता है। कल जो तरकीब चलती थी, नए मॉडल में नहीं चलती। पर "पूरा होना सिर्फ़ सबूत से मानूँगा" यह अनुशासन मॉडल के ऊपर की एक परत है, इसलिए पुराना नहीं पड़ता। कोई भी मॉडल इस्तेमाल करो, मॉडल की कितनी भी पीढ़ियाँ बदल जाएँ, सबूत माँगने वाला द्वार वैसे का वैसा काम का रहता है। उल्टे, मॉडल जितना समझदार होता जाता है उतना ही वह भरोसेमंद अंदाज़ में ग़लत होता है, इसलिए द्वार की क़ीमत और बढ़ जाती है।
AI ने कोड लिखने का बोझ हल्का कर दिया। बदले में उसने हमारे ज़िम्मे जो काम छोड़ा है वह है - "क्या इस पर भरोसा किया जा सकता है" यह तय करना। उस फ़ैसले को हर बार इंसानी इच्छाशक्ति से करने की कोशिश करो तो थकान होती है और चीज़ें रिसकर निकल जाती हैं। इसके बजाय मशीन को सबूत माँगने वाला बना दो, तो एक न थकने वाला द्वार मेरी जगह सख़्ती से खड़ा रहता है। AI से जितना ज़्यादा काम करवाने वाला इंसान हो, उसे असल में मेहनत जिस पर करनी चाहिए वह "कैसे काम करवाऊँ" नहीं, बल्कि "हो गया इस बात को कैसे वेरिफ़ाई करूँ" है।
संबंधित लेख
- 💻 डेवलपमेंट
न ली गई छूट - Spot और Graviton सस्ते क्यों हैं
AWS का बिल लगातार दो महीने बजट से ऊपर गया। घटाने लायक संसाधन ढूंढते हुए पता चला कि असली लीवर 'कितना इस्तेमाल करते हैं' नहीं, 'कैसे ख़रीदते हैं' था। Spot और Graviton सस्ते क्यों हैं, और फ़िज़ूलख़र्ची जैसा दिखने पर भी बंद न करने वाला ख़र्च (RDS Proxy) - बिल के हर आंकड़े में छिपी 'वजह' की कहानी।
- 💻 डेवलपमेंट
Shutdown Hooks दो बार चल रहे थे - जब SIGTERM के दो मालिक हों
हर डिप्लॉय पर Sentry में Prisma P2028 एरर आ रही थी। शटडाउन सीक्वेंस ठीक करने बैठा तो पता चला कि NestJS का enableShutdownHooks और graceful shutdown लाइब्रेरी दोनों SIGTERM पकड़ रहे थे, जिससे शटडाउन हुक्स हर बार दो बार चल रहे थे।
- 💻 डेवलपमेंट
staging में बस बंद कर दो? - शोर भरे alert के पीछे छिपी असली गड़बड़
staging में रोज़ आने वाला Google Play 404 alert। source बंद कर दो तो शांति हो जाती है, लेकिन वह और failure mode को ठीक करना, दो अलग चीज़ें निकलीं। असल में 404 एक permanent error है जिसे रीट्राई करने से कोई फ़ायदा नहीं, फिर भी वह 5xx के साथ मिलाकर रीट्राई हो रहा था - यही कहानी है।