कोड लिखने के लिए इस्तेमाल होने वाले AI coding agents को रखरखाव लागत ज़रूर घटानी चाहिए
(jamesshore.com)- भले ही AI coding agents कोड लिखने की गति बढ़ा दें, अगर वे रखरखाव लागत को उसी अनुपात में कम नहीं कर पाते, तो अस्थायी productivity बढ़ने के बाद उल्टा स्थायी productivity गिरावट हो सकती है
- हर कोड लिखे जाने के बाद bug fixes, cleanup, dependency upgrades जैसी लगातार maintenance की मांग करता है, और समय के साथ maintenance कुल काम के समय का अधिकांश हिस्सा ले लेता है
- अगर कोड output 2 गुना हो जाए और maintenance cost भी 2 गुना हो जाए, तो वास्तविक maintenance cost 4 गुना बढ़ती है, जिससे कुछ महीनों में productivity का फायदा खत्म हो जाता है
- AI को हटा देने पर भी पहले से बने कोड का maintenance burden बना रहता है, और स्थिति AI का उपयोग न करने से भी कम productivity पर अटक सकती है
- productivity को 2 गुना बढ़ाने के लिए ऐसा AI चाहिए जो maintenance cost को ठीक आधा कर दे, और coding speed सुधारने जितनी ही मेहनत maintenance cost घटाने पर भी लगानी होगी
रखरखाव लागत ही productivity तय करती है
- कोड लिखने में लगाया गया हर समय बाद में bug fixes, cleanup, dependency upgrades जैसे maintenance time को लगातार पैदा करता है
- यहाँ फोकस नए features या improvements पर नहीं, बल्कि कोड के मौजूद रहने तक हर साल दोहराए जाने वाले maintenance पर है
- उदाहरण के अनुमान में माना गया है कि हर 1 महीने के coding work पर पहले साल 10 दिन, और उसके बाद हर साल 5 दिन maintenance में लगते हैं
- माना गया है कि Wisdom of the Crowd तरीके से लगभग 50 developers से maintenance cost पूछी जाए तो काफ़ी सटीक जवाब मिल सकता है
- इस मान्यता से बने spreadsheet model के अनुसार, नए project की शुरुआत में ज़्यादातर समय feature development में जाता है, लेकिन समय के साथ पुराने code के maintenance का हिस्सा बढ़ता जाता है
- इस अनुमान में ढाई साल बाद maintenance पर जाने वाला समय कुल समय के आधे से ज़्यादा हो जाता है, और 10 साल बाद हालात लगभग ऐसे हो जाते हैं कि दूसरे काम करना मुश्किल हो जाए
- maintenance estimate को आधा कर देने पर 50% वाले बिंदु तक पहुँचने में 3 साल और मिल सकते हैं, और इसे 2 गुना करने पर 1 साल से भी कम समय में productivity 50% से नीचे गिर जाती है
- अगर productive team चाहिए, तो नए code लिखने की speed से ज़्यादा maintenance cost पर ध्यान देना चाहिए
मॉडल ग़लत हो सकता है, लेकिन दिशा सही है
- late-stage startups में 5~9 साल के बाद ऐसी समस्या दिखी कि teams काम ठीक से पूरा नहीं कर पातीं, और यह pattern graph में दिखने वाले रुझान जैसा था
- असली teams graph जितनी बुरी इसलिए नहीं दिखतीं क्योंकि maintenance cost कम रही होगी, या समस्या को किसी और तरीके से ढक दिया गया होगा
- संभावित प्रतिक्रियाएँ हैं: हर bug को fix न करना, हर dependency को upgrade न करना, team के धीमे होने पर लोगों को जोड़ना और फिर और जोड़ते जाना, या सब छोड़कर पूरा rewrite करना
- सटीक संख्याओं पर बहस हो सकती है, लेकिन समय बीतने के साथ productivity घटने का बड़ा रुझान अनुभव के हिसाब से सही लगता है
AI coding agents का multiplication effect
- उदाहरण के लिए माना गया है कि नवीनतम agent-style coding framework Rock Lobster कोड output को 2 गुना कर देता है
- साथ ही यह भी माना गया है कि कोड थोड़ा ज़्यादा समझना मुश्किल हो जाता है, team pull requests से दब जाती है, और approval से पहले code को ठीक से पढ़ा नहीं जाता
- अगर 1 महीने में 2 महीने का code बनाया जाए, और उस output की maintenance cost भी 2 गुना हो, तो अगले महीने की maintenance cost 4 गुना हो जाती है
- इस चरम उदाहरण में Rock Lobster इस्तेमाल करने के करीब 5 महीने बाद productivity फिर मूल स्तर पर लौट आती है, और कुछ महीनों बाद तो बिना इस्तेमाल किए रहने से भी बदतर हो जाती है
- इसका मतलब यह नहीं कि AI सचमुच productivity या maintenance cost को 2 गुना कर देता है; बात सिर्फ़ यह है कि अगर maintainability इंसानों द्वारा लिखे code जितनी भी हो, तब भी productivity का लाभ लंबे समय तक नहीं टिकता
agent बंद कर देने पर भी maintenance cost रहती है
- coding agents की एक लागत होती है, और जब उनका फ़ायदा उनकी लागत से कम लगने लगता है तो पुरानी working style पर लौटने का मन हो सकता है
- agent का उपयोग बंद करने पर productivity gain गायब हो जाता है, लेकिन agent से बने code की अतिरिक्त maintenance cost तब तक बनी रहती है जब तक वह code मौजूद है
- इस स्थिति में productivity उस स्तर से भी नीचे फँस सकती है जो agent का इस्तेमाल कभी न करने पर होती थी
जो गणित सही बैठता है, वह maintenance cost में कमी ही है
- कुल productivity का हिसाब सही बैठाने के लिए LLM जितने अनुपात से code output बढ़ाता है, maintenance cost को ठीक उसके उल्टे अनुपात में घटाना होगा
- अगर output 2 गुना है और उस output की maintenance cost भी 2 गुना है, तो कुल maintenance cost 4 गुना हो जाती है
- अगर output 2 गुना है लेकिन प्रति output maintenance cost समान रहती है, तब भी कुल maintenance cost 2 गुना ही होती है
- अगर output 2 गुना है, तो maintenance cost आधी होनी चाहिए; अगर output 3 गुना है, तो maintenance cost एक-तिहाई होनी चाहिए
- speed gains लेते हुए long-term lock-in से बचने के लिए यह शर्त पूरी करनी होगी
मौजूदा coding agents को लेकर चिंता और दूसरे संभावित leverage
- Hacker News जैसे sources में ऐसे बहुत संकेत दिखते हैं कि coding agents maintenance cost बढ़ा रहे हैं
- कुछ लोगों का कहना है कि वे बड़े systems को समझने में मदद करते हैं, लेकिन ज़रूरी स्तर की बड़ी maintenance cost reduction नहीं दिखती; बल्कि स्थिति उलटी लगती है
- भले ही मॉडल वास्तविकता को पूरी तरह न दर्शाता हो, यह संदेश वैध है कि AI को नए code लिखने की गति के अनुपात में maintenance cost भी घटानी चाहिए
- coding speed सुधारने की कोशिश करें तो maintenance cost सुधारने में भी उतना ही समय लगाना चाहिए
- यह anti-AI तर्क नहीं है; code की maintainability बढ़ाए बिना भी maintenance work को ज़्यादा productive बनाने वाले AI जैसे दूसरे leverage हो सकते हैं
- अपनी वास्तविक स्थिति के हिसाब से assumptions बदलने के लिए spreadsheet की copy बनाकर model के अलग-अलग variables को समायोजित किया जा सकता है
2 टिप्पणियां
AI पर अविश्वास पैदा होने का सबसे बुनियादी कारण यह है कि
फ़िलहाल ज़्यादातर विशेषज्ञ (खुद को ऐसा कहने वाले) यह चिल्लाते फिर रहे हैं कि वे उन AI की कमियों का सामना नहीं कर रहे जिनकी बात दूसरे लोग करते हैं, और कोई trade-off भी मौजूद नहीं है, मानो वे दलालों की तरह बर्ताव कर रहे हों.
पहले ही ठग बहुत बढ़ चुके हैं, इसलिए पूरे क्षेत्र के प्रति अविश्वास जमा हो गया है.
Hacker News की राय
Dconf'24 प्रस्तुति Software as investment में सॉफ़्टवेयर के हर हिस्से के लिए संयोजित किए जा सकने वाले value function पर आधारित एक बुनियादी framework प्रस्तावित किया गया था
इस framework को AI की वजह से ख़ास तौर पर बदलने की ज़रूरत नहीं है, बस maintenance में AI कितना अच्छा है उसके अनुसार cost model अपडेट करना होगा
कहा जाता है कि AI 1.7 गुना ज़्यादा bugs बनाता है, लेकिन शायद उन्हें तेज़ी से ठीक भी कर सकता है, इसलिए पक्का नहीं कह सकता
अगर सॉफ़्टवेयर को investment की तरह देखें, तो “technical debt” की जगह “value” की बात होने लगती है, और debt बस ऐसी asset है जिसकी value 0 से कम है
जैसे-जैसे सॉफ़्टवेयर पुराने high-margin दौर से बाहर आ रहा है, वैसे-वैसे यह ठीक-ठीक परिभाषित करना ज़रूरी हो जाता है कि कौन-सा सॉफ़्टवेयर आर्थिक रूप से अस्तित्व में रहने लायक है
सॉफ़्टवेयर में हमेशा कुछ हिस्से ऐसे होते हैं जिन्हें और बेहतर लिखा जा सकता था, और वही debt है
यह एक insightful नज़रिया है और मैं सहमत हूँ
दुर्भाग्य से maintainability को अक्सर “non-functional requirements” वाली टोकरी में डाल दिया जाता है
लेकिन maintainability जैसे non-functional requirements को भविष्य की functional requirements की delivery को सुरक्षित रखने और संभव बनाने वाली चीज़ के रूप में देखना चाहिए
इसे सिर्फ़ इस तरह frame नहीं करना चाहिए कि सॉफ़्टवेयर को क्या करना है बनाम उसे कैसे करना है
अगर किसी project में लगातार features जोड़ना और सुधार करना महत्वपूर्ण है, तो बहुत छोटे समय को छोड़कर maintainability असल में लगभग functional requirement जैसी हो जाती है
जैसे ही आप कोई अलग नाम देते हैं, आप कम समझ रखने वाले लोगों को उसे अलग घेराबंदी करके उसकी priority घटाने का बहाना दे देते हैं
quality महत्वपूर्ण है, और अगर उसे बनाए न रखा जाए तो profit-and-loss statement पर बहुत तेज़ और बहुत ज़ोरदार असर पड़ता है
इसलिए वह किसी भी दूसरे factor जितनी ही महत्वपूर्ण है
Kevlin Henney के शब्द operational properties और development properties इस्तेमाल किए जा सकते हैं
maintainability मूल रूप से development property है
1~2 साल का product roadmap हो सकता है, लेकिन ईमानदारी से कहें तो ऐसे roadmap कई बार engineering plan से ज़्यादा sales के लिए होते हैं
revenue गिरते ही product और engineering दिशा बदल देते हैं, और company जितनी शुरुआती stage में होती है, यह उतना ज़्यादा होता है
startup mode से बाहर आने के बाद चीज़ों को स्थिर होना चाहिए, लेकिन बहुत-सी companies ऐसा नहीं करतीं और short-term planning का वही pattern दोहराती रहती हैं
नतीजतन product stability low priority पर बनी रहती है
आख़िरकार लगता है कि कई companies के पास अच्छा software बनाने के resources ही नहीं हैं, या फिर वे सच में इसकी परवाह नहीं करतीं
अपना project बनाते समय हमने देखा कि AI तेज़ है, लेकिन AI जो bugs डालता है उन्हें अजीब तरह से पकड़ना मुश्किल होता है
वे obvious bugs नहीं होते, बल्कि 3 हफ़्ते बाद production environment में कुछ टूटता है और trace करने पर पता चलता है कि AI ने किसी subtle हिस्से को ग़लत समझ लिया था
सच कहूँ तो AI maintenance cost कम करने से ज़्यादा cost की जगह बदलता है
लिखने का समय घटता है और review का समय बढ़ता है
AI code ग़लत होने पर भी बहुत fluent और confident होता है, इसलिए उसका review इंसानी code से भी कठिन हो जाता है
net gain होगा या नहीं, यह पूरी तरह इस बात पर निर्भर करता है कि team code लिखने से ज़्यादा उसे पढ़ने में कितनी अच्छी है
मेरे अनुभव में AI maintenance cost कम करता है
लेकिन context महत्वपूर्ण हो सकता है। मैं कई दशकों पुराने projects संभालता हूँ, और नए features का काम भी बहुत है, लेकिन पुराना code और पुराने projects अचानक बहुत ज़्यादा संभालने योग्य और modernize करने में आसान हो गए हैं, और कई मामलों में उन्हें हटाना भी संभव हुआ है
पुराने libraries और build tools की dependencies कुछ मामलों में update हुईं, कुछ में बस हटा दी गईं, और builds तेज़ व developers के लिए आसान हो गए
end-to-end test setup और automation भी बहुत आसान हुए हैं, DevOps भी काफ़ी बेहतर हुआ है, और operational issues की diagnosis भी काफ़ी सुधरी है
logs और information बहुत ज़्यादा हैं, और महत्वपूर्ण चीज़ें पकड़ने के लिए integrated dashboards और monitoring भी है, लेकिन अब लगभग 50 deployed system projects पर मैं पहले से कहीं ज़्यादा analysis कर सकता हूँ
लेख का मूल दावा यह है कि “value-adding” feature development के हर 1 घंटे पर कितने घंटे maintenance करना पड़ता है
इसलिए पहली बात, सिर्फ़ maintenance cost नहीं मापनी चाहिए बल्कि ratio देखना चाहिए, और दूसरी बात, वह पुराना code मूल रूप से AI द्वारा लिखा ही नहीं गया था
लेकिन लेखक की बात शायद यह है कि अगर AI tools की पहुँच खो जाए तो सब कुछ ज़्यादा मुश्किल लगने लगेगा
जैसे भारी मशीनों से पहाड़ हटाने की आदत पड़ जाए और फिर वापस हाथ के औज़ारों पर आना पड़े
deploy होने वाली code lines के साथ incidents बढ़े हैं, और incidents भी लगातार ज़्यादा गंभीर हो रहे हैं
हाँ, हमने पुराने code में बहुत सुधार किया है, ज़्यादा delete भी किया है, code modernization automate कर सकते हैं, problem diagnosis बेहतर हुआ है, और mitigation के options भी बढ़े हैं
लेकिन यह सब मिलकर भी उस भारी पैमाने की भरपाई नहीं कर पाया जिस पर code deploy हो रहा है जबकि उसे कोई ठीक से समझता ही नहीं
हमारी team AI से code जोड़ती भी है, लेकिन उससे पुराना और abandon किया हुआ code आक्रामक तरीके से हटाने का काम भी करती है
“क्या अभी भी कोई इसका इस्तेमाल करता है?”, “इसे call कैसे किया जाता है?” जैसे सवालों के जवाब आसान हो जाते हैं अगर frontend, backend और पूरे codebase को agent के सामने रखकर उससे software project का नक्शा बनवाया जाए
IDE भी single language और आम तौर पर single project के भीतर कुछ हद तक यह कर लेता है, लेकिन RPC या REST जैसी boundaries कई IDE tools को तोड़ देती हैं
मुझे यह सवाल बहुत पसंद आया: अगर चुन सकते, तो आप कैसा codebase चाहते?
थोड़ा सोचने पर शायद आप बहुत ज़्यादा features वाला codebase नहीं चाहेंगे
आप शायद ऐसा codebase चाहेंगे जो अभी वाले से काफ़ी मिलता-जुलता हो, लेकिन समझने में आसान हो, और भविष्य की business problems के हिसाब से maintain और extend करना आसान हो
“काम करने वाला” codebase, यानी वह codebase जिसे maintain किया जाता है, असल दुनिया की समस्याएँ हल कर रहा होता है, और ऐसी समस्याएँ हल करना हमेशा साफ़-सुथरेपन से ज़्यादा महत्वपूर्ण होना चाहिए
साफ़ codebase अक्सर शेल्फ़ पर रखकर सराहे जाने वाले display example बन जाते हैं
मैं दो बातें जोड़ना चाहूँगा
पहली, software में सिर्फ़ technical maintenance नहीं होता, user support भी होता है, और software जितना बढ़ता है, यह भी उतना बढ़ता है
दूसरी, मुझे यक़ीन नहीं कि maintenance cost linear तरीके से बढ़ती है
भले ही वह linear बढ़े, आख़िरकार एक ऐसा बिंदु आता है जहाँ सारा समय maintenance में ही जाने लगता है
अगर सिर्फ़ हर हिस्से को नहीं बल्कि हिस्सों के आपसी interaction को भी maintain करना पड़े, तो ऐसा हो सकता है
AI सच में maintenance cost घटाता है या नहीं, इस बारे में मैंने सबसे मज़बूत संकेत यही देखा है कि developer AI output को draft की तरह लेता है या final deliverable की तरह
जब existing codebase में AI tools का उपयोग unfamiliar modules को समझने, targeted refactoring बनाने या migration scripts लिखने के लिए किया जाता है, तब maintenance burden सच में कम होता है
क्योंकि AI उस code पर काम कर रहा होता है जिसकी architecture मैं पहले से समझता हूँ, इसलिए मैं उसके output को जल्दी evaluate कर सकता हूँ
समस्या तब आती है जब AI ऐसा नया code बनाता है जिसे कोई गहराई से नहीं समझता
फिर उस code को ऐसे लोग maintain करते हैं जिन्होंने उसे न लिखा होता है, न design किया होता है
अगर code किसी दूसरे इंसान ने लिखा हो, तब भी कम-से-कम names, structure और commit history से intent का अनुमान लगाया जा सकता है
AI-generated code में अक्सर ऐसा पढ़ा जा सकने वाला intent नहीं होता, क्योंकि उसका “लेखक” पूरी file में फैला हुआ कोई लगातार intent नहीं रखता
लेख की सही बात यह है कि सिर्फ़ speed नहीं, maintenance cost भी मापनी चाहिए
असल में कुछ दिनों नहीं बल्कि कई महीनों तक AI-assisted code और human-written code के understanding time तथा change failure rate को track करना चाहिए
code review पर भी यही बात लागू होती है
सोचता हूँ कि क्या AI code reviews को देखने में बेहतर बना सकता है
human code reviews में developers जल्दी सीख जाते हैं कि code या comments को reflow करना, ऐसे indentation बदलना जिन्हें tools छिपा नहीं पाते, functions इधर-उधर ले जाना, या lines delete करना जैसी अनावश्यक visual changes से बचना चाहिए
अनावश्यक refactoring भी नहीं करनी चाहिए
शायद review को functional changes और visual changes में दो हिस्सों में बाँटा जा सकता है
इससे review बहुत आसान हो जाता है
review की शुरुआत “कुछ भी नहीं बदलना चाहिए” से होती है, और reviewer pattern matching कर सकता है
वरना reviewer को हर code line फिर से evaluate करनी पड़ती है कि सच में कुछ नहीं बदला, और इसे ठीक से करना बहुत मुश्किल होता है
मैंने जिन version control systems का इस्तेमाल किया है, वे सभी independently reviewed change queues की अनुमति देते थे
अगर development के दौरान refactoring की ज़रूरत हो, तो एक commit push करें, refactor करें, review भेजें, फिर चल रहे काम को rebase करके आगे बढ़ें
अगर “CLEANUP:”, “REFACTOR_ONLY:” जैसे changes लगातार flow में भेजे जाएँ, तो अंतिम बदलाव किसी विशाल monster change की तुलना में बहुत छोटे हो जाते हैं
reviewers इस मेहनत की सराहना करेंगे
ऐसे organization में metrics game भी बुरी दिशा में नहीं जाएगा
लेखक शायद इस धारणा से शुरू करता है कि इंसानों को AI के हर code को विस्तार से review करना चाहिए, और AI की मदद के बिना उसे समझ और maintain भी कर पाना चाहिए
मेरे अनुभव में लोग AI का इस्तेमाल इस तरह नहीं करते
शुरुआत में वे ऐसा करते हैं। जब तक भरोसा न बन जाए, और जब तक वे यह न सीख लें कि मनचाहा परिणाम पाने के लिए prompt कैसे करना है, तब तक वे उबाऊ हिस्सों को automate करने के लिए AI का इस्तेमाल करते हैं, जबकि शुरुआती implementation या patterns इंसान बनाता है और AI खाली जगह भरता है
यह code लिखने के तरीके में किसी बड़े बदलाव से ज़्यादा enhanced autocomplete जैसा है
AI के साथ जितना ज़्यादा काम होता है, लोग AI द्वारा असल में generate किए गए code को लेकर उतना कम चिंतित होते हैं
इसका मतलब यह नहीं कि यह अच्छी बात है। इससे bugs, performance problems और security holes बन सकते हैं
लेकिन वास्तविकता यही है। AI code ने bug बनाया? AI से कहो उसे ठीक करे
AI code फूला हुआ और पढ़ने में मुश्किल है? अगर परवाह है तो AI से कहो उसे ठीक करे। बहुत-से लोगों को परवाह ही नहीं होती
अगर इंसान पूरी तरह code maintenance से बाहर हो जाए, तो maintainable code की ज़रूरत भी ख़त्म हो जाती है
हम अभी 100% वहाँ नहीं पहुँचे हैं, लेकिन उसी दिशा में बढ़ रहे हैं
कई companies के लिए चीज़ें पहले से ही काफ़ी अच्छी हैं, इसलिए risk लेकर YOLO मोड में जाना भी उन्हें ठीक लगता है
व्यक्तिगत रूप से मैं AI-generated code पर इतना भरोसा नहीं करता कि उसे पढ़ूँ ही नहीं, लेकिन मैं हर line भी नहीं पढ़ता
मैं tests को tested code से ज़्यादा ध्यान से देखता हूँ, performance-critical हिस्सों पर ज़्यादा ध्यान देता हूँ, और overall structure को guide करता हूँ
फिर भी अगर चीज़ें standard तक न पहुँचें, तो मैं खुद maintain नहीं करता बल्कि AI से ठीक करने को कहता हूँ
अगर maintenance इतना सस्ता हो जाए, तो maintenance cost मेरी चिंता ही नहीं रहती
यह लेख अच्छी तरह दिखाता है कि AI agents या assistants को सिर्फ़ शुरुआती “नया widget बना दो” वाले हिस्से में नहीं, बल्कि software development के कई हिस्सों में मदद करनी होगी
लेखक का मानना है कि अगर कोई AI agent या assistant को सिर्फ़ नया widget बनाने के चरण में इस्तेमाल करे, तो AI की मदद से ज़्यादा code निकलेगा और इसलिए maintain करने लायक code भी बहुत बढ़ जाएगा
भले ही code quality ऊँची हो, समय के साथ maintenance cost तो आती ही है
लेकिन लेखक जिस समस्या की बात कर रहा है, वह पूरी तरह सबकी साझा समस्या नहीं बल्कि काफ़ी हद तक ख़ुद पैदा की गई समस्या भी लगती है
लेखक द्वारा बताई गई startup स्थिति, यानी “चलो किसी तरह इसे काम करवा दें ताकि market fit मिले और customer पकड़ सकें”, वैसे भी बाद में ज़्यादा maintenance cost लेकर आती रही है
क्योंकि यह कुछ हद तक तर्कसंगत है कि पहले यह देखा जाए कि business है भी या नहीं, और अगर है तो उसे तेज़ी से बढ़ाने के लिए speed के नाम पर quality थोड़ी कम की जाए
और यह भी लगा कि लेखक AI वास्तव में maintenance हिस्से में कैसे मदद कर सकता है, इस पर खुलकर बात करने से हिचक रहा है
इंसानी guidance के साथ AI पुरानी dependencies ठीक करने या झुंझलाहट भरे bugs सुलझाने में बहुत उपयोगी हो सकता है
ऐसे काम software engineers को अक्सर थकाऊ chores जैसे लगते हैं, और यही वह तरह का काम है जिसमें AI की मदद लेने का मन करता है