Agentic Coding एक जाल है

• Agentic coding वह तरीका है जिसमें इंसान requirements और plan बनाता है और कई coding agents implementation करते हैं, लेकिन इसकी संरचना इंसान और generated/committed code के बीच की दूरी को लगातार बढ़ाती है
• यह तरीका तभी सफल हो सकता है जब अनुभवी developers architecture स्तर पर इसकी critical review करें, लेकिन AI का अधिक उपयोग इसके लिए ज़रूरी skills को कमजोर करने वाला cognitive debt पैदा कर सकता है
• Anthropic के research में उठाए गए supervision paradox की तरह, Claude का प्रभावी उपयोग करने के लिए उसे supervise करने की coding क्षमता चाहिए, और coding agents का उपयोग उसी क्षमता को कमजोर कर सकता है
• LLM को अक्सर गहरी समझ और संक्षिप्तता के बजाय तय समय में ज़्यादा code generate करने की दिशा में इस्तेमाल किया जाता है, और यह अस्पष्ट requirements को assumptions या hallucinations से भरकर अधिक review, fixes और token usage पैदा कर सकता है
• Claude outage और token cost में उतार-चढ़ाव vendor lock-in और cost uncertainty को उजागर करते हैं, और AI को implementation की जगह लेने वाले orchestrator के बजाय planning support, documentation, research और सीमित delegation tool के रूप में इस्तेमाल करना understanding debt को कम कर सकता है

---

संरचनात्मक trade-offs

• coding agents उपयोगी और शक्तिशाली हैं, लेकिन इनमें पहले से ही ऐसे trade-offs हैं जिन्हें quantitative और practical दोनों स्तरों पर परखा जाना चाहिए
  • AI की non-determinism से आने वाली अस्पष्टता को कम करने के लिए आसपास के systems की complexity बढ़ जाती है
  • कई developers की skills कमजोर पड़ सकती हैं
  • Claude Code outage जैसी vendor-specific failures पूरी team को रोक सकती हैं
  • employee cost स्थिर होती है, लेकिन token cost लगातार बदल और बढ़ सकती है
• इस तरीके के सफल होने के लिए अनुभवी developers को architecture स्तर पर critically सोचना होगा और generated code की हज़ारों lines में समस्या बड़ी होने से पहले पकड़नी होगी
• लेकिन AI tools इस काम के लिए ज़रूरी critical thinking और cognitive clarity पर नकारात्मक असर डाल सकते हैं, और cognitive debt बढ़ सकता है

यह सिर्फ़ एक नया abstraction नहीं है

• इसे सिर्फ़ “programmer का abstraction की ऊँची layer पर जाना” कहकर समझाना काफ़ी नहीं है
• ज़्यादा अस्पष्टता का मतलब अपने-आप उच्च-स्तरीय abstraction नहीं होता
• FORTRAN, compiler और high-level languages आने पर भी bugs, instability, inefficiency और बढ़ते “magic” को लेकर चिंताएँ थीं
• अतीत की ज़्यादातर चिंताएँ इस बात की normative और theoretical फ़िक्र थीं कि नई technology अपनाने पर क्या खो जाएगा, लेकिन AI tools ने आने के कुछ ही वर्षों में वास्तविक असर दिखाना शुरू कर दिया है
• इसका असर सिर्फ़ junior developers तक सीमित नहीं है, बल्कि 10 साल से अधिक अनुभव वाले developers में भी दिख रहा है
• junior developers direct code handling के कम अवसर और generated code review की भूमिका में धकेले जाने के कारण और भी तीखी learning curve का सामना कर रहे हैं
• code review महत्वपूर्ण है, लेकिन वह learning process का सिर्फ़ आधा हिस्सा है; code को खुद लिखने और debug करने की friction खत्म हो जाए तो सीखने की क्षमता काफ़ी कमज़ोर हो जाती है
• इस phenomenon पर research को समय लगेगा, इसलिए real-time स्थिति समझने के लिए anecdotal evidence भी महत्वपूर्ण है, लेकिन MIT Media Lab report और Microsoft से जुड़ी रिपोर्टिंग जैसी supporting सामग्री भी मौजूद है

इस बार बदलाव अलग क्यों है

• C++ developer के Java या Python पर जाने से वह “brain fog” की शिकायत नहीं करता था, और system administrator के AWS पर जाने से उसे networking understanding खोने जैसा महसूस नहीं होता था
• senior engineer का management role में जाकर कम coding करना और समय के साथ “rusty” हो जाना कोई नई बात नहीं है
• पुराने रास्ते में engineer दशकों की coding, friction और problem-solving जमा करने के बाद syntax से ज़्यादा architecture decisions वाले role में जाते थे
• अब developers ऐसी उच्च-स्तरीय workflow में जा रहे हैं जहाँ उन्हें बिना उस लंबे अनुभव के AI agents manage करने पड़ रहे हैं
• समस्या यह है कि ऐसी workflow वही skills मांगती है जो आम तौर पर दशकों के अनुभव से बनती हैं
• senior engineers भी इससे बाहर नहीं हैं
  • Simon Willison ने, लगभग 30 साल के अनुभव वाले developer होने के बावजूद, कहा कि अगर application क्या कर सकती है और कैसे काम करती है इसका “मज़बूत mental model” न हो, तो features बढ़ने के साथ reasoning कठिन होती जाती है

अनुभवी orchestrator का paradox

