रीफैक्टरिंग से मिलने वाले आर्थिक लाभ

• एजेंट द्वारा लिखी गई 17,155 लाइनों की Rust data access layer को चरणबद्ध तरीके से रीफैक्टर करने पर, उसी फीचर बदलाव के लिए आवश्यक input tokens 159,564 से घटकर 27,360 रह गए, यानी 83% कमी
• कुल code size लगभग वही रहा, लेकिन संबंधित code को अधिक cohesive files में अलग करने से एजेंट बदलाव के लिए आवश्यक न्यूनतम file set ही पढ़ सका
• input tokens में बड़ी कमी तब तक नहीं आई जब तक सबसे बड़ी file पर्याप्त छोटी नहीं हो गई; अंत में data layer को 19 Rust files में बाँटा गया और सबसे बड़ी file का आकार 17,155 लाइनों से घटाकर 3,695 लाइनों तक लाया गया
• output tokens और फीचर implementation की मात्रा लगभग नहीं बदली, और Claude भी अपने-आप उपयुक्त रीफैक्टरिंग चुनने या उसे स्थिर रूप से करने में सक्षम नहीं था, इसलिए planning और execution में मानव की सक्रिय guidance की ज़रूरत पड़ी
• Sonnet 5 की input pricing $3/MTok के आधार पर प्रति बदलाव बचत लगभग $0.397 ही थी, लेकिन यह पुष्टि हुई कि आगे data access layer में हर बदलाव के साथ लागत बार-बार घट सकती है

---

एजेंट द्वारा बनाई गई 17,155 लाइनों की file

• कामकाजी सहायता के लिए बनाया गया application dynamic update/query वाली web UI, modals और autosave, external systems integration, machine learning और text analysis, background jobs, और automated deployment environment से लैस है
• कुल लगभग 150,000 लाइनों में से Rust लगभग 120,000 लाइनें है और बाकी TypeScript व Terraform हैं; इनमें से अधिकांश Claude Code और कुछ Cursor की मदद से एजेंट ने लिखीं
• डेवलपर ने कभी-कभार रुचि से देखने को छोड़कर code को पढ़ा या review नहीं किया
• data access layer में हर read/write query पर वही HTTP request settings और JSON encoding/decoding दोहराई जाती रही, जिससे यह 6,000 से अधिक लाइनों तक बढ़ी और अंततः एक Rust file 17,155 लाइनों तक पहुँच गई
• इस module में deduplication और internal language नहीं थी, function extraction सीमित थी और class extraction भी लगभग नहीं था, लेकिन interfaces सुरक्षित रखने थे और boundaries स्पष्ट थीं, इसलिए यह रीफैक्टरिंग प्रयोग के लिए उपयुक्त था

एक ही बदलाव को दोहराकर मापने का तरीका

• लक्ष्य यह देखना था कि क्या अभी रीफैक्टरिंग पर tokens खर्च करके भविष्य के feature changes की token consumption घटाई जा सकती है
• चूँकि एजेंट पिछले काम से नहीं सीखता, इसलिए हर चरण में एक नए sub-agent से बिल्कुल वही बदलाव करवाया गया ताकि learning effect मिश्रित न हो
• प्रयोग निम्न क्रम में किया गया
  • कड़े रीफैक्टरिंग सिद्धांतों के अनुसार पूरी योजना लिखी गई
  • एक prompt में representative change परिभाषित किया गया
  • sub-agent ने बदलाव किया और token consumption report की ताकि baseline मापी जा सके
  • बदलाव के परिणाम को discard करके रीफैक्टरिंग का एक चरण लागू किया गया
  • उसी बदलाव को फिर से कराया गया और परिणाम discard किया गया; यह प्रक्रिया दोहराई गई
  • हर चरण की token cost, execution time, और code lines दर्ज की गईं
• Claude real-time token count विश्वसनीय रूप से नहीं दे सका, इसलिए उससे sent/received character counts report करवाए गए और tiktoken से character count को 4 से भाग देकर tokens का approximation किया गया

चरणवार मापन के परिणाम

