कोड लिखने में इस्तेमाल होने वाले AI coding agents को maintenance लागत घटानी होगी

• नया code लिखने की गति से ज़्यादा maintenance लागत ही लंबी अवधि की productivity तय करती है
• उदाहरण मॉडल में ढाई साल बाद maintenance कुल समय के आधे से ज़्यादा हो जाता है
• अगर AI agent output और maintenance लागत दोनों बढ़ाता है, तो उसका असर जल्दी खत्म हो जाता है
• agent को बंद कर देने पर भी पहले से बने code की अतिरिक्त maintenance लागत बनी रहती है
• अगर output दोगुना है, तो प्रति code maintenance लागत भी आधी होनी चाहिए

---

maintenance लागत productivity तय करती है

• code लिखने में लगाया गया हर समय बाद में लगातार bug fixes, cleanup, dependency upgrades जैसी maintenance का समय पैदा करता है
• फोकस नई features या improvements पर नहीं, बल्कि code के मौजूद रहने तक हर साल दोहराए जाने वाले maintenance पर है
• उदाहरण अनुमान मानता है कि code लिखने के हर 1 महीने पर पहले साल 10 दिन, और उसके बाद हर साल 5 दिन maintenance में लगते हैं
• माना गया है कि Wisdom of the Crowd तरीके से करीब 50 developers से maintenance लागत पूछी जाए, तो काफ़ी सटीक जवाब मिल सकता है
• इस मान्यता पर बने spreadsheet model के अनुसार, नए project के शुरुआती दौर में ज़्यादातर समय feature development में जाता है, लेकिन समय के साथ पुराने code के maintenance का अनुपात बढ़ता जाता है
• इस अनुमान में ढाई साल बाद maintenance पर लगने वाला समय कुल समय के आधे से ज़्यादा हो जाता है, और 10 साल बाद स्थिति ऐसी हो जाती है कि लगभग कोई और काम करना मुश्किल हो जाता है
• अगर maintenance अनुमान को आधा कर दिया जाए, तो 50% बिंदु तक पहुँचने में 3 साल और मिल सकते हैं, और अगर इसे दोगुना कर दिया जाए, तो 1 साल से भी कम समय में productivity 50% से नीचे गिर जाती है
• अगर आप productive team चाहते हैं, तो नए code लिखने की गति से ज़्यादा maintenance लागत पर ध्यान देना चाहिए

मॉडल ग़लत हो सकता है, लेकिन दिशा सही है

• बाद के चरण वाले startups में 5~9 साल बाद ऐसी समस्या दिखी, जहाँ team काम को ठीक से पूरा नहीं कर पाती, और यह graph में दिखने वाले pattern से मिलता-जुलता था
• असली teams graph जितनी खराब नहीं दिखतीं, क्योंकि maintenance लागत कम रही हो सकती है, या समस्या को किसी और तरीके से ढका गया हो सकता है
• संभावित प्रतिक्रियाएँ हैं: हर bug को fix न करना, हर dependency को upgrade न करना, team के धीमा होने पर लोगों को जोड़ना और फिर लगातार और जोड़ते रहना, या सब कुछ छोड़कर दोबारा rewrite करना
• सही संख्याओं पर बहस हो सकती है, लेकिन समय के साथ productivity घटने की बड़ी प्रवृत्ति अनुभवजन्य रूप से सही लगती है

AI coding agents का गुणक प्रभाव

• उदाहरण के लिए माना गया है कि आधुनिक agent-आधारित coding framework Rock Lobster code output को दोगुना कर देता है
• साथ ही यह भी माना गया है कि code थोड़ा और कठिन समझ में आता है, team pull requests से दब जाती है, और approval से पहले code को ठीक से पढ़ा नहीं जाता
• अगर एक महीने में दो महीने जितना code बनता है, और उस output की maintenance लागत भी दोगुनी हो जाती है, तो अगले महीने की maintenance लागत 4 गुना हो जाती है
• इस चरम उदाहरण में Rock Lobster इस्तेमाल करने के लगभग 5 महीने बाद productivity फिर मूल स्तर पर लौट आती है, और कुछ महीनों बाद तो यह बिना इस्तेमाल किए जाने की तुलना में भी खराब हो जाती है
• इसका मतलब यह नहीं है कि AI वास्तव में productivity या maintenance लागत को दोगुना कर देता है; ज़ोर इस बात पर है कि भले maintainability इंसानों के लिखे code जितनी ही हो, productivity का लाभ लंबे समय तक नहीं टिकता