• Anthropic की हाल की research coding agents के बार-बार उपयोग के ख़तरे के रूप में “supervision paradox” पर बात करती है
• मूल बात यह है कि Claude का प्रभावी उपयोग supervision मांगता है, और Claude को supervise करने के लिए वही coding skills चाहिए जो AI के अत्यधिक उपयोग से कमज़ोर हो सकती हैं
• LinkedIn पर 50 engineers को manage करने वाले Sandor Nyako ने संगठन में skill atrophy फैलते देख अपनी team से कहा कि “ऐसे कामों में AI का उपयोग न करें जिनमें critical thinking या problem-solving चाहिए”
• उनका मानना है कि skills विकसित करने के लिए कठिनाई झेलना और समस्याओं पर गहराई से सोचना ज़रूरी है, और critical thinking के बिना यह पूछना मुश्किल हो जाता है कि AI सही है या नहीं
• “overuse” की सीमा भी स्पष्ट नहीं है, लेकिन data-based research और anecdotal material दिखाते हैं कि कुछ ही महीनों में skills तेज़ी से कमजोर हो सकती हैं
• coding agents का उपयोग एक विरोधाभास पैदा करता है: agents को अच्छी तरह manage करने के लिए जिन skills की ज़रूरत है, वही skills इससे कमजोर हो सकती हैं

LLM गलत दिशा को तेज़ करते हैं

• ज़रूरी नहीं था कि code हर हाल में और तेज़ लिखा जाए
• खासकर ऐसा code जिसे पूरी तरह समझा न गया हो, या code की इतनी बड़ी मात्रा जिसे reasonable time में review न किया जा सके, उसे तेज़ी से बनाना तो बिल्कुल ज़रूरी नहीं था
• AI से पहले अच्छे developers की प्राथमिकताएँ आम तौर पर ये थीं
  • code और codebase के रिश्ते को समझना
  • यह सुनिश्चित करना कि वह documented efficient standards पर खरा उतरता है
  • readability बनाए रखते हुए लक्ष्य के लिए ज़रूरी code lines को न्यूनतम रखना
  • processing time को ध्यान में रखना
• Agentic coding और LLM ने व्यवहार में इन प्राथमिकताओं को उलट दिया है
• मौजूदा capabilities और usage pattern अक्सर तय समय में generated code की मात्रा बढ़ाकर speed बढ़ाने पर केंद्रित हैं
• speed उच्च कौशल का स्वाभाविक byproduct हो सकती है, लेकिन जब इसे ज़बरदस्ती धक्का दिया जाता है तो accuracy गिरती है
• LLM को गहरी समझ और संक्षिप्तता बढ़ाने के लिए इस्तेमाल किया जा सकता है, लेकिन forced adoption और संगठन-व्यापी token usage-केंद्रित उन्माद दिखाते हैं कि व्यवहार में चीज़ें अक्सर उस दिशा में नहीं जातीं

coding भी planning है

• कुछ developers code के ज़रिए बेहतर plan करते हैं और बेहतर सोचते हैं
• code के साथ सोचना और काम करना कोई अर्थहीन repetitive labor नहीं, बल्कि वह प्रक्रिया है जो security, performance, user experience और maintainability तक तकनीकी स्तर पर सोचने के लिए मजबूर करती है
• OpenCode के निर्माता Dax ने Spec Driven Development पर interview में कहा कि जब वह नया या कठिन काम करते हैं, तो खुद code टाइप करने की प्रक्रिया से समझते हैं कि क्या करना है
• वह पहले बहुत बड़ा spec लिखने के बजाय types, functions के बीच interactions और folder structure को सीधे छूकर concept बनाना पसंद करते हैं
• इंसान जो कहता है वह हमेशा उसकी वास्तविक मंशा से मेल नहीं खाता, और LLM इस अस्पष्टता को assumptions या hallucinations से भर देते हैं
• नतीजे में ज़्यादा review, agent से ज़्यादा fixes, ज़्यादा token usage और generated output से और बड़ा disconnect पैदा होता है
• उल्टा, बहुत clear और structured prompt लिखने पर भी LLM hallucinated methods दे सकता है
• LLM compiler नहीं, बल्कि next-token prediction engine हैं; इसलिए deterministic system को probabilistic system से बदलकर यह उम्मीद नहीं की जा सकती कि ambiguity शून्य हो जाएगी
• AI को सक्रिय रूप से इस्तेमाल करने वाले senior developers भी इस disconnect को बढ़ती समस्या मानने लगे हैं

vendor lock-in और cost uncertainty

• Claude outage के दौरान ऐसी posts आईं जिनमें कहा गया कि कुछ developers और engineering teams ठहर गईं
• कुछ workflows और coding abilities पहले ही इस हद तक पहुँच चुकी हैं कि वे खास AI vendors पर बहुत ज़्यादा निर्भर हैं
• जो skill पहले सिर्फ़ keyboard और text editor से की जा सकती थी, अब उसके लिए AI model provider की subscription चाहिए

• token cost का अनुमान लगाना कठिन है

  • model providers को भारी subsidy मिल रही है, और models खुद भी लगातार बदलती नींव पर खड़े हैं
  • नए model releases अक्सर ऊँचे benchmarks, hype, और वास्तविक उपयोग के बाद “nerfed” होने की शिकायत जैसे pattern दोहराते हैं
  • साथ ही यह शिकायत भी आती है कि वही काम करवाने में 2–3 गुना ज़्यादा tokens जल रहे हैं
  • employee cost का अनुमान लगाया जा सकता है, लेकिन token cost का daily, monthly या yearly स्तर पर अनुमान मुश्किल है
  • अगर पूरी team default रूप से agentic coding अपनाती है, तो cost account को बहुत flexible रखना होगा
  • Primeagen ने कहा है कि पूरी agentic workflow अपनाने पर “model provider असल में आपको own कर लेता है”
  • ऐसा औद्योगिक ढाँचा बन सकता है जिसमें वही काम करने के लिए token consumption cost देनी पड़े जो पहले critical thinking और problem-solving ability से किया जाता था
  • यह सिर्फ़ product vendor lock-in नहीं, बल्कि पूरे उद्योग की skill capacity पर vendor lock-in जैसा है
  • इसकी financial और intellectual foundation कभी भी हिल सकती है, और local LLM अभी उस स्तर के usage को absorb करने के लिए तैयार नहीं हैं
  • यह समस्या सिर्फ़ theoretical नहीं है; इस पर reporting हो चुकी है, और model providers खुद भी इसे रेखांकित कर रहे हैं
  • Anthropic की एक और research कहती है कि debugging skills में 47% की गिरावट आई
  • workplace, खासकर software engineering, में AI को आक्रामक रूप से अपनाने पर जल्दी परिणाम पाने के लिए AI पर निर्भरता बढ़ सकती है, जबकि समस्या आने पर debug करने की बुनियादी skills बन ही नहीं पातीं

