AI कोडिंग के जाल

• AI coding agents कोड लिखने की गति को नाटकीय रूप से बढ़ा रहे हैं, लेकिन वास्तविक विकास प्रक्रिया में सबसे महत्वपूर्ण हिस्सा अब भी समझ और समस्या-समाधान ही है
• LLM का उपयोग करके तेज़ी से कोड बनाया जा सकता है, लेकिन पूरे संदर्भ की कमी के कारण पोस्ट-प्रोसेसिंग कार्य और समझने में अधिक समय लगता है
• इसके कारण प्रोडक्टिविटी की अपेक्षाओं और वास्तविक दक्षता के बीच अंतर पैदा होता है, और डेवलपर्स अपनी पसंद के रचनात्मक कामों की बजाय टेस्टिंग, रिफैक्टरिंग, डॉक्युमेंटेशन जैसे दोहराव वाले और बोझिल कामों में समय खर्च करने लगते हैं
• अतीत के ‘tech lead dilemma’ की तरह, यदि अल्पकालिक परिणामों के लिए जटिल काम AI या सीनियर लोगों पर केंद्रित कर दिए जाएँ, तो दीर्घकाल में टीम की क्षमता में गिरावट और संकट पैदा हो सकता है
• LLM को एक शक्तिशाली junior engineer की तरह समझकर, सत्यापित विकास प्रक्रियाओं को AI के साथ सहयोग में लागू करके सस्टेनेबल सॉफ्टवेयर डिलीवरी की संरचना बनानी चाहिए

---

समस्या की पहचान: कोडिंग से भी अधिक महत्वपूर्ण क्या है

• सॉफ्टवेयर डेवलपमेंट मूलतः समस्या-समाधान केंद्रित काम है
• वास्तविक कोडिंग डेवलपर की सारी सोच और चिंतन का अंतिम छोटा हिस्सा भर है
• डेवलपर कोड के अलावा डोमेन समझना, आवश्यकताओं को विभाजित करना, abstraction, side effects पर विचार, incremental testing, bug fixing जैसे कई काम करते हैं
• पारंपरिक विकास प्रवाह: पर्याप्त सोच के बाद कोड लिखना
• AI कोडिंग के युग में: पहले कोड, बाद में समझ का पैटर्न बन रहा है

AI कोडिंग का बदलाव: पहले कोड बनने वाला paradigm

• Claude Code जैसे AI coding agents तेज़ी से कोड बना देते हैं, लेकिन पूरे सिस्टम के संदर्भ को पूरी तरह नहीं समझ पाते
• इंसानी review, testing, integration की प्रक्रिया अनिवार्य है, और AI द्वारा लिखे गए कोड को बाद में समझने में बहुत समय लगता है
• मार्केटिंग में कोडिंग स्पीड में सुधार पर ज़ोर दिया जाता है, लेकिन वास्तविक काम करने वाले सॉफ्टवेयर की डिलीवरी प्रोडक्टिविटी में सुधार बहुत कम होता है
• डेवलपर्स AI द्वारा बनाए गए परिणामों के testing, deduplication, documentation, infrastructure management जैसे दोहराव वाले और कठिन कार्यों में अधिक समय लगाने लगते हैं
• वास्तविक कोडिंग का आनंद कम हो जाता है और दोहराव वाले काम बढ़ जाते हैं

तकनीकी लीडर की पुरानी दुविधा

• जब कोई इंजीनियर tech lead की भूमिका लेता है, तो वह टीम की तकनीकी डिलीवरी की ज़िम्मेदारी उठाता है
• जब टीम का अनुभव एक ही व्यक्ति पर केंद्रित हो जाता है, तो प्रोडक्टिविटी असंतुलन पैदा होता है
• न्यायसंगत वितरण (टीम की वृद्धि को महत्व देना) और केंद्रित आवंटन (तेज़ विकास पर ध्यान) के बीच टकराव होता है
  • केंद्रित आवंटन से अल्पकालिक लाभ बड़ा हो सकता है, लेकिन अनुभव के असमान संकेंद्रण से टीम के लिए दीर्घकालिक जोखिम (सहारे का अभाव, burnout, सहयोग में कठिनाई) पैदा होते हैं
