Claude Code आपके प्रोडक्ट को बेहतर नहीं बनाता

 (ethanding.substack.com)
1 पॉइंट द्वारा GN⁺ 2 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • कोडिंग एजेंट्स का productivity प्रभाव समान नहीं है, बल्कि K-आकार में बंटता है; मुख्य मेट्रिक प्रति घंटे लिखी गई code lines नहीं, बल्कि क्या प्रति engineer product improvement की गति वास्तव में बढ़ी है, यह है
  • Dax, Karri Saarinen, David Cramer AI के आलोचक नहीं हैं, लेकिन उन्हें अब तक यह भरोसा नहीं हुआ है कि coding agents प्रोडक्ट सुधार की गति को स्पष्ट रूप से बढ़ाते हैं; Cramer का मानना है कि LLM जटिलता और bloat बढ़ाकर लंबी अवधि की गति को धीमा करते हैं
  • अगर Claude Code ने Anthropic के भीतर 7 महीनों तक विशिष्ट बढ़त दी होती, तो प्रतिस्पर्धियों से उसका अंतर चक्रवृद्धि की तरह बढ़ना चाहिए था; लेकिन Codex, Cursor, Cognition, और Factory अब भी प्रतिस्पर्धा में हैं, इसलिए यह संभव है कि bottleneck code production नहीं है
  • अच्छी engineering culture code lines को asset नहीं, बल्कि cost मानती है; features और integrations बढ़ने पर bug surface, dependencies, और आसपास की functionality भी साथ बढ़ती है, इसलिए जटिलता linear नहीं बल्कि चक्रवृद्धि रूप में बढ़ती है
  • product quality के frontier पर तेज़ी से code लिखने से अधिक महत्वपूर्ण हैं taste, compression, deletion, और rejection पर निर्णय; Claude Code 0 से Camry स्तर तक जाने में उपयोगी है, लेकिन यह Ferrari कारीगरों को और तेज़ Ferrari बनाने में मदद नहीं करता

K-आकार की productivity curve

  • coding agents से productivity में बढ़ोतरी समान नहीं होती, बल्कि K-आकार में बंटती है
    • senior engineers ने 2023 के LLM inflection point के बाद measurable output वृद्धि दिखाई है
    • junior engineers का output लगभग ठहरा हुआ है या घटा है
    • महत्वपूर्ण मेट्रिक प्रति घंटे code lines नहीं, बल्कि प्रति engineer product improvement की गति वास्तव में बढ़ी है या नहीं, यह है
  • agentic coding कुछ खास कामों में Pull Request बनाने का समय घटा देती है
    • “6 साल का backlog एक quarter में निपटा दिया”, “Cursor से backend 3 दिन में बना लिया”, “Claude Code पूरी तरह Claude से कोड किया गया” जैसे दावे बार-बार दोहराए जाते हैं
    • लेकिन code production की गति क्या product quality सुधार का समकक्ष मेट्रिक है, यह अलग सवाल बना रहता है

अच्छे प्रोडक्ट बनाने वाले engineers की चेतावनी संकेत

  • Dax, Karri Saarinen, David Cramer तीनों AI के आलोचक नहीं हैं, लेकिन उन्हें अब तक यह विश्वास नहीं हुआ कि coding agents प्रोडक्ट सुधार की गति को स्पष्ट रूप से बढ़ाते हैं
    • Dax opencode.ai बना रहे हैं
    • Karri Saarinen, Linear के CEO हैं
    • David Cramer ने Sentry को शुरू से बनाया और उसे $10 million monthly revenue पैमाने तक बढ़ाया
  • David Cramer का मानना है कि LLM फिलहाल net productivity gain नहीं दे रहे हैं
    • वे entry barrier को कम करते हैं, लेकिन ऐसी complex software बनाते हैं जिनका maintenance कठिन होता है
    • उनका कहना है कि इससे long-term speed धीमी पड़ती दिखती है
    • वे LLM की “complexity के भीतर incremental development performance की कमी”, “वास्तविक simplification और idiomatic interface generation की क्षमता की कमी”, और “ढीली-ढाली test generation techniques” को समस्या मानते हैं
    • अंततः उनका निष्कर्ष है कि इसका बड़ा हिस्सा bloat है
  • Dax का कहना है कि coding agents का सबसे अच्छा उपयोग कैसे किया जाए, यह अभी स्पष्ट नहीं है
    • दूसरी ओर, बाहर “हर PR AI-generated है”, “अभूतपूर्व speed”, “6 साल का backlog निपटा दिया” जैसे दावे बहुत हैं
    • लेकिन वास्तविक product improvement की गति बढ़ाने में इन सभी को कठिनाई हो रही है