AI की भूमिका कम करने वाला approach

• LLM learning और capability improvement के लिए एक शक्तिशाली tool हो सकते हैं
• वे concepts और techniques को अधिक गहराई और चौड़ाई से explore करने में मदद कर सकते हैं, और पहले से कम मेहनत में नए ideas के साथ experiment करने दे सकते हैं
• code generation tools अपने आप में नई चीज़ नहीं हैं
  • Emmet, autocomplete और snippets ऐसे tools थे जो कम manual typing और अधिक generation के लिए बने थे
  • COBOL ने भी MOVE, WRITE जैसे English-like शब्दों से कम लिखकर अधिक command व्यक्त करने की कोशिश की थी
  • jQuery का motto भी “write less, do more” था
• LLM को ऐसे code generation tools में एक और जोड़ के रूप में देखा जा सकता है
• अहम फ़र्क़ यह है कि LLM और coding agents को सहायक process के रूप में इस्तेमाल किया जाए
• productivity के लिए व्यक्ति की skills की कुर्बानी दिए बिना, planning stage की brainstorming में AI का उपयोग और implementation में इंसान की सक्रिय भागीदारी बनाए रखना संभव है
• ज़रूरत पड़ने पर ही delegation करने से productivity gains मिल सकते हैं और understanding debt कम हो सकता है

रोज़मर्रा का उपयोग पैटर्न

• LLM का उपयोग specs और planning बनाने में करें, लेकिन implementation इंसान lead करे
• यह “orchestration” workflow को उलटने जैसा है, और task के हिसाब से 20% से 100% तक direct coding की जा सकती है
• model इस्तेमाल करते समय भी request और generated code के बीच दूरी घटाने के लिए अक्सर pseudocode लिखा जाता है
• model को temporary code generation, conversational documentation और research tool की तरह इस्तेमाल किया जाता है
• इसे responsible delegation tool की तरह इस्तेमाल करें: सवाल पूछें, iterate करें, refactor करें और approach को अधिक स्पष्ट करें
• एक बार में उतना ही code generate करें जितना review किया जा सके
• अगर review के लिए code बहुत ज़्यादा हो, तो गति धीमी करें, काम को छोटे हिस्सों में बाँटें, और ज़रूरत हो तो खुद refactor करें ताकि अंतिम परिणाम की व्यापक समझ बनी रहे
• ऐसा implementation LLM या agent को न सौंपें जिसे आपने खुद कभी किया ही न हो या अकेले न कर सकते हों
• अपवाद education या tutorial के उद्देश्य हो सकते हैं, और ऐसे outputs को बाद में अक्सर फेंक दिया जाता है
• संक्षेप में, AI का उपयोग Star Trek के Data की तरह नहीं बल्कि Ship’s Computer की तरह करना चाहिए

सिर्फ़ तेज़ नहीं, बेहतर काम

• models से productivity gains वास्तव में मिलते हैं
• साथ ही, काम को सीधे और बार-बार हाथ लगाने से पैदा होने वाली friction और understanding भी वास्तव में महत्वपूर्ण है
• coding को समझे बिना coding का democratization करने की कोशिशें बार-बार असफल रही हैं
• code को समझने के लिए code के साथ सीधे जुड़ना पड़ता है
• अगर आप code के साथ लगातार जुड़े और लिखते नहीं रहते, तो वह समझ और connection खो सकते हैं
• समझ घटने पर agents को बेहतर manage करने की क्षमता भी कम हो जाती है, और AI coding phase एक अजीब और अनावश्यक रूप से तनावपूर्ण संक्रमणकाल बन जाता है

यह एक और बड़ा experiment हो सकता है

• मौजूदा रुझान ऐसा लगता है जैसे हम लंबे समय के असर को पूरी तरह समझे बिना अपने ऊपर एक और बड़े पैमाने का experiment चला रहे हों
• social media अपनाते समय भी उसके दीर्घकालिक निहितार्थ पूरी तरह समझे नहीं गए थे, और बाद में ध्यान की कमी जैसी कई व्यापक समस्याएँ सामने आईं
• इस बार दाँव पर इससे भी ज़्यादा ख़तरनाक चीज़ है
• fast.ai के निर्माता Jeremy Howard ने कहा है कि जो लोग AI agents पर सब कुछ दाँव पर लगाते हैं, वे अपनी खुद की अप्रासंगिकता सुनिश्चित करते हैं
• अगर आप अपनी पूरी सोच computer को outsource कर देंगे, तो आप अपनी capability बढ़ाने, सीखने और अधिक सक्षम बनने की प्रक्रिया रोक देंगे

[GN⁺]

Hacker News की राय