• baseline स्थिति में data access layer और सबसे बड़ी file दोनों 17,155 लाइनों की थीं, कुल Rust code 50,359 लाइनें था, और representative change के लिए 159,564 input tokens, 1,705 output tokens, और 342 सेकंड लगे
• 15 चरणों के बाद data access layer 16,608 लाइनों की रह गई, सबसे बड़ी file 3,695 लाइनों की थी, कुल Rust code 49,812 लाइनें था, और input 27,360 tokens, output 2,113 tokens, execution time 454 सेकंड था
• बीच के चरणों में जैसे-जैसे सबसे बड़ी file छोटी हुई, input tokens भी घटते गए
  • चरण 7 में queries.rs निकालने के बाद सबसे बड़ी file 15,670 लाइनों की रही और input 151,850 tokens हो गया
  • चरण 8 में traits.rs निकालने के बाद सबसे बड़ी file 13,845 लाइनों की रही और input 132,558 tokens हो गया
  • चरण 12 में store/ अलग करने के बाद सबसे बड़ी file 9,269 लाइनों की रही और input 104,080 tokens तक घट गया
  • अंतिम store/ separation के बाद सबसे बड़ी file 3,695 लाइनों की रह गई और input 27,360 tokens तक तेजी से गिर गया
• अंतिम data access layer 19 Rust files से बनी और सबसे बड़ी file test library बन गई
• आगे की रीफैक्टरिंग में यही तरीका उस test file पर भी लागू किया जा सकता है

input tokens 83% क्यों घटे

• उसी काम के input tokens 159,564 से घटकर 27,360 रह गए, यानी 132,204 tokens की बचत
• data access layer का कुल code volume लगभग नहीं बदला, इसलिए यह code कम पढ़े जाने का परिणाम नहीं था
• एजेंट ने काम के लिए आवश्यक न्यूनतम file set की पहचान की और धीरे-धीरे केवल छोटे code regions ही पढ़े; Claude Code के thinking output और file-reading summaries में भी यह दिखा
• files को बस मनमाने ढंग से छोटे हिस्सों में बाँट देने से वही प्रभाव मिलना कठिन है, क्योंकि संबंधित code खोजने के लिए कई files पढ़नी पड़ सकती हैं
• सबसे बड़ी गिरावट अंतिम separation में आई, लेकिन उससे पहले duplicate code निकालने और दोहराए जाने वाले core structures बनाने की वजह से file separation संभव हुई
• यह क्रम लागत घटाने के उद्देश्य से पहले से डिज़ाइन नहीं किया गया था; बल्कि पहले local duplication हटाने, फिर common core उभरने देने, और उसके बाद छोटी files में बाँटने वाली सामान्य रीफैक्टरिंग प्रक्रिया से निकला

output tokens और आर्थिक प्रभाव

• representative change लिखते समय बने output tokens में लगभग कोई बदलाव नहीं आया, यानी रीफैक्टरिंग वास्तविक बदलाव के आकार को कम नहीं कर सकी
• output token pricing input tokens की तुलना में 5 गुना थी, लेकिन उनका absolute volume बहुत कम था
• Sonnet 5 की input price $3/MTok मानने पर प्रति बदलाव बचत लगभग 39.7 सेंट बनती है
• debugging, अधिक जटिल features, या पूरे codebase-स्तर की रीफैक्टरिंग में यह बचत जमा होती है या नहीं, और स्वयं रीफैक्टरिंग की लागत कितनी है, यह सत्यापित नहीं किया गया
• क्या output tokens घटाने वाली रीफैक्टरिंग संभव है, यह भी स्पष्ट नहीं है; साधारण representative change में non-deterministic code generation का शोर structure changes के असर को ढँक देता था

Claude के साथ की गई रीफैक्टरिंग

