- AI tools junior developers को सिर्फ सतही क्षमता दे रहे हैं; वे तेज़ी से code output कर देते हैं, लेकिन यह समझाना अक्सर संभव नहीं होता कि वही approach क्यों चुनी गई
- senior developers की असली value code लिखने की speed में नहीं, बल्कि वर्षों की असफलताओं से बनी failure pattern recognition में होती है
- AI का उपयोग करते हुए भी error को खुद analyze करना, code trace करना और hypothesis बनाना जैसी जानबूझकर की गई जद्दोजहद की प्रक्रिया ज़रूरी है
- commit किए जाने वाले हर code के लिए library चुनने का कारण, pattern, और trade-off को खुद explain कर पाना चाहिए; वरना वह production के लिए तैयार नहीं है
- AI को सिर्फ answer generator नहीं, बल्कि tutor की तरह इस्तेमाल करना चाहिए, ताकि अलग-अलग approaches के फायदे और सीमाएँ सीखी जा सकें
समस्या का मूल: AI से बन रही सतही क्षमता
- LLM के उपयोग से feature जल्दी बनाना और deploy करना संभव हुआ है, लेकिन code चुनने का कारण समझा न पाना एक आम स्थिति बन गई है
- code review में approach पर पूछे गए सवालों का जवाब न दे पाने वाली सतही क्षमता(shallow competence) की समस्या फैल रही है
- AI द्वारा सुझाए गए code को ज्यों का त्यों स्वीकार करने का pattern बार-बार दोहराया जा रहा है
- ऊपर से productivity ऊँची दिखती है, लेकिन design intent और trade-off की समझ कमजोर रहती है
- समय के साथ यह समस्या भरोसा घटने का कारण बन सकती है
senior developers की value क्यों है
- अनुभवी developers महंगे इसलिए नहीं होते कि वे code जल्दी लिखते हैं, बल्कि इसलिए कि उन्होंने लंबे समय में यह सीखा है कि क्या नहीं करना चाहिए
- गलत architecture decision लेने, उसके परिणाम झेलने, और रात 2 बजे outage call उठाने जैसे अनुभवों से जो failure pattern recognition बनती है, कंपनियाँ असल में उसी के लिए भुगतान करती हैं
- अभी कई junior developers AI का इस्तेमाल करते हुए इस प्रक्रिया को ही skip कर रहे हैं
5 रणनीतियाँ
-
1. fundamentals को सही ढंग से सीखें
- अच्छा code क्या होता है यह जानना ज़रूरी है, तभी AI के output का सही मूल्यांकन किया जा सकता है; वरना AI output को अंधाधुंध स्वीकार कर लिया जाता है
- सुझाई गई किताबें: Head First Design Patterns (coding patterns और उन्हें चुनने के कारण समझने के लिए) और Designing Data-Intensive Applications (data-intensive systems की design principles के लिए)
-
2. outage cases का अध्ययन करें
- Cloudflare, AWS, Azure, Google जैसी बड़ी services में outage होने पर जारी किए गए detailed post-mortem दस्तावेज़ पढ़ने की सलाह दी गई है
- इनमें कारण, root cause analysis, fix का तरीका, और दोबारा ऐसी घटना रोकने के उपाय शामिल होते हैं
- Amazon में COE(Correction of Errors) और Facebook समेत अधिकांश बड़ी tech कंपनियों में इसी तरह के internal documents होते हैं
- complex systems कैसे टूटते हैं, इसे समझना सिर्फ documentation पढ़ने से कहीं ज़्यादा गहराई से याद रह जाता है
-
3. जद्दोजहद को जानबूझकर अपनाएँ
- AI से पहले समस्या को खुद हल करने की प्रक्रिया कोई विकल्प नहीं बल्कि default थी, लेकिन अब 24 घंटे उपलब्ध एक escape hatch मौजूद है
- error को AI में paste करने से पहले stack trace पढ़ें, code trace करें, logs जाँचें, और क्या गलत हुआ इस पर hypothesis बनाएँ
- यही प्रक्रिया असली debugging instinct बनाती है
- इसके बाद AI का उपयोग किया जा सकता है
- on-call में हिस्सा लेना और वे tickets उठाना जिन्हें कोई नहीं लेना चाहता, system कैसे काम करता है यह सीखने का सबसे प्रभावी तरीका है
-
4. जिस code को समझते नहीं, उसे कभी release न करें
- अगर code review में किसी specific approach के बारे में पूछे जाने पर जवाब हो, "AI ने suggest किया था", तो तुरंत भरोसा खत्म हो जाता है
- समस्या AI के उपयोग में नहीं, बल्कि अपने द्वारा submit किए जा रहे code को समझने की कोशिश न करने में है
- commit की जाने वाली हर line के लिए यह समझा पाना चाहिए कि यही library क्यों, यही pattern क्यों, और trade-off क्या है
- speed थोड़ी कम करनी पड़े तो भी पहले समझ ज़रूरी है; केवल copy-paste करने वाले व्यक्ति की reputation वापस पाना बहुत कठिन होता है
-
5. answer नहीं, "क्यों" को prompt करें
- AI से सिर्फ problem solve करने को कहने के बजाय, अलग-अलग approaches और उनके फायदे-नुकसान समझाने को कहें
- इससे दो प्रभाव होते हैं:
- trade-off के बारे में सचमुच सीखने का मौका मिलता है
- AI जब reasoning process से गुजरता है, तो उसकी recommendation खुद बदल सकती है, जिससे बेहतर जवाब मिल सकता है
speed pressure पर व्यावहारिक सलाह: productivity और learning का संतुलन
- धीमे पड़ जाने पर पीछे छूटने का डर वास्तविक है, लेकिन काम को पूरी तरह रोकने की ज़रूरत नहीं है
- free time, side projects, और कम प्रतिस्पर्धी tickets में जानबूझकर कठिन और असुविधाजनक learning करें
- असली skill बनाने के समय और सिर्फ output देने के समय के बीच सचेत रूप से अंतर करना ज़रूरी है
AI को tutor की तरह इस्तेमाल करें
- आज developers के पास ऐसा AI tutor है जो किसी भी चीज़ को मनचाही गहराई तक समझा सकता है, जो पिछली पीढ़ियों के पास नहीं था
- AI से सिर्फ काम करवाने के बजाय, उससे explain करने और सिखाने के लिए भी कहें
- developer की value code output करने की क्षमता में नहीं, बल्कि किसी भी code को देखकर यह तय कर पाने की क्षमता में है कि वह अच्छा है या नहीं
- code AI-generated हो या न हो, अच्छे और बुरे में फर्क कर पाना ही मुख्य क्षमता है
- जानबूझकर किया गया learning और failures का accumulation ही लंबी अवधि की competitiveness बना सकता है
अभी कोई टिप्पणी नहीं है.