कोडिंग वर्कफ़्लो में बदलाव
- 2024 के नवंबर में 80% manual+autocomplete और 20% agent coding था, लेकिन दिसंबर में यह अनुपात उलटकर 80% agent coding और 20% revision/touch-up हो गया
- व्यावहारिक रूप से अब अंग्रेज़ी में programming करने जैसी स्थिति हो गई है, जहाँ LLM को यह बताया जाता है कि कौन-सा कोड लिखना है
- इसमें अहं को ठेस पहुँचाने वाला पहलू है, लेकिन बड़े पैमाने की "code action" units में software को संभालने की क्षमता बेहद उपयोगी है
- इसे अपनाने, सेट करने, इस्तेमाल सीखने, और क्या संभव/असंभव है यह समझ लेने पर यह और प्रभावी हो जाता है
- यह लगभग 20 साल के programming करियर में base coding workflow का सबसे बड़ा बदलाव है, और यह सिर्फ कुछ हफ्तों में हुआ है
- अनुमान है कि काफ़ी संख्या में इंजीनियरों (दो-अंकीय प्रतिशत) के साथ भी ऐसा हो रहा होगा, लेकिन आम जनता की समझ अभी शायद शुरुआती single-digit प्रतिशत स्तर पर है
IDE/agent swarm/error की संभावना
- "अब IDE की ज़रूरत नहीं" या "agent swarm" जैसी hype अभी के लिए बढ़ा-चढ़ाकर कही गई लगती है
- model अब भी ग़लतियाँ करते हैं, और अगर कोड वास्तव में महत्वपूर्ण है तो बाज़ जैसी नज़र से निगरानी करनी पड़ती है, इसलिए बगल में एक बड़ा IDE खुला होना ज़रूरी है
- ग़लतियों का स्वरूप बदल गया है: अब यह साधारण syntax error नहीं, बल्कि थोड़े लापरवाह और जल्दबाज़ junior developer जैसी सूक्ष्म conceptual errors हैं
- सबसे आम error type: उपयोगकर्ता की जगह गलत assumptions बना लेना और बिना पुष्टि किए उसी पर आगे बढ़ जाना
- अतिरिक्त समस्याएँ:
- confusion को manage नहीं कर पाना
- clarification नहीं माँगना
- inconsistency को सामने नहीं लाना
- trade-off पेश नहीं करना
- जहाँ विरोध करना चाहिए वहाँ नहीं करना
- अब भी कुछ हद तक sycophantic प्रवृत्ति होना
- plan mode में स्थिति बेहतर होती है, लेकिन हल्का inline plan mode चाहिए
- code और API को ज़रूरत से ज़्यादा complex बनाने, abstraction को फुलाने, और काम के बाद dead code साफ़ न करने की प्रवृत्ति भी है
- कभी-कभी 1000 lines में अक्षम, फूला हुआ और नाज़ुक structure बना देता है, लेकिन जब पूछा जाए, "क्या इसे ऐसे नहीं किया जा सकता?", तो जवाब आता है "बिल्कुल!" और तुरंत उसे 100 lines में घटा देता है
- काम से असंबंधित होने पर भी, जो comments और code उसे पसंद नहीं आते या पूरी तरह समझ नहीं आते, उन्हें बदल/हटा देने की प्रवृत्ति अब भी है
- CLAUDE.md में निर्देश डालकर साधारण सुधार की कोशिश करने पर भी ये समस्याएँ आती हैं
- इन समस्याओं के बावजूद यह अब भी शुद्ध रूप से बहुत बड़ा improvement है, और manual coding पर लौटना बहुत मुश्किल लगता है
- मौजूदा workflow: बाईं ओर ghostty window/tab में कुछ Claude Code sessions, और दाईं ओर IDE में code की जाँच और manual edits
Tenacity
- agent को बिना रुके किसी चीज़ से जूझते देखना बेहद दिलचस्प है
- यह थकता नहीं, हतोत्साहित नहीं होता, और जहाँ इंसान काफ़ी पहले हार मानकर बाद में लौटने की सोचता, वहाँ भी यह कोशिश जारी रखता है
- किसी चीज़ से लंबे समय तक जूझकर 30 मिनट बाद आख़िरकार सफल होते देखना "AGI महसूस होने" जैसा पल लगता है
- इससे एहसास होता है कि stamina ही काम का मुख्य bottleneck है, और LLM हाथ में हो तो यह नाटकीय रूप से बढ़ जाता है
speedup
- LLM की मदद से होने वाले "speedup" को कैसे मापा जाए, यह स्पष्ट नहीं है
- जो काम करना था वह निश्चित रूप से काफ़ी तेज़ महसूस होता है, लेकिन मुख्य असर यह है कि सोचे गए काम से कहीं ज़्यादा चीज़ें की जाने लगती हैं:
- हर तरह की ऐसी चीज़ें भी code की जा सकती हैं, जिन्हें पहले coding के लायक नहीं समझा जाता था
- knowledge/skill की समस्या के कारण जिन codebases पर पहले काम नहीं कर सकते थे, अब उन तक पहुँचना संभव है
- यह speedup है, लेकिन बड़ा हिस्सा शायद expansion है
leverage
- LLM किसी खास लक्ष्य के पूरा होने तक loop चलाने में शानदार है, और यही उस "AGI-feeling" वाले जादू का बड़ा हिस्सा है
- इसे क्या करना है यह step-by-step बताने के बजाय, success criteria दें और फिर देखें
- tests पहले लिखवाएँ और फिर उन्हें pass करवाएँ
- इसे browser MCP और loop में डालें
- पहले ऐसा naive algorithm लिखवाएँ जिसकी correctness बहुत ऊँची होने की संभावना हो, फिर correctness बनाए रखते हुए optimization माँगें
- अगर तरीका imperative से declarative में बदला जाए, तो agent ज़्यादा देर तक loop चलाकर ज़्यादा leverage देता है
मज़ा
- अप्रत्याशित बात यह है कि agent के साथ programming ज़्यादा मज़ेदार हो जाती है
- blank-filling जैसी उबाऊ मेहनत हट जाती है और सिर्फ creative हिस्सा बचता है
- रुकावट/ठहराव (मज़ा न आने वाली स्थिति) कम हो जाती है, और ज़्यादा हिम्मत महसूस होती है — क्योंकि साथ में हमेशा सकारात्मक प्रगति का कोई न कोई रास्ता होता है
- कुछ लोगों की भावना उलटी भी है: LLM coding कोडिंग को ही पसंद करने वाले engineers और कुछ बनाने को पसंद करने वाले engineers में बाँट देगी
Atrophy
- यह महसूस होने लगा है कि हाथ से code लिखने की क्षमता धीरे-धीरे atrophy होने लगी है
- generation (code लिखना) और discrimination (code पढ़ना) दिमाग़ की अलग-अलग क्षमताएँ हैं
- programming से जुड़ी छोटी syntax details के कारण, लिखने में कठिनाई हो सकती है लेकिन code review आराम से किया जा सकता है
Slopacolypse
- अनुमान है कि 2026 GitHub, Substack, arXiv, X/Instagram और आम तौर पर हर digital media में Slopacolypse (कम-गुणवत्ता वाले AI-generated content की बाढ़) का साल होगा
- वास्तविक सुधारों के अलावा, बहुत ज़्यादा AI hype productivity theater भी दिखाई देगा (क्या यह और भी संभव है?)
सवाल
- "10X engineer" के साथ क्या हो रहा होगा? — औसत और शीर्ष engineers के बीच productivity ratio? यह ratio काफ़ी बढ़ सकता है
- LLM से लैस होने पर, क्या generalist धीरे-धीरे specialist से आगे निकलेंगे? LLM blank-filling (micro) में grand strategy (macro) की तुलना में बहुत बेहतर है
- भविष्य की LLM coding कैसी लगेगी? क्या यह StarCraft खेलने जैसी होगी? या Factorio खेलने, या संगीत बजाने जैसी?
- समाज का कितना हिस्सा digital knowledge work के bottleneck से अटका हुआ है?
TLDR
- Claude और Codex जैसे LLM agent capabilities ने 2025 के दिसंबर के आसपास किसी तरह का consistency threshold पार कर लिया है, जिससे software engineering और संबंधित क्षेत्रों में phase shift आया है
- ऐसा लगता है कि intelligence वाला हिस्सा अचानक बाकी सब चीज़ों — integration (tools, knowledge), नए organizational workflows की ज़रूरत, process, और व्यापक diffusion — से काफ़ी आगे निकल गया है
- 2026 वह साल होगा जब industry इस नई capability को absorb करने में high-energy year देखेगी
अभी कोई टिप्पणी नहीं है.