• पिछले कुछ वर्षों में agentic coding के साथ काम करते हुए, मैंने 35 साल तक हाथ से सीधे programming करने की तुलना में अपनी भाषा, सिस्टम और tools के बारे में ज़्यादा सीखा है
  सिस्टम, तकनीक और approach चुनने की मेरी क्षमता अब भी tool से कहीं बेहतर है, लेकिन ये tools बहुत-सी बारीकियों को जानने वाले बेहद जानकार intern जैसे हैं। अनुभव कम है, और गलतियाँ भी पूरे उत्साह से करते हैं, लेकिन कम-से-कम शुरुआत में feedback लेते हैं और उस पर अमल भी करते हैं। हाँ, वे चीज़ों को पूरी तरह समझकर आत्मसात नहीं करते, इसलिए अक्सर भूल जाते हैं
  यह कहना कि आपको जिस चीज़ पर काम कर रहे हैं उसका सब कुछ पता होना चाहिए, बहुत भोली सोच है। अगर आप दो या उससे अधिक टीमों में काम करते हैं, तो बहुत-से हिस्से ऐसे होंगे जिन्हें आप पूरी तरह नहीं समझते, और अगर codebase पुराना है तो लगभग सब कुछ अपरिचित लग सकता है। दशकों में जमा हुए बड़े monorepo में, लोग आपको जिस हिस्से का expert मानते हैं, उसे भी अगर आप सचमुच ठीक से समझते हों तो खुद को भाग्यशाली मानिए
  ऐसी बातें कहने वाले लोग आमतौर पर या तो बहुत junior होते हैं, या लगभग अकेले काम करते हैं, या ऐसा लगता है जैसे 20 साल से एक ही project पकड़े बैठे हों। किसी team या बड़े संगठन में काम करने वाला कोई भी यह दावा नहीं कर सकता कि उसे पूरा codebase पता है, और agentic programming करने वाला भी नहीं। फिर भी agent से सवाल पूछो तो जवाब मिल जाता है, और जिसने पूरी ज़िंदगी दूसरों का code पढ़ा हो, वह LLM का लिखा code भी पढ़ सकता है। बुरा code machine ने लिखा हो या इंसान ने, इससे मुझे कोई फर्क नहीं पड़ता, और कम-से-कम machine मेरा feedback लेकर उस पर काम तो करती है

  • आम तौर पर यह सही है कि आपको सब कुछ, यहाँ तक कि ज़्यादातर चीज़ें भी जानने की ज़रूरत नहीं होती, लेकिन जिस project या system पर मैं काम कर रहा हूँ, उसके बारे में जो ज़रूरी है उसे तेज़ी से ढूँढ और समझ सकना चाहिए
    मैंने बहुत-सी software teams को मामूली समस्या पर भी रुकते देखा है, जैसे ही low-level language, assembly, कम प्रचलित algorithm, या network protocol जैसी अतिरिक्त skill की ज़रूरत पड़ती है
    दूसरी तरफ, कई बार समस्या यह नहीं होती कि लोग जो देख रहे हैं उसे समझ नहीं सकते, बल्कि यह कि वे black box चीज़ें इस्तेमाल कर रहे होते हैं, जैसे proprietary library या proprietary operating system, इसलिए वे भीतर जाकर देख नहीं सकते और वास्तविक behavior की पुष्टि नहीं कर सकते
    इसलिए मेरा मानना है कि चाहे बहुत कम ही सही, लेकिन जिस चीज़ पर आप काम कर रहे हैं उसके बारे में सब कुछ पता लगाने का माहौल हमेशा संभव होना चाहिए
  • 35 साल के अनुभव का मतलब है कि सीखने की क्षमता और एक सामान्य ढाँचा पहले से बना हुआ है, और आपको पता है कि agentic coding को सहायक tool की तरह कैसे इस्तेमाल करना है। जो junior आज शुरुआत कर रहे हैं, उनके पास यह नहीं है, इसलिए वे agentic coding पर ज़रूरत से ज़्यादा निर्भर हो जाते हैं, और उन्हें यह भी नहीं पता होता कि वे क्या नहीं जानते
  • यह लेख यह नहीं कह रहा कि “जिस चीज़ पर काम कर रहे हो उसका सब कुछ जानो”, बल्कि यह कह रहा है कि code लिखने की क्षमता और code को प्रभावी ढंग से पढ़ने की क्षमता मूल रूप से जुड़ी हुई हैं
  • सहमत हूँ। मैं यह नहीं जानता कि रेत transistor कैसे बनती है या assembly के हर विवरण क्या हैं, फिर भी ठीक से काम कर रहा हूँ, इसलिए मैं भी पूरे stack का सब कुछ नहीं जानता
    अहम बात यह है कि आप बाकी system को सीखने से डरते नहीं, और एक index बनाए रखते हैं
    सबसे बढ़कर, किसी भी चीज़ को जल्दी समझ सकना चाहिए। तभी आप व्यापक रूप से काम कर सकते हैं। ज़रूरत पड़ने पर गहराई में जाओ, और ज़रूरत पड़ने पर ऊपरी स्तर से देखो — समस्या के हिसाब से सही abstraction level पकड़ना चाहिए
    बहुत पहले university में computer science majors को engineering के कई व्यापक हिस्से पढ़ाए जाते थे। जब मैंने पूछा, “मुझे chemical engineering या analog control systems कब जानने की ज़रूरत पड़ेगी?”, तो जवाब मिला, “शायद कभी काम न आए। लेकिन इतना जल्दी समझना आना चाहिए कि उसके लिए code लिख सको, और फिर बाद में भूल भी जाओ तो चलेगा। हम तुम्हें मज़बूत नींव दे रहे हैं”
    बड़ी codebase के अंदर भी यही बात लागू होती है
  • यहाँ समस्या यह है कि एक अर्थ में code लिखने वाला agent और उस code के बारे में सवालों का जवाब देने वाला agent एक ही agent नहीं होता। अगर मूल agent ने अपनी reasoning process छोड़ी ही नहीं, तो अक्सर बहुत असहाय स्थिति बन जाती है
    git-ai [0] जैसे tools LLM session को capture करते हैं, हर file edit को किसी खास agent action से जोड़ते हैं, और agent को code के किसी टुकड़े के बारे में उससे जुड़ी बातचीत — यानी user ने क्या prompt किया था, उस code को बनाने वाले LLM की reasoning क्या थी — यह सब देखने देते हैं। इससे संतुलन बदल सकता है, लेकिन अभी इसका व्यापक इस्तेमाल नहीं है
    [0] https://usegitai.com/