• स्वस्थ टीम संस्कृति के लिए विकास और दक्षता के संतुलन का तरीका चाहिए

अच्छी नेतृत्व क्षमता का मूल: प्रक्रिया और विकास के बीच संतुलन

• अनुभवी इंजीनियरों की समझ पूरी टीम तक पहुँचे, इसके लिए विभिन्न development principles और frameworks लागू करने की ज़रूरत है
• उदाहरण: Extreme Programming, code review, incremental deployment, modular design, test-driven development, pair programming, documentation, continuous integration आदि
• अंतिम लक्ष्य: rework को न्यूनतम करना, सहयोग को अधिकतम करना, व्यक्तिगत विकास को बढ़ावा देना

AI agents के साथ सहयोग: नई टीम लीड की भूमिका

• नवीनतम LLM-आधारित coding agents एक बेहद तेज़ junior developer जैसे हैं
• पारंपरिक junior developers से अलग, LLM में सीखने की क्षमता का अभाव और गति की कोई सीमा नहीं जैसी स्पष्ट भिन्नताएँ हैं
• AI गुणवत्ता सुधार की बजाय लगातार गति बढ़ाने पर केंद्रित रहता है, जबकि इंसानी संदर्भ और डोमेन समझ उसमें कम होती है
• सहयोग के दो पैटर्न:
  • AI-आधारित engineering: धीमा हो सकता है, लेकिन दक्ष और सस्टेनेबल टीमवर्क की ओर उन्मुख
  • vibe coding: तेज़ परिणामों पर केंद्रित, लेकिन धीरे-धीरे ऐसी अव्यवस्था जमा करता है जिसे सुधारा नहीं जा सकता
• यह Silicon Valley की code growth की पारंपरिक कमजोरी जैसा है: अल्पकालिक लाभ के बाद विकास की सीमा की दीवार से टकराना

AI कोडिंग के जाल से बचने के व्यावहारिक तरीके

• LLM अपनी स्थिति नहीं समझता और अंधाधुंध कोड पैदा करता है
• इंजीनियरों को AI को स्पष्ट संरचना, मानक और प्रक्रिया देनी होगी ताकि कच्चे आउटपुट को वास्तविक सेवा में बदला जा सके
• पारंपरिक development cycle की best practices को AI सहयोग वाले माहौल में घनिष्ठ रूप से लागू करने के लिए नई playbook की आवश्यकता है
• प्रत्येक प्रमुख चरण में AI के उपयोग के तरीके:
  • spec definition: edge cases का विश्लेषण, लक्ष्य के दायरे पर फोकस
  • documentation: दोबारा उपयोग योग्य guides और प्रमाण सुरक्षित करना
  • module design: सीमित संदर्भ देकर समझ बेहतर करना
  • test-driven development: implementation से पहले test cases बनाना, regression रोकना
  • coding standards: style और quality बनाए रखना
  • monitoring: logs का स्वचालित विश्लेषण और insights निकालना

निष्कर्ष

• सॉफ्टवेयर डिलीवरी सिर्फ कोड लिखने से पूरी नहीं होती; AI और इंसानों के बीच प्रभावी सहयोग संरचना बनाना अनिवार्य है
• LLM को एक अत्यंत तेज़ junior developer मानकर, सत्यापित विकास प्रक्रियाएँ लागू करनी होंगी, तभी स्केलेबल और उच्च-गुणवत्ता वाले सॉफ्टवेयर दिए जा सकते हैं

[GN⁺]

Hacker News की राय