• Claude code देखकर अपने-आप यह नहीं चुन सका कि कौन-सी रीफैक्टरिंग लागू करनी है; वास्तविक परिणाम prompt में सीधे दिए गए निर्देशों के अनुरूप थे
• development harness में explicit रीफैक्टरिंग चरण मौजूद थे, फिर भी Claude ने उनके आधार पर 17,155 लाइनों की file को बेहतर नहीं बनाया
• planning के दौरान Claude Code ने पहले चरण के रूप में function extraction पहचाना, जबकि Claude.ai ने पूरी client class extraction तक पहचान ली
• mechanical changes के लिए grep और sed इस्तेमाल करने वाली Python scripts का उपयोग किया गया, लेकिन scripts अक्सर indentation के कारण भ्रमित हो गईं
• सबसे अधिक मूल्यवान repository file separation पहली कोशिश में छूट गया और बाद के चरण में फिर लागू करना पड़ा; इसी वजह से measured steps की संख्या और appendix की plan steps आपस में मेल नहीं खातीं
• पूरे प्रयोग में लगभग 8 घंटे लगे और इसका अधिकांश हिस्सा बिना मानवीय हस्तक्षेप के चला
  • 6 घंटे 40 मिनट बाद छूटा हुआ चरण मिला, तब एक बार हस्तक्षेप करना पड़ा
  • slow hotel Wi‑Fi से अधिक, जरूरत से बहुत बड़ा हो चुका Cargo temporary build cache test execution को धीमा करने का मुख्य कारण था

representative change prompt

• हर sub-agent को केवल codebase और architecture documents दिए गए और उससे वही async public trait ItemWatchStore implement कराया गया
• trait में ये तीन methods शामिल थे
  • watch_item(&self, item_id: &str, user_id: &str) -> Result<()>
  • unwatch_item(&self, item_id: &str, user_id: &str) -> Result<()>
  • watched_items_for_user(&self, user_id: &str) -> Result<Vec<String>>
• watch जानकारी Firestore की item_watches collection में itemId, userId, createdAt fields के साथ store की गई
• अलग Rust record struct के बिना item ID का Vec<String> return किया गया
• FakeStore में in-memory Vec<(String, String)> field जोड़ी गई और FirestoreStore में मौजूदा HTTP pattern को जस का तस रखते हुए implementation किया गया
• response के अंत में पढ़ी गई files और character counts, तथा response character count को JSON में print करने को कहा गया, और code commit न करने का निर्देश दिया गया

लागू की गई रीफैक्टरिंग योजना

• चरण 1 — FirestoreClient class extraction

  • domain query coordination और Firestore HTTP transport responsibilities को अलग किया गया
  • reqwest::Client, project_id, MetadataAuth, URL/auth headers handling को नई struct में ले जाया गया
  • योजना के अनुसार FirestoreStore implementation में लगभग 1,200 लाइनें कम होनी थीं और client में लगभग 120 लाइनें जुड़नी थीं

• चरण 2 — extract_doc_id, new_link function extraction

  • 20 document parsers में ID extraction और 62 बार दोहराई गई Link creation को common बनाया गया
  • लगभग 500 लाइनों की कमी का अनुमान था

• चरण 3 — link query pipeline function extraction

  • लगभग 15 जगहों के query result collection और लगभग 8 जगहों के single-target ID lookup pattern को common बनाया गया
  • लगभग 200 लाइनों की कमी का अनुमान था

• चरण 4 — FakeStoreInner link condition function extraction

  • लगभग 15 methods में दोहराए गए inner.links.iter() variants को दो methods में अलग किया गया
  • लगभग 120 लाइनों की कमी का अनुमान था

• चरण 5 — Firestore value creation functions की शुरुआत

  • 128 से अधिक बार दोहराए गए string, timestamp आदि के json! expressions को चार function calls से बदला गया
  • multi-line macros को single-line calls में बदलकर लगभग 80 लाइनों की कमी का अनुमान था

• चरण 6 — FieldsBuilder extraction

  • लगभग 20 encoders के field map creation pattern को builder में समेकित किया गया
  • लगभग 40 लाइन वाले encoders को लगभग 12 लाइन तक घटाकर कुल 500~600 लाइनों की कमी का अनुमान था

