- LLM coding tools की बार-बार होने वाली गलतियों का समाधान यह बताना कि इंसान सब कुछ review कर लेंगे, code review की processing limits के कारण गुणवत्ता और उत्पादकता दोनों की गारंटी देना कठिन बनाता है
- अनुभवजन्य शोध के अनुसार प्रभावी review की ऊपरी सीमा एक बार में लगभग 1 घंटा·400 LOC है; इससे आगे थकान और एकाग्रता घटने से defects पकड़ने की प्रभावशीलता तेजी से कम होती है
- यह मानक लागू करने पर LLM द्वारा लिखे हर 400 LOC के लिए किसी skilled developer की 1 घंटे की केंद्रित review चाहिए, इसलिए वास्तविक दैनिक throughput 1,000 LOC से कम हो सकता है
- शुरुआती प्रमाण बताते हैं कि इंसान LLM-generated code में कम defects ढूंढते हुए भी अधिक मजबूत confidence दिखाते हैं, इसलिए केवल review से errors पर्याप्त रूप से छांटे जा सकते हैं, ऐसा मानना कठिन है
- LLM code की defect detection rate, review speed और daily sustainable volume को सीधे मापने और reproduce करने वाला empirical research होना चाहिए, तभी tools की effectiveness को anecdotes नहीं बल्कि evidence के आधार पर आंका जा सकेगा
LLM coding tools को संदेह की नजर से देखने के कारण
- समस्या का केंद्र intellectual property rights, ecological cost, resource consumption या यह आकलन नहीं है कि LLM outputs पूरी तरह खराब हैं
- मौजूदा scientific evidence के आधार पर यह पुष्टि करना कठिन है कि LLM coding tools developers को code बेहतर या तेज लिखने में कैसे मदद करते हैं
- समर्थन में दिए गए तर्क संबंधित समस्याओं और evidence से सीधे नहीं निपटते, और skepticism के जवाब कभी-कभी समस्या को और मजबूत कर देते हैं
- लगभग 1 साल पहले लिखे गए लेख में अब लगभग replace हो चुके Coding Assistants शब्द का उपयोग है, लेकिन generative AI के विभिन्न coding use cases को समेटने वाला दूसरा शब्द न मिलने के कारण इसे ज्यों का त्यों रखा गया है
‘intern’ analogy और full review वाला समाधान
- LLM coding tools में operating structure और interaction interface जैसे कारणों से error risk अपेक्षाकृत अधिक होता है
- hallucinations या typos बना सकते हैं
- request से असंबंधित result दे सकते हैं या काम किसी अलग path से आगे बढ़ा सकते हैं
- users ऐसे tools की तुलना अक्सर intern से करते हैं
- यह अपेक्षा रखनी चाहिए कि result कुछ हद तक गलत होगा
- यह मानना चाहिए कि tool ठीक से समझे बिना काम कर रहा है कि वह क्या कर रहा है
- आम तौर पर अपनाया जाने वाला response है कि intern या junior developer के code की तरह किसी skilled व्यक्ति से output की पूरी review कराई जाए
- यह इस premise पर आधारित है कि इंसान बेहतर जानते हैं और अंतिम जिम्मेदारी भी उन्हीं की है
- इसके साथ यह logic भी आता है कि codebase में जाने वाला हर code वैसे भी review के दायरे में आता है
LLM supervision के लिए जरूरी review level
- industry और research literature में review कई अलग-अलग practices को समेटता है
- हल्का और कई लोगों में distributed review changes से जुड़ा knowledge share करने और surface-level rules लागू करने में उपयोगी है, लेकिन LLM code को supervise करने के standard के रूप में पर्याप्त नहीं है
- पुराने committee-style inspection की तरह कई घंटों तक हर line को दर्दनाक ढंग से check करने की जरूरत नहीं, लेकिन काफी गहरी और पूरी code review चाहिए
- LLM complex code लिख सकता है और software की details में defects छिपे हो सकते हैं, इसलिए केवल हल्की checking पर्याप्त नहीं है
code review के सामने आने वाली empirical limits
- empirical research में प्रभावी review की मुख्य limits ये पाई गई हैं
- एक review session 1 घंटे से ज्यादा हो जाए तो वह बहुत लंबा हो जाता है
- उस समय में प्रभावी रूप से review की जा सकने वाली मात्रा अधिकतम लगभग 400 LOC है
- 1 घंटे से ज्यादा की review में code size चाहे जो हो, effectiveness तेजी से घटती है
- सिर्फ इसलिए नहीं कि अधिकांश code पहले ही review हो चुका होता है
- 1 घंटे तक उच्च concentration बनाए रखने से fatigue और boredom आता है, इसलिए break की जरूरत पड़ती है
- 1 घंटे के sessions के बीच जरूरी recovery time पर कोई study नहीं मिली
- extreme upper limit के तौर पर दिन में कुछ बार मान सकते हैं
- औसत संभव संख्या के रूप में दिन में लगभग 2 बार सुझाया जाता है, लेकिन यह कोई पक्का आंकड़ा नहीं है
- प्रति घंटे review की जा सकने वाली code lines code के context और type, reviewer के experience और knowledge के आधार पर काफी बदलती हैं
- यह absolute standard नहीं है, लेकिन 400 LOC/H से तेज review द्वारा defects को प्रभावी रूप से ढूंढकर mark करने के उदाहरण empirical data में बहुत कम हैं, इसलिए इसे effective maximum speed माना जा सकता है
LLM code पर लागू throughput calculation
- LLM code की समस्या को review से हल करना हो तो best case में भी generated हर 400 LOC पर skilled developer का 1 घंटा चाहिए
- developer के लिए allowed review sessions लगभग 10~40 प्रति सप्ताह हैं, और हर session के बीच अज्ञात length का recovery time चाहिए
- recovery time कम से कम 1~2 घंटे हो सकता है, लेकिन इसका समर्थन करने वाली direct research नहीं है
- यह focus time meetings, design, incident response और खुद लिखे जाने वाले code पर सोचने में भी लगना चाहिए
- best case में LLM इस्तेमाल करने वाला developer रोजाना हजारों LOC लिख, review और commit कर सकता है
- realistic scenario में daily throughput 1,000 LOC से कम हो सकता है
- इसमें boilerplate, tests, migrations और configuration files सब शामिल हैं
- एक single test file भी 400 LOC से ज्यादा हो सकती है
- सबसे अच्छे हालात में भी, जब code का अधिकांश हिस्सा simple और review करने में आसान हो, review productivity gains की upper bound बन जाता है
human code और LLM code की review में फर्क
- मौजूदा evidence उन situations से आया है जहां human reviewers इंसानों द्वारा लिखे code के defects ढूंढते हैं; इसका same efficiency LLM code पर लागू होती है, इसका evidence नहीं है
- शुरुआती evidence में LLM-generated code review करने वाले लोगों ने कम defects पाए, लेकिन सभी defects पा लेने का confidence अधिक दिखाया
- human author और human reviewer के combination की तुलना में LLM coding tool और human reviewer का combination lower-quality result बना सकता है, फिर भी बाद वाले reviewer अपने performance को higher rate कर सकते हैं
- full review न सिर्फ LLM की productivity advantage को limit करती है, बल्कि frequent errors को वास्तव में solve करती है, इसका solid evidence भी कम है
defects fix करने से पहले ही आने वाली cost
- इस calculation में पाए गए defects को fix करने की cost शामिल नहीं है
- यह केवल professional developers की work environment में code review करने और issues mark करने की capability और cost पर बात करता है
- LLM द्वारा बनाए गए defects की संख्या या severity चाहे जो हो, generated code review करने की cost आती ही है
- अगर LLM coding tools बहुत high-quality code भी बनाएं, तब भी हर output review करने की शर्त में वही cost और productivity limit रहती है
review करने में कठिन code सौंपने का विरोधाभास
- LLM समर्थक यह बात advantage के रूप में रखते हैं कि tool इंसानों के लिए लिखने में painful code को produce कर सकता है
- एक case आगे से जरूरी Bash code का 100% LLM से लिखवाने का सुझाव देता है
- shell scripts में parsing loose होती है और meaning बहुत ज्यादा overlapped होता है, इसलिए punctuation की एक typo harmless भी हो सकती है और पूरे computer को delete करने जैसे result तक ले जा सकती है
- ऐसा code errors बनाने में आसान और समझने व review करने में कठिन होता है, और fatal mistakes को notice करना भी मुश्किल होता है
- random errors करने वाले tool को सबसे कठिन-to-review code सौंपकर यह कहना कि इंसान check कर लेंगे, पहले यह साबित नहीं करता कि LLM output वास्तव में effective review target है
- review errors को solve करती है या पर्याप्त productivity gain बचता है, इसका जवाब दिए बिना सबसे difficult-to-review code को representative use case बनाना ही समस्या है
जिन empirical tasks को validate करना होगा
- पहला task यह measure करना है कि human reviewers LLM-generated code के defects कितनी अच्छी तरह ढूंढते हैं
- defect detection capability
- review speed
- एक दिन में sustainable review volume
- इंसानों द्वारा लिखे code पर studies की तरह humans द्वारा LLM code review करने का data चाहिए
- मौजूदा experiments और empirical data scale और context में सीमित हैं, इसलिए और replication studies जरूरी हैं
- मौजूदा scientific data इस ओर इशारा करता है कि इंसान LLM outputs को अच्छे से review नहीं कर पाते या उनकी problems detect करना कठिन है
- यह LLM के detection से बचने के लिए trained होने की property से मेल खा सकता है
- यह भी verify करना होगा कि existing results संयोग तो नहीं थे
- दूसरा task यह confirm करना है कि LLM-generated artifacts की review human-written artifacts की review से qualitatively different problem है या नहीं
- अगर फर्क इतना बड़ा है कि existing code review research लागू ही न हो, तो मौजूदा आलोचना का logic टूट सकता है
- हालांकि शुरुआती evidence बताता है कि LLM-generated code की review आसान से ज्यादा कठिन हो सकती है, और ऐसा हुआ तो criticism उल्टे और मजबूत होगा
anecdotes नहीं, professional tools की empirical evaluation
- code review के बारे में ज्ञात facts को देखते हुए, current interfaces और processes इस्तेमाल करने वाले LLM tools professional developers को क्या benefit देते हैं, यह verify करना कठिन है
- vendors द्वारा evidence से टकराने वाले tools और procedures बार-बार देने से भी ज्यादा frustration इस attitude से है कि skeptics को समस्या से निपटे बिना abnormal माना जाता है
- TDD, type systems, testing·development organization separation, CI/CD, DevOps में भी empirical evidence की तुलना में anecdotes के हावी होने का pattern बार-बार दिखा है
- “इस बार मेरे लिए काम किया” जैसे cases पर निर्भर होने के बजाय, code review का empirical basis जिस तरह बना, उसी तरह real research करनी चाहिए
- LLM coding tools को professional development tools की तरह treat करना है, तो ergonomics और empirical evidence के केंद्र में रखकर effectiveness और limits validate करनी होंगी
1 टिप्पणियां
Lobste.rs की रायें
सिर्फ़ speed ही एकमात्र लक्ष्य होना ज़रूरी नहीं है। bug fix को अलग तैयारी commit के रूप में निकालकर स्वतंत्र रूप से review किया जा सकता है, ऐसे type structure को सुधारा जा सकता है जो गलत state को व्यक्त कर सके, और अगर test reliability कम हो तो property-based testing·fuzzing·formal methods आज़माए जा सकते हैं
पहले ऐसे काम एक ही commit में ठूँस दिए जाते थे या technical debt TODO के रूप में छोड़ दिए जाते थे, लेकिन अब इन्हें ठीक से implement करने की marginal cost हैरान करने वाली हद तक कम हो गई है। LLM एक खुला tool है, इसलिए यह उपयोगकर्ता जिन मूल्यों को महत्व देता है उतनी ही उपयोगिता लौटाता है
हाँ, ऐसे prototype बढ़ने का जोखिम भी है जो अधूरे रह जाएँ और production तक न पहुँचें, लेकिन कुल मिलाकर rigor को महत्व देने वाली engineering के लिए यह बहुत मददगार है
यह शायद company culture की समस्या हो, लेकिन निराशाजनक है, और उम्मीद है कि industry संभले और बेहतर quality का software बनाए
अगर पुराने project में agent को एक single prompt के साथ लगा दें, तो वह बिना बहुत मेहनत के लगातार असली bug ढूँढ लेता है। इंसान भी ढीले होते हैं और मुझसे भी गलतियाँ होती हैं, लेकिन LLM तेज़ होने के साथ कई मायनों में ज़्यादा मूर्ख है, इसलिए उसकी समस्या बस जल्दी सामने आ जाती है
गलतियाँ जमा होती जाती हैं, इसलिए अगर agent को बिना सोचे code बदलने दिया जाए तो चीज़ें जल्दी बिगड़ती हैं, लेकिन सिर्फ़ इसलिए कि naive usage अस्थिर है, tool को ही बेकार मान लेना भी आलसी निष्कर्ष है
अब हर बदलाव पर architecture, maintainability, reliability·security आदि शामिल करते हुए 5 विशेषज्ञ reviews अपने-आप चलाए जाते हैं, और design document प्रणाली में व्यवस्थित करके agent के decision-making को काफ़ी बेहतर बनाया जा रहा है। यह perfect नहीं है, लेकिन naive तरीके से बेहतर है, और इसमें और सुधार की गुंजाइश होना भी नए tools के साथ काम करने का मज़ेदार हिस्सा है
prompt से तेज़ी से generate कर लेने पर भी verify और समझने में ज़्यादा समय लगता है, तो सोचने पर मजबूर होना पड़ता है कि क्या शुरू से खुद लिखना तेज़ होता। कौन-सा विकल्प बेहतर है, यह तय करने में भी समय और ऊर्जा लगती है, और मैं वह संसाधन कहीं और लगाना चाहता हूँ
फिर भी अगर PR submit करने वाला ownership और responsibility लेता है, तो LLM का उपयोग हुआ या नहीं, इससे फ़र्क नहीं पड़ता। अगर quality·accuracy·consistency के मानक पूरे होते हैं, तो तेज़ तरीका चुना जा सकता है, और ज़िम्मेदारी इंसानी लेखक पर ही रहती है
व्यक्तिगत रूप से AI सीखने और समझ को चौड़ा व गहरा करने में अच्छा है, लेकिन input time ही नहीं बल्कि पूरी प्रक्रिया को देखें तो अभी भी सीधे code लिखना ज़्यादा productive है
समस्या की शुरुआत ही इस बात से है कि लेख लगभग 1 साल पहले लिखा गया था। पिछले 6 महीनों में, खासकर पिछले 3 महीनों में, नवीनतम paid cloud models की उपयोगिता काफ़ी बढ़ी है
audit काम में विकसित किए गए MFIC सिद्धांत की तरह यह देखना चाहिए कि क्या पूरे failure category को रोकने वाले control mechanisms मौजूद हैं: https://gist.github.com/pmarreck/b30aa3ca69cb70a5526f8a63ab8c8d7e
ऐसे tools भी चाहिए जैसे https://github.com/pmarreck/dirtree और https://github.com/pmarreck/codescan, जो existing code और project structure को context में बनाए रखते हैं, और यह उन human developers के लिए भी उपयोगी है जो codebase भूल गए हों या उससे परिचित न हों
आखिरकार या तो इसे ठीक से इस्तेमाल कर लाभ उठाया जा सकता है, या फिर खुद custom code लिखते हुए bug और security vulnerability भी बनाई जाएँ और तेज़ competitors से पीछे छूट जाएँ। Desk.com के बंद किए गए million-line Ruby on Rails codebase पर 2 person-years बिताने के नाते, enterprise code अस्थायी होता है, इसलिए यह LLM-generated code के साथ अच्छी तरह फिट बैठता है
अगर Erlang internals हों तो उस पर भरोसा करना मुश्किल होगा, लेकिन function unit के स्तर पर लिखवाकर review तो किया जा सकता है, और कभी-कभी यह उम्मीद से बेहतर भी होगा। knitting needle और loom में से सिर्फ़ एक चुनने के बजाय, स्थिति के हिसाब से दोनों का इस्तेमाल करना आदर्श है
अपने व्यक्तिगत अनुभव और आसपास के भरोसेमंद skilled developers को देखकर, LLM ने बार-बार बेहतर और तेज़ coding संभव बनाई है, इसलिए यह कहने वाले लेख को गंभीरता से लेना मुश्किल है कि scientific evidence के आधार पर यह मददगार नहीं हो सकता
peer-reviewed paper न भी हों, मैंने काफ़ी कुछ देख लिया है, और सिर्फ़ एक METR study अगर developers की productivity बढ़ने के अनुमान का विरोध करती है, तो भी मैं अपना मौजूदा निष्कर्ष नहीं बदलूँगा
अगर rigorously और methodologically sound तरीके से यह दिखाया जाए कि यह मौजूदा मज़बूत empirical research से कहाँ अलग है, तो मैं अपना विचार बदलने को तैयार हूँ। लेकिन सिर्फ़ व्यक्तिगत अनुभव या बिना व्याख्या वाली दर्जन भर anecdotes काफ़ी नहीं हैं
science और engineering ने अरबों लोगों का जीवन बेहतर किया है, और सिर्फ़ इसलिए कि किसी को लगता है कि वह इससे बेहतर जानता है, इसे छोड़ा नहीं जा सकता
किसी को cult member कहना मक़सद नहीं है, लेकिन अपने विश्वास को चुनौती दिए जाने को निजी तौर पर लेना, जबकि दूसरों को मनाने का तरीका न जानना, cult groups की communication style से मिलता-जुलता है
ज़्यादातर LLM से बने PR में भी submitter को ज़िम्मेदारी लेनी चाहिए, और उन्हें ऐसे context और size में बाँटना चाहिए जिन्हें दूसरे आसानी से समझ सकें। code अब भी software की अंतिम specification है, और यह तथ्य नहीं बदला कि developers को उसका ownership लेना और उसे समझना चाहिए
1 साल पहले AI agent बहुत गलतियाँ करते थे, यह दावा सही है, लेकिन आज भी ऐसा है या नहीं यह स्पष्ट नहीं, और पिछले साल नवंबर के आसपास frontier models का inflection point महसूस हुआ था
यह सच है कि LLM code की मात्रा बढ़ाकर review क्षमता पर नया दबाव डालते हैं, लेकिन engineers को इस पर ब्रेक लगाना चाहिए और यह सुनिश्चित करना चाहिए कि review की मात्रा वास्तविक processing capacity के अनुरूप रहे
इससे भी बुरी बात यह है कि नया code ज़्यादातर काम करता है, इसलिए बिना cleanup के merge हो जाने की संभावना ज़्यादा रहती है
frontier models जब भारी मात्रा में code लिख रहे हैं, तब यह गंभीरता से न परखना अजीब है कि negative contribution के रूप में code हटाने का सुझाव दिया जाए। “The Best Code is No Code At All” - Jeff Atwood की तरह, अगर abstraction layers से फूले हुए codebase की complexity सुलझाकर lines delete करने का सुझाव दिया जा सके तो वह नया और दिलचस्प होगा
शायद यह पहले से संभव हो, लेकिन मैंने अभी तक इसे सीधे नहीं देखा है
सुधार करूँ तो “The Limits Of Reviews” खंड में efficient maximum speed 400 lines per hour बताई गई थी, न कि जैसा मैंने पहले सोचा था 400 lines per review
फिर भी अब भी जिज्ञासा है कि 1 घंटा और 400 lines वाला यह आँकड़ा आखिर किस code review paper से आया था। अगर paper का नाम अलग से नहीं रखा है, तो उसे दोबारा ढूँढने में बहुत समय खर्च करने की ज़रूरत नहीं है
मैं अभी यात्रा पर हूँ, इसलिए कुछ दिनों बाद फिर याद दिलाएँ
अगर 40 घंटे के सप्ताह में review का हिस्सा 25% हो, तो लगभग 540 lines per hour, 15% हो तो 900 lines, और 5% हो तो 2,700 lines बनती हैं। वास्तविक throughput 500~1,000 lines per hour के आसपास लगता है, जो बिना source वाले आँकड़े के कुछ हद तक क़रीब है
यह तर्क समझना मुश्किल है कि AI-generated code को human-written code की तुलना में ज़्यादा या कम review किया जाना चाहिए। approval criteria एक जैसे हैं, इसलिए उसी स्तर पर review किया जाता है