सतत मूल्यांकन: कोडिंग एजेंट्स का ऑपरेटिंग सिस्टम

पुराने कोडिंग असिस्टेंट का सौदा सरल था: वह एक लाइन सुझाता था, आप आँखें सिकोड़कर देखते थे, और शायद किसी को नुकसान नहीं होता था। अब कोडिंग एजेंट टूल कॉल कर सकते हैं, स्टेट बदल सकते हैं, और किसी रिपॉज़िटरी में ऐसे लड़खड़ाते हुए घूम सकते हैं जैसे रूट एक्सेस वाला बहुत आत्मविश्वासी इंटर्न। अब सिर्फ “वाइब्स” QA रणनीति नहीं हैं। वे तो विंड टनल में रखी सुगंधित मोमबत्ती हैं।

LetsLearnGenAI से मिला उपयोगी नज़रिया यह है कि evals, AI-सहायता प्राप्त कोडिंग का ऑपरेटिंग सिस्टम बनते जा रहे हैं। चमकदार ऐप लेयर नहीं, लीडरबोर्ड वाला वॉलपेपर नहीं, बल्कि वह कंट्रोल सरफेस जो टीमों को बताता है कि क्या बदला, क्या टूटा, और एजेंट को काम जारी रखना चाहिए या उसे जूस बॉक्स देकर बिल्ड पाइपलाइन से बाहर छोड़ आना चाहिए।

Anthropic हमें वह उबाऊ परिभाषा देता है जिसकी हमें ज़रूरत है

Anthropic eval को AI सिस्टम के लिए एक टेस्ट के रूप में परिभाषित करता है: एक इनपुट दें, फिर सफलता मापने के लिए आउटपुट पर ग्रेडिंग लॉजिक लागू करें। अपनी 09 जनवरी, 2026 की इंजीनियरिंग पोस्ट में, Anthropic कहता है कि अच्छी evaluations टीमों को agents को अधिक आत्मविश्वास से शिप करने में मदद करती हैं, क्योंकि वे failures और behavioral changes को users तक पहुँचने से पहले ही visible बना देती हैं। कंपनी यह भी बताती है कि agents को chatbots की तुलना में मापना कठिन क्यों है: वे कई turns में काम करते हैं, tools call करते हैं, state modify करते हैं, और intermediate results के आधार पर adapt करते हैं।

@title मूल्यांकन संरचना
@source Demystifying evals for AI agents

  Input
    │
    ▼
  AI system
    │
    ▼
  Output
    │
    ▼
  Grading logic
    │
    ▼
  Success measure

@caption Anthropic evals को input, output, grading logic, और success measurement के रूप में वर्णित करता है।

यह परिभाषा लगभग चिढ़ाने वाली हद तक साधारण लगती है, और इसी वजह से यह महत्वपूर्ण है। Repository agents सिर्फ अगला token predict नहीं कर रहे होते, वे ऐसे environments के अंदर actions ले रहे होते हैं जो fragile tests, अजीब dependencies, और final_final_really.py नाम की एक file से भरे होते हैं। अगर आप किसी task को replay करके outcome को consistently grade नहीं कर सकते, तो आप agent adopt नहीं कर रहे हैं। आप उसे summon कर रहे हैं।

Task Type ही छिपा हुआ variable है

एक task-stratified arXiv study ने AIDev dataset के 7,156 pull requests पर OpenAI Codex, GitHub Copilot, Devin, Cursor, और Claude Code की तुलना की। Paper ने पाया कि task type का बड़ा असर था: documentation tasks में 82.1% acceptance मिला, जबकि new features में 66.1%, यानी 16 percentage point का gap, जो ज़्यादातर tasks के लिए typical inter-agent variance से अधिक था। उसने यह भी बताया कि acceptance rate में केवल Devin ने consistent positive trend दिखाया, 32 हफ्तों में 0.77% per week, जबकि बाकी agents अधिकतर stable रहे।