• चरण 7 — queries.rs separation

  • 32 LinkQuery constants और संबंधित types को अलग module में ले जाया गया
  • मौजूदा call sites बदले बिना mod.rs से लगभग 800 लाइनें कम की गईं

• चरण 8 — traits.rs separation

  • 17 public traits और संबंधित error types को स्थानांतरित कर फिर से re-export किया गया
  • mod.rs से लगभग 1,900 लाइनें कम हुईं, लेकिन नई file भी लगभग 1,900 लाइनों की बनी

• चरण 9 — traits/ को domain के अनुसार विभाजित करना

  • traits को planning.rs, content.rs, people.rs, system.rs में बाँटा गया
  • definitions और call sites बदले बिना file sizes को लगभग 300~650 लाइनों तक सीमित किया गया

• चरण 10 — codec.rs separation

  • document encoders/decoders, parsers, FieldsBuilder, और value creation functions को स्थानांतरित किया गया
  • चरण 6 के बाद यह लगभग 400~500 लाइनों का module बना और mod.rs से लगभग 500 लाइनें कम हुईं

• चरण 11 — fake_store.rs separation

  • FakeStore, FakeStoreInner, और 18 trait implementations को स्थानांतरित किया गया
  • mod.rs से लगभग 4,700 लाइनें कम हुईं

• चरण 12 — FirestoreStore implementation separation

  • store/mod.rs में struct, constructor, FirestoreClient, MetadataAuth रखे गए और trait implementations को domain-आधारित files में बाँटा गया
  • लगभग 10,000 लाइनों की file को 10 files में बदला गया, जिनमें हर एक 120~650 लाइनों की थी, और mod.rs लगभग 100 लाइनों की re-export file बन गई

• चरण 13 — tests को target module के साथ रखना

  • test code बदले बिना हर implementation file के नीचे ले जाया गया
  • mod.rs से लगभग 2,000 लाइनें कम हुईं और हर file में संबंधित 200~700 लाइनों के tests जुड़े

सीमाएँ और आगे के प्रयोग

• रीफैक्टरिंग योजना लिखने और उसे लागू करने में लगे tokens अलग से नहीं गिने गए, इसलिए रीफैक्टरिंग निवेश लागत का सटीक हिसाब नहीं लगाया जा सका
• उस समयावधि की कुल usage के आधार पर upper bound 5 million tokens था, लेकिन इसमें plan को दो बार लिखने का काम, experiment और representative change design, तथा अन्य काम भी शामिल थे
• प्रयोग का विषय अभी greenfield चरण में है और एक ही डेवलपर द्वारा बनाया व संचालित एक बड़ा application है, इसलिए परिणामों को सामान्यीकृत नहीं किया जा सकता
• आगे के काम में रीफैक्टरिंग tokens का सटीक मापन, अधिक जटिल बदलाव, बड़े दायरे की रीफैक्टरिंग, continuous रीफैक्टरिंग, और अलग-अलग approaches के relative value comparison की आवश्यकता है
• यह प्रयोग रीफैक्टरिंग से मिलने वाले समय और आर्थिक मूल्य, तथा स्वयं रीफैक्टरिंग की लागत, दोनों को साथ मापने के लिए एक शुरुआती बिंदु बनता है

[GN⁺]

Hacker News राय

