अगर आपको लगता था कि कोड लिखने की गति ही समस्या है, तो असल में उससे भी बड़ी समस्या है

• AI coding tools डेवलपमेंट की गति बढ़ाते हैं, ऐसा कहा जाता है, लेकिन वास्तविक bottleneck कोड लिखना नहीं बल्कि संगठन की अक्षम प्रक्रियाएँ हैं
• कोड उत्पादन बढ़ाने से review wait, deployment delay, अस्पष्ट requirements जैसी नॉन-डेवलपमेंट स्टेज की रुकावटें और गंभीर हो जाती हैं, और वास्तविक cycle time उल्टा बढ़ जाता है
• Eli Goldratt के Theory of Constraints के अनुसार, bottleneck न होने वाले चरण को optimize करने से सिस्टम तेज नहीं होता, बल्कि और बिगड़ता है
• जब AI द्वारा जनरेट किए गए कोड को उसका लेखक भी पूरी तरह नहीं समझता, तब incident response की surface area बढ़ती है और सिस्टम को समझकर reason कर सकने वाले लोग कम हो जाते हैं — ऐसा एक संरचनात्मक जोखिम पैदा होता है
• प्रतिस्पर्धात्मक बढ़त उस टीम को नहीं मिलती जो सबसे तेज कोड लिखती है, बल्कि उस टीम को मिलती है जो यह समझती है कि क्या बनाना है और उसे users तक पहुँचाती है

---

गलत optimization की शुरुआत

• AI coding assistant अपनाने के बाद code output 40% बढ़ा है, ऐसे दावे सामने आए हैं
  • लेकिन “यह गति आखिर किस दिशा में है?” यह सवाल गायब है
• पहले से तेज चरण, यानी code writing, में resources डालने पर पूरा सिस्टम और धीमा हो जाता है
  • bottleneck नहीं होने वाले हिस्से को तेज करने से अधूरे कोड का inventory जमा होता है, और quality गिरती है तथा अव्यवस्था बढ़ती है

bottleneck के बाहर optimize करने से सिस्टम और खराब होता है

• 1984 में Eli Goldratt के उपन्यास The Goal में प्रस्तुत Theory of Constraints का मुख्य विचार यह है: हर सिस्टम में ठीक एक bottleneck होता है, और पूरे throughput का निर्धारण उसी bottleneck की capacity से होता है
• bottleneck न होने वाले चरण को optimize करने से सिस्टम तेज नहीं होता, बल्कि अधूरे काम का inventory ही बढ़ता है, जिससे lead time बढ़ता है, भ्रम फैलता है और quality गिरती है
• उदाहरण के तौर पर, अगर station A widgets को तेजी से बनाता है लेकिन bottleneck station B की processing speed वही रहती है, तो A और B के बीच बस अनप्रोसेस्ड widgets का ढेर लग जाता है

“कोड output 3 गुना” होने पर वास्तव में क्या होता है

• डेवलपर्स पहले से कहीं तेज PR बना रहे हैं, लेकिन reviewers की संख्या वही है, इसलिए PR review queue में एक दिन, दो दिन, या एक हफ्ते तक पड़े रहते हैं
• लेखक तब तक अगले AI-assisted feature पर context switch कर चुका होता है, इसलिए 8 दिन पहले लिखे कोड पर आए review comments का जवाब देते समय उसे वह कोड लगभग याद नहीं रहता
• reviews इतने बढ़ जाते हैं कि ठीक से पढ़े बिना approve कर देने वाले rubber-stamp reviews होने लगते हैं
• CI को 45 मिनट लगते हैं, flaky tests की वजह से fail होने पर rerun करना पड़ता है, deployment pipeline meeting में बैठे owner की manual approval का इंतज़ार करती है, और feature staging में 3 दिन तक पड़ा रहता है
• डेवलपर तब तक 2 और PR खोल चुका होता है, WIP (Work In Progress) तेज़ी से बढ़ता है, और सब लोग 6-6 चीज़ें एक साथ कर रहे होते हैं जबकि कुछ भी पूरा नहीं होता
• कोड ज़्यादा बन रहा है लेकिन software कम ship हो रहा है; cycle time खराब हो चुका है, फिर भी dashboard पर productivity 40% बढ़ी हुई दिखती है
• AI-generated code का अतिरिक्त जोखिम यह है कि जिसने उसे “लिखा” है, उसने वास्तव में लिखा नहीं बल्कि prompt देकर सरसरी नज़र डाली होती है; इसलिए रात 2 बजे production incident होने पर न on-call engineer और न prompt लिखने वाला उस कोड को समझा पाता है
• कोड बढ़ना और समझ कम होना productivity gain नहीं, बल्कि एक ज़्यादा सुंदर dashboard के साथ लगा time bomb है