• 25 साल से अधिक अनुभव वाले senior developer के रूप में, हाल ही में मुझे “क्या आप 5 मिनट के लिए जुड़ सकते हैं” टाइप की meeting में धकेल दिया गया, और मुझे ऐसी meetings से सचमुच नफरत है जहाँ बीच में बिना किसी context के घसीट लिया जाता है
  बिना परिचय के सवाल तेज़ी से फेंके गए, और बात दर्जनों external integrations में से एक की थी। और बदतर यह कि उधर की टीम अपनी अलग terminology इस्तेमाल करती है
  इन integrations को बनाते समय model पर बहुत ज़्यादा निर्भरता थी, इसलिए सवाल समझना बहुत कठिन था। काम बेहद नीरस था, और बाहर से मोटी specifications भी दी गई थीं
  मैं अब भी इस बात को सकारात्मक मानता हूँ कि अगर model न इस्तेमाल किया होता, तो शायद 10 गुना समय लगाने पर भी ये integrations पूरी नहीं हो पातीं। लेकिन अब मैं गंभीरता से सोच रहा हूँ कि उन “aha” points को फिर से document करूँ, ताकि आगे ऐसे असहज पल न आएँ
  मैंने किसी meeting में खुद को इतना अज्ञानी और शर्मिंदा कभी महसूस नहीं किया, और मेरे पास कहने को बस यही था: “मैं यह देखकर बताऊँगा, यह भी, और वह भी”
  cognitive debt सचमुच वास्तविक है, और व्यक्तिगत रूप से यह technical debt से भी ज़्यादा दर्दनाक है। technical debt पूरी team साझा करती है, लेकिन cognitive debt व्यक्तिगत होती है, और अगर उसे बनाने वाला मैं ही हूँ, तो मुझे उससे बेहतर परिचित होना चाहिए
  आगे से, जब तक “यह क्या है”, “वह क्या है” टाइप की 5-मिनट वाली flashcard-जैसी Markdown glossary न बना लूँ, मैं नहीं मानूँगा कि काम पूरा हुआ है

  • यह उस स्थिति जैसा है जिसकी शिकायत doctors अक्सर करते हैं। patient आता है और कहता है कि बस कोई दवा prescribe कर दीजिए, लेकिन अच्छे doctors अक्सर पूरा संदर्भ समझे बिना दवा या सलाह नहीं देते
    senior developer वही होता है जिसे पसंद न आने वाले व्यवहार पर रोक लगानी चाहिए। आपके पास वह authority होती है। आप कह सकते हैं, “दिलचस्प सवाल है। अपना perspective देने के लिए मुझे थोड़ा और context चाहिए। क्या आप system architecture का एक छोटा-सा overview दे सकते हैं, या यह बता सकते हैं कि इस approach से असल में कौन-सी समस्या हल करनी है?”
  • कैसा workplace होगा जहाँ किसी को meeting के बीच में खींचकर, बिना context के technical questions दागे जाएँ और उसी वक्त जवाब की उम्मीद की जाए? बहुत-से लोग ऐसी जगह से बचना चाहेंगे, इसलिए बताना चाहिए
    ऐसे व्यवहार के जवाब में “इस सवाल का सही उत्तर देने के लिए मुझे docs और code देखना पड़ेगा” एकदम ठीक और काफ़ी diplomatic जवाब है
  • अहंकार छोड़ो और इसकी चिंता मत करो। आपने tool इस्तेमाल किया, और अगर नहीं करते तो और मुश्किल होती। बस कह दो, “मुझे नहीं पता, AI से पूछता हूँ”
  • 2014 का 7-मिनट का “The Expert” sketch याद आता है: https://www.youtube.com/watch?v=BKorP55Aqvg
    ऐसी meetings मज़ेदार नहीं होतीं जहाँ expertise को कुछ बनाने वाली चीज़ की तरह नहीं, बल्कि सिर्फ रचनात्मक confirmation bias की पुष्टि के साधन की तरह इस्तेमाल किया जाता है
  • आसान है। आखिर में agent से वही सूची लिखवा लो। और फिर उसे कभी मत पढ़ो

• generated code में समस्याएँ ढूँढने के लिए developer को सचमुच परवाह करनी पड़ती है। बहुत-से developers, खासकर बड़ी कंपनियों में, पहले से ही अपने काम से काफ़ी detached हैं और बस minimum effort से ticket बंद करके ज़िम्मेदारी आगे धकेलने का तरीका ढूँढते रहते हैं
  ऐसे developers, चाहे सक्षम हों, फिर भी generated code को इतना समझने की मेहनत नहीं करेंगे कि agent से छूटी हुई समस्याएँ पकड़ सकें। खासकर आज के AI-driven speed hype में तो और भी नहीं

  • सही। generated code पढ़ना इसलिए भी कठिन है क्योंकि यह मानव लेखक के mental model पर टिके सभी semantic expectations तोड़ देता है
    generated code भाषाई रूप से भरोसेमंद दिखता है, लेकिन यह अक्सर आम idioms की नकल incoherent तरीके से करता है, इसलिए असली bug ऐसे तरीकों से संयोग से छिप सकते हैं जिनकी कल्पना सामान्य इंसान, यहाँ तक कि खराब programmer भी, शायद न करे
    LLM के पास कोई आंतरिक evaluation नहीं होती, इसलिए reviewer को इसे line-by-line आँकना पड़ता है, और उन छिपे हुए आधारों व tacit knowledge को फिर से शुरू से खड़ा करना पड़ता है जो LLM के पास थे ही नहीं। और इस प्रक्रिया में कभी-कभी गैर-समस्याओं में फँसकर महँगा समय बर्बाद होता है
    इस बिंदु पर कई बार शुरू से लिखना कम महँगा पड़ता है
  • बड़ी companies में अपवाद होते हैं, लेकिन कई teams में बहुत-से developers को परवाह करने के लिए ही सज़ा मिलती है
  • कुछ लोग कहते हैं कि बड़ा भाई पहले junk food बेचता है, फिर वजन घटाने का “solution” बेचता है
    शायद अभी companies junk AI खरीद रही हैं, और अगले चरण में उन्हें उसका “solution” भी वादा किया जा रहा है। capitalism ठीक वैसा ही चल रहा है जैसा उम्मीद थी