• यह देखना दिलचस्प है कि ज़्यादातर IT कंपनियों द्वारा नज़रअंदाज़ की गई developer best practices अब AI best practices के रूप में फिर से ईजाद हो रही हैं
  पहले कोड के अंदर documentation रखने, सिर्फ Jira task फेंकने के बजाय पूरे project का context बताने, और long-term productivity के लिए refactoring करने की बात कही जाती थी तो लोग उसे उबाऊ मानते थे
  अब वही बातें—AI documentation को code और CLAUDE.md में रखना, prompts से बहुत बारीक control न करना, और AI productivity के लिए refactor करना—दिलचस्प मानी जा रही हैं

  • इंसानी सहकर्मियों की तुलना में AI agents से वही काम लगातार एक जैसे तरीके से करवाना कहीं आसान है
    इंसान सही तरीका जानते हुए भी व्यस्त हो सकते हैं या ध्यान भटक सकता है, लेकिन agents उबाऊ कामों से ऊबते नहीं; इसलिए वे प्रक्रियाएँ, जो इंसानों पर असरदार साबित हुई थीं पर लगातार लागू करना मुश्किल था, अब व्यावहारिक रूप से संभव हो जाती हैं
    एक shared specification के आधार पर implementation और tests अलग-अलग agents से लिखवाए गए और audit agent से verify करवाया गया ताकि वे एक-दूसरे के output से प्रभावित न हों; यह IBM द्वारा 1980 के दशक में इंसानों के लिए विकसित cleanroom engineering को AI के साथ व्यापक और consistent तरीके से लागू करने जैसा है
  • इस लेख से जुड़े व्यक्ति Martin Fowler हैं, जिन्होंने 20 साल से ज़्यादा पहले 《Refactoring》 किताब लिखकर इस शब्द को लोकप्रिय बनाया था
    यह पुरानी practices को AI hype के हिसाब से नया बनाकर पेश करना नहीं है, बल्कि सबूतों के साथ दिखाना है कि 20 साल से ज़्यादा पुरानी best practices आज भी मान्य हैं
  • AI से पहले और बाद का बड़ा अंतर यह है कि इंसानों के पास काफ़ी अच्छी long-term context management capability होती है
    Agents को हर session में context फिर से सीखना पड़ता है, इसलिए best practices की value कहीं ज़्यादा बढ़ जाती है और असर भी तुरंत दिखता है
  • AI boom की वजह से मनचाहे developer experience improvement work के लिए budget मिलना संभव हुआ है, लेकिन यह कड़वा लगता है कि वजह गलत है
    फिर भी, एक घंटे में CLI को 100 बार चलाकर किसी नए flag की usability test कर पाना अच्छा है
  • इंसान SharePoint के पुराने documents, meetings में सुने गए बिखरे हुए overall context, और refactoring की कम priority के बावजूद—quality और schedule खराब होने पर भी—किसी तरह results निकाल लेते हैं
    इसके उलट AI के पास यह आधार न हो तो वह बहुत खराब perform करता है या बिल्कुल काम नहीं करता, इसलिए healthy engineering practices long-term improvement नहीं बल्कि जरूरी prerequisite बन जाती हैं
    भले ही असल net effect बिल्कुल न हो, AI को workflow में शामिल करना इस मायने में उपयोगी है कि इससे सही development practices अपनाने का बहाना मिल जाता है

• इस लेख की अच्छी बात यह है कि यह AI tools वास्तव में कैसे इस्तेमाल होते हैं, इसके आधार पर concrete और quantitative critique करता है
  वास्तविक use cases के बिना सामाजिक जोखिमों पर अस्पष्ट चर्चा करने वाले लेखों की तुलना में, AI क्या नहीं कर सकता यह measurements से दिखाने वाले लेख कहीं ज़्यादा उपयोगी हैं
  इसी वजह से Boko Haram सदस्यों का interview लेकर यह जांचने वाली report भी प्रभावशाली लगी कि AI का terrorism में कैसे इस्तेमाल हुआ

