वह कोड जो AI नहीं लिखेगा

मैं तकनीकी साक्षात्कार (technical interview) के प्रश्न के रूप में फॉर्म वैलिडेशन (form validation) का उपयोग करता हूँ। यह सरल दिखता है। लोग इसे जिस तरह से हल करते हैं, उससे पता चलता है कि वे कैसे सोचते हैं।

मैंने इस समस्या का परीक्षण Claude, ChatGPT और Gemini पर किया। वे सभी एक ही समाधान पर पहुँचे।

अधिकांश लोग इसे हल करने के लिए तीन में से एक तरीके का उपयोग करते हैं:

सभी AI मॉडलों ने स्कीमा दृष्टिकोण (schema approach) को चुना। यह तकनीकी रूप से सही है। यह मिसिंग कीज़ (missing keys) को संभालता है। यह अच्छी तरह से स्केल करता है। यदि रनटाइम (runtime) पर आपका डेटा बदलता है, तो स्कीमा सही विकल्प है।

लेकिन अधिकांश सॉफ़्टवेयर के लिए एक बेहतर तरीका है।

हर चीज़ के लिए एक ही पैटर्न खोजने की कोशिश करने के बजाय, कंपोज़िशन (composition) का उपयोग करें। प्रत्येक बिज़नेस कॉन्सेप्ट (business concept) को अपना स्वयं का फंक्शन दें।

यह दृष्टिकोण रिकर्शन का उपयोग नहीं करता है। यह स्कीमा का उपयोग नहीं करता है। यह स्पष्ट, अलग-अलग फंक्शन का उपयोग करता है।

इसका लाभ सरल है। कोड बिज़नेस को दर्शाता है। एक बिलिंग एड्रेस एक अलग कॉन्सेप्ट है। यह अपने स्वयं के लॉजिक का हकदार है। जब आप एक नया प्रकार जोड़ते हैं, तो आप मौजूदा फंक्शन को नहीं बदलते हैं। आप एक नया फंक्शन जोड़ते हैं। यह आपके बदलावों को लोकल (local) रखता है।

AI शायद ही कभी इस रास्ते को चुनता है। यह उस पैटर्न को चुनता है जो लॉजिक को सेंट्रलाइज़ (centralize) करता है। हमारी शिक्षा हमें डुप्लीकेशन को खत्म करना और सामान्यीकरण (generalize) करना सिखाती है। AI उसी संस्कृति से सीखता है।

AI विफल नहीं हो रहा है। यह केवल उन्हीं इंजीनियरिंग अंतर्ज्ञानों (engineering instincts) का पालन कर रहा है जो हमने उसे सिखाए हैं।

सबसे अच्छा समाधान वह नहीं है जिसमें कोड की लाइनें सबसे कम हों। यह वह है जो आपके बिज़नेस डोमेन (business domain) को सबसे ईमानदारी से दर्शाता है।

अगली बार जब आप कोई समाधान बनाएँ, तो खुद से एक सवाल पूछें:

क्या यह मेरे कोड में परिवर्तनशीलता (variability) है, या यह मेरे डेटा में है?

उत्तर आपके पूरे डिज़ाइन को बदल देता है।

स्रोत: https://dev.to/iceonfire/the-code-ai-wont-write-1ieb