Claude Code की विशिष्ट बढ़त अंतर में दिखाई नहीं देती

  • अगर Claude Code पूरी तरह Claude से कोड किया गया था, तो product improvement की गति तेज़ होनी चाहिए थी
    • अगर Claude Code का उपयोग product improvement की गति को सिर्फ 1.5x भी बढ़ाता, तो शुरुआत से इसे इस्तेमाल करने वाली टीम को समय के साथ प्रतिस्पर्धियों से अंतर बढ़ाना चाहिए था
    • engineering productivity एक compound function है, इसलिए हर quarter अंतर और बढ़ना चाहिए था
  • वास्तविक बाज़ार स्थिति ऐसा compound gap नहीं दिखाती
    • Codex, Claude Code से कुछ महीने बाद लॉन्च हुआ, लेकिन functional रूप से पहले ही प्रतिस्पर्धी है
    • Cursor का deal flow मज़बूत है
    • Cognition और Factory भी अब भी महत्वपूर्ण enterprise contracts जीत रहे हैं
    • लोग अब भी इस पर बहस कर रहे हैं कि कौन-सा tool बेहतर है
  • मुख्य प्रतिवाद यह है कि अगर Anthropic के पास Claude Code 7 महीनों तक विशिष्ट रूप से था, तो वास्तविक product speed advantage होने पर प्रतिस्पर्धियों से उसका अंतर इतना बढ़ जाना चाहिए था कि उसे पकड़ना असंभव हो जाता
    • Codex अप्रासंगिक हो जाना चाहिए था, लेकिन ऐसा नहीं हुआ
    • अगर compound advantage दिख नहीं रहा, तो संभव है कि product quality का bottleneck code नहीं था
  • संभावित counterarguments भी इसी निष्कर्ष को मज़बूत करते हैं
    • लाभ रहा भी हो, तो complexity debt ने उसे खा लिया होगा
    • Anthropic की engineering team इतनी बड़ी हो सकती है कि प्रति engineer marginal gain dilute हो गया हो
    • लेकिन इस स्थिति में भी bottleneck code production नहीं, बल्कि कोई और अधिक कठिन तत्व बन जाता है

code lines asset नहीं, cost हैं

  • अच्छी engineering culture code lines को output नहीं, बल्कि expense मानती है
    • महत्वपूर्ण features के लिए code लिखा जाता है, गैर-जरूरी features के लिए नहीं
    • codebase balance sheet का asset नहीं, बल्कि debt के अधिक करीब है
  • comma.ai की software subsidiary tinychat में codebase एक निश्चित आकार से ऊपर जाने पर alarm बजता था, और deleted code का जश्न मनाया जाता था
    • हर line of code एक bug surface है
    • हर function अगले function की dependency बन जाता है
    • हर feature आसपास की और functionality पैदा करता है
  • product surface area fractal की तरह फैलता है
    • अगर Slack integration जोड़ते हैं, तो Teams integration और email fallback path की ज़रूरत पड़ती है
    • अगर notifications जोड़ते हैं, तो उसे mobile, SMS, और enterprise MDM policies के अनुसार फिर से बनाना पड़ता है
    • अगर MFA support जोड़ते हैं, तो उसे Duo, Okta, और SAML के साथ compatible होना चाहिए
    • complexity linear नहीं, बल्कि compound रूप से बढ़ती है
  • Linear में 178 लोग हैं, 6 साल का समय लगा है, और ARR $100 million पैमाने का है
    • Jira, cumulative engineering effort में Linear से 56 गुना बड़ा है, लेकिन consumer quality score में 6 points कम दिखता है
    • मुख्य बात यह है कि quality और codebase mass एक ही चीज़ नहीं हैं
  • Facebook जैसे पैमाने पर UI code को तेज़ी से बनाना bottleneck नहीं है
    • एक skilled engineer Facebook feed mockup एक दिन में बना सकता है
    • वास्तविक constraint यह है कि अरबों लोगों तक किसी भी load और latency पर uptime बनाए रखते हुए उस experience को पहुँचाने के लिए ज़रूरी code lines को कम किया जाए
    • reward function production नहीं, बल्कि compression है
    • ऐसे कामों में coding agents long-term trade-offs का मूल्यांकन नहीं कर पाते, और न ही उनके पास system का कोई सिद्धांत होता है