agent को बंद करने पर भी maintenance लागत बनी रहती है

• coding agents की लागत होती है, और जब उनका फ़ायदा उनकी लागत से कम हो जाए, तो पुरानी पद्धति पर लौटने की कोशिश हो सकती है
• agent का इस्तेमाल बंद करने पर productivity का लाभ तो गायब हो जाता है, लेकिन agent से बने code की अतिरिक्त maintenance लागत code के मौजूद रहने तक बनी रहती है
• इस स्थिति में productivity उस स्तर से भी नीचे बँध सकती है, जो agent का इस्तेमाल कभी न करने पर होती

सही बैठने वाला गणित केवल maintenance लागत में कमी है

• LLM जिस अनुपात से code output बढ़ाता है, उसी का सटीक उलटा अनुपात maintenance लागत घटाने में भी होना चाहिए, तभी कुल productivity की गणना सही बैठेगी
• अगर output दोगुना है और उस output की maintenance लागत भी दोगुनी है, तो कुल maintenance लागत 4 गुना हो जाती है
• अगर output दोगुना है, लेकिन प्रति output maintenance लागत वही रहती है, तब भी कुल maintenance लागत 2 गुना हो जाती है
• अगर output दोगुना है, तो maintenance लागत आधी होनी चाहिए; और अगर output तीन गुना है, तो maintenance लागत एक-तिहाई होनी चाहिए
• यही शर्त पूरी होने पर speed का लाभ मिलता है और लंबी अवधि की dependency से भी बचा जा सकता है

मौजूदा coding agents को लेकर चिंता और दूसरे संभावित lever

• Hacker News जैसे sources में ऐसे कई संकेत दिखते हैं कि coding agents maintenance लागत बढ़ाते हैं
• कुछ लोग कहते हैं कि वे बड़े systems को समझने में मदद करते हैं, लेकिन ज़रूरी स्तर की बड़ी maintenance लागत में कमी दिखती नहीं, बल्कि स्थिति उलटी के ज़्यादा करीब लगती है
• मॉडल वास्तविकता को पूरी तरह नहीं दिखाता, लेकिन यह संदेश वैध है कि AI को नए code लिखने की गति के अनुपात में maintenance लागत भी घटानी चाहिए
• अगर coding speed में सुधार चाहा जाए, तो maintenance लागत सुधारने पर भी उतना ही समय देना चाहिए
• यह anti-AI तर्क नहीं है; code की maintainability बढ़ाए बिना भी maintenance काम को अधिक productive बनाने वाले AI जैसे दूसरे lever मौजूद हैं
• अपनी वास्तविक स्थिति के हिसाब से मान्यताओं को बदलने के लिए spreadsheet की copy बनाकर मॉडल के अलग-अलग variables समायोजित किए जा सकते हैं

[GN⁺]

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 दौर से बाहर आ रहा है, वैसे-वैसे यह ठीक-ठीक परिभाषित करना ज़रूरी हो जाता है कि कौन-सा सॉफ़्टवेयर आर्थिक रूप से अस्तित्व में रहने लायक है

  • लोग पहले से ही अपनी मेहनत को investment की तरह देखते हैं, लेकिन इससे समय के साथ debt जमा होने से नहीं रुकता
    सॉफ़्टवेयर में हमेशा कुछ हिस्से ऐसे होते हैं जिन्हें और बेहतर लिखा जा सकता था, और वही debt है
  • क्या यह वही प्रस्तुति है? https://youtu.be/YBZ6JFrfuiM?si=6ZdZph8GxOy-OLHZ जिज्ञासा है, देखना चाहूँगा

