रफ्तार धीमी करनी क्यों ज़रूरी है

 (mariozechner.at)
27 पॉइंट द्वारा GN⁺ 2026-03-26 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • हाल में AI coding agents के तेज़ी से फैलाव से development की गति बढ़ी है, लेकिन software quality में गिरावट और instability भी गंभीर हुई है
  • agents iterative learning क्षमता के बिना वही errors जमा करते रहते हैं, और बड़े codebase में search recall में गिरावट और complexity का विस्फोट होता है
  • अगर पूरे system को मानव नियंत्रण के बिना सौंप दिया जाए, तो यह duplicate code, गलत design patterns, और maintain न किए जा सकने वाले codebase तक ले जाता है
  • फिलहाल agents का non-core tasks या experimental क्षेत्रों में सीमित उपयोग करना चाहिए, और अंतिम quality gate के रूप में मानव को बने रहना चाहिए
  • रफ्तार धीमी करना और मानवीय agency वापस पाना सीखने, विकास, और sustainable software ecosystem के लिए अहम है

सब कुछ टूटा हुआ है

  • पिछले 1 साल में coding agents इतने विकसित हो गए हैं कि वे वास्तविक projects पूरा कर सकते हैं, लेकिन इसके साथ software quality में गिरावट साफ़ दिखाई दे रही है
    • बड़े services में भी 98% uptime सामान्य होता जा रहा है, और UI bugs बार-बार दिखते हैं
    • AWS के AI-संबंधित outage cases और Microsoft के AI code ratio बढ़ने वाले बयानों का उल्लेख किया गया है
  • कुछ कंपनियाँ दावा करती हैं कि उनके product code का 100% AI लिखता है, लेकिन नतीजों में memory leaks, UI errors, feature instability जैसी कम गुणवत्ता दिखती है
  • कई developers ने बताया है कि agent-centered development के कारण code review की कमी, design की अनुपस्थिति, और बेकार features की अधिकता से वे maintain न किए जा सकने वाले codebase में फँस गए

agents के साथ काम नहीं करने का तरीका

  • developers speed और code volume के नशे में quality और control छोड़ चुके हैं
    • “distributed, autonomous, automated” के नाम पर large-scale agent orchestration की कोशिश होती है, लेकिन व्यवहार में यह unstable outputs का उत्पादन करती है
    • कुछ projects को चलाना भी मुश्किल है, और वे मानव हस्तक्षेप के बिना maintain नहीं हो सकते
  • यह व्यक्तिगत project स्तर पर संभव हो सकता है, लेकिन वास्तविक user-base वाले products में ज़्यादातर मामले असफल रहे हैं

  • error accumulation, learning की कमी, कोई bottleneck नहीं, और delayed pain

    • agents में iterative learning क्षमता नहीं होती, इसलिए वे वही errors बार-बार पैदा करते हैं
    • इंसान errors से सीखते हैं, लेकिन agents वही गलतियाँ अनंत बार दोहराते हैं
    • इंसानों की code लिखने की गति सीमित होती है, इसलिए error accumulation धीमा होता है, लेकिन agents की फ़ौज में कोई bottleneck नहीं होता, इसलिए errors विस्फोटक रूप से जमा होते हैं
    • नतीजतन codebase पर भरोसा नहीं किया जा सकता, और automated tests भी अविश्वसनीय हो जाते हैं
    • अंत में manual testing ही एकमात्र validation method बचती है, और development team खुद को जाल में फँसा लेती है

  • complexity से सीखने वाले व्यापारी

    • agents पूरे system context को देखे बिना सिर्फ़ local decisions लेते हैं
    • इसके कारण duplicate code, अनावश्यक abstraction, और structural chaos तेज़ी से जमा होते हैं
    • मानव संगठनों में ऐसी complexity कई वर्षों में धीरे-धीरे बनती है, लेकिन agent-based teams कुछ ही हफ्तों में उसी स्तर की अव्यवस्था तक पहुँच जाती हैं
    • agents training data से सीखे हुए गलत design patterns को जस का तस दोहराते हैं, और मानव नियंत्रण न हो तो recover न की जा सकने वाली complexity पैदा कर देते हैं

  • agent search का low recall

    • जब agents code modification या refactoring की कोशिश करते हैं, तो वे ज़रूरी पूरा code ढूँढ नहीं पाते
    • codebase जितना बड़ा होता है, search recall उतना ही तेज़ी से गिरता है, जिससे duplication और inconsistency पैदा होती है
    • Bash, LSP, vector DB जैसे विभिन्न tools इस्तेमाल करने पर भी large-scale codebase में सीमाएँ बनी रहती हैं
    • इससे code smells और अनावश्यक complexity और बढ़ जाती है