असली bottleneck अच्छी product ideas के frontier को आगे बढ़ाने की क्षमता है

  • frontier पर product quality सुधार इस बात से सीमित नहीं है कि आप कितनी जल्दी code लिखते हैं, बल्कि इस बात से है कि frontier को आगे धकेलने लायक अच्छे ideas आप कितनी जल्दी सोचते हैं
  • Jira और Linear का अंतर यह नहीं है कि किसने बेहतर box draw किया
    • Linear के पास इस बात की ठोस creative vision थी कि project management software कैसा महसूस होना चाहिए, और उसने वर्षों तक उसे संयम के साथ लागू किया
    • ऐसी quality token throughput से नहीं आती, बल्कि taste और कम बनाने के निर्णय से आती है
  • “6 साल का backlog निपटा दिया” जैसा दावा सुनने में जितना प्रभावशाली लगता है, उतना है नहीं
    • CRUD features और internal tools से भरा backlog उन कामों के लिए उपयुक्त है जिन्हें coding agents तेज़ करते हैं
    • साथ ही, ऐसे काम product frontier को आगे बढ़ाने वाले काम नहीं होते
    • तेज़ी से ship कर देने से product बेहतर नहीं होता; वह तब बेहतर होता है जब shipped चीज़ users को अधिक परवाह करने पर मजबूर करे
  • AI coding agents 0 से 1 तक जाने वाले products को quality frontier तक तेज़ी से पहुँचने में मदद करते हैं
    • वे first working version तक पहुँचने का समय घटाते हैं
    • शुरुआती चरण के कामों में speed gain वास्तव में मौजूद है
  • लेकिन इसकी cost भी है
    • codebase quality से तेज़ी से बढ़ता है
    • technical debt compound रूप से जमा होती है
    • आज की speed, भविष्य में चुकाई जाने वाली cost खरीदकर हासिल की जाती है

सबको Camry, किसी को Ferrari नहीं

  • frontier पर मौजूद टीमों का bottleneck coding agents नहीं, बल्कि taste वाले लोग हैं
    • Linear और Sentry की तरह “कम करके सर्वश्रेष्ठ बनने” की क्षमता खास लोगों के भीतर होती है
    • उदाहरण के तौर पर Linear के Nan Yu और Skunk Works के Kelly Johnson का उल्लेख किया गया है
    • Kelly Johnson की चुनी हुई टीम ने SR-71 बनाया, और SR-71 को 60 साल बाद भी सबसे तेज़ air-breathing manned aircraft के रूप में याद किया जाता है
    • Blackbird तेज़ इसलिए नहीं था कि उसने ज़्यादा blueprints produce किए, बल्कि इसलिए कि Johnson के पास यह सिद्धांत था कि क्या छोड़ना है
    • delete करने, compress करने, और reject करने का taste किसी frontier model roadmap में नहीं है, और baseline ऊपर जाने के साथ इसकी value और बढ़ती है
  • अगर आप पहले से frontier पर हैं, तो token spend के ज़रिए R&D cost को दोगुना करना आर्थिक value बनाता है या नहीं, यह स्पष्ट नहीं है
    • कहा जाता है कि Ramp engineers ने पिछले एक साल में token spend के कारण प्रभावी रूप से अपनी salary दोगुनी कर ली है
    • लेकिन Ramp product वास्तव में बेहतर हुआ है या नहीं, यह सत्यापित करना कठिन है
    • अगर आप पहले से नंबर 1 हैं, तो win rate लगभग स्थिर होती है, और “और बड़े अंतर से नंबर 1” होना मापना कठिन है
    • राय बदलने के लिए Ramp की win-rate या P&L data चाहिए होगा
    • लेखक, Ramp customer होने के नाते, कहते हैं कि उन्हें अभी और पिछले साल के बीच कोई ठोस अंतर महसूस नहीं होता
  • Claude Code हर किसी को Camry जैसा प्रतिस्पर्धी product बनाने में मदद कर सकता है, लेकिन Ferrari कारीगरों को और तेज़ Ferrari बनाने में मदद नहीं करता
    • 0 से Camry स्तर तक जाने में यह बेहद उपयोगी है
    • top-tier न होने वाले software की production cost काफ़ी घट सकती है
    • लेकिन इसके बदले factory की rafters में बहुत-सा confusion और debt जमा होता है, और अंततः किसी न किसी को उसे साफ़ करना पड़ता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2 시간 전