• यह लेख थोड़ा मुद्दे के किनारे से निकलता हुआ लगता है
  AI का बहुत इस्तेमाल करोगे तो skill atrophy होगी
  लेकिन मैं कमरे में खड़े उस असहज हाथी को स्वीकार करना चाहता हूँ। AI लोगों को बहुत तेज़ बना रही है। इसका मतलब यह नहीं कि तेज़ output अपने-आप में बुरा है, बल्कि यह कि output और code उस समग्र समझ और अनुभव से आगे निकल रहे हैं जिसने उसे बनाना चाहिए था। इनाम उस व्यक्ति को मिल रहा है जो business value की बात कर सकता है, न कि उस व्यक्ति को जो गहरी जानकारी के आधार पर सुरक्षित निर्णय लेते हुए चीज़ें बनाता है
  AI अच्छी है, और अच्छे solutions भी दे सकती है, लेकिन अंततः उसे पता नहीं होता कि वह क्या कर रही है, और best case में भी उसे मज़बूत orchestration चाहिए
  हम business-driven development की कीचड़ में हैं, और खराब फैसलों के लिए पर्याप्त reputational punishment वापस नहीं आ रही

  • skill atrophy वास्तविक है। लेकिन मैं सचमुच 10 साल से अपने managers से skill atrophy की शिकायत करता आया हूँ। इसलिए मेरे लिए AI बस कई समस्याओं में से एक है। किसी वजह से मैं हर साल कम coding कर रहा था
    दूसरे शब्दों में, मुझे यक़ीन नहीं कि skill atrophy इतनी बड़ी समस्या है। यह बस संकेत भी हो सकता है कि हमारे काम की प्रकृति बदल रही है। शायद हम ऐसे युग में जा रहे हैं जहाँ C++ standard याद रखना और उसकी सैकड़ों features का सही उपयोग करना, अच्छी architecture समझने की क्षमता जितना मूल्यवान नहीं रहेगा
  • मोटे तौर पर सहमत हूँ, लेकिन कठोर सच्चाई यह है कि ज़्यादातर corporate priorities हमेशा से लगभग, ढीले-ढाले business-driven development ही रही हैं। मानव-केंद्रित engineering process उस दर्शन के सबसे बुरे नतीजों को संयोग से रोकने वाली एक guardrail थी, जानबूझकर बनाई गई व्यवस्था नहीं
  • “बहुत तेज़” होने का एक और पहलू यह है कि यह हमारी समस्याओं के क्रम को बदल देता है
    सामान्य development में आप “क्या हम सचमुच यह बनाना चाहते हैं?” और “अगर इसे ऐसे बनाया तो क्या गलत हो सकता है?” जैसे सवालों पर ज़्यादा आगे-पीछे होते हैं, आदर्श रूप से PR approval, merge या deploy से पहले। अब उसका कुछ हिस्सा “चलो बाद में देखें कौन शिकायत करता है” की तरफ खिसक रहा है। जैसा कहा जाता है, रोकथाम का एक औंस इलाज के एक पाउंड से बेहतर है
  • business-driven सरकार business-driven नियम लिख रही हो, ऐसे business-driven दुनिया में, अगर आप सफलता optimize करना चाहते हैं तो विकल्प क्या है, समझ नहीं आता
  • सिर्फ companies ही ऐसी नहीं हैं। open source projects में भी मैं अक्सर ऐसे बड़े PR merge होते देखता हूँ जो ऊपर-ऊपर ठीक लगते हैं लेकिन उनमें हज़ार छोटे bugs भरे होते हैं। जानलेवा नहीं, पर काफ़ी परेशान करने वाले
    ऊपर से वह code उस project की idiomatic C++ भी नहीं होती, और LLM मौजूदा APIs को पूरी तरह नज़रअंदाज़ कर देती है। इन्हें ठीक किया जा सकता है और maintainer को पकड़ लेना चाहिए, लेकिन generated code की मात्रा के कारण सबको बहुत ज़्यादा ऊर्जा खर्च करनी पड़ती है

• ऐसे blog posts लगभग निश्चित रूप से AI की मदद से लिखे गए होंगे, जबकि यह बात यहाँ और पूरे internet पर सालों से comment topic बनी हुई है। skill degradation गंभीर चिंता है, और 2022 से AI को लेकर संशय रखने वाले सभी लोग इसे बार-बार कहते आए हैं, लेकिन कुछ लोग और कुछ जगहें मानो परवाह ही नहीं करतीं
  अगर किसी बिंदु पर आप code के बारे में insight के बिना सिर्फ garbage machine का lever खींच रहे हैं, तो आपका boss यह पूछे कि आपको 50,000 डॉलर से ज़्यादा salary क्यों मिले — यह सवाल जायज़ हो सकता है