• मैं AI-विरोधी ऐसा तर्क देखना चाहता हूँ जो सिर्फ़ इस दावे पर आधारित न हो कि “तकनीक लोगों को आलसी बना देती है।” जिसने भी गंभीरता से LLM से कोड बनवाया है, वह महसूस करता है कि plan-structure-test-retrospective loop अब भी बहुत महत्वपूर्ण है। बिना सावधानी के बस चला दो, तो चीज़ें बहुत जल्दी टूट सकती हैं। इस loop को ठीक से लागू करो, तो मैं अपनी पसंद की architecture design और result experience को test करने में बहुत समय लगा सकता हूँ। LLM आसान हिस्सों को जल्दी निपटा देता है, इसलिए आख़िर में जो काम हमारे हिस्से में बचता है, वह कम दिलचस्प और कम सराहा जाने वाला होता है। जिन क्षेत्रों में AI विशेषज्ञता को चमकाता है, वहाँ काम का आनंद लेने वाले और सोचने के अनुभव का आनंद लेने वाले लोगों के बीच नज़रिया बहुत साफ़ अलग हो जाता है। जिन्हें सोचना पसंद है, वे AI की वजह से लगभग पूरी तरह उसी हिस्से पर ध्यान दे सकते हैं। दूसरी तरफ़, जिन्हें खुद टाइप करना और हाथ से काम करना पसंद है, उनके लिए AI उल्टा वही हिस्सा छीन लेता है जो उन्हें पसंद है

  • AI code generation के बारे में, मुझे लगता है कि तकनीक लोगों को आलसी बनाती है—इससे ज़्यादा महत्वपूर्ण आलोचना यह है कि AI-generated code के प्रति गहरी समझ छिन जाती है। software engineer का मूल काम code generate करना नहीं, बल्कि पूरे system को design करना है। यहाँ महत्वपूर्ण चीज़ है code कैसे काम करता है इसकी सोचने की रूपरेखा (mental model) और domain expertise; code उस mental model से निकला हुआ परिणाम है। एक तय पैमाने से बड़े project में, जब तक code आपने खुद न लिखा हो, उसे पूरी तरह जानना मुश्किल होता है। अगर यह mental model नहीं बनता, तो दूसरी समस्याएँ भी साथ आती हैं। LLM-आधारित coding agents की syntax-level reasoning में सीमाएँ हैं, इसलिए scale पर उनकी कमज़ोरी दिखती है

  • अपनी बात कहूँ तो, मैं Cline जैसे AI tools कभी-कभी इस्तेमाल करता हूँ, लेकिन धीरे-धीरे सीधे टाइप करके coding करने का अनुपात बढ़ रहा है। वजह यह है कि ज़्यादातर मामलों में coding बस prompt writing से replace हो जाती है। अगर prompt लिखने और inference का समय मेरे हाथ से सीधे coding करने के समय से कम हो, तो मैं AI इस्तेमाल करता हूँ, लेकिन आम तौर पर यह सिर्फ़ refactoring जैसी speed bottleneck वाली स्थिति में ही लागू होता है। ज़्यादातर कामों में सीधे करूँ तो 10 मिनट लगते हैं, AI से करूँ तो prompt लिखने और चलाने में 8 मिनट लगते हैं। अगर बिना गलती के ठीक चल जाए तो 2 मिनट बचते हैं, लेकिन अगर fix या re-prompt करना पड़े तो उल्टा 10~12 मिनट लग जाते हैं, और AI credits भी खर्च हो जाते हैं, यानी सबसे बुरा सौदा। यह हिसाब लगाते-लगाते मैं इस नतीजे पर पहुँचा हूँ कि code quality और लगने वाले समय दोनों को देखें तो manual काम ज़्यादा सुरक्षित है

  • इस दावे पर कि तकनीक लोगों को लापरवाह बनाती है, आम तौर पर तकनीक कई बार लोगों को और सावधान भी बनाती है। समस्या यह है कि यह AI तकनीक उपयोगकर्ता को लापरवाही की ओर धकेलने की संभावना ज़्यादा रखती है। मेरी दिलचस्पी coding के मज़ेदार हिस्से में नहीं, बल्कि मैं design (architecture) को ज़्यादा पसंद करता हूँ। अगर इरादे को सीधे code में उतारा जा सके, तो मैं वही तरीका अपनाऊँगा। लेकिन chatbot interface इरादे को परोक्ष और अपूर्ण तरीके से पहुँचाता है, इसलिए जब इसे high-level code build में इस्तेमाल करते हैं तो मेरे दिमाग़ के model और actual code की समझ जल्दी अलग होने लगती है, और इससे एक अस्थिर नींव बचती है। लाइन-दर-लाइन बहुत ध्यान से review किया जा सकता है, लेकिन वह tool के मकसद के उलट है। AI coding “10 गुना तेज़” वाली भावना के कारण detailed implementation और macro-level understanding के बीच की दूरी को बढ़ावा देती है। वास्तव में structural हिस्सों के बारे में कम सोचना AI coding बेचने का एक बड़ा फ़ायदा बताया जाता है, लेकिन यही understanding gap बाद में समस्या बनता है। अच्छी automation reliable और predictable होती है, इसलिए सिर्फ़ upper-level invariants को समझना काफ़ी होता है, लेकिन chatbot code ऐसी गारंटी नहीं देता, और आख़िर में हर चीज़ manually verify करनी पड़ती है। यहाँ safety और reliability उल्टा और मुश्किल लगती है

  • “सोचने वाले हिस्से पर ध्यान दो” वाली बात मैं इतनी बार देख चुका हूँ कि अब यह घिसी-पिटी लगती है। सवाल यह है कि क्या कोई व्यक्ति, जिसने कई सालों तक असली काम खुद करके नहीं देखा, सिर्फ़ सोचने से गहराई वाले काम कर सकता है? आख़िरकार, बिना खुद करके देखे, सोच भी धीरे-धीरे उथली हो सकती है

  • मेरा नज़रिया यह है कि debugging, लिखने से ज़्यादा मुश्किल है, इसलिए जो code मैंने खुद नहीं लिखा उसे debug करने से बेहतर है कि मैं खुद लिखूँ