• AI के बिना खुद की गई refactoring मुझे सच में बहुत पसंद है
  दिखने वाला बदलाव नहीं होता, लेकिन यह संतोष मिलता है कि एक website, जिसके results अभी तुरंत नहीं दिखेंगे, भविष्य में संभालने के लिए कहीं आसान हो जाएगी
  पहले से स्थापित patterns से हल हो चुकी समस्याओं को past के अजीब workaround code द्वारा फिर से हल किए जाते देखना, फिर उन्हें best practices की तरफ ले जाना और नया technical debt न बनाना—यह पूरी प्रक्रिया puzzle जैसी मज़ेदार है
  Authentication तक सब कुछ ढीले-ढाले तरीके से खुद implement करके कठिन रास्ते से internal principles सीखे, और नतीजा यह हुआ कि अगले 10 साल तक enjoy करने लायक refactoring material भी मिल गया

  • Fowler की 《Refactoring》 पढ़कर शक था कि यह science/research code पर भी असरदार होगी या नहीं, लेकिन असंतोषजनक code structure पर experimentally apply करने के बाद नज़रिया पूरी तरह बदल गया
    codebase एक system है—यह बात ठोस रूप से समझ आई, और code को ऐसे higher level पर देखने लगा जैसे कोई continuous organization या mesh हो जिसे खींचा और दबाया जा सकता है
    AI इस learning process को खत्म कर सकता है, यही junior developer वाली समस्या को सामने लाता है। intuition पाने के लिए खुद गहराई में उतरना ही रास्ता है, और Naur ने 40 साल पहले चेतावनी दी थी फिर भी यह सीख बार-बार भुला दी जाती है
  • शायद इसलिए भी कि इससे Windows 98 disk defragmentation screen देखने जैसा dopamine reward मिलता है
  • वह भावना craftsman के गर्व की है। जो समझते हैं उन्हें explanation की जरूरत नहीं, और जो नहीं समझते उन्हें कोई explanation समझा नहीं सकता
  • Refactoring के दौरान regression रोकने के लिए test suite को किस हद तक safety net के रूप में बनाया गया था, यह जानने की जिज्ञासा है
  • कई refactoring patterns और उनके वास्तविक application cases पढ़ने-सीखने की प्रक्रिया मज़ेदार है

• मेरा मानना है कि जब agent refactoring करे, तो human involvement अनिवार्य है
  generative model शुरुआती काम पर ध्यान देते हुए जो हिस्से छोड़ देता है, review model उन्हें ढूंढ सकता है, लेकिन क्या वह पूरे project के उद्देश्य और code के आपस में जुड़ने के तरीके को सच में समझकर duplication या अधिक elegant structure पहचान सकता है, यह संदिग्ध है
  coding agent को refactoring सौंपना कुछ-कुछ trauma surgeon से athletic performance बढ़ाने को कहने जैसा है; इसे सही से करने के लिए holistic perspective चाहिए
  बड़े file को कई files में बांट देना भर superficial refactoring है। कौन-सा code साथ रहना चाहिए और क्या utility function में निकालना चाहिए, इस पर कोई theory न हो तो यह factorization नहीं, बल्कि बड़ी संख्या को छोटी संख्याओं में तोड़कर फिर जोड़ देने जैसा है
  agent कभी-कभी ऐसा system भी बना देते हैं जो API से पहले से मिल रही values को फिर से store और calculate करता है, लेकिन इंसान पूरे project को देखकर ठीक-ठीक पता लगा सकता है कि JSON की किसी खास key में जरूरी data पहले से मौजूद है

  • मौजूदा LLM भी अगर code के किसी खास हिस्से पर concrete refactoring instruction दिया जाए, तो काफी अच्छा काम करते हैं। उदाहरण के लिए data class के बजाय functools.partial से Command pattern implement करने जैसी जटिल मांग भी संभाल सकते हैं
    file boundaries logical subsystem की boundaries दिखाती हैं, जिससे reasoning आसान होती है, और दूसरे files की contents को default रूप से opaque माना जाता है—यह concept भी training data में खूब मौजूद है
    मुझे लगता है कि इस structure के फायदे सिर्फ human cognition की accidental characteristics नहीं, बल्कि objective aspects भी हैं
  • इंसान ने पास बैठकर direction समझाई, तो महीनों लगने वाली refactoring लगभग एक हफ्ते में ज्यादातर पूरी हो गई
    refactoring का अनुभव, दूसरों के codebase से निपटने का तरीका, और original designer के रूप में past और present intent समझा पाने की क्षमता मददगार रही
    यह कम dependency vulnerability वाली, LLM के लिए संभालने में आसान niche language थी; JavaScript और Python वाली bias हटाने के बाद काम की गति बहुत बढ़ गई
    यह JSR-223 project था जिसमें कई popular languages में scripts लिखी जाती थीं, लेकिन environment requirements के कारण सब JVM पर run होती थीं: https://en.wikipedia.org/wiki/Scripting_for_the_Java_Platform
  • agents refactoring नहीं कर सकते—यह आकलन पुराना हो चुका है; आज वे बहुत बढ़िया हैं
    इस hiring market में latest frontier model-based coding agents इस्तेमाल करना और उनकी capabilities व limitations को सटीक समझना जरूरी है; interview में उलटा आकलन देना rejection का कारण बन सकता है

