इंजीनियरिंग जजमेंट सबसे दुर्लभ संसाधन बनता जा रहा है
इम्प्लीमेंटेशन सस्ता होता जा रहा है। यह जजमेंट को महंगा बनाता है।
जजमेंट का मतलब अंतर्ज्ञान (intuition) या राय नहीं है। यह अनिश्चितता के बीच निर्णय लेने की क्षमता है। AI इस कौशल को पहले से कहीं अधिक स्पष्ट बनाता है।
दो इंजीनियरों को एक ही काम मिल सकता है: इनवॉइस रिकॉन्सिलिएशन (invoice reconciliation) के लिए एक API बनाना। AI दोनों के लिए कोड लिख सकता है। सिंटैक्स और फ्रेमवर्क एक जैसे ही दिखेंगे।
अंतिम सिस्टम अलग होंगे। एक इंजीनियर एक ऐसा अव्यवस्थित (messy) सर्विस बना सकता है जिसे मेंटेन करना कठिन हो। दूसरा इंजीनियर बिजनेस रूल्स और लॉजिक को स्वतंत्र कंपोनेंट्स में अलग कर सकता है।
वह चुनाव AI ने नहीं किया। इंजीनियर ने किया।
आर्किटेक्चर अभी भी मायने रखता है क्योंकि इम्प्लीमेंटेशन अब अंतर पैदा करने वाला कारक (differentiator) नहीं रह गया है। कोड के पीछे लिए गए निर्णय ही अब अंतर पैदा करते हैं।
AI के साथ जटिलता खत्म नहीं होती। यह बस स्थानांतरित (move) हो जाती है।
अतीत में, इंजीनियर विचारों को कोड में बदलने में समय बिताते थे। अब, AI वह अनुवाद करता है। असली मेहनत एक भी लाइन लिखने से पहले ही हो जाती है।
आपको इन जैसे सवालों के जवाब देने होंगे:
- हम किस समस्या का समाधान कर रहे हैं?
- कौन सा डेटा 'सोर्स ऑफ ट्रुथ' (source of truth) है?
- बिजनेस रूल्स कहाँ होने चाहिए?
- हम सफलता को कैसे मापते हैं?
ऑटो-कम्प्लीट (Autocomplete) इनका जवाब नहीं दे सकता। इनके लिए संदर्भ (context) की आवश्यकता होती है।
सॉफ्टवेयर डेवलपमेंट अब इंफॉर्मेशन इंजीनियरिंग जैसा दिखता है। बाधा (bottleneck) कोड नहीं है। बाधा जानकारी (information) है।
आपको इनका सामना करना पड़ता है:
- अधूरी आवश्यकताएं (Missing requirements)।
- अपूर्ण डॉक्यूमेंटेशन।
- विरोधाभासी बिजनेस रूल्स।
- अस्पष्ट स्वामित्व (Undefined ownership)।
जो इंजीनियर जानकारी को व्यवस्थित करता है, वह उस इंजीनियर की तुलना में अधिक मूल्य (value) पैदा करता है जो तेजी से कोड लिखता है।
वर्कफ़्लो बदल गया है। पहले यह ऐसा था: Requirement -> Design -> Code -> Debug -> Deploy.
अब यह है: Business Problem -> Context -> Architecture -> AI Implementation -> Human Review -> Security -> Evaluation -> Production.
कोडिंग अब प्रक्रिया का एक छोटा हिस्सा है। इसके आसपास की गतिविधियाँ प्राथमिकता हैं।
उच्च-प्रभाव वाले निर्णय कोड एडिटर के बाहर होते हैं। वे तब होते हैं जब आप पूछते हैं:
- क्या इसे एक अलग सर्विस होना चाहिए?
- क्या हम इस निर्णय का ऑडिट कर सकते हैं?
- क्या होगा यदि AI गलत हो?
- क्या यह आर्किटेक्चर विकसित हो सकता है?
AI इंजीनियरिंग केवल प्रॉम्प्ट्स या मॉडल चयन से कहीं अधिक है। वे केवल एक परत हैं।
असली चुनौतियाँ आर्किटेक्चरल हैं:
- हम बिजनेस नॉलेज को कैसे मॉडल करते हैं?
- हम अस्पष्टता (ambiguity) को कैसे दूर करते हैं?
- हम भरोसा (trust) कैसे बनाए रखते हैं?
मॉडल हर कुछ महीनों में बदल जाते हैं। आर्किटेक्चर वर्षों तक चलते हैं। एक खराब आर्किटेक्चर बहुत जल्दी महंगा साबित होता है।
बेहतरीन टीमें ऐसे सिस्टम बनाती हैं जो मॉडलों की कई पीढ़ियों तक टिके रहें। वे अनुकूलन क्षमता (adaptability) के लिए काम करती हैं।
AI केवल एब्स्ट्रैक्शन (abstraction) की एक और परत है। उच्च एब्स्ट्रैक्शन के लिए मजबूत तर्क (reasoning) की आवश्यकता होती है, कमजोर तर्क की नहीं।
सबसे मजबूत इंजीनियर सबसे तेज़ प्रोग्रामर नहीं होते। वे वे होते हैं जो स्पष्टता (clarity) पैदा करते हैं। वे आर्किटेक्चर को परिभाषित करते हैं, डेटा को मानकीकृत (standardize) करते हैं, और अस्पष्टता को कम करते हैं।
एक अच्छा सिस्टम इंसानों और AI एजेंटों को मिलकर काम करने में मदद करता है। एक खराब सिस्टम केवल गलतियों को तेज़ी से होने का कारण बनता है।
जो इंजीनियर स्पष्टता पैदा करता है, वह लीवरेज (leverage) पैदा करता है।
Source: https://dev.to/uigerhana/engineering-judgment-is-becoming-the-scarcest-resource-1a5l
Optional learning community: https://t.me/GyaanSetuAi