• ऐसी चर्चा पढ़ते हुए हर बार मेरे मन में यही आता है कि क्या लेखक वही tools इस्तेमाल कर रहा है जो मैं कर रहा हूँ। मैं Claude Code के साथ साधारण boilerplate से लेकर complex algorithm तक, यहाँ तक कि बहुत उलझाने वाले बड़े codebase के अंदर भी, लगभग सब कुछ बनवा सकता हूँ। हाँ, यह 100% सही नहीं होता, लेकिन बहुत क़रीब होता है। ऊपर से, यह अक्सर ऐसे algorithm भी सुझाता है जिनके बारे में मैंने सोचा नहीं था। ऐसे tools मेरा समय कम से कम 10 गुना बचाते हैं

• यह लेख ठीक है, लेकिन इसमें दो भ्रम दिखते हैं। पहला, skilled developer जब LLM इस्तेमाल करता है तब भी पर्याप्त exploration, पहले से सोच-विचार, और design अब भी ज़रूरी हैं। बल्कि LLM को सही तरह उपयोग करने के लिए मुझे सामान्य से ज़्यादा सोचना पड़ता है, अलग-अलग design options की तुलना करनी पड़ती है, और पूरे structure का नक्शा बनाना पड़ता है। पहले मैं इस प्रक्रिया को document नहीं करता था, लेकिन अब इसे design document के रूप में छोड़ता हूँ। दूसरा, यह दावा कि LLM ऐसे junior developer जैसा है जो grow नहीं करता—दोनों पूरी तरह अलग हैं। इंसानी junior developer एक व्यक्ति है और LLM एक tool है। लोग कहते हैं कि junior के साथ काम करने से cumulative value बनती है, जबकि LLM के साथ नहीं; लेकिन यह भी सही नहीं है। भले ही LLM खुद सीखता नहीं, मैं इसे काफ़ी ज़्यादा कुशलता से साधना और बेहतर ढंग से इस्तेमाल करना सीख जाता हूँ। अभी products में LLM को अच्छी तरह लागू करने का शुरुआती दौर है, इसलिए स्वाभाविक है कि इसमें compound growth value दिख रही है

  • “भले ही LLM न सीखे, मैं सीखता हूँ” इस बात से सहमत हूँ, लेकिन फिर भी मैं चाहता हूँ कि LLM सच में user के साथ interaction से सीखे। मैं चाहता हूँ कि session की सामग्री को file में save/load किया जा सके ताकि LLM पहले सीखे गए पूरे context को बिना कुछ छोड़े समझ सके। कुछ frontend UI में session save/restore किया जा सकता है, लेकिन महत्वपूर्ण बात यह है कि a) ऐसी “re-learning” का LLM की current context window पर असर न पड़े (हालाँकि मैं चाहूँगा कि यह अवधारणा ही ख़त्म हो जाए), और b) यह बिल्कुल lossless हो। summary के बाद आगे बढ़ना, RAG जैसी विधियाँ पहले से हैं, लेकिन इन सबमें मूलभूत सीमाएँ हैं—जैसे information loss, या restore होने के लिए current interaction का trigger होना। उदाहरण के लिए, अगर मैंने कल LLM को किसी function के बारे में समझाया और session save कर लिया, फिर आज session restore करने के बाद उससे कोई बिल्कुल असंबंधित सवाल पूछूँ, तब भी मैं चाहता हूँ कि LLM पुराने context को भी ध्यान में रखकर जवाब दे। और जब चाहूँ तब साफ़ शुरुआत (clean slate) भी स्पष्ट रूप से कर सकूँ, ऐसी व्यवस्था होनी चाहिए

  • सही बात है। software की कुल productivity में सोचने का समय, असली code लिखने के समय की तुलना में कहीं बड़ा हिस्सा लेता है, इसलिए भले ही LLM coding वाला हिस्सा तेज़ कर दे, कुल productivity या manpower demand में नाटकीय बदलाव नहीं आता

  • DO NOT WRITE ANY CODE YET prompt से शुरू करना मेरे लिए भी default है। यह पहले समझने का तरीका है कि LLM क्या करने वाला है और control अपने पास रखने का भी। मुझे code लिखने से ज़्यादा logic/problem solving/system integration जैसी design खुद ज़्यादा मज़ेदार लगती है

  • Copilot के Ask mode, GPT-5 Codex के Plan/Chat mode जैसी सुविधाएँ हैं जिनसे code files बदले बिना सिर्फ़ planning की जा सकती है। मैंने Codex कुछ दिन इस्तेमाल किया और पर्याप्त निर्देश देने पर यह बहुत शानदार निकला

  • मैं भी ज़्यादातर “पहले plan बताओ” जैसी शैली पसंद करता हूँ, यानी LLM से actual execution से पहले detailed plan पूछना