• संक्षिप्त context सिर्फ token consumption घटाता नहीं, reasoning भी बेहतर करता है, और एक context में अधिक layers डालकर उन्हें intelligently handle करने देता है
  अच्छे abstraction की ओर refactoring ऐसा software बनाती है जो सिर्फ test किए गए cases में नहीं, बल्कि interpolated और extrapolated cases में भी सही होने की अधिक संभावना रखता है और बेहतर generalize करता है
  इसके पीछे information theory और Bayesian math है, और economically व energy-efficient software का अधिक accurate होना एक शानदार संयोग जैसा लगता है
  मुख्य बात code की entropy घटाना है

  • दुनिया और ब्रह्मांड में कहीं भी entropy reduction को कुछ बनाने के काम के रूप में देखा जा सकता है
  • अगर human readability को लक्ष्य से हटाकर सिर्फ token consumption reduction को objective function बना दें, तो कहां पहुंचेंगे कहना मुश्किल है
    LLM कम context में भी meaning को पहले से ही काफी अच्छी तरह infer कर लेते हैं

• data प्रस्तुत किया गया है, यह दिलचस्प है, और यह मेरे अनुभव से मेल खाता है कि अच्छी तरह separated code में LLM को बड़ा फायदा मिलता है, लेकिन खुद ऐसा code बनाने की उसकी क्षमता उतनी शानदार नहीं है
  ज्यादातर human developers के साथ भी शायद ऐसा ही होगा

  • मैं अलग से messy code removal time को budget में रखता हूं, और अभी भी बगल वाली window में वही काम कर रहा हूं
    कुल मिलाकर AI का फायदा बड़ा है, लेकिन cleanup time भी चाहिए, और मुझे लगता है कि अब भी हर line पढ़नी पड़ती है
    दूसरी team की progress न रुके इसलिए कुछ reviews टाल दिए थे, और बाद में सामान्य से बड़ा technical debt चुका रहा हूं, लेकिन पहले bottleneck हटाना अधिक valuable था
    AI ने हर मायने में technical debt लेना आसान बना दिया है, और सही guidance मिले तो debt reduction भी काफी अच्छा करता है। हालांकि परिणाम व्यक्ति-व्यक्ति पर निर्भर करते हैं: https://news.ycombinator.com/item?id=49035455
  • default state में वही results देखे, लेकिन refactoring direction को specific बनाकर देने पर वह बेहतर separated code बना सका
    अच्छी तरह structured code के examples या open source repositories के जरिए क्या करना है और क्या नहीं करना है, यह दिखाना बहुत मदद करता है

• refactoring के economic benefits का अधिकतर हिस्सा token savings से ज्यादा मानवीय समझ में सुधार से आता है
  रात 3 बजे की outage call को जल्दी resolve करना, production में जाने वाले bugs कम करना, और competitors से तेज़ ship करना संभव होता है
  सबसे बढ़कर, जब आप system समझते हैं तो responsibility और ownership लेने को तैयार होते हैं, जिससे समस्या आने पर उसे तेजी से ठीक करते हैं और सुधार वाली जगहों पर भी actively जुट जाते हैं

