Constraint Decay: Back End Code Generation में LLM Agents की Fragility

#Introduction

हम सबने वो मैजिक देखा है जब कोई LLM agent कुछ ही सेकंड्स में एक नए फीचर का scaffold तैयार कर देता है। यह boilerplate कोड लिखता है, initial routes सेटअप करता है, और देखने में यह एकदम flawless स्ट्रक्चर लगता है। लेकिन जैसे-जैसे टास्क ज्यादा complex होने लगते हैं, खासकर backend environments में, वो शुरुआती brilliance अक्सर धीमे-धीमे structural chaos में बदल जाती है।

arXiv पर पब्लिश हुए एक नए पेपर, जिसका टाइटल Constraint Decay: The Fragility of LLM Agents in Back End Code Generation है, ने एक ऐसी प्रॉब्लम को फॉर्मलाइज़ किया है जिसे कई senior engineers ने intuitively महसूस किया है: जैसे-जैसे language models लंबी या ज़्यादा complex backend logic जनरेट करते हैं, वे सिस्टम के constraints को फॉलो करना भूलने लगते हैं। इस phenomenon को "Constraint Decay" नाम दिया गया है, और यह production backend systems में autonomous coding agents के इस्तेमाल में एक बहुत बड़ी रुकावट है।

#What Happened: Constraint Decay का Mechanics

इस पेपर के रिसर्चर्स ने complex backend applications जनरेट करने वाले state-of-the-art LLM agents का एक comprehensive evaluation किया। उन्होंने शुरुआत में ही agents को strict constraints दिए—जैसे database schema rules, authentication requirements, strict typing guidelines, और specific architectural patterns।

रिसर्च में उन्हें एक consistent degradation pattern देखने को मिला। Initial generation phases में (जैसे शुरुआत की कुछ फाइल्स को scaffold करना या किसी API endpoint की पहली 50 लाइनें लिखना), agents ने लगभग 100% constraints को फॉलो किया। लेकिन, जैसे-जैसे context बढ़ा और generation task लंबा हुआ, agents में "decay" होना शुरू हो गया।

ऐसा नहीं है कि मॉडल prompt को पूरी तरह भूल गया, बल्कि उसका attention mechanism dilute हो गया। उसने local coherence को ज्यादा प्रायोरिटी देना शुरू कर दिया—मतलब यह ध्यान रखना कि जो लाइनें अभी लिखी जा रही हैं वो सही से compile हों और उनका syntactic सेंस बने—और इसके चक्कर में global constraints पीछे छूट गए। जब तक agent किसी complex transaction के आखिरी हिस्से या किसी secondary helper function तक पहुँचा, तब तक user permissions चेक करने या सही database transaction scopes अप्लाई करने जैसे critical rules चुपचाप इग्नोर कर दिए गए।

#Why It Matters: Backend का Unforgiving Nature

Frontend development में, एक छोटे से hallucination का मतलब हो सकता है कि कोई बटन अलाइन न हो या कलर मैच न करे। लेकिन backend engineering का environment काफी unforgiving होता है। Constraint decay से सिर्फ technical debt ही नहीं बढ़ता, बल्कि इससे immediate और critical vulnerabilities पैदा होती हैं।

जब कोई LLM agent backend में constraint decay का शिकार होता है, तो इसके नतीजे काफी खतरनाक हो सकते हैं:

• Security Breaches: Authorization checks भूल जाना या sanitized input wrappers न लगाना सीधे Insecure Direct Object References (IDOR) या SQL injection जैसी vulnerabilities की वजह बनता है।
• Data Corruption: मल्टीपल database operations को किसी transaction में wrap करना भूल जाने से, अगर कोई प्रोसेस बीच में ही फेल हो जाए, तो database एक inconsistent state में जा सकता है।
• Architectural Drift: Dependency injection rules या domain-driven design boundaries को इग्नोर करने से tightly coupled spaghetti कोड बन जाता है, जिसे बाद में human engineers को बहुत मेहनत से सुलझाना पड़ता है।

Backend systems पूरी तरह से absolute invariants पर टिके होते हैं। कोई agent जो 95% constraint adherence के साथ काम करता है, वो कई बार उस agent से ज्यादा खतरनाक होता है जो पूरी तरह से compile ही न हो। ऐसा इसलिए क्योंकि वो 5% failure rate अक्सर syntactically valid कोड के पीछे छिप जाता है।

