AI के कोड उगलने वाले दौर में, पानी उतरने पर पता चलता है कौन नंगा तैर रहा था

मुख्य सारांश

• ChatGPT के आने के 3 साल के भीतर डेवलपर का दिन "कोड लिखने" से "AI output की जाँच" की ओर खिसक रहा है
• डेवलपर की भूमिका खत्म नहीं हो रही, बल्कि कोड लिखने वाले से review और approval authority रखने वाले व्यक्ति की ओर उसका केंद्र बदल रहा है
• AI कोई legal entity नहीं है, इसलिए वह जिम्मेदारी नहीं ले सकता; EU AI Act जैसे regulation भी जिम्मेदारी को इंसानों पर ही तय करने की दिशा में मजबूत हो रहे हैं
• AI युग में जरूरी मुख्य क्षमता prompt skill नहीं, बल्कि long-term change cost का अनुमान, abstraction पर फैसला, और tacit knowledge को भाषा में बदलना है — और ये मूल रूप से वही चीजें हैं जो आज भी अच्छे डेवलपर के लिए जरूरी हैं
• Fred Brooks के accidental complexity vs essential complexity के विचार से समझें तो AI केवल accidental complexity हल करता है; domain की essential complexity के लिए अब भी इंसानी judgment जरूरी है
• tool proficiency (prompt engineering आदि) की वैधता tool बदलने के cycle से बंधी होती है, लेकिन design judgment और tacit knowledge को भाषा में व्यक्त करने की क्षमता तब तक उपयोगी रहती है जब तक software की essential complexity मौजूद है

---

विस्तृत सारांश

ChatGPT के बाद के 3 साल

• 2022 के अंत में ChatGPT के आने पर यह अनुमान नहीं था कि यह इतनी तेजी से आगे बढ़ेगा
• पारंपरिक डेवलपर की परिभाषा: "natural language requirements analysis → design → direct implementation" सब खुद करने वाला व्यक्ति
• अब दिन का बड़ा हिस्सा "AI को context देना → generated code पढ़ना, सुधारना, फिर से request करना" में जाता है
• AI coding agent अब सिर्फ साधारण सहायक नहीं रहे; function और module स्तर पर उनका लिखा कोड इंसान के लिखे कोड से अलग पहचानना मुश्किल होता जा रहा है

लेखक से निर्णयकर्ता तक

• कोड production की क्रिया "खुद कोड लिखने" से "कोड पर judgment देने" की ओर बढ़ रही है
• यहाँ "judgment" का मतलब सिर्फ यह देखना नहीं कि AI output इच्छानुसार है या नहीं, बल्कि यह सत्यापित करना है कि business intent को technical implementation में सही तरह translate किया गया है या नहीं
• "अगर AI के लिखे कोड से payment bug पैदा हो जाए तो जिम्मेदार कौन है?" यही असली सवाल है
• AI legal personhood नहीं रखता, इसलिए कोड को review और approve करने वाला डेवलपर और संगठन ही जिम्मेदार पक्ष हैं
• 2024 से लागू EU AI Act: medical, finance, infrastructure जैसे high-risk क्षेत्रों में AI system पर human oversight अनिवार्य
• self-driving car दुर्घटना की जिम्मेदारी → manufacturer और driver, FDA-approved medical AI → अंतिम निर्णय doctor का, 2010 Flash Crash → algorithm चलाने वाली इकाई ही regulation के दायरे में
• automation जितनी उन्नत होती है, responsibility structure उतना धुंधला नहीं बल्कि और स्पष्ट रूप से इंसानों की ओर तय होता जाता है

AI युग में डेवलपर से अपेक्षित क्षमताएँ

① long-term change cost का अनुमान लगाने की क्षमता

• AI "काम करने वाला कोड" बनाने के लिए optimized है (training data में सबसे बार-बार दिखे pattern को दोहराना)
• अभी तुरंत चलने वाला कोड और 6 महीने बाद भी maintain करना आसान रहने वाला कोड — दोनों के मापदंड बिल्कुल अलग हैं
• खराब design की लागत कोड लिखते समय नहीं, बल्कि बदलाव की जरूरत पड़ने पर सामने आती है
• LinkedIn पर ऐसे पोस्ट बढ़ रहे हैं: "AI से बनाया, लेकिन maintain करना मुश्किल निकला इसलिए डेवलपर hire करना पड़ा", "feature जोड़ नहीं पाए, इसलिए बंद करना पड़ा"

② कोड का बहुआयामी मूल्यांकन करने की क्षमता