वास्तविक bottleneck 1: क्या बनाना है, यही नहीं पता

• PM ने 2 महीने से असली users से बात नहीं की, और requirements Jira ticket की 3 लाइनों और एक Figma link के रूप में पहुँचती हैं
• इंजीनियर्स हर दिन 50 तरह के micro-decisions — behavior, edge cases, error handling — बिना किसी स्पष्ट spec के अनुमान से लेते हैं
• एक टीम ने sales person द्वारा Slack में भेजी गई उस बात के आधार पर 6 हफ्ते तक एक feature बनाया जो शायद किसी संभावित ग्राहक ने किसी call में कही थी; अंत में उस ग्राहक ने खरीदारी नहीं की, और वह feature सिर्फ 11 लोगों ने इस्तेमाल किया, जिनमें 9 internal QA थे
• code writing को तेज करने से सिर्फ गलत चीज़ को जल्दी बनाने की गति बढ़ती है, यानी आप बस अनुमान लगाने को automate कर रहे हैं
• bottleneck असल में समस्या की समझ है, और इसे तेज typing से हल नहीं किया जा सकता

वास्तविक bottleneck 2: कोड “पूरा” होने के बाद की हर चीज़

• अधिकांश संगठनों में code writing पूरी यात्रा का सिर्फ लगभग 20% है, बाकी 80% समय कोड अलग-अलग queues में इंतज़ार करता है
• ऐसे उदाहरण मौजूद हैं जहाँ एक feature दोपहर भर में लिखा गया, लेकिन production तक पहुँचने में 2 महीने लग गए
• PR review, CI, staging, QA, security review, product approval, deployment window, canary rollout जैसी लंबी handoff, wait और queue की शृंखला मौजूद रहती है
• ज़्यादातर समय कोड चलता नहीं, बल्कि किसी के देखने, pipeline के चलने, और मौजूद रहने की अनुमति मिलने का इंतज़ार करता है
• तेज़ी से ship करने के लिए आपको उन बिंदुओं को ढूँढना होगा जहाँ काम इंतज़ार करता है, और actual work time की तुलना में queue wait time का ratio मापना होगा

वास्तविक bottleneck 3: deployment trust का दुष्चक्र

• जब tests flaky हों, observability खराब हो, और canary process पर किसी को भरोसा न हो, तो टीमें deployment से डरती हैं
• डर की वजह से changes को बड़ी releases में bundle किया जाता है; इससे risk और बढ़ता है, deployment और डरावना बनता है, और फिर चीज़ें और बड़े batches में bundle होती हैं — यह डर का vicious cycle है
• इसमें अगर और तेज code output जोड़ दिया जाए, तो कोड बढ़ेगा लेकिन deployment culture उतना ही भयभीत रहेगा; नतीजा यह कि batches और बड़े होंगे और release frequency और कम हो जाएगी

वास्तविक bottleneck 4: launch के बाद feedback की कमी

• feature बनाकर release करने के बाद न ठीक analytics होती है, न post-launch user interviews, और न ही कोई यह देखता है कि वह feature वास्तव में समस्या हल कर रहा है या नहीं
• अगला feature भी अनुमान, उसके बाद वाला भी अनुमान — पूरी product roadmap feedback के बिना लगाए गए अनुमानों की श्रृंखला बन जाती है
• तेज code output बस “बनाओ, रिलीज़ करो, कंधे उचकाओ” cycle को और तेज़ घुमाता है