यही वह हिस्सा है जिसे teams को अपने CI dashboard के अंदरूनी हिस्से पर tattoo कर लेना चाहिए। Average benchmark score के आधार पर coding agent चुनना वैसा है जैसे drawer में forks की संख्या देखकर restaurant चुनना। आपकी local eval suite को tasks को उस काम के हिसाब से split करना चाहिए जो आप सच में करते हैं: docs, bug fixes, refactors, migrations, tests, और new features। वरना जो agent आसान maintenance chores में शानदार दिखता है, वह चुपचाप आपकी architecture को ऐसे कुतर सकता है जैसे server room में raccoon।

Production evals को production जैसे tasks चाहिए

REAP paper तर्क देता है कि AI coding agents की production deployment के लिए तेज़, reproducible evaluation signals चाहिए। वह कहता है कि online A/B testing में हफ्तों लग सकते हैं और user experience को risk हो सकता है, shadow deployment runs के बीच reproducible signals नहीं देता, और public benchmarks language distribution, prompt style, और codebase structure में real workloads से अलग हो सकते हैं। REAP manual labeling के बिना real developer-agent sessions से production-derived benchmarks को automatically curate करने का प्रस्ताव रखता है।

यही research evals से operating discipline तक का पुल है। एक उपयोगी team eval puzzle problems का museum नहीं है, बल्कि उस mess से बना living regression suite है जो आपका codebase सच में पैदा करता है। REAP paper practical landmines भी बताता है: untestable prompts, misaligned tests, और flaky tests reliability को compromise कर सकते हैं। अनुवाद: अगर आपका eval खराब agent और खराब test में फर्क नहीं बता सकता, तो बधाई हो, आपने YAML वाला fog machine बना लिया।

Benchmarks ज़रूरी हैं, पर्याप्त नहीं

ProjDevBench एक अलग कमजोरी पर दबाव डालता है: end-to-end project development। इसके arXiv abstract के अनुसार, benchmark coding agents को project requirements देता है और resulting repositories को Online Judge testing plus LLM-assisted code review का उपयोग करके evaluate करता है। यह 8 categories में 20 programming problems cover करता है, छह coding agents को evaluate करता है, और 27.38% overall acceptance rate report करता है।

यह low acceptance rate panic करने की वजह नहीं है, बल्कि responsibly scope करने की वजह है। Paper कहता है कि agents basic functionality और data structures संभाल लेते हैं, लेकिन complex system design, time complexity optimization, और resource management में struggle करते हैं। Builders के लिए practical move साफ है: narrow, high-signal tasks से शुरू करें जहाँ correctness check की जा सके, फिर केवल तब expand करें जब आपके evals दिखाएँ कि agent improve कर रहा है। Measurement के बिना autonomy सिर्फ trench coat पहने autocomplete है।

Human को loop में रखें, बेहतर हो तो जागा हुआ

Agents That Teach paper एक नरम लेकिन महत्वपूर्ण failure mode जोड़ता है: developer learning। यह तर्क देता है कि जब developers substantial coding tasks autonomous agents को delegate करते हैं, तो incidental learning short-circuit हो सकती है, जिससे authors के शब्दों में Knowledge Debt बनता है। Paper छह design principles propose करता है और SHIELD प्रस्तुत करता है, एक multi-agent system जिसका उद्देश्य coding agent की अपनी reasoning से contextual, out-of-band learning surface करना है।

यह इसलिए मायने रखता है क्योंकि evals को सिर्फ यह नहीं मापना चाहिए कि tests green हैं या नहीं। Teams को यह भी पूछना होगा कि क्या developers change को explain कर सकते हैं, maintain कर सकते हैं, और notice कर सकते हैं जब agent पूरे confidence के साथ nonsense का एक छोटा cathedral बना देता है। अगला practical step कोई विशाल eval empire नहीं है। एक छोटी local suite बनाइए, उसे real tasks पर run कीजिए, task type के अनुसार stratify कीजिए, regressions track कीजिए, और production misses से cases जोड़ते रहिए।

अगर agent drive करने वाला है, तो evals steering wheel हैं, fuzzy dice नहीं।