• इस लेख में Microsoft की marketing material का हवाला देकर 10% productivity improvement की बात की गई है, जबकि Harvard research में उल्टा 10% productivity decline दर्ज हुआ था। किसी खास कंपनी के प्रचार की बजाय, independent research results का हवाला पहले देने वाले लेख बेहतर होंगे

• इस लेख में जो एक मुख्य बात पूरी तरह नहीं आ पाई, वह Casey Muratori की यह बात है कि “अगर आप learning-centered mindset के साथ programming करते हैं, तो AI उल्टा अर्थहीन हो जाता है।” व्यक्तिगत रूप से मुझे लगता है कि AI code generators सिर्फ़ one-off या फेंक देने वाले code के लिए ही उपयोगी हैं। जिन क्षेत्रों में मैं गंभीरता से सीखना चाहता हूँ, वहाँ code generation AI से न करवाना learning effect को अधिकतम करता है। “AI-led engineering” कुछ लोगों के लिए निश्चित ही अर्थपूर्ण होगी, लेकिन कम-से-कम मेरे लिए हाथ से code block लिखना ज़्यादा मज़ेदार है और आख़िर में result भी बेहतर बनता है। संबंधित वीडियो, 5 मिनट का हिस्सा

  • “सीखने को अधिकतम करने की अवस्था वह है जहाँ AI से बिल्कुल code generate न कराया जाए” — यह तर्क बहुत चरम लगता है। सीखने के लिए खुद करना ज़रूरी है, लेकिन दूसरों से संवाद या मदद बिल्कुल न लेना जैसा यह दावा कुछ ज़्यादा कठोर लगता है