वास्तविक bottleneck 5: calendar ही load-bearing wall है

• कभी-कभी bottleneck तकनीकी नहीं होता, बल्कि decision-making के लिए ज़रूरी meetings, एक महीने से बातचीत न करने वाली 3 teams के बीच API contract पर सहमति, या हर महत्वपूर्ण design के लिए single approval point बने architect का 2 हफ्तों का backlog होता है
• 6 हफ्ते चलने वाली quarterly planning process की वजह से urgent काम भी 5 हफ्ते इंतज़ार करता है
• वास्तव में ऐसे मामले होते हैं जहाँ feature सिर्फ इसलिए release नहीं हो पाता क्योंकि “हम छुट्टी पर गए व्यक्ति के साथ meeting का इंतज़ार कर रहे हैं”
• यह coordination की समस्या, मानवीय समस्या, और राजनीतिक समस्या है; इसका code writing speed से कोई लेना-देना नहीं

इसकी जगह क्या करना चाहिए

• value stream mapping: किसी एक feature को idea से production तक track करें, और हर चरण में लगा समय तथा चरणों के बीच का wait time दर्ज करें
• cycle time मापें: code lines, merged PRs, या story points नहीं, बल्कि commit से production तक और user के इस्तेमाल तक पहुँचने में लगा समय मापना चाहिए
• waiting state हटाएँ: अगर PR review में 2 दिन लगते हैं, तो pair programming, छोटे PR, dedicated review time, asynchronous review norms जैसे उपाय अपनाएँ। अगर deployment manual approval पर अटका है, तो उसे automate करें या कम से कम Slack button में बदलें
• शुरू करना रोकें, पूरा करने पर ध्यान दें: WIP limits किसी कारण से होती हैं; प्रगति पर चल रही 10 चीज़ों से पूरी हुई 3 चीज़ें बेहतर हैं। हर in-progress item context-switching cost लाता है
• काम करने वालों से बात करें: डेवलपर्स पहले से जानते हैं कि bottleneck कहाँ है; वे standup में शिकायत करते हैं और Slack में महीनों से memes बना रहे हैं। उन्हें बस लगा कि कोई सुन नहीं रहा

मुख्य निष्कर्ष

• VP को “code output 40% बढ़ा” कहने के बजाय यह कहना चाहिए था: “हमारे value stream analysis से पता चला है कि features चरणों के बीच औसतन 9 दिन इंतज़ार कर रहे हैं, और हम इसे आधा करेंगे”
• प्रतिस्पर्धात्मक बढ़त उस टीम को मिलती है जो सबसे तेज कोड नहीं लिखती, बल्कि जो यह समझती है कि क्या बनाना है, उसे बनाती है, और users तक पहुँचाती है
• bottleneck keyboard नहीं है

[roxie]

उस संभावित ग्राहक ने खरीदारी नहीं की, और उस फीचर का इस्तेमाल सिर्फ़ 11 लोगों ने किया (उनमें से 9 internal QA थे)

lol

[github88]

पाइपलाइन तो वही है
लगता है बस डेवलपर्स ही गैर-जिम्मेदार हो गए हैं

[brilliant08]

लगता है सॉफ्टवेयर कारीगर बनना पड़ेगा

[GN⁺]

Hacker News की राय