• AI का इस्तेमाल सिर्फ तेज़ जाने के लिए करना गलत चीज़ को optimize करना है। मैंने जहाँ भी काम किया, वहाँ किसी feature को implement करने में लगने वाले बाकी सारे कामों की तुलना में “code लिखना” सबसे कम समय लेता था
  मान लीजिए कोई feature है जिसे एक दिन में code किया जा सकता है। पहले company की Agile हो या Waterfall, उसकी planning mindset के ज़रिए सब कुछ plan करना होगा, काम तोड़ना होगा, JIRA tickets बनानी होंगी, और तय करना होगा कि कौन करेगा। इसमें ही कई दिन या हफ्ते लग सकते हैं। फिर proposed design वाला design doc लिखना, peers और teammates से review लेना होगा; अगर feature वास्तविक है तो इसमें एक और हफ्ता लग सकता है। अगर कई teams जुड़ी हैं, तो उनकी सहमति और design alignment भी चाहिए, तो एक और हफ्ता जोड़ लो। कुछ जगहों पर काम शुरू करने की approval भी चाहिए, और approver के schedule व availability के हिसाब से कुछ और दिन निकल जाते हैं
  उसके बाद एक दिन code लिखते हो और tests पास कराते हो
  फिर code review होता है, team के साथ कई rounds में आगे-पीछे चलता है, और अतिरिक्त reviews भी आ सकते हैं। इसमें फिर कई दिन या हफ्ते लगते हैं। बड़ी company हो तो legal, privacy, performance, accessibility, QA जैसी दूसरी teams के तमाम reviews भी पार करने होते हैं। समानांतर चलें तब भी सावधानी से कहें तो 2 हफ्ते और जोड़ लो। अंत में staging पर डालते हो और कुछ समय internal dogfooders के बीच पकने देते हो ताकि भरोसा हो कि यह सही चल रहा है। 1 हफ्ता और। अब staging से production में ले जाने की तैयारी है, लेकिन कोई गंभीर company कुछ भी सीधे 100% production पर नहीं भेजती। rollout धीरे-धीरे बढ़ाना पड़ता है, और rollback की ज़रूरत हो तो feedback और metrics देखने पड़ते हैं। पूरी release में और 2 हफ्ते लग सकते हैं
  यानी design से release तक 2 महीने लगने वाले feature में, हम उस हिस्से को जो एक दिन लेता है, 5 मिनट तक घटाने के लिए पागल हुए जा रहे हैं

  • यह software engineering की कहावत याद दिलाता है
    software बनाते समय याद रखना चाहिए कि वह समस्या के बारे में आपकी समझ का snapshot है। वह सभी को — यहाँ तक कि भविष्य के आपको भी — आपके approach, स्पष्टता, और सामने की समस्या के समाधान की उपयुक्तता के बारे में बताता है। इसलिए यह समझदारी से चुनना चाहिए कि आप क्या कहना चाहते हैं
    2 महीने वाले feature में एक दिन वाले हिस्से को 5 मिनट करने की बात बिल्कुल सही पकड़ी गई है
  • models अब dependency updates, build/deploy scripts, और unit tests जैसे उबाऊ कामों को लगभग पूरी तरह automate करने में बहुत अच्छे हो गए हैं। जो काम पहले कई दिन लेते थे, वे अब कुछ मिनटों में हो सकते हैं, और यहाँ 50x speedup आसानी से संभव है
    स्थिर companies में यह काम सभी engineers की रोज़मर्रा की ज़िंदगी का छोटा हिस्सा नहीं था। “platform engineering” कहो या कुछ भी, यह इलाका मर चुका है
    और जो तकनीकी रूप से जोखिम भरे विचार पहले risk-reward balance ठीक न होने की वजह से आज़माए नहीं जाते थे, वे अब पहुँच में हैं। यह सिर्फ “तेज़ जाना” नहीं है; किसी चीज़ को आज़माने की speed engineering process की प्रकृति ही बदल देती है
  • आपने जो सारे process बताए, वे code लिखने में लगने वाला समय अधिकतम करने के लिए ही मौजूद हैं[0]। corporate दुनिया में software engineers सबसे महंगे कर्मचारियों में होते हैं, और उनका समय बर्बाद होना P&L पर असर डालता है, इसलिए ये process बनाए जाते हैं
    अगर software engineers पर्याप्त सस्ते हो जाएँ, तो इनमें से बहुत-से process की ज़रूरत ही खत्म हो जाएगी। जिन companies में पहले से ऐसे process हैं, वे मुश्किल में पड़ेंगी क्योंकि ऐसी bureaucracy तोड़ना बेहद कठिन है; लेकिन जिनके पास शुरू से ऐसे process नहीं हैं या जो उन्हें हटा सकती हैं, उनके पास बड़ा competitive advantage होगा
    यह नई बात नहीं है। startups हमेशा execution speed के दम पर incumbents से प्रतिस्पर्धा करते आए हैं। नया यह है कि अब उस speed को लंबे समय तक बनाए रखने की क्षमता है
    legal, privacy, performance, accessibility, QA जैसे reviews भी सब target पर हैं। अगर company ऐसे reviews से जुड़ी legal liability किसी बाहरी provider पर डाल सकती है, तो वह ऐसा करेगी
    [0] फिलहाल इस विडंबना को छोड़ देते हैं कि इस process का बड़ा हिस्सा आख़िरकार उन्हीं कर्मचारियों पर डाल दिया जाता है जिनका समय बचाने के लिए यह बनाया गया था
  • यह बहुत हद तक इस पर निर्भर करता है कि आप किस तरह की company में काम करते हैं। उदाहरण के लिए, किसी startup को इस तरह नहीं चलाया जा सकता
  • हर company ऐसे काम नहीं करती
    Big Tech में ऐसे दिखावटी process बहुत होते हैं, लेकिन छोटी companies तेज़ और खुरदरे ढंग से आगे बढ़ सकती हैं

• code quality आख़िरकार आप पर निर्भर है
  agent के साथ iterate करते रहो; ऐसा कुछ नहीं जो आपको तब तक polish करने से रोके जब तक code वही ठीक वही quality न पा ले जो आप खुद लिखते समय चाहते हैं

  • अगर लक्ष्य मेरी अपनी code quality है, तो मेरे लिए खुद लिखना ही तेज़ और कम frustrate करने वाला रहा है
  • मुझे अपनी code quality नहीं चाहिए, मुझे AGI code quality चाहिए। वही वादा किया गया था, साथ में jetpack और flying cars भी
  • इसलिए मुझे ऐसे लेख समझ नहीं आते, और वे मानव आलस्य पर case study जैसे लगते हैं। अगर अच्छे परिणाम चाहिए तो परिणाम review करो और iterate करो। अगर अच्छी foundation चाहिए तो वह foundation खुद लिखो, और बाद में वही foundation LLM को खराब code लिखने से काफ़ी हद तक रोकती है
    ऐसे लेख काफ़ी frustrate करते हैं। हालांकि लेखक ने जो token cost की बात की है, वह वास्तविक और जोखिमपूर्ण है
  • कुछ रोक नहीं रहा, लेकिन शुरू से खुद लिखने की तुलना में यह धीमा है। AI productivity gain एक मिथक है
  • मेरे अनुभव में AI को वहाँ तक मनाते-मनाते लाने में उतना ही या उससे ज़्यादा समय लगता है। खासकर जब यह भी साबित न हो कि वह तेज़ है, तो LLM को बीच में रखने से बेहतर है सीधे खुद लिखो और जानो कि चीज़ कैसे काम करती है