#Technical Implications: Agents कहाँ Fail होते हैं

Technical implications को सही से समझने के लिए, चलिए constraint decay का एक concrete example देखते हैं। मान लीजिए कि एक agent को एक user service लिखने का instruction दिया गया है, जिसका constraint यह है: हर data mutation पर एक audit trail log होना चाहिए और user का role verify होना चाहिए।

पहले function में, agent एकदम परफ़ेक्ट परफॉर्म करता है:

// Initial Generation: Constraints fully respected
async updateUserProfile(userId: string, data: Partial<User>, actor: UserContext) {
    if (actor.role !== 'ADMIN' && actor.id !== userId) {
        throw new UnauthorizedError("Insufficient permissions");
    }
    const updatedUser = await this.db.users.update(userId, data);
    await this.auditLog.record('UPDATE', 'User', userId, actor.id);
    return updatedUser;
}

लेकिन, सैकड़ों लाइनें लिखने के बाद, जब वो कोई secondary function जनरेट कर रहा होता है, तो constraint decay साफ़ दिखने लगता है:

// Later Generation: Constraint Decay sets in
async bulkUpdateUserStatuses(userIds: string[], status: string, actor: UserContext) {
    // Missing role verification constraint!
    // Missing audit log constraint!
    return await this.db.users.updateMany({ id: { $in: userIds } }, { status });
}

रिसर्चर्स ने अलग-अलग backend constraints की categories में इन failures को quantify किया। यह decay uniform नहीं होता है; कुछ constraints दूसरों के मुकाबले ज्यादा जल्दी decay होते हैं:

जैसा कि इस टेबल से साफ़ है, basic syntax और typing rules के मुकाबले security और architectural constraints काफी तेज़ी से decay होते हैं, जो एक अलार्मिंग बात है।

#What's Next: AI Agents में Decay को कैसे कम करें

Constraint Decay की फाइंडिंग्स से यह बात साफ़ हो जाती है कि सिर्फ context windows को बड़ा करने से (जैसे 1M+ token contexts पर शिफ्ट होना) यह प्रॉब्लम सॉल्व नहीं होगी। सच तो यह है कि बड़े contexts कई बार attention dilution को और ज्यादा बढ़ा देते हैं।

Reliable backend agents बनाने के लिए, इंडस्ट्री को अपना फोकस architectural solutions की तरफ शिफ्ट करना होगा:

1. Iterative Verification: Agents को "Test-Driven Generation" अप्रोच अपनानी होगी, जहाँ वे हर logical block जनरेट करने के बाद रुकें, और explicit constraint checklists के खिलाफ static analysis और unit tests रन करें।
2. Constrained Decoding: ऐसी strict sampling techniques को इम्प्लीमेंट करना जिससे LLM को ऐसा कोड जनरेट करने के लिए फ़ोर्स किया जा सके जो किसी predefined AST (Abstract Syntax Tree) या schema को फॉलो करे। इससे architectural drift के चांसेस कम हो जाते हैं।
3. Modular Agent Workflows: किसी एक omnipotent agent से पूरी सर्विस लिखवाने के बजाय, टास्क को heavily scoped रखना चाहिए। एक agent logic लिखे, एक specialized "Security Auditor" agent authentication constraints का रिव्यु करे, और कोई तीसरा agent audit logging को हैंडल करे।

#Conclusion

"Constraint Decay" पेपर AI engineering स्पेस के लिए एक जरूरी reality check है। LLMs नो डाउट बहुत ही पावरफुल pattern-matching engines हैं, लेकिन robust backend कोड लिखने के लिए invisible rules को सख्ती से फॉलो करना पड़ता है—एक ऐसा काम जिसे लम्बे समय तक मेन्टेन रख पाना current attention mechanisms के लिए काफी मुश्किल होता है।

हम Ichiban Tools में जैसे-जैसे अपने development pipelines में AI को इंटीग्रेट कर रहे हैं, हम अपने agents को इन limitations को ध्यान में रखकर ही डिज़ाइन कर रहे हैं। Backend development में AI का फ्यूचर किसी agent को एक ही बार में पूरा monolithic application लिखने देने में नहीं है; बल्कि यह constrained, verifiable, और highly scoped loops बनाने के बारे में है जो decay को production तक पहुँचने से पहले ही पकड़ लें।

arXiv पर पूरा पेपर पढ़ें: arxiv.org/abs/2605.06445