• यह एक insightful नज़रिया है और मैं सहमत हूँ
  दुर्भाग्य से maintainability को अक्सर “non-functional requirements” वाली टोकरी में डाल दिया जाता है
  लेकिन maintainability जैसे non-functional requirements को भविष्य की functional requirements की delivery को सुरक्षित रखने और संभव बनाने वाली चीज़ के रूप में देखना चाहिए
  इसे सिर्फ़ इस तरह frame नहीं करना चाहिए कि सॉफ़्टवेयर को क्या करना है बनाम उसे कैसे करना है
  अगर किसी project में लगातार features जोड़ना और सुधार करना महत्वपूर्ण है, तो बहुत छोटे समय को छोड़कर maintainability असल में लगभग functional requirement जैसी हो जाती है

  • मुझे लगता है कि किसी team या organization के लिए non-functional requirements, “technical debt” आदि जैसे मुद्दों से निपटने का पहला और सबसे महत्वपूर्ण कदम है उन्हें अलग नाम न देना
    जैसे ही आप कोई अलग नाम देते हैं, आप कम समझ रखने वाले लोगों को उसे अलग घेराबंदी करके उसकी priority घटाने का बहाना दे देते हैं
    quality महत्वपूर्ण है, और अगर उसे बनाए न रखा जाए तो profit-and-loss statement पर बहुत तेज़ और बहुत ज़ोरदार असर पड़ता है
    इसलिए वह किसी भी दूसरे factor जितनी ही महत्वपूर्ण है
  • “non-functional” शब्द को भूल जाना बेहतर है। जो software काम ही न करे, उसे कौन चाहेगा?
    Kevlin Henney के शब्द operational properties और development properties इस्तेमाल किए जा सकते हैं
    maintainability मूल रूप से development property है
  • सही बात। समस्या यह है कि बहुत-सी software companies असल में अगले quarter से आगे शायद ही सोचती हैं
    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 ही नहीं हैं, या फिर वे सच में इसकी परवाह नहीं करतीं
  • maintenance cost की दलील दोनों तरफ़ काम करती है
    अपना 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 कर सकता हूँ

  • मेरा अनुभव भी कुछ ऐसा ही है, लेकिन अगर सिर्फ़ AI को maintenance assistant की तरह इस्तेमाल किया जा रहा है, तो पता नहीं यह उसी तर्क में आता है या नहीं
    लेख का मूल दावा यह है कि “value-adding” feature development के हर 1 घंटे पर कितने घंटे maintenance करना पड़ता है
    इसलिए पहली बात, सिर्फ़ maintenance cost नहीं मापनी चाहिए बल्कि ratio देखना चाहिए, और दूसरी बात, वह पुराना code मूल रूप से AI द्वारा लिखा ही नहीं गया था
  • सहमत हूँ। AI legacy code से निपटना आसान बना देता है
    लेकिन लेखक की बात शायद यह है कि अगर AI tools की पहुँच खो जाए तो सब कुछ ज़्यादा मुश्किल लगने लगेगा
    जैसे भारी मशीनों से पहाड़ हटाने की आदत पड़ जाए और फिर वापस हाथ के औज़ारों पर आना पड़े
  • AI सहायता के साथ ऐसे बड़े enterprise में, जहाँ लोग बिना समझे codebase के हर हिस्से में code बिखेर रहे हैं, हमारा अनुभव बिल्कुल उलटा है
    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 करना आसान हो

  • code शून्य में मौजूद नहीं होता
    “काम करने वाला” codebase, यानी वह codebase जिसे maintain किया जाता है, असल दुनिया की समस्याएँ हल कर रहा होता है, और ऐसी समस्याएँ हल करना हमेशा साफ़-सुथरेपन से ज़्यादा महत्वपूर्ण होना चाहिए
    साफ़ codebase अक्सर शेल्फ़ पर रखकर सराहे जाने वाले display example बन जाते हैं

• मैं दो बातें जोड़ना चाहूँगा
  पहली, software में सिर्फ़ technical maintenance नहीं होता, user support भी होता है, और software जितना बढ़ता है, यह भी उतना बढ़ता है
  दूसरी, मुझे यक़ीन नहीं कि maintenance cost linear तरीके से बढ़ती है
  भले ही वह linear बढ़े, आख़िरकार एक ऐसा बिंदु आता है जहाँ सारा समय maintenance में ही जाने लगता है

  • क्या आपका मतलब है कि यह linear से भी तेज़ बढ़ती है?
    अगर सिर्फ़ हर हिस्से को नहीं बल्कि हिस्सों के आपसी 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 में दो हिस्सों में बाँटा जा सकता है

  • refactoring को अलग review में किया जा सकता है, और उसके साथ यह नियम रखा जा सकता है कि behavior में कोई बदलाव नहीं होना चाहिए, साथ में “REFACTOR_ONLY:” जैसा tag लगाया जा सकता है
    इससे 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 भी बुरी दिशा में नहीं जाएगा
  • यह code changes की नहीं बल्कि code review tools की समस्या है
  • https://github.com/ReviewStage/stage-cli इस विषय पर एक दिलचस्प शुरुआती बिंदु लगता है

• लेखक शायद इस धारणा से शुरू करता है कि इंसानों को 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 की मदद लेने का मन करता है