इंजिनिअरिंग जजमेंट आता सर्वात दुर्मिळ संसाधन बनत आहे
अंमलबजावणी (Implementation) स्वस्त होत आहे. यामुळे निर्णयक्षमता (judgment) महाग होत आहे.
निर्णयक्षमता म्हणजे केवळ अंतर्ज्ञान (intuition) किंवा मत (opinion) नाही. अनिश्चिततेच्या परिस्थितीत निर्णय घेण्याची क्षमता म्हणजे निर्णयक्षमता होय. AI मुळे हे कौशल्य आता पूर्वीपेक्षा अधिक स्पष्टपणे दिसून येत आहे.
दोन इंजिनिअर्सना एकच काम दिले जाऊ शकते: invoice reconciliation साठी एक API तयार करणे. AI दोघांसाठीही कोड लिहू शकते. सिंटॅक्स (syntax) आणि फ्रेमवर्क्स (frameworks) दोन्हीसाठी सारखेच दिसतील.
परंतु अंतिम सिस्टिम्स वेगळ्या असतील. एक इंजिनिअर कदाचित एक विस्कळीत (messy) सर्व्हिस तयार करेल ज्याची देखभाल करणे कठीण असेल. दुसरा इंजिनिअर बिझनेस रूल्स (business rules) आणि लॉजिक (logic) स्वतंत्र घटकांमध्ये (independent components) विभागून तयार करेल.
तो निर्णय AI ने घेतला नाही. तो इंजिनिअरने घेतला.
आर्किटेक्चर (Architecture) अजूनही महत्त्वाचे आहे कारण आता अंमलबजावणी (implementation) हा फरक ठरवणारा घटक राहिलेला नाही. कोडमागील निर्णय हा खरा फरक ठरवणारा घटक आहे.
AI मुळे गुंतागुंत (complexity) संपत नाही, ती फक्त दुसरीकडे सरकते.
पूर्वी, इंजिनिअर्स कल्पनांचे कोडमध्ये रूपांतर करण्यासाठी वेळ खर्च करत असत. आता, AI हे रूपांतर करते. खरे कठीण काम तुम्ही कोडची एक ओळ लिहिण्यापूर्वीच पूर्ण होते.
तुम्हाला खालीलंसारख्या प्रश्नांची उत्तरे द्यावी लागतील:
- आपण कोणती समस्या सोडवत आहोत?
- 'सोर्स ऑफ ट्रुथ' (source of truth) म्हणून कोणता डेटा वापरला जावा?
- बिझनेस रूल्स (business rules) कुठे असावेत?
- आपण यशाचे मोजमाप कसे करू?
Autocomplete या प्रश्नांची उत्तरे देऊ शकत नाही. त्यासाठी संदर्भाची (context) आवश्यकता असते.
सॉफ्टवेअर डेव्हलपमेंट आता 'इन्फॉर्मेशन इंजिनिअरिंग' (information engineering) सारखे दिसत आहे. अडथळा (bottleneck) कोडमध्ये नाही, तर माहितीमध्ये (information) आहे.
तुम्हाला या गोष्टींचा सामना करावा लागतो:
- अपूर्ण आवश्यकता (Missing requirements).
- अपूर्ण दस्तऐवजीकरण (Incomplete documentation).
- परस्परविरोधी बिझनेस रूल्स (Conflicting business rules).
- अस्पष्ट मालकी हक्क (Undefined ownership).
जो इंजिनिअर माहितीचे आयोजन (organize) करतो, तो वेगाने कोड लिहिणाऱ्या इंजिनिअरपेक्षा जास्त मूल्य (value) निर्माण करतो.
कामाची पद्धत (workflow) बदलली आहे. पूर्वी ती अशी होती: Requirement -> Design -> Code -> Debug -> Deploy.
आता ती अशी आहे: Business Problem -> Context -> Architecture -> AI Implementation -> Human Review -> Security -> Evaluation -> Production.
कोडिंग आता प्रक्रियेचा एक छोटा भाग आहे. त्याभोवतीच्या इतर क्रिया आता प्राधान्यक्रमाच्या आहेत.
उच्च-प्रभाव पाडणारे निर्णय कोड एडिटरच्या बाहेर घेतले जातात. ते तेव्हा घेतले जातात जेव्हा तुम्ही विचारता:
- हे एक वेगळे सर्व्हिस (separate service) असावे का?
- आपण या निर्णयाचे ऑडिट (audit) करू शकतो का?
- जर AI चुकले तर काय होईल?
- हे आर्किटेक्चर विकसित (evolve) होऊ शकते का?
AI इंजिनिअरिंग म्हणजे केवळ प्रॉम्प्ट्स (prompts) किंवा मॉडेल निवडणे इतकेच नाही. ते केवळ एक स्तर (layer) आहे.
खरी आव्हाने आर्किटेक्चरल (architectural) आहेत:
- आपण बिझनेस नॉलेजचे (business knowledge) मॉडेलिंग कसे करू?
- आपण संदिग्धता (ambiguity) कशी दूर करू?
- आपण विश्वास (trust) कसा टिकवून ठेवू?
मॉडेल्स दर काही महिन्यांनी बदलतात. आर्किटेक्चर वर्षानुवर्षे टिकते. खराब आर्किटेक्चर खूप लवकर महाग पडते.
सर्वोत्तम टीम्स अशा सिस्टिम्स तयार करतात ज्या मॉडेल्सच्या अनेक पिढ्यांपर्यंत टिकून राहतील. त्या लवचिकतेसाठी (adaptability) ऑप्टिमाइझ करतात.
AI हा केवळ अमूर्ततेचा (abstraction) आणखी एक स्तर आहे. उच्च अमूर्ततेसाठी (higher 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