agents के साथ काम करने का तरीका (फिलहाल)

  • agents तेज़ code generation और उच्च शुरुआती quality के कारण आकर्षक हैं, लेकिन पूरे system की ज़िम्मेदारी देने पर ढह जाते हैं
    • सही use cases हैं छोटे दायरे के non-core tasks, ऐसे tasks जिनमें self-evaluation loop संभव हो, और ऐसे tasks जिनकी failure घातक न हो
    • उदाहरण के लिए, internal tools बनाना, ideas पर experiment करना, और performance measurement आधारित automation research (auto-research) उपयुक्त हैं
  • मानव को हर हाल में अंतिम quality gate बने रहना चाहिए, और agents के outputs को review, edit, और integrate करना चाहिए
    • अगर evaluation function सिर्फ़ संकीर्ण metrics को दर्शाए, तो agents code quality, complexity, accuracy को नज़रअंदाज़ कर सकते हैं
  • रफ्तार धीमी करना ही मुख्य बात है
    • क्या बना रहे हैं और क्यों बना रहे हैं, इस पर सोचने का समय सुरक्षित करना चाहिए, और अनावश्यक features को साहस के साथ ठुकराना चाहिए
    • एक दिन में agents जितना code बना सकते हैं, उसे इतना सीमित करें कि उसकी review संभव हो
    • architecture, API जैसे system के मूल रूप को इंसानों को ही सीधे लिखना चाहिए
    • agents के साथ pair programming करते हुए code writing process में friction और understanding के अवसर बनाए रखने चाहिए
  • यह approach maintainable codebase बनाती है, user satisfaction बढ़ाती है, और अनावश्यक features की जगह core features पर ध्यान केंद्रित कराती है
    • अगर मानवीय समझ बनी रहे, तो agent search recall की समस्या भी कम होती है, और समस्या आने पर सीधे सुधार भी संभव होता है
    • शुरुआती design गलत हो तब भी उसके कारण समझकर उसे सुधारने की क्षमता बनी रहती है
  • अंततः ज़रूरत है discipline और मानवीय agency की
    • system की quality और sustainability मानव हस्तक्षेप और निर्णय पर निर्भर करती है
    • “धीरे चलना” ही सीखने और विकास, और स्वस्थ software ecosystem को बनाए रखने का एकमात्र रास्ता है

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

2 टिप्पणियां

 
tested 2026-03-26

Pi – संक्षिप्त टर्मिनल कोडिंग हार्नेस
इसे बनाने वाला व्यक्ति यही है।
 