• functional correctness (जिसे test से verify किया जा सकता है) से आगे बढ़कर structural quality, performance implications, और security aspects को एक साथ देखना होगा
• AI code generation की गति जितनी बढ़ती है, production speed और review capability के बीच संतुलन उतनी आसानी से टूटता है
• जब इंसान खुद लिखते थे, तब code production पर एक physical limit थी; AI कुछ सेकंड में सैकड़ों लाइनें बना देता है
• अगर review criteria, parallel review system, और automated gates पर्याप्त न हों, तो technical debt और तेजी से जमा होती है
• कई कंपनियों को AI अपनाने के बाद productivity gain महसूस न होने की वजह: code generation तेज हुई, लेकिन AI code review की प्रक्रिया ही bottleneck बन गई

③ abstraction की क्षमता

• AI भी interface definition, class separation, module separation कर सकता है, और औपचारिक रूप से काफी अच्छा करता है
• निर्णायक अंतर यह है: AI की abstraction statistical average पर आधारित है, जबकि अनुभवी डेवलपर की abstraction सीमित संसाधनों और अनिश्चित भविष्य के बीच trade-off judgment पर आधारित होती है
• AI output code का खतरनाक पक्ष: ऊपर से देखने पर सब अच्छा लगता है — file सही तरह बंटी हुई, naming convention ठीक, pattern परिचित
• समस्या बदलाव की जरूरत पड़ने पर सामने आती है: "सिर्फ एक payment method और जोड़ना था, लेकिन तब जाकर समझ आया कि 'साफ-सुथरी दिखने वाली' structure के कई हिस्से एक साथ बदलने पड़ेंगे"
• frontend उदाहरण: AI कभी data fetching, state management, और UI rendering को एक ही विशाल component में ठूँस देता है, या उल्टा एक साधारण chart के लिए 3 custom hooks + context provider बना देता है

④ tacit knowledge को explicit बनाने की क्षमता

• "कुछ गड़बड़ लग रही है" जैसी instinct को "इस function की दो जिम्मेदारियाँ हैं" जैसी ठोस भाषा में बदलना आना चाहिए, तभी AI को सटीक निर्देश दिए जा सकते हैं
• few-shot, chain-of-thought जैसी औपचारिक prompt तकनीकें नहीं, बल्कि क्या बनाना है यह साफ परिभाषित करना और कौन-सा context महत्वपूर्ण है यह पहचानकर देना असली क्षमता है
• tool proficiency की उम्र: tool replacement cycle से बंधी (jQuery → React, Webpack → Vite)
• design judgment और tacit knowledge को भाषा में बदलने की क्षमता की उम्र: जब तक software की essential complexity मौजूद है, तब तक यह उपयोगी है

deliberate practice design की आवश्यकता

• कहा जाता है "जो tool नहीं कर सकता, उस पर ध्यान दो", लेकिन विडंबना यह है कि उसी क्षमता को विकसित करने के मौके कम होते जा रहे हैं

① दो बिंदु जिन्हें AI को नहीं सौंपना चाहिए: design और review

• कोड लिखने से पहले का design: prompt लिखने से पहले interface और responsibility की सीमा तय कर लें, तब AI output की तुलना अपनी design decision से की जा सकती है
• AI से PR review करवाकर, कोई बड़ी समस्या न दिखे तो सीधे approve कर देना = "PT period में मैदान पर जाकर सिर्फ बेंच पर बैठकर वापस आ जाना"

② जानबूझकर खुद लिखने का समय

• design sense तभी बनती है जब implementation का दर्द पता हो; जो दर्द खुद न झेला हो, वह संवेदना में नहीं बदलता
• junior developer के लिए AI generated code review करना वैसा है जैसे "जो अभी driving सीख ही रहा हो, उससे autonomous car के decision का मूल्यांकन करने को कहना"
• भविष्य की coding ability: रोज के काम का हिस्सा नहीं, बल्कि judgment को बनाए रखने की training (reviewer license लेने की प्रक्रिया)

③ "क्यों" को भाषा देना सीखना

• "कुछ अजीब है" पर रुक जाएँ तो वह instinct है, "इस function की दो responsibilities हैं" तक जाएँ तो वह भाषा है
• AI के बनाए कोड के चल जाने पर वहीं न रुकें; खुद से पूछने की आदत डालें: "इसने यह structure क्यों चुना होगा?", "अगर कोई दूसरी structure होती तो trade-off क्या होते?"

आखिरकार मूल बात नहीं बदली

• Fred Brooks (1986): accidental complexity (tool की सीमाएँ) vs essential complexity (समस्या में निहित जटिलता)
• AI accidental complexity को हल करता है — boilerplate, repetitive pattern, syntax errors
• essential complexity (business requirement की अस्पष्टता, टकराते design goals के बीच संतुलन, भविष्य के बदलाव की अनिश्चितता) AI के आगे बढ़ने पर भी खत्म नहीं होती
• जब तक इंसान judgment और responsibility का केंद्र बना हुआ है, judgment के लिए जरूरी क्षमताओं का मूल स्वरूप नहीं बदलता
• कोड production जितना automate होगा, उतना ही output की जाँच करने वाली judgment की अहमियत और उभरकर सामने आएगी