• Claude Code इस्तेमाल करते हुए मैं सोचने में कहीं ज़्यादा समय देने लगा हूँ। जो feature बनाना चाहता हूँ, उसे 400~600 शब्दों में describe करना पहले कभी नहीं करना पड़ता था, लेकिन अब मैं अधिक जानकारी को बैठकर व्यवस्थित करता हूँ। इस सोच-विचार से तेज़ और बेहतर परिणाम आते हैं, लेकिन साथ ही code के बारे में मेरी समझ पहले से कुछ कम हो जाती है। फिर भी, Claude Code इस्तेमाल करने पर experienced developers कम सोचते हैं—इस बात से मैं सहमत नहीं हो सकता। शायद बहुत से लोग agents को लगभग सिर्फ़ prompts लिखने जैसे अप्रभावी तरीक़े से इस्तेमाल कर रहे हैं, लेकिन इसे मैं agent की गलती नहीं मानता

• ऐसी चर्चाएँ देखकर लगता है कि अभी हम एक अस्पष्ट संक्रमणकाल में हैं। शायद अगले साल तक आज जैसी चर्चाओं को “बहुत ज़्यादा सोचना” समझा जाएगा। कुछ वैसा ही दौर जैसे internet के व्यापक होने से पहले और बाद में “यह बस एक अस्थायी फैशन है” या “गलत निवेश है” जैसे सवाल बहुत उठते थे

• ऐसी पोस्टें अक्सर यह बात छोड़ देती हैं

  1. हर coding एक जैसी नहीं होती। सामने production system हो सकता है और मैं सिर्फ़ एक साधारण experiment कर रहा हो सकता हूँ
  2. हर व्यक्ति agents को अलग तरीके से इस्तेमाल करता है
  3. बेहतरीन developers का समय भी एक cost है
     अच्छा होता अगर AI code assistance के फायदे, नुकसान और trade-offs को व्यवस्थित रूप से समेटने वाला कोई लेख होता। नैतिक मूल्यांकन (अच्छा/बुरा) हटाकर चर्चा करना ज़रूरी है। जब “coding skill” आपकी पहचान का हिस्सा हो, तब इस पर ठंडे दिमाग़ से बात करना खास तौर पर मुश्किल होता है—यह मैं मानता हूँ
  • मूल लेख तुम्हारे बताए गए 1 नंबर बिंदु (coding की परिस्थितियों की विविधता) का एक बार ज़िक्र करता है

• मैं हर दिन खुद से कहकर हौसला देता हूँ, “बस 30 साल और निकाल लो, फिर retirement।” machine learning क्षेत्र में 10 साल हो गए, computer के सामने बैठते-बैठते थक गया हूँ और काम से भी थक चुका हूँ। बस घास पर लोटना चाहता हूँ

  • लगता है तुम्हें आराम (sabbatical) की ज़रूरत है, इसलिए एक बार इसकी सलाह देना चाहूँगा

• “सोचना&coding vs सोचना&editing” वाला graph दिलचस्प है। हाल में Codex इस्तेमाल करते हुए मुझे पूरा यक़ीन था कि AI मेरे code में बहुत editing कराएगा। लेकिन असल में, जब समस्या की जड़ code से बिल्कुल जुड़ी ही न हो, तब बहुत समय बर्बाद होता है। हाल ही में authentication issue के कारण मैं काफ़ी देर तक सिर्फ़ code ही खंगालता रहा, जबकि असली वजह VM की ipv6 setting में गड़बड़ी निकली

[shakespeares]

इससे सहमति है। जब AI coding करते हैं, तो post-processing का काम इतना ज़्यादा हो जाता है कि उसे असली business में समाहित करना और maintain करना बहुत मुश्किल हो जाता है.
साथ में develop करने के नज़रिए से जितना हो सके उतना ping-pong करते हुए आगे बढ़ें, फिर भी कुछ code हमने सीधे नहीं लिखा होता, इसलिए वह अक्सर दिमाग से निकल जाता है.
मुझे लगता है कि boundaries हर हाल में ज़रूरी हैं.