• मुख्य बात यह है कि refactoring token consumption घटाती है, और abstract चर्चा के बजाय effect को quantify किया गया है, यह अच्छा है
  लेकिन Fowler ने 《Refactoring》 में कहा था कि refactoring की essential prerequisite मजबूत tests हैं, और AI से अलग असली benefit मुझे यहीं दिखता है
  अच्छे tests इंसान या robot से बने regressions को रोकते हैं, और दोनों के पढ़ने योग्य specification को code के रूप में छोड़ते हैं: https://www.oreilly.com/library/view/refactoring-improving-the/9780134757681/

  • लेख martinfowler.com पर छपा है, लेकिन इसे Martin ने नहीं लिखा; author Thoughtworks CTO Giles Edwards-Alexander के रूप में दिखाए गए हैं
  • असल core point यह है कि बचत मुश्किल से कुछ दर्जन cents के स्तर की है
    Sonnet 5 की कीमत 3 dollars प्रति MTok मानकर चलें, तो data access layer को छूने वाले future changes में बचत 39.7 cents है
    OpenAI की price cuts, open models, और long-term token price decline को देखते हुए, करीब 100 dollars प्रति घंटे वाले senior developer से refactoring guide करवाने की लागत से यह मेल नहीं खा सकता

• एजेंट द्वारा बनाया गया कोड इतना बड़ा ढेर बन गया है कि उसे केवल एजेंट ही पढ़ और समझ सकता है, और यहाँ यह बात ज़्यादा मायने रखती है कि वास्तविकता क्या है, बजाय इसके कि यह feature है, bug है या कोई emergent property
  AI tools से बनाए गए code को संभालने के लिए हम फिर से AI tools पर निर्भर हो रहे हैं
  हालांकि इंसानों ने भी पहले से ही भयानक रूप से बड़ी files और monorepos बनाए हैं, और LLM की वजह से ही उन्हें edit और refactor करना आखिरकार संभालने लायक हुआ है
  जब codebase इंसानों के समझने के लिए बहुत बड़ा और अस्त-व्यस्त हो गया है, तब LLM हमें बचा भी सकता है; निजी तौर पर मुझे विशाल files से नफ़रत है, लेकिन यह कड़वा लगता है कि Fowler-शैली के सफ़ाई सिद्धांत अब शायद उतने अहम न रहें

  • यह कहना कि agent code केवल agent ही समझ सकता है, मूल रूप से सच नहीं है; अगर ऐसा लगता है तो LLM इस्तेमाल करने का तरीका गलत है
  • खराब code पहले से था, लेकिन AI एक नई समस्या है जो खराब hiring से होने वाले नुकसान का दायरा 1,000 गुना बढ़ा देता है
    औसत या कभी-कभी अच्छा काम करने वाले कर्मचारी को भी यह बिजली की गति से वे काम करवा सकता है जो पहले company processes की वजह से नहीं कर पाता था, और उल्टा उसे खराब कर्मचारी में बदल सकता है
  • LLM द्वारा 100% लिखे गए codebase को पढ़ने या मनचाही जगह खोजने में भी कोई समस्या नहीं हुई, और यह खुद लिखे code से ज़्यादा मुश्किल नहीं था
  • मैंने ऐसा कोई मामला नहीं देखा जहाँ agent द्वारा बनाया गया code इंसानों द्वारा लिखे सबसे खराब code से भी खराब हो
    अगर agent बहुत बड़ी file या function बनाता है, तो बस उसे ऐसा न करने का निर्देश देने पर वह मान लेता है

• Refactoring एक healthy development team का संकेत दिखाने वाली सबसे अच्छी निशानियों में से एक है, ऐसा मुझे लगता है
  Refactoring के अपने फायदे हैं, लेकिन product owner या feature work plan में इसकी value साफ़ दिखाई नहीं देती
  अगर team पूरे software की health के लिए refactoring करती है, तो इसका मतलब है कि developers अच्छे software के लिए सुझाव आराम से दे सकते हैं, और उन सुझावों को गंभीरता से लिया जाता है
  Software decay तब सबसे गंभीर होता है जब team के पास high-quality software की vision को साकार करने की प्रेरणा या अधिकार नहीं होता; अगर team excellence को लेकर अपने judgment पर चल सकती है, तो आम तौर पर यह अच्छा संकेत है
  बेशक Ruby, Node, Rust से गुजरकर फिर agent-friendly technology में पूरी तरह rewrite करने जैसी अति भी होती है, लेकिन enterprise environments में ऐसी teams कहीं ज़्यादा आम हैं जिन्हें लगता है कि सुधार करने की अनुमति ही नहीं है