सबसे अच्छे AI बिल्डर वे हैं जो 'ना' कहते हैं

किसी AI बिल्डर की सबसे बड़ी खासियत यह नहीं है कि वह किसी प्रॉम्प्ट को कितनी तेज़ी से काम करने वाले कोड में बदल देता है। असल खासियत यह है कि वह कितनी बार इससे इनकार करता है। ऐसा बिल्डर जो आपकी हर माँग खुशी-खुशी वायर कर देगा — एडमिन रूट पर कोई ऑथ नहीं, बिना आइडेम्पोटेंसी चेक वाला वेबहुक, क्लाइंट-साइड JS में सीधे पेस्ट की गई API की, सिर्फ़ इसलिए कि "बस काम चलना चाहिए" — गलत पाँच मिनट को ऑप्टिमाइज़ कर रहा होता है। वह डेमो के लिए ऑप्टिमाइज़ कर रहा होता है, न कि उस मंगलवार के लिए जो छह हफ़्ते बाद आएगा जब वह रूट स्क्रैप कर लिया जाएगा।

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

इनकार आपको असल में कितना महंगा पड़ता है

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

गलती यह मानने में है कि यह एक ही डायल है। ऐसा नहीं है। कम से कम तीन अलग-अलग वजहें हैं जिनकी वजह से बिल्डर को विरोध करना चाहिए, और उन्हें बिल्कुल अलग तरीके से संभाला जाना चाहिए।

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

एक फाउंडर ने मुझे एक बार बताया कि उनके बिल्डर ने जो सबसे उपयोगी काम किया वह था बल्क-डिलीट एक्शन से पहले एक कन्फर्मेशन स्टेप हटाने से इनकार करना। उन्होंने इसे हटाने के लिए कहा था क्योंकि टेस्टिंग के दौरान यह "परेशान करने वाला" था। तीन हफ्ते बाद, एक साथी ने गलती से एक फिल्टर पर उंगली फिसला दी, और यही कन्फर्मेशन स्टेप एकमात्र वजह है कि 40,000 पंक्तियां अभी भी मौजूद हैं।

इनकार तभी काम करता है जब वह समझ में आए

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

जहां आलोचकों की बात सही है

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

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