• जब हमारी टीम ने agent-based development को गंभीरता से अपनाना शुरू किया, तो चिंता थी कि coding तेज़ हो जाएगी लेकिन review का समय बढ़ जाएगा
  अभी तक कोई स्पष्ट बदलाव नहीं दिखा है, और सब लोग नया workflow सीख रहे हैं, इसलिए data भी पर्याप्त नहीं है
  लेकिन कुछ मामलों में तेज़ coding खास तौर पर उपयोगी होती है — ideas पर experiment करना, जटिल repetitive काम, simple लेकिन labor-intensive implementation, happy path के बाद edge cases को handle करना आदि
  खासकर जब किसी existing branch या PR को वैसे ही आगे बढ़ाना हो, तब agent बहुत अच्छा काम करता है
  सबसे बड़ा productivity gain यह है कि जब agent coding कर रहा होता है, तब मैं दूसरा काम कर सकता हूँ। उदाहरण के लिए, मैं PR review करके लौटूँ तो output तैयार मिलता है
  शुरुआत में मैं skeptical था, लेकिन अब सावधानी से आशावान हूँ। 10x improvement शायद ज़्यादा है, लेकिन 2x improvement भी बड़ी बात होगी

  • मैं भी उस stage से गुज़रा था, लेकिन आखिरकार छोड़ दिया। जब agent coding करता है और आप दूसरा काम करते हैं, तो context switching इतना बढ़ जाता है कि उल्टा focus और productivity दोनों को नुकसान होता है
    यह तरीका तभी ठीक लगता है जब गलती की cost कम हो या change scope छोटा हो। नहीं तो quality और satisfaction गिरती है, और बस schedule compress हो जाता है
    आखिर में parallel चलाकर समय वापस नहीं मिलता, बस टलते आ रहे काम थोड़े कम टलते हैं
  • दूसरी कंपनियों का अनुभव झलक में देखना दिलचस्प था। मैं भी ज़्यादातर बातों से सहमत हूँ
    लेकिन जब agent coding कर रहा हो और आप दूसरा काम करें, तो एक अजीब थकान महसूस होती है
    AI productive है, लेकिन यह इंसानी कारीगर की तरह coding करने से बिल्कुल अलग तरह का श्रम है
  • अगर बड़े refactoring AI कर दे, तो sunk cost में कम फँसना पड़ता है
    जिस refactoring को खुद करने पर छोड़ना मुश्किल होता, AI के करने पर उसे ईमानदारी से “यह अच्छा नहीं था” कहना आसान हो जाता है
  • जब agent coding कर रहा हो और आप दूसरा काम करें, यह सुनने में ही भयानक लगता है
    लगातार multitasking करने से burnout जल्दी आता है। अफ़सोस है कि चर्चा में मानवीय पहलू गायब है
    मैं हमेशा ‘optimized state’ में काम नहीं करना चाहता

• किसी ने कहा कि “समस्या को समझना ही bottleneck है”, लेकिन मैं पूछना चाहता हूँ कि तेज़ typing समस्या को समझने में मदद क्यों नहीं कर सकती?
  अगर आप जल्दी से कुछ गलत बनाकर देख लें, तो क्या इससे सही दिशा भी जल्दी नहीं मिल सकती?
  मैं अक्सर कुछ बनाते-बनाते समझता हूँ कि मुझे वास्तव में क्या चाहिए। Prototype बनाना जितना सस्ता होता जा रहा है, यह प्रवृत्ति उतनी ही बढ़ती है
  बेशक, अंत में बात अक्सर “users से और बात करनी चाहिए थी” वाली retrospective पर खत्म होती है, लेकिन वह अलग समस्या है

  • लेकिन customer असफलताओं को अनंत समय तक बर्दाश्त नहीं करता। खासकर B2B या SaaS माहौल में feedback loop बहुत धीमा होता है
    बैंक जैसी जगहों पर तो ज़्यादा से ज़्यादा हफ़्ते में एक बार ही experiment संभव होता है
  • AI उन समस्याओं में पहले से ही मज़बूत है जो अनगिनत बार दोहराई जा चुकी हैं, या जहाँ लगभग सही उत्तर भी चल जाता है
    लेकिन ज़्यादातर software ऐसा नहीं होता। Code लिखना पूरे काम का सिर्फ़ एक हिस्सा है
    जैसे surgeon का काम सिर्फ़ ‘काटना’ नहीं होता, वैसे ही engineer का काम सिर्फ़ code लिखना नहीं है
  • “क्या तेज़ typing से समस्या जल्दी समझी जा सकती है?” इस सवाल का मेरा जवाब होगा — “तो क्या तेज़ बोलने से बातचीत भी बेहतर समझ आती है?”
  • तेज़ prototyping तब उपयोगी है जब उसका नतीजा user या requirements से सीधे टकराता हो
    अगर आप अकेले बैठकर सिर्फ़ code polish कर रहे हैं, तो वह बस और बड़ा confusion पैदा करता है
    कई बार PM या customer से एक घंटा बात करना कहीं बेहतर होता है
  • “तेज़ typing से समस्या जल्दी समझने” का कोई example हो तो जानना चाहूँगा

