एआई ऐप बिल्डिंग का भविष्य टाइप सुरक्षा पर निर्भर करता है

एआई द्वारा उत्पन्न कोड संकलित हो सकता है, लेकिन सख्त टाइप सुरक्षा के बिना उस सफलता की अवधि बहुत कम होती है। टाइप सुरक्षा वह गार्डरेल है जो नाजुक कोड को छिपे हुए बग्स और रनटाइम विफलताओं में बदलने से रोकती है क्योंकि सिस्टम स्केल करता है।

हमें एआई को सख्त टाइपिंग में मजबूर करना शुरू करना होगा, जो संदर्भ, निर्देश, लिंटिंग और फीडबैक लूप के माध्यम से होता है। यह कुछ अतिरिक्त घंटे लेता है, लेकिन यह ऐसा कोड उत्पन्न करता है जो टिकाऊ होता है।

प्रोत्साहन समस्या

एआई आपको प्रसन्न करना चाहता है। यह पुरस्कार कार्य के लिए अनुकूलित होता है जो यह दिया जाता है, और अधिकांश समय यह केवल “क्या यह संकलित होता है?” होता है। इसका मतलब है कि यह हर कोने को काट देगा जो एक हरे चेकमार्क प्राप्त करने के लिए आवश्यक है। वे शॉर्टकट्स संकलन समय में ठीक लगते हैं, लेकिन रनटाइम पर ढह जाते हैं।

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

दो प्रकार के त्रुटियाँ

जब एआई द्वारा उत्पन्न कोड चलता है, तो आप आमतौर पर दो प्रकार की टाइप सुरक्षा समस्याओं को देखते हैं:

1. संकलन समय त्रुटियाँ

• क्या होता है: संकलक घोषित प्रकार और जो पारित किया गया था उसके बीच एक मिलान पाता है।
• मानव इसे कैसे ठीक करता है: तय करें कि कॉलर गलत है (42 को स्ट्रिंग में परिवर्तित करें) या फ़ंक्शन सिग्नेचर गलत है (इसे नंबर प्रकार स्वीकार करने के लिए बदलें).
• एआई इसे कैसे “ठीक” करता है: तर्क का प्रकार किसी भी में बदलें। समस्या “हल” हो गई है, लेकिन आपने बस उस गार्डरेल को हटा दिया है जो भविष्य की त्रुटियों को पकड़ लेगी।

2. रनटाइम त्रुटियाँ

• क्या होता है: संकलक सोचता है कि सब कुछ ठीक है (अक्सर इसलिए कि प्रकार ढीले हो गए हैं), लेकिन रनटाइम पर वास्तविक मान धारणा से मेल नहीं खाता है।
• मानव इसे कैसे ठीक करता है: वेरिएबल को उसके स्रोत (जैसे कि एपीआई या डेटाबेस क्वेरी) तक वापस ले जाएं और सीमा पर प्रकार को ठीक करें ताकि डेटा एक उचित स्ट्रिंग के रूप में आ जाए।
• एआई इसे कैसे “ठीक” करता है: संदर्भ के बिना, यह अनुमान लगाता है। शायद यह सब कुछ स्ट्रिंग(…) में लपेटता है, या बस प्रकार को फिर से बढ़ा देता है। दुर्घटना इस स्थान पर चली जाती है, लेकिन अब तर्क टूट जाता है। नंबर जो गणित के लिए थे, अब स्ट्रिंग हैं।

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

डेटाबेस गुणक

जैसे ही आप एक डेटाबेस से जुड़ते हैं, त्रुटियाँ बढ़ जाती हैं और उनके कारणों को ट्रेस करना मुश्किल हो जाता है। एसक्यूएल एक कारण के लिए टाइप किया गया है। प्रत्येक स्कीमा (इंट, टेक्स्ट, यूयूआईडी, बूलियन) डेटा के बारे में धारणाओं को एन्कोड करता है।

जब एआई सब कुछ स्ट्रिंग | किसी भी में समतल करता है, तो आप उन गारंटियों को खो देते हैं:

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

यही कारण है कि गंभीर टीमें टाइप की गई भाषाओं का उपयोग करती हैं और स्कीमा से एपीआई तक टाइप सुरक्षा को लागू करती हैं। यदि आप ऐसा नहीं करते हैं, तो डेटाबेस आपको सुरक्षा प्रदान करना बंद कर देता है और छिपी हुई समस्याएं जुड़ जाती हैं।

क्यों परिपक्व टीमें सख्त टाइपिंग को लागू करती हैं

सख्त टाइपिंग विकासकर्ताओं को धीमा करने के बारे में नहीं है। यह स्केल को संभव बनाने के बारे में है।
प्रकार:

• इरादे को कोड में एन्कोड करता है।
• रिफैक्टर्स को सुरक्षित और भविष्यवाणी योग्य बनाता है।
• उत्पादन में हिट करने से पहले पूरी कक्षा के बग्स को पकड़ता है।
• भविष्य के विकासकर्ताओं (और एआई) को दिखाता है कि एक फ़ंक्शन या वस्तु का उपयोग कैसे करना है।

टाइप सुरक्षा के बिना, एआई की कोड स्लोपीनेस जुड़ जाती है। इसके साथ, उसी एआई उत्पादन ग्रेड कोड का उत्पादन करता है जिस पर आप भरोसा कर सकते हैं।

एआई को टाइप सुरक्षा में कैसे मजबूर किया जाए

आपको एआई को एक जूनियर इंजीनियर की तरह मानना होगा। तेज, प्रतिभाशाली, लेकिन दिशा के बिना लापरवाह।

सही संदर्भ प्रदान करें

इसे इंटरफेस और प्रकार दें जिनका उपयोग यह कर सकता है। उपयोग के उदाहरण दिखाएं। कोड को संरचित करने के सही तरीके के बारे में राय रखें।

सख्त निर्देश दें

बहुत स्पष्ट रूप से एआई को बताएं कि किसी भी का उपयोग न करें, अज्ञात की अनुमति न दें, और हर विधि, वस्तु और चर को टाइप किया जाए। उम्मीद है कि यह इन निर्देशों का पालन करने में कठिनाई होगी (विशेष रूप से पहले पास में)।

लिंटिंग के साथ लागू करें

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

चेक के साथ पुनरावृत्ति करें

संकलन समय त्रुटियों, रनटाइम लॉगिंग, क्लिक-थ्रू परीक्षण। प्रत्येक पुनरावृत्ति एआई को टाइप को कसकर और उत्पादन-ग्रेड कोड की ओर ले जाने के लिए मजबूर करती है।

एक बेहतर तरीका बनाने के लिए

मैंने सीखा है कि कच्चे पीढ़ी की गति के लिए उच्च गुणवत्ता की बलि देना लंबे समय में भुगतान करता है। इसका मतलब है कि किसी भी प्रकार के लिए शून्य सहनशीलता के लिए लड़ना, कई फीडबैक लूप और सख्त लिंटिंग नियमों को लागू करना जिन्हें एआई को पास करना होगा trước कि कोड ‘पूरा’ कहा जा सके। यह लगातार प्रयास लेता है, लेकिन यह कोड की गुणवत्ता को फिसलने से रोकने का एकमात्र तरीका है।

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

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