Lobste.rs की राय

  • जटिलता घातीय रूप से बढ़ती है, और शायद उससे भी तेज़। इसलिए AGI singularity से डरने वाले लोग भी अक्सर यह बात चूक जाते हैं कि चाहे कोई इंसान, model, या agent कितना भी स्मार्ट हो, जैसे-जैसे ideas, systems, projects, codebases, और feature sets बड़े होते जाते हैं, वे आखिरकार तेज़ी से बढ़ती जटिलता की दीवार से टकराते हैं
    हर software project शुरुआत में अपेक्षाकृत सुचारु चलता है, लेकिन एक बिंदु पर जटिलता की घातीय वृद्धि सब पर भारी पड़ने लगती है। अच्छी architecture, design, और quality उस क्षण को सिर्फ टालती हैं; अगर सक्षम लोग सही design करें और quality बनाए रखें, तो वे size, features, performance, और wow points को शायद 10 गुना अधिक समय तक संभाल सकें, लेकिन अंततः दीवार तक पहुँचना ही होता है
    LLM सहायता एक निश्चित स्तर तक, और आम तौर पर औसत गुणवत्ता वाले features और code को बहुत तेज़ी से बनवा देती है। यानी उस दीवार तक भी बहुत जल्दी पहुँचा देती है। growth, experimentation, और अपेक्षाकृत आसान लेकिन समय लेने वाले low-complexity कामों के लिए यह अच्छी है, लेकिन यह पहले कभी न रही चीज़ें या बड़े और जटिल projects बनाने में सक्षम नहीं बनाती। उसके लिए जटिलता को दबाने वाले सुधार चाहिए, और अभी के LLM वह ठीक से नहीं दे पाते

    • यह एक क्लासिक समस्या है। जब कारण और परिणाम तुरंत जुड़े हों, तो तत्काल लाभ आसानी से दिख जाता है, लेकिन जब कारण और परिणाम के बीच समय का अंतर हो, तो नकारात्मक प्रभावों को देखना बहुत कठिन हो जाता है
      http://bastiat.org/en/twisatwins.html
      code agents के इस्तेमाल की लागत सीधे दिखाई नहीं देती, और सबसे बढ़कर वह इस रूप में आती है कि system कैसे काम करता है इसकी सामूहिक समझ का क्षय होने लगता है
    • फिर भी स्तरीय संगठन बड़े पैमाने की जटिलता को संभालने का रास्ता देता है। प्रकृति में भी हम देखते हैं कि इसी तरीके से बेहद जटिल संरचनाएँ बनती हैं। स्वतंत्र इकाइयाँ मिलकर बड़े ढाँचे बनाती हैं, और systems भी इसी तरह बनाए जा सकते हैं
      मज़बूत systems को झटकों को सहना और खुद को अनुकूलित करना आना चाहिए, इसलिए हर भाग स्वतंत्र रूप से fail हो सके और नुकसान स्थानीय स्तर पर सीमित रहे। जब system को nested subsystems के रूप में संगठित किया जाता है, तो cells जैसी इकाइयाँ बनती हैं जो आपस में बात करके काम करती हैं। इन इकाइयों को दूसरी cells की अंदरूनी प्रक्रिया जानने की ज़रूरत नहीं होती; वे स्थिर subassemblies की तरह काम करती हैं
      हर स्तर दूसरे स्थानों पर हो रही चीज़ों से बाधित हुए बिना अपने क्षेत्र में self-organization और resilience बनाए रख सकता है। असल में यह interface के पीछे incidental complexity को encapsulate करना है, और ऐसे abstractions बनाना है जिनमें अर्थ निहित हो। levels को बड़े systems के components को जोड़ने वाले connective tissue की तरह देखना बेहतर है
      Erlang OTP software में इस दृष्टिकोण का अच्छा उदाहरण है, जहाँ बड़े systems को अलग-थलग processes के रूप में बनाया जाता है जो एक-दूसरे को messages भेजते हैं। कोई individual process मर जाए या error दे दे, तो भी पूरा system नहीं गिरता
    • मेरे हिसाब से “जटिलता को दबाना” decisions, opinions, और कभी-कभी विरोध या टकराव की भी माँग करता है
      अगर किसी से कुछ implement करने को कहा जाए, तो वह जवाब दे सकता है जैसे “यह बहुत जटिल है”, “यह एक साल बाद फट जाएगा”, “यह Y टीम के काम से compatible नहीं है”, या “इसे implement करने के लिए पर्याप्त लोग नहीं हैं”। आख़िरी बात सच भी हो सकती है, या अप्रत्यक्ष रूप से “नहीं” कहने का तरीका भी
      LLM के ऐसा जवाब देने की संभावना बहुत कम है। खासकर क्योंकि उन्हें optimistic और polite तरीके से tune किया गया है। और चूँकि ऐसी प्रवृत्ति engagement बढ़ाने के लिए भी ज़रूरी है, इसलिए उनके अलग तरह से tune होने की संभावना भी कम लगती है
      यह समस्या कुछ-कुछ उस मामले जैसी लगती है जहाँ LLM ने users की suicide में मदद की। वह तो काफ़ी स्पष्ट मामला था, फिर भी LLM ने बार-बार ऐसा किया। unmanaged complexity की वजह से projects का मर जाना उससे कहीं कम स्पष्ट है, इसलिए निकट भविष्य में LLM इसमें बहुत बेहतर हो जाएँगे, ऐसी उम्मीद बड़ी नहीं लगती

  • “अगर Claude Code सच में product development speed में वास्तविक बढ़त देता है, और Anthropic के पास यह 7 महीने तक exclusive रहा, तो Claude Code और उसके सभी competitors के बीच की दूरी पाटी नहीं जा सकनी चाहिए। Codex अर्थहीन होना चाहिए। लेकिन लोग अब भी सक्रिय रूप से बहस कर रहे हैं कि कौन बेहतर है” — इस तरह की reasoning बहुत मज़बूत नहीं लगती
    Claude Code अच्छा software है, लेकिन ऐसा कोई अजीब AGI magic नहीं है जो competition को असंभव बना दे

    • ऊपर से Codex भी vibe coding से ही बना है, इसलिए उस लिहाज़ से भी यह तुलना थोड़ी मज़ाकिया लगती है। कुछ महीने पहले शुरू करना शायद बहुत मायने नहीं रखता। जो कई features बाद में जुड़ते हैं, वे अक्सर इस बात से आते हैं कि असली users tool के साथ क्या करते हैं
      ऐसा नहीं कि Claude Code के पास शुरुआत से पूरी roadmap तैयार थी और मुख्य बाधा code लिखने की speed थी। असली बाधा ideas हैं। सब लोग करते-करते ही चीज़ें खोज रहे हैं
      मैंने इस लेख को बस सरसरी तौर पर देखा है, इसलिए गहराई से कुछ कहना मुश्किल है, लेकिन sentence-case की समस्या को छोड़ भी दें, तो भी इसका अधिकांश हिस्सा LLM द्वारा लिखी गई गद्य जैसा लगा, इसलिए इसे पढ़ने का मन नहीं हुआ

  • अभी तक agents की गलतियाँ गुणात्मक रूप से जमा होने की प्रवृत्ति दिखाती हैं
    अगर आप ऐसा API बना देते हैं जो तकनीकी रूप से काम तो करता है लेकिन उसे इस्तेमाल करने के लिए थोड़ा extra code चाहिए, तो उसके परिणामस्वरूप code बढ़ता है, और duplication, branching, और bugs के पैदा होने की जगहें भी बढ़ती हैं। फिर fractal की तरह और भी बहुत-सा बहुत अच्छा न होने वाला code लिख दिया जाता है
    एक agent ने कभी ऐसा struct डिज़ाइन किया था जिसमें id field optional थी। उसकी ज़रूरत सिर्फ उसी constructor की वजह से थी जो उसने खुद लिखा था। फिर उसने id होने और न होने, दोनों स्थितियों के लिए थके बिना code की दो अलग धाराएँ लिख दीं, और id न होने के लिए अजीब fallback paths भी बना दिए। वे fallback paths स्वाभाविक रूप से जटिल और fragile थे। struct के लगभग हर उपयोग और उन पर निर्भर चीज़ें भी इससे संक्रमित हो गईं, जबकि id के बिना वाला constructor इस्तेमाल ही नहीं हुआ। codebase का आधा हिस्सा आसानी से हटाया जा सकता था
    मुझे सच में नहीं पता कि क्या “अगर तुम बेवकूफ़ी कर रहे हो तो खुदाई बंद करो” जैसी पर्याप्त instructions देकर इसे ठीक किया जा सकता है और coding के “solve” होने तक बस कुछ hacks ही बाकी हैं, या यह stochastic parrots की दीर्घकालिक समस्या है जहाँ linear सुधार के लिए लगातार घातीय रूप से बढ़ती लागत चुकानी पड़ेगी। जब तक गलतियाँ चक्रवृद्धि की तरह जमा होती रहेंगी, compounding growth आखिरकार रोक लगाएगी

    • मैंने human developers के साथ भी बहुत मिलती-जुलती चीज़ें होते देखी हैं। मेरे हिसाब से बेहतरीन developers को अलग करने वाली विशेषताओं में से एक यह है कि वे एक स्तर ऊपर और बाहर रुककर वापस देखने की प्रवृत्ति रखते हैं
      कभी-कभी इसमें business process भी शामिल होता है। domain को अच्छी तरह समझने वाला developer कई महीनों तक कोई technical solution implement करने के बजाय यह पूछ सकता है, “लगातार और गहराई में जाने के बजाय क्या process बदल नहीं सकते?” और जवाब कभी-कभी होता है, “बिलकुल, वह तो आसान है”
      लगता है LLM भी अंततः इस हिस्से में बेहतर होंगे। अभी भी अगर आप सीधे पूछें, “यह approach ठीक नहीं लग रही, क्या हम alternatives सोच सकते हैं?”, तो वे काफ़ी बार उन्हें ढूँढ़ भी लेते हैं। बस अभी सफलता और असफलता अनियमित है, और एक बार वे ऐसी बेवकूफ़ी कर बैठें, तो असंबंधित काम करते समय खुद से उसे पहचान लेने की संभावना कम होती है
      इसमें trade-off भी है। लोग पहले से शिकायत करते हैं कि models problems को ज़रूरत से ज़्यादा सोचते हैं और tokens जला देते हैं। अगर किसी developer के पास इस बात का अनुभव और intuition हो कि किसी खास समस्या का code “कैसा महसूस होना चाहिए”, तो वह स्वाभाविक रूप से जानता है कि कब रुककर पीछे मुड़कर देखना है। शायद बेहतर training के साथ agents भी ऐसी intuition हासिल कर लें

  • नवंबर 2025 के inflection point के बाद के data के साथ अद्यतन संस्करण देखना अच्छा होगा