अधिकांश इंजीनियर AI का उपयोग करते हैं। कुछ ही इंजीनियर इसके साथ इंजीनियरिंग करते हैं।
अब अधिकांश सॉफ्टवेयर इंजीनियर AI का उपयोग करते हैं।
वे इसका उपयोग डिबगिंग, टेस्ट लिखने, या SQL क्वेरी जेनरेट करने के लिए करते हैं। AI का उपयोग करना आसान है। AI के साथ इंजीनियरिंग करना कहीं अधिक कठिन है।
मैंने वास्तविक रिपॉजिटरी (repository) कार्यों पर AI का उपयोग करते समय एक समस्या देखी। एक गलत बदलाव केवल खराब आउटपुट ही नहीं देता, बल्कि यह आपके स्ट्रक्चर, आपके टेस्ट और भविष्य की मेंटेनेबिलिटी (maintainability) को भी बिगाड़ देता है।
कोड जनरेशन वाला हिस्सा आसान है। एक व्यापक प्रॉम्प्ट (prompt) तेज़ी से कोड तैयार कर देता है। पहली नज़र में यह साफ-सुथरा दिखता है।
उपयोगी परिणाम तभी मिलते हैं जब आप पहले उबाऊ काम करते हैं। आपको चाहिए:
- आवश्यकता (requirement) को परिभाषित करें।
- स्कोप (scope) को सीमित करें।
- बाधाओं (constraints) को समझाएं।
- तय करें कि बदलाव को कैसे सत्यापित (verify) करना है।
कौशल प्रॉम्प्टिंग (prompting) नहीं है। कौशल काम को सही आकार देना (shaping the work) है।
AI आउटपुट की गति बढ़ाता है। यह सत्यापन (verification) की गुणवत्ता नहीं बढ़ाता। यदि कोड जेनरेट करना तेज़ हो जाता है, तो अस्पष्ट आवश्यकताएं और भी महंगी हो जाती हैं। कमजोर रिव्यू (reviews) और भी खतरनाक हो जाते हैं।
AI आपके मौजूदा इंजीनियरिंग लूप (engineering loop) को और बढ़ा देता है।
यदि आवश्यकता अस्पष्ट है, तो भी AI कुछ न कुछ बना देगा। यदि आर्किटेक्चर (architecture) अस्त-व्यस्त है, तो AI उस अस्त-व्यस्तता की ही नकल करेगा। यदि आप आउटपुट का रिव्यू नहीं कर सकते, तो गति एक जोखिम बन जाती है।
सवाल यह नहीं है कि क्या AI इंजीनियरों की जगह ले लेगा। सवाल यह है कि: जब कोड सस्ता हो जाए, तो इंजीनियरिंग के कौन से हिस्से अधिक महत्वपूर्ण हो जाएंगे?
मेरा जवाब: कार्यान्वयन (implementation) से पहले स्पष्ट रूप से सोचना।
AI पुराने सुझावों को और भी महत्वपूर्ण बना देता है:
- दो बार सोचें, एक बार कोड करें।
- AI से बनाने के लिए कहने से पहले समस्या को परिभाषित करें।
- किसी उत्तर को स्वीकार करने से पहले ट्रेडऑफ़ (tradeoffs) की जांच करें।
- मर्ज (merge) करने से पहले व्यवहार (behavior) को सत्यापित करें।
इंजीनियरिंग अब कोड लिखने से हटकर सही बदलाव को आकार देने की ओर बढ़ रही है।
AI को एक ऐसे सहयोगी (collaborator) के रूप में मानें जिसे स्ट्रक्चर की आवश्यकता है। एक अच्छा लूप ऐसा दिखता है: Requirement → Gaps → Plan → Small change → Review → Checks → Notes.
वास्तविक इंजीनियरिंग कोड बनाने के बारे में नहीं है। यह विश्वसनीय बदलाव लाने के बारे में है।
लाभ सबसे अधिक कोड जेनरेट करने में नहीं है। लाभ यह जानने में है कि क्या बनाना है और वह आपके सिस्टम में कैसे फिट बैठता है।
जीतने वाले इंजीनियर सबसे तेज़ प्रॉम्प्ट लिखने वाले नहीं होंगे। वे वे होंगे जो टूल के इर्द-गिर्द बेहतर वर्कफ़्लो (workflows) डिज़ाइन करेंगे।
Source: https://dev.to/jeelvankhede/most-engineers-use-ai-few-engineer-with-it-3pd
Optional learning community: https://t.me/GyaanSetuAi