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

• हाल में 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 को बनाए रखने का एकमात्र रास्ता है