• मैं AI tools का उपयोग approach पर brainstorming के लिए और कभी-कभार code generate करने के लिए करता हूँ, लेकिन असली typing खुद करता हूँ। इससे समय के साथ mechanism और programming language भूल जाने की संभावना कम होती है

  • मैं भी ज़्यादातर implementation plan माँगता हूँ, लेकिन code को न्यूनतम रखकर, या बिना code, या pseudocode में; असली code खुद लिखता हूँ। open source काम में मेरी खुशी का मुख्य हिस्सा खुद code लिखना है
    सच कहूँ तो अगर सारा काम बस LLM को code लिखने के लिए prompt करना और उसका review करना रह जाए, तो शायद मैं open source maintainer बने रहने की ज़हमत ही न उठाऊँ। उसमें कोई संतुष्टि नहीं दिखती
    अगर यह मेरी paid job होती, तो मैं LLM का इस्तेमाल कैसे अलग ढंग से करता — यह सोचने वाली बात है। मैं software developer इसलिए हूँ क्योंकि मुझे यह craft खुद पसंद है। मुझे बनाना पसंद है, दिमाग लगाकर ideas को code में बदलना पसंद है। अगर काम सिर्फ LLM को prompt करना रह जाए, तो पता नहीं मैं वह पेशा जारी रखूँगा या नहीं। कम-से-कम दूसरे career options देखना शुरू कर दूँगा
  • एक उपयोगी approach यह है कि उससे कहो कि वह कभी तुम्हारे लिए code न लिखे। इससे वह explanation देने को मजबूर होता है, और बाद में तुम खुद coding करके उस idea को आज़माते हुए बेहतर समझते हो
    maintain करने वाले code में मैं यही करता हूँ। फिर भी model बहुत-सी गलत जानकारी मिला देता है, इसलिए कभी-कभी फँस जाता हूँ। अक्सर वे बातें होती हैं जो कभी सही थीं लेकिन अब गलत हैं
    throwaway scripts या आसानी से validate होने वाली scripts मैं generate करने देता हूँ, लेकिन कहता हूँ कि over-engineering न करे और हर edge case पकड़ने की कोशिश भी न करे। scripts में किसी failed step का साफ़ दिख जाना, error के साथ रुक जाना, समझने में ज़्यादा अच्छा होता है
    PowerShell जैसी भाषाएँ, जिन्हें पढ़ना मुझे कठिन लगता है, उनसे बचता हूँ; और ऐसी चीज़ें generate कराना पसंद करता हूँ जो स्क्रीन में समा जाएँ, ताकि मैं सब कुछ पढ़ और समझ सकूँ। Python, Bash, Batch मेरी मुख्य scripting languages हैं
  • मैंने भी system prompt में सेट कर रखा है कि वह कभी पूरा solution या code न दे। इसलिए जब मैं सवाल पूछता हूँ तो वह बस छोटा 10-line example या pseudocode जैसा कुछ देता है। यह तरीका reasoning के लिहाज़ से कहीं आसान है
    मैं अब भी AI के 50% से अधिक सुझाव ठुकरा देता हूँ। वे या तो बहुत साधारण होते हैं, या बिना वजह code इधर-उधर ले जाते हैं, या कभी-कभी बस गलत होते हैं
  • अगर AI जो भी तुम भूल गए हो वह फिर से बता सकती है, तो भूलने की चिंता क्यों हो

• मज़ेदार बात यह है कि यह technology दो में से एक चीज़ लगती है
  या तो यह manager के लिए technology है, जिसमें बिना expertise के delegation तो हो जाता है लेकिन यह पता नहीं चलता कि चीज़ गलत है या पूरी तरह असंभव, या फिर यह coder के लिए technology है, जिसमें expertise तो है लेकिन वही expertise धीरे-धीरे खोती जाती है
  इसलिए अगले quarter तक के VC और shareholders को छोड़कर, यह आखिर किसके लिए है, समझ नहीं आता

• थोड़ा off-topic है, लेकिन लेख में यह कहना कि Spec Driven Development भविष्य है, मुझे मज़ेदार लगा
  तकनीकी रूप से देखें तो Waterfall वाले समय में हम पहले से यही कर रहे थे। कभी-कभी अच्छे documentation वाले दिन याद आते हैं। पिछले 10 साल, शायद उससे भी ज़्यादा समय से, मुझे अक्सर एक-पंक्ति वाले JIRA tickets मिलते रहे हैं, जिनमें लगभग कुछ भी specify नहीं होता था, इसलिए लोगों को फोन करना पड़ता था
  मैं अभी भी AI के साथ काम करने से बच रहा हूँ। प्रयोग के लिए कुछ local models आज़माना चाहता हूँ, लेकिन किसी और की चीज़ों को जोड़-तोड़कर बनाए गए सिस्टम के लिए पैसे देने से इनकार करता हूँ। और अभी तक local models उम्मीद से कमज़ोर रहे हैं

  • remote models आगे चलकर और महँगे होंगे। उनके business future की बुनियाद inference cost में सुधार की उम्मीद पर टिकी है। आपको खुद को इस तरह की जेल में नहीं बाँधना चाहिए