वही कोड जो AI नहीं लिख पाएगा
मैं फॉर्म वैलिडेशन (form validation) का उपयोग तकनीकी साक्षात्कार (technical interview) के प्रश्न के रूप में करता हूँ। यह सरल दिखता है। इसके उत्तर बताते हैं कि लोग कैसे सोचते हैं।
मैंने इस समस्या का परीक्षण Claude, ChatGPT और Gemini पर किया। वे सभी एक ही समाधानों तक पहुँचे।
अधिकांश लोग विभिन्न पतों (addresses) को संभालने के लिए एक टाइप पैरामीटर (type parameter) के साथ एक ही फंक्शन का उपयोग करते हैं। यह काम करता है। लेकिन हर नया नियम उसी फंक्शन में एक नई शाखा (branch) जोड़ देता है। अंतर छिपे रहते हैं।
मैंने जो सबसे चतुर मानवीय उत्तर देखा, उसमें रिकर्शन (recursion) का उपयोग किया गया था। यह डेटा के आकार (data shape) के माध्यम से चलता है। यह सुरुचिपूर्ण (elegant) है। लेकिन इसमें एक दोष है। यह केवल उन्हीं फ़ील्ड्स को वैलिडेट करता है जो मौजूद हैं। यदि कोई की (key) गायब है, तो फंक्शन उसे कभी देख ही नहीं पाता। इसके पास सत्य का कोई स्रोत (source of truth) नहीं होता।
तीनों AI ने यही गलती की। जब मैंने इस दोष की ओर इशारा किया, तो उन सभी ने एक स्कीमा (schema) का सुझाव दिया। स्कीमा-संचालित दृष्टिकोण (schema-driven approach) तकनीकी रूप से सही है। यह गायब कीज़ (missing keys) को संभालता है और अच्छी तरह से स्केल करता है।
लेकिन एक बेहतर तरीका है: कंपोजिशन (Composition)।
एक विशाल फंक्शन या एक जटिल स्कीमा के बजाय, आप प्रत्येक प्रकार के लिए विशिष्ट फंक्शन बनाते हैं।
- एक फंक्शन मानक पते (standard address) के लिए।
- एक फंक्शन शिपिंग (shipping) के लिए।
- एक फंक्शन बिलिंग (billing) के लिए।
आप अपने वैलिडेटर (validator) को बनाने के लिए उन्हें संयोजित करते हैं।
यह दृष्टिकोण गायब की (missing key) की समस्या को हल करता है। बिलिंग वैलिडेटर हमेशा VAT नंबर की जाँच करता है, भले ही की (key) गायब हो। यह इसलिए काम करता है क्योंकि बिलिंग पता एक वास्तविक व्यावसायिक अवधारणा (business concept) है। यह केवल आपके डेटा में एक पैटर्न नहीं है।
अंतर स्पष्ट रूप से व्यक्त होते हैं। जब कोई नया पता प्रकार आता है, तो आप एक नया फंक्शन जोड़ते हैं। आप पुराने कोड को नहीं बदलते हैं।
AI और बेहतरीन इंजीनियर अक्सर एक ही जाल में फंस जाते हैं। हमें पैटर्न खोजने और लॉजिक को केंद्रीकृत (centralize) करने के लिए सिखाया जाता है। हम हर कीमत पर डुप्लीकेशन (duplication) को खत्म करने की कोशिश करते हैं।
AI इस प्रवृत्ति को हमारे ट्रेनिंग डेटा से विरासत में प्राप्त करता है। यह सामान्यीकरण (generalization) को प्राथमिकता देता है।
समस्या यह नहीं है कि AI गलत है। समस्या यह है कि AI शायद ही कभी सबसे महत्वपूर्ण प्रश्न पूछता है: क्या यह परिवर्तनशीलता (variability) मेरे कोड में है या मेरे डेटा में?
यदि पते के प्रकार स्थिर हैं, तो कंपोजिशन (composition) का उपयोग करें। यदि पते के प्रकार बाहरी डेटा के माध्यम से बदलते हैं, तो स्कीमा (schema) का उपयोग करें।
सबसे सरल समाधान वह नहीं है जिसमें सबसे कम लाइनें हों। यह वह है जो आपके बिजनेस डोमेन (business domain) को दर्शाता है।
Source: https://dev.to/iceonfire/the-code-ai-wont-write-1ieb
Optional learning community: https://t.me/GyaanSetuAi