• अभी का LLM craze ऐसा लगता है जैसे समस्या से पहले solution आ गया हो
  सच में speed बढ़ानी है तो पहले पूछना चाहिए, “असल bottleneck क्या है?”
  Management अगर AI presentation देखकर यह मान ले कि “इसे इस्तेमाल करेंगे तो सब तेज़ हो जाएगा”, तो यह सिर्फ़ vibe management है

  • लेकिन मेरे 30 साल के अनुभव में development सिर्फ़ coding (#4 चरण) नहीं है, बल्कि business understanding, design, testing, approval, operation, maintenance तक जाने वाली लंबी प्रक्रिया है
    Coding उसमें सबसे labor-intensive और automatable हिस्सा है
    LLM इस हिस्से का बोझ काफ़ी कम कर सकता है। खासकर test code लिखने जैसे काम AI अच्छी तरह करता है

• इंसानी developers अभी भी code के प्रति अपना obsession नहीं छोड़ पा रहे हैं
  असल में code सिर्फ़ समाधान की एक intermediate representation (IR) है
  जैसे GCC assembly में बदलते समय internal optimization की चिंता नहीं करता, वैसे ही agent code generate करे तो हमें सिर्फ़ result की correctness देखनी चाहिए
  अगर clear spec और repetitive review process हो, तो इंसान हो या agent, दोनों एक जैसा implementation दे सकते हैं

  • लेकिन compiler deterministic तरीके से काम करता है, और हमेशा एक जैसा परिणाम देता है
    LLM ऐसा नहीं है। वह गलत समझ सकता है या hallucination कर सकता है
    इसलिए अब भी इंसान को review करना पड़ता है
  • High-level language का source code एक formal language है। यह natural language से अलग है
  • अगर आप सच में ऐसा मानते हैं, तो फिर सीधे खुद assembly में convert क्यों नहीं करते, बीच का step क्यों रखते हैं?
  • असलियत इतनी सरल नहीं है। कई बार remodel किए गए घर की तरह, codebase भी structural limits से टकराता है
    agent अक्सर गलत pattern चुन लेता है या technical debt जमा कर देता है
    हो सकता है एक दिन programming language ही हट जाए, लेकिन अभी वह समय दूर है
  • High-level language में meaning deterministically बना रहता है, लेकिन agent coding में ऐसा नहीं होता
    meaning फैल जाता है, compress हो जाता है, और कभी-कभी गायब भी हो जाता है

• बहुत-सी कंपनियाँ सच में अच्छा code नहीं चाहतीं
  अंदरूनी evaluation इस आधार पर होती है कि “कितना deploy किया गया”, और अगर आप समस्या उठाएँ तो सुनने को मिलता है कि “तुम बहुत ज़्यादा detail में जा रहे हो”
  आखिर में internal stakeholders को बस ‘हम सफल रहे’ कहने का आधार चाहिए होता है

  • मैं इसे थोड़ा उदार नज़रिए से देखना चाहूँगा। कंपनियाँ अच्छा code चाहती हैं, लेकिन speed और quality के trade-off को भी देखती हैं
    technologists की ज़िम्मेदारी है कि वे risk को समझाएँ
  • लेकिन व्यवहार में लोग अब कम परवाह कर रहे हैं
    AI अपनाने के बाद quality degradation वास्तव में दिखाई दे रही है

• हमारी कंपनी में PR approval भी जैसे-तैसे होता है, CI में 45 मिनट लगते हैं, और deployment कई दिनों तक टलता रहता है
  ऊपर से AI इस्तेमाल करना भी मना है। कहा तो जाता है कि ज़्यादातर code इंसानों ने लिखा है, लेकिन इस पर भी शक होता है
  इस लेख ने दो बातें मिस कर दीं — (A) agent usage और process optimization साथ-साथ चल सकते हैं, (B) कुछ tickets में सचमुच code ही bottleneck होता है
  आखिर में महत्वपूर्ण यह है कि AI है या नहीं नहीं, बल्कि bottleneck हटाने वाला process improvement है

• मैं solo developer हूँ। Coding speed सच में समस्या है, क्योंकि वही दूसरे कामों के लिए समय छीन लेती है
  आज मैंने Claude Code सेट किया, और अब googling या test लिखने में कम समय लगता है
  Productivity 10x नहीं होगी, लेकिन labor-saving technology के रूप में इसकी काफ़ी value है। बिल्कुल dishwasher की तरह

  • मेरा अनुभव भी कुछ ऐसा ही है। पहले काम के बाद रात देर तक googling करता रहता था और test लिखना टालता रहता था
    अब AI test भी लिख देता है और edge cases के बारे में चेतावनी भी दे देता है
    यह perfect नहीं है, लेकिन नई features release करने की speed बढ़ी है और मेरा समय भी बचा है
    “AI पर भरोसा नहीं किया जा सकता” सुनना वैसा लगता है जैसे “compiler पर भरोसा नहीं किया जा सकता”
    आखिर में इंसान direction देता है, prompt बेहतर करता है, और साथ-साथ आगे बढ़ता है
  • शीर्षक असल में यह पूछ रहा है कि “क्या coding ही मुख्य समस्या है?”
    startup या VC माहौल में coding से ज़्यादा business problem solving महत्वपूर्ण है
    Code output बढ़ जाने से यह गारंटी नहीं मिलती कि पूरे system का परिणाम बेहतर होगा
  • मैं भी सहमत हूँ। अब भी code को line-by-line review करना पड़ता है
    Template या code generator की तरह speed तो बढ़ती है, लेकिन जब तक requirements gathering 10x तेज़ नहीं होती, 10x productivity संभव नहीं है
  • यही सही दिशा है
  • लेकिन dishwasher पानी और energy बचाता है, LLM ऐसा नहीं करता
    इसलिए यह analogy थोड़ी अनुपयुक्त लगती है

• AI को वे गलतियाँ करने से कैसे रोका जाए जो इंसान आमतौर पर नहीं करते?
  इंसान code को step-by-step logically review करता है, लेकिन AI ऐसा नहीं करता
  Amazon जैसी जगहों पर senior engineer review करें तब भी, review का मकसद हर bug पकड़ना नहीं होता
  और senior लोग तो meetings में इतने व्यस्त होते हैं कि अक्सर code context भी ठीक से नहीं जानते। ऐसे review कितने असरदार होंगे?

  • लेकिन इंसान भी गलती करते हैं। GitLab, S3, Knight Capital, MySpace — सभी ने बड़े incidents किए हैं
    इंसान को perfect समझना भ्रम है
    हम AI से इंसानों से भी ऊँचा standard माँग रहे हैं
    आखिर में असली बात QA process को मज़बूत करना है। Testing की ज़िम्मेदारी सिर्फ़ developer पर नहीं छोड़नी चाहिए

• मुझे पहले पढ़ी हुई किताब 《The Goal》 याद आ गई। जब प्रक्रिया के एक चरण को automate किया जाता है, तो अगला चरण bottleneck बन जाता है
  Software में भी यही बात लागू होती है; code generation तेज़ हो जाए, तो भी अगर बाकी process साथ नहीं दे, तो उसका मतलब नहीं
  आखिर में सब कुछ profit generation के लक्ष्य के अधीन है। Code quality भी उसी का एक उप-तत्व भर है

• Code writing speed high-risk स्थितियों में bottleneck नहीं होती
  कई बार धीरे-धीरे plan करना और परिणामों पर गंभीरता से सोचना बेहतर होता है
  उदाहरण के लिए, AI industry जैसी जगहों पर अगर बहुत बड़े systems बहुत तेज़ी से बना दिए जाएँ, तो गलत दिशा में civilizational risk पैदा हो सकता है
  वहीं अगर weekend पर अकेले बनाया गया छोटा game हो, तो बात अलग है। आखिर में speed को risk का आकार तय करता है