GN⁺ 2026-03-26
Hacker News की राय

  • आजकल जब भी मैं ऐसे चिंतनशील लेख पढ़ता हूँ, तो मुझे भी किसी बिंदु पर थकान महसूस होती है
    आखिरकार असली बात यह है कि “हम क्या बना रहे हैं” और “क्या वह टूल वास्तव में मददगार है”
    Ruby, PHP, Lotus Notes, Visual BASIC के दौर में भी हमने यही गलतियाँ दोहराईं
    टूल्स का समझदारी से उपयोग करना चाहिए, और इतनी रफ्तार से काम करना चाहिए कि टीम वास्तव में जो जटिल वास्तविकता बना रही है, उसे समझ सके
    Agile हो या Waterfall, Docker हो या Podman — यही असल मुद्दा नहीं है
    आजकल हम ऐसे दौर में हैं जहाँ LLM production DB मिटा देता है, और फिर उसका postmortem ब्लॉग में चित्र भी बना देता है, लेकिन यह सच में engineering है या नहीं, पता नहीं
    शायद software development शुरू से ही कोई इंजीनियरिंग अनुशासन था ही नहीं

    • “हम क्या बना रहे हैं” वाले सवाल से मैं 1000% सहमत हूँ
      पिछले 10 सालों में software industry meta work से भर गई है — नए frameworks, tools, virtualization layers, organizational structures वगैरह
      लेकिन असल में यह सब “किस लिए” बनाया जा रहा है, यह साफ नहीं है
      मानो यह किसी पिरामिड जैसी संरचना की तरह हो, जहाँ industry को बनाए रखने के लिए नई नौकरियाँ बनाई जा रही हों
      फिर भी असली engineering मौजूद है — जब हम वैज्ञानिक तरीके से सवाल तय करते हैं और उनके जवाबों के आधार पर निर्णय लेते हैं
      इसके उलट, ‘gut feeling’ पर काम करना और सिर्फ CEO की बात मानना engineering नहीं है
    • पहले की तुलना में software engineering की गुणवत्ता काफी बेहतर हुई है
      पहले बहुत-सी टीमें version control तक इस्तेमाल नहीं करती थीं, और अगर करती भी थीं तो वह बहुत खराब होता था
      Joel Spolsky का Joel Test देखें, तो उस दौर की ज़्यादातर कंपनियों का जवाब “नहीं” होता
    • मैं सोचता हूँ कि क्या software को पुल के design की तरह बनाया जा सकता है
      पुलों में load, material, lifespan जैसी चीज़ें सटीक रूप से गणना की जाती हैं, लेकिन websites में traffic तक का अनुमान लगाना मुश्किल होता है
      servers या frameworks की सीमाओं को मात्रात्मक रूप से संभालने के लिए हमारे पास कोई मानक नहीं है
      कभी software भी शायद सचमुच engineering बन जाए, लेकिन अभी वहाँ तक पहुँचना बाकी है
    • सच कहें तो software, engineering से ज़्यादा रचनात्मक प्रयोग के करीब है
      “engineer” शब्द शायद सिर्फ ज़्यादा पैसा कमाने के लिए जोड़ा गया था
      असली engineers proof और validation को महत्व देते हैं, जबकि हम नए patterns और प्रयोगों का आनंद लेते हैं
      इसलिए ‘engineer’ शब्द मुझे उल्टा असहज करता है
    • Edsger Dijkstra ने 1988 में ही कहा था कि “software engineering एक असंभव अनुशासन है”
      उन्होंने इसकी आलोचना “ऐसी methodology” के रूप में की थी जिसके जरिए programming न जानने वाले लोग programming करना चाहते हैं, और लगता है कि आज भी यह बात उतनी ही सही है

  • आजकल AI-आधारित development process बड़ी कंपनियों के इर्द-गिर्द जमता जा रहा है, और vendor lock-in बढ़ता जा रहा है
    अगर codebase agent-केंद्रित हो गया, तो आखिरकार वही agents कोड को समझ पाएँगे
    उस बिंदु पर कीमतें बढ़ेंगी, और human developers के लिए वापस लौटना मुश्किल एक one-way transition बन सकता है
    आशावादी लोग कहते हैं, “तकनीक हमेशा सस्ती होती है और बेहतर बनती है,” लेकिन यह तेल बाज़ार जैसा भी हो सकता है

    • मुझे भी यही चिंता है
      जैसे पहले DVD से streaming पर जाने के दौरान हुआ था, हम मानो वही फ़िल्म दो बार खरीद रहे हों
      Claude Opus 4.6 जैसे models अब प्रति मिनट 1 डॉलर तक महंगे हो गए हैं, और prompt engineering से अब इसकी भरपाई नहीं हो रही
      आखिरकार AI services भी low-cost–mid-tier–premium परतों में बँटती जा रही हैं
      prompt engineering को अब लगभग चतुर jailbreaking जैसा माना जा रहा है
    • इसी वजह से, skilled professionals को अपनी skills खुद बनाए रखनी चाहिए
      अपनी knowledge work क्षमता को AI कंपनियों को ‘lease’ पर देना जोखिम भरा है
      “अब लागत और नहीं बढ़ेगी” जैसा वाक्य बातचीत का अंत है — वे पासा फेंक चुके हैं
    • Facebook या Uber प्रति request लागत सार्वजनिक क्यों नहीं करते, इसका कारण सरल है — वे एकाधिकार आधारित pricing करते हैं
      AI की बड़ी कंपनियाँ भी उसी रास्ते पर जाएँगी
      अंत में हम शायद token addiction market में फँस जाएँ
    • दूसरी तरफ, code का entropy कम होता है, इसलिए छोटे और अधिक efficient models भी काफी हो सकते हैं
      open source का अदृश्य हाथ अंततः सब कुछ मुफ़्त कर देगा
    • मैं उल्टा इस बात को लेकर आश्वस्त हूँ कि LLM की लागत लगातार घटती रहेगी
      hardware और software के बेहतर होने के साथ computation की unit cost लगातार घटती है
      blockchain boom की तरह जिन तकनीकों का वास्तविक उपयोग नहीं होता, वे गायब हो जाती हैं, लेकिन AI के पास असली users हैं
      Uber जैसी सेवाएँ भी शुरुआती आलोचना के बावजूद अंततः सस्टेनेबल बिज़नेस बनीं
      तेल के विपरीत, computing हर साल सस्ती और तेज़ होती जाती है

  • इस लेख का लेखक Pi नाम का open source coding agent framework बनाने वाला व्यक्ति है
    इसका उपयोग OpenClaw में भी हो रहा है

    • Goodreads उद्धरण के जरिए यह दिखाया गया है कि लेखक की लिखावट में थोड़ा self-deprecating humor है
    • मैं Mario Zechner को libGDX और RoboVM के समय से follow करता आया हूँ
      उनका Pi पर ब्लॉग पोस्ट भी देखने लायक है
    • दूसरी ओर, OpenClaw के निर्माता का दर्शन बिल्कुल अलग है
    • इसलिए इस लेख को सिर्फ anti-AI आलोचना कहकर खारिज नहीं किया जा सकता
      वह LLM और agents के साथ किसी भी अन्य व्यक्ति से अधिक गहराई से काम कर चुका है
    • लेकिन कुछ लोगों को ऐसे लेख बहुत कुछ कहे बिना लिखे गए लेखन जैसे लगते हैं

  • जो कंपनियाँ दावा करती हैं कि “AI 100% कोड लिखती है,” वे अक्सर बिखरे हुए उत्पाद जारी करती हैं
    पुराने DOS या MacOS के दौर में ऐसा कोड पूरे system को crash कर सकता था, इसलिए गुणवत्ता अधिक महत्वपूर्ण थी
    अब OS ज़्यादा सहनशील हो गया है, इसलिए ढीला-ढाला कोड भी बच जाता है

    • समस्या computing resources नहीं, बल्कि “हमेशा online” रहने की धारणा और “अभी ship करो, बाद में ठीक कर लेंगे” वाली संस्कृति है
      OTA updates की वजह से अधूरे products को आसानी से बाहर भेजा जाता है ताकि competitors से पहले launch हो सके
    • लेकिन पहले भी बेहद खराब software बहुत था
      बस हमें याद वही कुछ products रहते हैं जो अच्छे बने थे
    • इंटरनेट से पहले patch करना मुश्किल था, इसलिए रिलीज़ से पहले कड़े परीक्षण किए जाते थे
      अब सिर्फ network connection हो तो OS तक को game की तरह आसानी से update किया जा सकता है

  • coding agents ‘लुभाने वाली siren’ की तरह हैं
    शुरुआत में वे तेज़ और स्मार्ट लगते हैं, लेकिन जिस क्षण आप सोचते हैं, “कंप्यूटर, मेरा काम मेरी जगह कर दो,” सब ढहने लगता है
    लेकिन यह अस्थायी है — AI पहले ही मापे जा सकने वाले क्षेत्रों में इंसानों से आगे निकल चुका है
    असली समस्या HCI (human–computer interaction) की है
    इंसानी मूल्यों के अनुरूप interface design करना आगे की सबसे महत्वपूर्ण चुनौती है

  • अभी AI hype cycle अपने शिखर पर है
    जैसे पहले MongoDB या NoSQL के समय लोग कहते थे “SQL मर चुका है,” वैसे ही अंततः लोग फिर व्यावहारिक संतुलन की ओर लौटेंगे
    NoSQL गायब नहीं हुआ, लेकिन अब उसका उपयोग वहीं होता है जहाँ उसकी सच में ज़रूरत है

  • “आजकल software नाज़ुक और बिखरा हुआ है” — इस बात से सहमत होते हुए भी, सच यह है कि software खुद नहीं बदला है
    पहले भरोसा नहीं था, इसलिए लोग खुद जाकर चीज़ें जाँचते थे, और वही धीमी गति समस्याएँ कम करती थी
    DevOps का सार है भरोसे के आधार पर तेज़ चलना, लेकिन गुणवत्ता बनाए रखना
    Toyota के Andon cord की तरह, समस्या मिलते ही तुरंत रुकना और root cause ठीक करना चाहिए
    यह तकनीकी नहीं बल्कि संस्कृति और process का मुद्दा है

    • systems engineering के नज़रिए से देखें तो हर चरण पर acceptable failure modes तय और validate करने चाहिए
      गलत interfaces या business context mismatch को जल्दी पकड़ना होगा
    • large-scale integration भी एक समस्या है
      जब हर कोई GitHub, AWS, Cloudflare का उपयोग करता है, तो एक जगह रुकने पर पूरी दुनिया रुक जाती है
    • Andon cord जैसी संस्कृति हर जगह चाहिए
    • semiconductor industry में ऐसी संस्कृति पहले से है
      tape-out से ठीक पहले bug मिले तो वे messenger को दोष नहीं देते, बल्कि बहुत सावधानी से निर्णय लेते हैं

  • programming का output सिर्फ code नहीं, बल्कि प्रोग्रामर स्वयं भी होता है
    code लिखते हुए बनने वाले mental models और muscle memory ही असली संपत्ति हैं
    अगर AI इस प्रक्रिया की जगह ले ले, तो अंततः प्रोग्रामर की वृद्धि ही गायब हो जाएगी
    Jonathan Blow का “Preventing the Collapse of Civilization” भी यही मुद्दा उठाता है

  • कल मैंने एक सहकर्मी के साथ इसी तरह की बात की
    हमने एक demo देखा जिसमें AI logs पढ़ता है, bug ठीक करता है, और postmortem भी लिख देता है,
    लेकिन समस्या यह है कि इंसानों के पास उस प्रक्रिया को अंदर तक आत्मसात करने का समय ही नहीं बचता
    जैसे कहा जाता है, “कार में brake होते हैं, तभी वह तेज़ चल सकती है,”
    वैसे ही इंसान की समझ की गति के अनुरूप सीखने का friction बनाए रखना ज़रूरी है

    • लेकिन उस उदाहरण की असली कमी यह है कि इंसान को पहले यह पहचानना होगा कि system टूटा हुआ है
      अगर agent खुद पहचान ले और खुद recovery भी कर ले, तो क्या इंसान को सीखने की ज़रूरत बचेगी?
      हाँ, root cause छूट सकता है, लेकिन अगर self-healing system काफ़ी मज़बूत हो, तो क्या वह वास्तव में समस्या है?

  • product design के नज़रिए से भी यही समस्या महसूस होती है
    development की रफ्तार इतनी तेज़ है कि खुद इस्तेमाल करके validate करने का समय ही नहीं मिलता
    अगर गलत design के ऊपर features जोड़ते जाएँ, तो बाद में वापस लौटना मुश्किल हो जाता है
    अंत में असली बात गति नहीं, बल्कि गुणवत्ता और सीखने के बीच संतुलन है

    • असल बात code lines बढ़ाना नहीं, बल्कि customer feedback लेकर iterative improvement करना है
      और इस प्रक्रिया में अनिवार्य रूप से समय लगता है