- LLM एजेंट्स ढीली spec के साथ code generation में मज़बूत हैं, लेकिन production-grade backend के लिए ज़रूरी API contracts, architecture, DB और ORM constraints का पालन करने में अभी भी कमज़ोर हैं
- एक ही OpenAPI spec के साथ functional requirements को स्थिर रखा गया, और 8 web frameworks के 80 greenfield tasks तथा 20 feature implementation tasks पर वही behavioral tests लागू किए गए
- non-functional constraints को framework selection, architecture pattern, database backend और ORM integration—इन 4 dimensions में बाँटकर structural complexity के असर को अलग किया गया
- constraint decay वह घटना है जिसमें structural requirements जमा होने पर performance तेज़ी से गिरती है; high-configuration fully specified tasks में assertion pass rate औसतन 30 points गिरा
- failure का मुख्य कारण data layer defects थे, जहाँ गलत query construction और ORM runtime violations एजेंट logic failures के लगभग 45% के लिए ज़िम्मेदार थे
मुख्य समस्या और evaluation setup
- LLM एजेंट्स ढीली spec के साथ autonomous code generation में मज़बूत हैं, लेकिन production-grade backend software के लिए आवश्यक structural constraints का सख्ती से पालन करने की उनकी क्षमता का अभी पर्याप्त मूल्यांकन नहीं हुआ है
- production-grade backend को केवल API contract के अनुसार endpoints ही नहीं, बल्कि architecture patterns, database integration और निर्दिष्ट ORM layer जैसी functional requirements से बाहर की शर्तों को भी पूरा करना होता है
- मौजूदा benchmarks अक्सर ऐसे solutions को भी reward देते हैं जो functional रूप से सही हों लेकिन structural रूप से मनमाने हों, इसलिए constrained multi-file backend development की कठिनाई को वे पर्याप्त रूप से नहीं पकड़ते
- पहले के research ने मुख्य रूप से existing codebase में specific issues को fix करने, natural-language prompts पर आधारित unconstrained generation, single-file solutions, और skeleton code completion पर ध्यान दिया, लेकिन structural constraints के स्तर को व्यवस्थित रूप से बदलने के प्रभाव को नहीं देखा
- एक ही OpenAPI spec के साथ functional requirements को स्थिर रखा गया और सभी conditions में वही end-to-end behavioral tests लागू करके structural complexity के प्रभाव को अलग किया गया
- experiments में 8 web frameworks पर फैले 80 greenfield generation tasks और 20 feature implementation tasks शामिल थे
- non-functional constraints को framework selection, architecture pattern, database backend और ORM integration के 4 dimensions में बाँटा गया
- baseline condition में केवल वही API spec दी गई, जबकि constrained conditions में clean architecture, PostgreSQL और SQLAlchemy जैसी requirements जोड़ी गईं
- evaluation में end-to-end behavioral tests और static validators दोनों का उपयोग किया गया, ताकि functional correctness और structural compliance को अलग-अलग मापा जा सके
प्रमुख परिणाम और उनका अर्थ
- constraint decay को ऐसी घटना के रूप में पहचाना गया जिसमें structural requirements बढ़ने के साथ एजेंट performance में बड़ी गिरावट आती है
- high-performing configurations में भी baseline condition से fully specified tasks तक जाते हुए assertion pass rate औसतन 30 points गिरा, और कुछ कमज़ोर configurations लगभग 0 के करीब पहुँच गईं
- एक ही API contract होने पर भी frameworks के अनुसार success rate में बड़ा अंतर था, और एजेंट Flask जैसे हल्के और स्पष्ट frameworks में बेहतर काम करते हैं
- FastAPI और Django जैसे convention-heavy environments में औसत performance काफ़ी कम हो गई
- error analysis में data layer defects मुख्य कारण के रूप में सामने आए, जिनमें गलत query construction और ORM runtime violations प्रमुख थे
- data layer defects को एजेंट logic failures के लगभग 45% का प्रमुख कारण वर्गीकृत किया गया
- functional requirements और structural requirements को एक साथ संतुष्ट करना coding agents के लिए अभी भी एक महत्वपूर्ण unsolved challenge बना हुआ है
- evaluation pipeline, task collection, agent execution trajectories और analysis scripts constraint-decay पर उपलब्ध हैं
1 टिप्पणियां
Hacker News टिप्पणियाँ
मैं LLM code generation को लेकर पूरी तरह संदेह में था, लेकिन अब मेरे काम में इस्तेमाल होने वाले code का 80% से ज़्यादा generated code है
हालांकि इसकी सीमाएँ भी काफी साफ़ हो गई हैं, और कुछ projects में दिखने लगी हैं, और यह लेख जैसे मेरे संदेह की पुष्टि करता है
काम जितना जटिल होता है, उतना ही Markdown specs, rules, skills पर constraints, style guide, boundary conditions, error handling, और optimization guidelines जोड़ते जाना पड़ता है
एक बिंदु पर ऐसा लगता है जैसे programming language की ज़्यादा formal और deterministic दुनिया में मौजूद complexity को natural language की informal और non-deterministic दुनिया में शिफ्ट किया जा रहा है
लिखने की speed में बढ़ोतरी बहुत बड़ी है, और business स्वाभाविक रूप से इसे productivity gain मानता है, लेकिन इसकी कीमत भी साफ़ है, जिसे बहुत लोग नज़रअंदाज़ करते दिखते हैं
कोई भी इन्हें 100% review नहीं करता, और review करे भी तो वह बहुत subjective होता है
“RESTful approach का पालन करो”, “हम REST इस्तेमाल करते हैं, GraphQL नहीं”, और “90% endpoints resource-oriented हैं लेकिन कुछ RPC जैसे दिखते हैं, उन्हें नज़रअंदाज़ करो” — इनके बीच फर्क क्या है, यह धुंधला है
यह सब काफी मूर्खतापूर्ण लगता है
असल में यह undefined behavior से भरा है, लेकिन फिर भी ऐसे programs compile करता है जो ज़्यादातर “काम करते हुए दिखते” हैं
business इसे productivity improvement मानता है, यह सुनकर लगता है जैसे हम फिर उसी दौर में लौट आए हों जहाँ “productivity” को lines of code per second से मापा जाता था
जब codebase context window के पहले 20% के भीतर फिट नहीं होता और एक inference में पूरी तरह repeatable रहने की सीमा से बाहर चला जाता है, तब execution harness और code patch techniques कहीं ज़्यादा महत्वपूर्ण हो जाते हैं
OAI ने model में जिस apply_patch तरीके को refine किया है, वह ultra-large codebase के लिए सबसे अच्छा approach लगता है
line ranges या simple find-and-replace पर आधारित तरीके किनारों पर टूट जाते हैं, और cshtml files जैसे मुश्किल cases को संभालने के लिए multiple spatial anchors की ज़रूरत होती है
prepare/commit behavior, कई बड़ी files में फैले ambiguous context को दोहराते हुए anchors को refine करने के लिए ideal है
LLM कुछ नया बना नहीं सकते
“Systematic research से पता चलता है कि LLM-based coding agents में constraint decay होता है। मौजूदा models unconstrained generation में तो बेहतरीन हैं, लेकिन जब उन्हें explicit architectural rules का पालन करना होता है, तब performance गिर जाती है। end users के लिए इसका मतलब है कि agents तेज़ prototyping के लिए भरोसेमंद हो सकते हैं, लेकिन production-grade backend development के लिए अभी भी उन पर भरोसा करना कठिन है.”
इस study की बड़ी कमजोरी यह है कि cost की वजह से इसने frontier models को पर्याप्त रूप से test नहीं किया, इसलिए specific performance numbers को सावधानी से देखना चाहिए
फिर भी, जब behavior और architecture दोनों सही होने चाहिए, तब model performance गिरती है — यह निष्कर्ष दिलचस्प है और आगे देखने लायक है
अगर सिर्फ functional requirements हों, तो यह एक तरह का program synthesis बन जाता है, और reinforcement learning इसे बहुत मज़बूती से optimize कर सकता है
लेकिन जब functional और non-functional requirements मिल जाती हैं, तो आप असल में model को एक incomplete specification दे रहे होते हैं, और model को blanks भरने के लिए कुछ हद तक user intent का अनुमान लगाना पड़ता है
यही वजह है कि prompt में मनचाहे code style के examples डालना इतना शक्तिशाली होता है
जितनी ज़्यादा reference material होती है, उतना ही वह पहले आई चीज़ों को दोहराने पर निर्भर हो जाता है
यह भी संभव है कि लेखक बाद के chapters में कम ध्यान देते हों और editing में कम मेहनत लगाते हों
Amazon पर इसकी मात्रा बहुत है, लेकिन LLM अभी भी अच्छा लेखन नहीं कर पाते
जब वह incompatible solutions देता है और आप अतिरिक्त context व requirements जोड़ते हैं, तो उसमें मूल architecture पर fixate हो जाने की प्रवृत्ति दिखती है, और वह adapt करने में संघर्ष करता है
कभी-कभी वह चुपके से मूल plan के पक्ष में बदलाव घुसाने की भी कोशिश करता है
ऐसा लगता है जैसे संभावित answer space के बड़े हिस्से unreachable हो जाते हैं
उदाहरण के लिए, करीब एक साल पहले जब image generators पर guardrails लगाए गए, तो सब लोग एक जैसे दिखने लगे, और story generators ने सिर्फ कुछ standard names इस्तेमाल करने शुरू कर दिए
सोचता हूँ कि frontier models में अभी भी ऐसा होता है या नहीं
ऐसे models की weakness analysis में मेरी बहुत दिलचस्पी नहीं है। अनुभव से लगता है कि model को मज़बूत करने और reasoning effort बढ़ाने से कई कमज़ोरियाँ पूरी तरह गायब हो जाती हैं
खासकर तब, जब आप साफ़-साफ़ बता दें कि कौन-सा behavior चाहिए, और acceptance criteria बढ़ने पर failure rate बढ़ना कोई हैरानी की बात नहीं है
स्थिति इससे भी बदतर है। agents सिर्फ “structural constraints” के तहत ज़्यादा संघर्ष नहीं करते, बल्कि जब उन्हीं structural constraints को बदलना ज़रूरी हो तब तो और भी ख़राब साबित होते हैं
जब हम systems या components design करते हैं, तो हम कुछ ideas तय करते हैं जो invariants बन जाते हैं
कुछ invariants बड़े होते हैं, जैसे overall architecture, और कुछ छोटे, जैसे data structure का चुनाव
लेकिन आख़िरकार वह क्षण आता है जब आप ऐसा feature जोड़ना चाहते हैं जो उन invariants से टकराता है
तब आम तौर पर तीन विकल्प होते हैं: feature न जोड़ो, invariant के ऊपर awkward या inefficient तरीके से feature चिपका दो, या वापस जाकर invariant बदलो
आम तौर पर इनमें से सिर्फ एक ही सही होता है, और कम-से-कम एक विकल्प बहुत बुरी तरह गलत होकर खराब नतीजा देता है
agents, constraints follow कर लेने की स्थिति में भी, constraints बदलने का समय कब आ गया है यह पहचानने में बेहद कमजोर हैं
यह pattern recognition और reasoning के बीच की सीमाओं में से एक है, और thought process जैसी marketing claims के बावजूद LLM ज़रा भी reasoning नहीं करते
उन्हें reasoning करता हुआ दिखाने की हर कोशिश, मेरी नज़र में, harness द्वारा बिजली को बोतल में बंद करने जैसी recursive containment effort के काफ़ी करीब है
मुझे हाल की वह पेपर याद आ रही है जिसमें अलग-अलग क्षेत्रों के document editing tasks LLM को सौंपे गए थे https://arxiv.org/abs/2604.15597
उस पेपर में माना गया था कि ज़्यादातर LLMs के लिए programming ही शायद एकमात्र ऐसा क्षेत्र है जहाँ वे errors जमा किए बिना और document को बिगाड़े बिना लंबे क्षितिज वाले काम कर सकते हैं
मैंने इस पेपर का अभी सिर्फ abstract पढ़ा है, लेकिन लगता है कि यह programming को और बारीकी से देखता है और मिलता-जुलता phenomenon दिखाता है
हालांकि यह लंबे क्षितिज वाले task से ज़्यादा, बड़े structural constraints के समूह के लिए एक “लंबे style horizon” जैसा लगता है
संबंधित चर्चा: https://news.ycombinator.com/item?id=48073246
यह बहुत दिलचस्प पेपर है और मैं पूरी तरह सहमत हूँ, लेकिन मुझे नहीं लगता कि यह कोई नई बात है
शुरू से ही यह उम्मीद थोड़ी गलत थी कि किसी agentic coding solution को project पर डालकर उसे tasks की सूची दे दी जाए और वह project के pre-defined constraints को जादुई ढंग से मान लेगा
मुझे नहीं लगता कि कोई भी agentic coding stack default state में यह कर सकता है
Agent को context, constraints और goals को reliably समझने के लिए अभी भी सही mechanism चाहिए, और जिस तरह बड़े AI labs tools·skills·processes को लगातार update कर रहे हैं, उससे साफ है कि यह क्षेत्र अभी भी प्रगति पर है
यह अतिरिक्त layer शायद केवल model और token consumption से कहीं ज़्यादा profitable हो सकती है
मुझे लगता है कि अभी टेस्ट किए गए दिखने वाले open models भी, अगर सही तरह चलाए जाएँ, तो चाही गई constraints का पालन करने वाला production code पहले से बना सकते हैं
जानना चाहूँगा कि पिछले कुछ महीनों में आपका production code कैसा रहा है
मैं लंबे क्षितिज वाली agentic coding पर काफ़ी प्रयोग कर चुका हूँ https://medium.com/@vishvananda/i-spent-2-billion-tokens-wri..., और यह भी देखा है कि कुछ architecture patterns को enforce करने पर agent का performance खराब हो जाता है
अगर constraints को बाद में जोड़ने के बजाय काम के दौरान साथ-साथ डाला जाए तो थोड़ा बेहतर होता है
इसका एक side effect है जिसे मैं कैल्सीफिकेशन कहता हूँ: codebase में कोई pattern दिखना शुरू हो जाए तो agent उसी pattern के पीछे चल पड़ता है, फिर वही context पर हावी होकर खुद को मज़बूत करता रहता है
मौजूदा codebase में यह code quality के हिसाब से ताकत भी बन सकता है और कमजोरी भी
शुरू से architecture guidelines शामिल करके नए codebase runs पूरे हो जाएँ, तो शायद और insights मिलें
साथ ही, जब model के पास implementation को “plan” करने की गुंजाइश होती है तब वह कुछ हद तक modularization ठीक करता है, लेकिन बाद में abstraction मददगार होगी यह खुद समझना उसके लिए दुर्लभ है
नया codebase हो और कई बार दोहराव के बाद, या legacy codebase में डाले जाने पर, यह खास तौर पर दिखता है, और अक्सर विशाल files तक पहुँचता है
जब user इसकी ओर इशारा करता है तो model ठीक से आलोचना करता है, इसलिए जब बात उसके अपने लिखे code की हो तो यह काफ़ी मज़ेदार लगता है
यह “chat जितनी लंबी होती जाती है, guardrails उतने धुंधले लगते हैं” का एक और version लगता है
Context window को पूरा इस्तेमाल न कर पाने की वजह यही है कि आखिर की तरफ output constraints या guardrails का पालन नहीं करता
लेकिन production-grade code को reliably बनाने के लिए model के पास व्यापक awareness होनी चाहिए, और इससे context window बहुत जल्दी भर जाती है
यह कुछ ऐसा है जैसे कहना, “इन 6 directories की हर चीज़ ध्यान में रखकर यह बदलाव करो,” लेकिन सब कुछ ध्यान में रखना ही context window को भर देता है और constraints मानने की क्षमता खो जाती है
लेकिन तब failure mode शायद linting को संतुष्ट करने पर केंद्रित हो जाएगा और requirements धीरे-धीरे भूलने लगेगा
कोशिश/विफलता की पुनरावृत्ति भी context के लिए बिल्कुल अच्छी नहीं होगी
शोध में Python और JS जैसी dynamic type languages का इस्तेमाल किया गया था
मेरे अनुभव में static type codebases इंसानों के लिए भी maintain करना आसान होते हैं, इसलिए agents के लिए भी ऐसा हो सकता है
Go code में Codex या Claude Code इस्तेमाल करते समय मैंने अनगिनत बार देखा है कि agent बदलाव करता है, build चलाता है, errors ढूँढता है, और फिर उन्हें ठीक करता है
आजकल models Python types को काफ़ी अच्छी तरह संभाल लेते हैं
Python में कई सालों से मजबूत static typing एक विकल्प रही है, और वही बस default होनी चाहिए
इसमें “8 web frameworks पर फैले tasks” की बात है; जानना चाहूँगा कि क्या किसी का अनुभव है कि LLM मौजूदा frameworks पर काम करने से बेहतर शुद्ध HTML+CSS+JS बनाता है
हाल में मैंने जो सबसे चौंकाने वाला संयोजन देखा, वह Razor Pages पर JavaScript के साथ progressive enhancement चढ़ाने का था
इस setup में नवीनतम models काफ़ी अच्छी तरह तय कर लेते हैं कि कौन-सा काम server side (cshtml) में होना चाहिए और कौन-सा client side (js) में
मैं यह सलाह दूँगा कि codebase के कुछ हिस्सों को पहले idiomatic रूप में सँवारने में समय लगाएँ, और उन files को example files के रूप में @ से specify करें
यह Markdown से control करने की कोशिश करने की तुलना में कहीं बेहतर काम करता है
FastAPI जैसी चीज़ों में यह काफ़ी ठीक है, लेकिन JavaScript सबसे खराब लगता है
Guidelines और examples देने पर भी यह तय API इस्तेमाल करने के बजाय ढेर सारा बेकार code inline करने की ओर झुकता है