- AI coding tools का उपयोग "code debt" बढ़ाने जैसा है
- एक ही product और revenue वाली दो कंपनियों में, 1 million lines of code वाली कंपनी की तुलना में 100,000 lines of code पर चलने वाली कंपनी को समझना और बदलना कहीं तेज़ होता है
- यानी जितना अधिक code, उतना अधिक debt; AI code generation productivity बढ़ाता है, लेकिन साथ ही इसे debt बढ़ाने वाली कार्रवाई के रूप में भी समझा जा सकता है
- debt के सकारात्मक और नकारात्मक, दोनों पहलू होते हैं
- सकारात्मक: कम समय में तेज़ growth संभव बनाता है
- नकारात्मक: लंबे समय में management विफल होने पर project के ढहने का जोखिम पैदा करता है
- यानी debt अच्छा भी हो सकता है, बुरा भी, उस पर interest हो भी सकता है और नहीं भी, वह तेज़ growth संभव बना सकता है, लेकिन project को ढहा भी सकता है
- अहम बात tool का इस्तेमाल करना या न करना नहीं, बल्कि उसे ज़िम्मेदारी से manage करने का रवैया है
- tools की आसान उपलब्धता सुनिश्चित करते हुए भी, generated code की quality और long-term cost को ध्यान में रखना चाहिए
5 टिप्पणियां
अगर code बहुत लंबा हो, फिर भी अगर यह आसानी से समझाया जा सके कि "यह क्या करता है", तो वह debt नहीं है.
बात यह है कि AI का बेतहाशा इस्तेमाल इसे मुश्किल बना देता है, इसलिए कहा जाता है कि वह debt पैदा करता है.
https://github.com/kelseyhightower/nocode
लेख में यह बात साफ़ तौर पर नहीं कही गई है, लेकिन क्या इसका मतलब यह भी हो सकता है कि AI से लिखा गया code, इंसान द्वारा सीधे लिखे गए code की तुलना में कम परिचित होने के कारण debt बन जाता है?
Hacker News राय
सतही तौर पर हर चीज़ को code lines (LOC) से मापने का तरीका अधूरा लगता है। अगर Company A ने 10 लाख lines of code को कहीं ज़्यादा साफ़, व्यवस्थित और अच्छी तरह documented रखा है, तो वह 1 लाख lines वाले खराब लिखे Company B से बेहतर स्थिति में हो सकती है। असली मुद्दा code नहीं बल्कि complexity है, और line count तो बस complexity का एक मोटा-सा संकेतक है। Code एक asset है। यह software company का output भी है और asset भी। बेशक asset ज़्यादा होगा तो complexity भी बढ़ेगी, लेकिन यह तो बहुत स्वाभाविक बात है। जैसे अमेरिका के highway network को सिर्फ इसलिए पूरी तरह नकारात्मक नहीं कहा जा सकता कि उसका maintenance मुश्किल और complex है। AI मुद्दे को अलग भी रख दें, तो अंत में लेखक की बात बस इतनी है कि "कम complexity बेहतर है" — यह एक बुनियादी और लगभग सभी को पता होने वाली बात है। इसलिए इस लेख की सबसे अहम बात को संक्षेप में यूँ कहा जा सकता है: "ज़रूर जाँचें कि AI coding tools final code में अनावश्यक complexity तो नहीं जोड़ रहे हैं"
मुझे तो उल्टा लगता है कि यहाँ complexity असली केंद्रीय मुद्दा नहीं है। मान लें कि कोई software business पहले से टिक चुका है, और उल्टा सोचें, तो हर cost (खरीद, वेतन आदि) को सिद्धांततः जितना हो सके कम करना ही सबसे अच्छा है। यह कहा जाता है कि complexity, simplicity से बदतर है, लेकिन वह इसलिए कि सचमुच complex होने पर वह ज़्यादा महंगी पड़ती है। पर आखिरकार महत्वपूर्ण चीज़, short term हो या long term, capital हो या operations, cost खुद है। असली सवाल यह है कि LLM-generated code cost घटाता है या बढ़ाता है। Code size, complexity, और वे अनगिनत variables जिनका OP या तुमने ज़िक्र भी नहीं किया, सब महत्वपूर्ण हैं
मैं अपने functions की complexity को cyclomatic complexity से देखता हूँ। SwiftLint से complexity मापता हूँ ताकि threshold पार होने पर flag हो जाए। कभी-कभी बस मोटे तौर पर split भी कर देता हूँ, लेकिन आमतौर पर मैं इसे और simple बनाने का रास्ता ज़रूर ढूँढ़ता हूँ। मेरी files काफ़ी लंबी होती हैं, लेकिन मैं comments और code का ratio लगभग 50:50 रखने की कोशिश करता हूँ। अगर LLM को complexity घटाने और comments बढ़ाने का prompt दिया जाए, तो वह शायद यह काफ़ी अच्छी तरह कर सकता है
Code volatile chemicals की तरह asset भी है और liability भी। अगर इसे सही तरह और जल्दी इस्तेमाल करो तो यह पैसा कमा सकता है, लेकिन अगर इसे छोड़ दो या बह जाने दो तो यह liability बन जाता है। Source code अपने-आप खराब नहीं होता, लेकिन organization के goals और processes बदलते रहने से उसकी 'fitness for purpose' लगातार बदलती रहती है
"हम simple software क्यों नहीं बना पाते?" यह विषय दिलचस्प लगता है। Complexity के बारे में यह बात प्रभावशाली लगी कि "जब systems एक-दूसरे के साथ interact करते हैं, तो complexity पैदा होती है। Complex systems कभी-कभी irrational दिशाओं में जा सकते हैं, और उनसे unexpected creativity भी निकल सकती है"
मेरे हिसाब से asset software खुद है, code asset नहीं है। जैसे highway का asset concrete नहीं बल्कि पूरा बना हुआ infrastructure है। Concrete की quality asset के depreciation और maintenance cost को प्रभावित करती है, और वह फिर asset value को प्रभावित करती है। इसमें risk management का नज़रिया भी ज़रूर शामिल होना चाहिए
अपने career के शुरुआती दौर में मुझे लगता था कि बहुत code लिखना महत्वपूर्ण है। 20 साल बाद अब मुझे ज़्यादा code delete करने पर गर्व होता है। Security engineer के नज़रिए से code सिर्फ liability नहीं बल्कि risk भी है। खासकर external library dependencies बड़ा risk हैं। हाल में मैंने एक सहकर्मी के साथ सिर्फ Rust standard library का उपयोग करके 600 lines से कम का एक छोटा Linux init system लिखा, और वह कई organizations के production में इस्तेमाल हो रहा है। बिना dependencies के, boot भी 1 second से कम में पूरा हो जाता है। इससे लगा कि systemd और लाखों lines के C code के बिना भी appliance-style Linux server बनाना पूरी तरह संभव है। खुद बनाओ तो code बहुत कम रहता है और पूरे system को पूरी तरह समझा जा सकता है
मुझे लगता है कि AI द्वारा बनाए गए code का worst-case scenario company के नज़रिए से नहीं, बल्कि ज़्यादा personal projects में साफ़ दिखता है। मैं या तो 10,000 lines का शानदार code खुद लिख सकता हूँ जिसे मैं अच्छी तरह समझता हूँ, या कई गुना तेज़ी से 20,000 lines का समस्याओं से भरा code मोटे तौर पर बना सकता हूँ। मैं खुद इन दोनों के बीच संतुलन खोजने की कोशिश करता हूँ। अगर मैं लगातार development को आगे बढ़ाने की कोशिश करूँ, तो मुझे लगता है कि पहले case में लगाया गया समय आखिरकार नुकसान बन सकता है
मुझे लगता है कि बीच का रास्ता हमेशा होता है। मेरे मामले में मैंने AI को actual code generation सिर्फ self-contained code, जैसे Bash और Python scripts, तक सीमित रखा है। ये scripts सिर्फ command line से interact करती हैं, इसलिए इनकी boundary साफ़ होती है और इन्हें manage करना आसान था। ऐसा code लिखने के बाद मैंने फिर कभी नहीं देखा। लेकिन core business-domain code को AI से generate कराने का ज़्यादा मतलब नहीं लगता, इसलिए ऐसा नहीं करता। वैसे भी code review करना ही पड़ता है, और असल में मुझे तभी फ़ायदा है जब मैं code की maintainability verify कर सकूँ। अगर code को सीधे फेंक देना हो या बस हल्का-सा review करना हो, तभी code generation tools काम के हैं। अगर AI product owner की भूमिका निभाकर असली business loss को समझ सके और उसे सुधार भी सके, तब बात अलग होगी, लेकिन तब तो users के गायब हो जाने के risk की भी चिंता करनी पड़ेगी
जब-जब मैंने AI पर बहुत ज़्यादा code के लिए भरोसा किया, तब-तब मुझे किसी न किसी दिन खोई हुई productivity की भारी कीमत चुकानी पड़ी। अगर सब कुछ vibe coding (यानी उस समय AI से मनमाफ़िक बनवाना) से बना app हो, तो शायद सबसे ज़रूरी skill यह तय करना होगा: “क्या सच में यह feature चाहिए भी था?” Spaghetti code को debug करते समय अगर यह भी समझ न आए कि हर line क्या कर रही है, तो वह सचमुच बेहद तकलीफ़देह होगा
तुमने कहा कि पहले मामले में समय खोया, लेकिन दूसरे मामले में भी (खराब code, कम समय) अंततः समय की हानि ही है। मुझे लगता है कि असल बात वही बीच का संतुलन खोजने में है
छोटा, लेकिन गलत नाम वाले variables या बहुत clever code, अक्सर लंबे लेकिन अच्छी तरह documented और स्पष्ट variable names वाले code से कहीं बदतर होता है। Debt आखिरकार उस समय के अनुपात में है जो code को समझने, बदलने और बढ़ाने में लगता है। Lines of code debt को पूरी तरह मापने वाला metric भी नहीं है। अगर सच में बाकी सब कुछ समान हो, तो code कम करने से readable code की क़ुर्बानी हो सकती है और debt उल्टा बढ़ सकता है। इसलिए मुझे लगता है कि 'the absence of theory is debt' वाला दावा ज़्यादा सही है। बल्कि short code खुद LLM के नज़रिए से debt हो सकता है। वजह यह है कि LLM का उपयोग theory building को कम करता है, और मौजूदा स्थिति में AI खुद project के बारे में theory बनाकर उसे engineer तक सही ढंग से पहुँचा नहीं पाता, इसलिए यह बात और भी सही लगती है
मुझे programming को theory building की प्रक्रिया के रूप में देखना पसंद है। खासकर business programs में यह theory business-centric होनी चाहिए। उदाहरण के लिए, "क्या इस codebase के लिए developers को आसानी से hire किया जा सकता है", "business model कितना stable है", और "हर feature की business importance क्या है" — ये नज़रिए ज़रूर शामिल होने चाहिए
अचानक एक idea आया। क्या AI से code के अंदर variables के names या functions के descriptions के बारे में पूछा जा सकता है? मैंने अब तक AI को सिर्फ code generation के लिए ही इस्तेमाल किया है
जिन कंपनियों में मैंने लंबे समय तक काम किया, उनमें कुछ ऐसी भी थीं जिनकी अपनी code assets लगभग नहीं थीं, लेकिन उनका core business external 3rd party enterprise services पर निर्भर था। यहाँ सवाल यह है कि ऐसे मामले में वास्तव में कितने code का हिसाब कैसे लगाया जाए? उदाहरण के लिए, अगर हम किसी legacy SaaS provider पर निर्भर हैं, तो क्या उनकी lines of code को भी हमारे debt का हिस्सा मानना चाहिए?
मेरे हिसाब से 3rd party services पर निर्भर होने का सबसे बड़ा risk यह है कि वे बंद हो जाएँ, या acquisition/merger के बाद service terms बदल जाएँ। अक्सर हम ऐसी services इस्तेमाल करने को मजबूर होते हैं जो सिर्फ बड़े funding वाले startups चलाते हैं, लेकिन जिनका business अभी सही मायने में self-sustaining नहीं होता
इस बात से पूरी तरह सहमत हूँ। एक पुरानी कंपनी में हमने email marketing SaaS इस्तेमाल किया था। हमारा integration code सिर्फ 500 lines का था, लेकिन service में इतनी समस्याएँ थीं कि आग बुझाने में बहुत मशक्कत करनी पड़ी। आखिर में हमने सिर्फ अपने ज़रूरी features को फिर से implement करके in-house ले लिया, और लागत व मेहनत दोनों में बहुत बचत हुई, जबकि code lines लगभग 3,000 बढ़ गईं
ठीक से समझ नहीं आ रहा।
यह तो साफ़ है कि code एक asset है, लेकिन hardware की तरह इसकी value भी कई कारणों से depreciate होती है — defects, software/hardware industry में बदलाव वगैरह। Software code जितना बढ़ता है, हर साल उसका depreciation cost भी बढ़ता है। अगर पर्याप्त management न हो (जैसे developers की संख्या के मुकाबले code बहुत ज़्यादा हो), तो बाद में issues ठीक करने की cost exponential रूप से बढ़ सकती है। यानी depreciation की अवधारणा पर मानो 'interest' भी लग जाता है। इसलिए 'debt' शब्द का इस्तेमाल समझ में आता है, लेकिन यह पूरी तरह मेल खाने वाला concept नहीं है
जाहिर है सबसे परफ़ेक्ट repository तो यही है
पहले मैं महीने में minus 20,000 lines code delete करने को अपनी उपलब्धि मानता था। कुछ साल पहले 20 remote developers की टीम के साथ वही दोबारा करने की कोशिश की, लेकिन pull requests की बाढ़ आ गई और उनका साथ देना असंभव हो गया। अब मैं Claude Code और GPT के साथ pair programming करता हूँ, और यह पूरी तरह दूसरे वाले अनुभव जैसा लगता है। मुझे यहाँ smart refactoring का मौका दिखता है। लेकिन शायद और context की ज़रूरत है। Cursor और Claude opus 4.1 के साथ legacy code पर यह आज़माया, लेकिन 10 लाख tokens भी कम पड़े। सोच रहा हूँ कि शायद personal LLM और shared LLM के बीच translation जैसी कोई परत हो सकती है; क्या किसी के पास ऐसा अनुभव है?
ऐसा लगता है कि लगभग कोई भी यह बहुत महत्वपूर्ण सवाल नहीं पूछता: "Feature X को पूरी तरह implement करने के लिए बिल्कुल न्यूनतम code कितना होना चाहिए?" बेशक इसका सटीक जवाब देना संभव नहीं, लेकिन सिर्फ इस तरह सोचना भी एक efficient mindset देता है। दूसरी ओर, लोग formal verification जैसी चीज़ों में दिलचस्पी लेते हैं जिनकी व्यावहारिक अहमियत अक्सर कम होती है। अगर minimum viable code size पर विचार न किया जाए, तो formal verification उल्टा wasteful और meaningless हो सकती है। और आमतौर पर लोग मान लेते हैं कि engineers द्वारा लिखा गया code सब अच्छा होता है, जबकि हक़ीक़त में उसका बड़ा हिस्सा अनावश्यक abstraction और complexity जोड़कर काम और बढ़ा देता है। Software engineering का बड़ा हिस्सा वास्तव में minus value हो सकता है। बेशक इसमें plus और minus दोनों मिले-जुले होते हैं, इसलिए फैसला और भी कठिन हो जाता है