LLM Evaluation Methods for Production Coding Agents

Production coding agents need evaluation methods that measure both how work gets done and whether the final answer passes. A successful result is safe, efficient, and fit for the pipeline only if its execution trajectory, tool-call sequence, and step-level behavior meet those requirements. To be ready for production, agents need layers of evaluation that link each action to task completion and to what happens at integration.

Why final-answer pass/fail scores are structurally insufficient for production coding agents

A coding agent plans, retrieves context, edits files, runs commands, observes test results, repairs errors, and prepares a reviewable artifact. Each observation can redirect the next action, so the unit of work is a loop. Planning, tool use, delegation, and recovery all affect the quality of that loop. A final-output score compresses these behaviors into one result. That compression removes precisely the evidence a production pipeline needs to judge whether the path was acceptable.

An agent can make a working patch even after calls it did not need, unsafe actions, or retries that cost too much. The patch may pass even when the trajectory falls short of what production requires. Harder benchmarks do not resolve that distinction. LiveCodeBench uses fresh competitive programming problems to address contamination, but its correctness scores still do not measure agentic execution quality. Humanity's Last Exam, developed by the Center for AI Safety and Scale AI and published in Nature in January 2026, raises the difficulty of final-answer evaluation while retaining its unit of measurement.

How process evaluation differs from outcome evaluation at three distinct levels

He et al.'s process evaluation framework separates action prediction, task uncertainty, and step attribution. At the action level, the question is what the agent will do next. Their strongest predictive signal is execution provenance, specifically the paths the agent has just seen in tool outputs, which predicts actions more strongly than the code dependency graph does. At the task level, the question is whether execution remains uncertain or recoverable. Execution variance is structured mainly by the instance, making uncertainty primarily a property of the task.

At the step level, the question becomes whether a particular action causally changed the outcome. He et al. introduce SCAE, a replay-based estimator derived from a structural causal model of agent execution, to make that causal quantity explicit and testable. Their findings also expose how difficult it is to localize causal effects at feasible replay cost. Process reward models, full-trace judges, and restart-based ablations therefore cannot be treated as interchangeable answers to one question. Souza and Machado's architecture-aware evaluation work adds a complementary constraint, namely that planners, memory, and tool routers shape what observable signals mean. Together, these frameworks establish that evaluation needs both a defined question and an understanding of the architecture producing the behavior.

The three-metric layer that trajectory evaluation actually requires

A correct result can conceal a wasteful route, which is the failure a trajectory accuracy metric makes visible. It measures how closely the step sequence matches a golden reference path. For example, an agent may get to the correct patch while taking detours and making the same tool calls again. Step and loop counts sharpen this diagnosis by comparing actions taken with the minimum needed. Per-step cost attribution then exposes repeated work that a trace total cannot explain.

A route that looks right can still have invalid operations, so it needs a separate ToolCorrectnessJudge. This metric checks tool selection, parameter accuracy, and graceful failure recovery. For example, selecting the right tool with the wrong arguments remains an invocation failure even if another call later rescues the task. Neither a path similarity score nor a clean final answer establishes that those operations were sound.

Conversely, orderly tool use does not prove that the goal was achieved, which makes a task completion judge indispensable. For example, an agent can claim that it completed an action without changing the resulting system state. Completion evaluation must distinguish that claim from actual completion, as tau-bench does by checking state as well as output text. Retrieval-augmented agents also require groundedness measures, including faithfulness, context precision, context recall, and answer relevancy. Latency and token counts describe resource use, but without completion evidence they can make an unsuccessful agent look efficient.

Why a full-trace LLM judge alone introduces systematic bias

LLM-as-judge makes trajectory review scalable, but access to the whole trace does not make its judgment causally reliable. He et al.'s experiments on file-localization episodes across repositories show that judges change how they blame earlier actions once they can see later steps. The underlying action has not changed in that comparison. The information available to the evaluator has changed.

The finding is systematic collider bias. By conditioning on the full trace, including evidence that post-dates the action under review, the judge responds to semantic relevance or late-trace evidence. Full-trace judges are still useful for evaluation at the task-level and outcome-level. Step-level causal attribution, however, requires controls rather than an assumption that more context produces better attribution.

Task-level judging also needs to be calibrated against human labels. Teams can start with a set of golden traces from production traffic and add to it through structured review. Per-turn classifiers complement this slower review by detecting policy violations, jailbreaks, and user frustration as turns occur. These signals can remain invisible in status codes, latency, and token counts. The appropriate response is to narrow each evaluator's responsibility while retaining LLM judgment.

The three-level production eval stack and where each level belongs in CI/CD

The stack used in production starts with Level 1 assertion-based unit tests. These fast, deterministic checks run on every commit and gate pull requests to keep known regressions from reaching review. Assertions covering tool-call structure, output schemas, valid mappings, and range checks belong here. Their speed makes routine gating practical. More capable LLM review is not a substitute for deterministic checks on properties that already have exact answers.

Level 2 adds trace-based evaluation with LLM-as-judge on curated datasets. This slower, probabilistic layer catches flaws in quality that people would notice but simple assertions miss. Calibration against human labels gives its scores an interpretable basis. Offline evaluation belongs in CI because repeated inputs make known-case regressions reproducible. A fixed dataset still cannot cover unseen inputs, multi-turn drift, or tool failures that occur only when tools run against live systems.

Level 3 evaluates production traffic continuously. It catches new failures and behavioral drift, and the labeled turns give teams data for fine-tuning or RL reward shaping. Evaluation-Driven Development extends this work across the lifecycle rather than treating evaluation as a release-time inspection. These levels form a progression. Production evidence becomes useful for learning only when Levels 1 and 2 already remove known failures that would otherwise overwhelm the signal.

What tool-call bloat reveals about process quality, and why trimming dead skills improves eval scores

Vercel removed the majority of tools from an agent while keeping the underlying model unchanged, increasing its success rate to perfect while substantially reducing tokens and latency. That distinction makes the case operationally useful. Outcome scoring could record the improvement, but transcript analysis supplies the evidence for what to remove.

Excess tools expand the choices available at each step and raise the risk of wrong-tool selection. ToolCorrectnessJudge can catch those failures before they reduce task completion. Production transcripts distinguish tools that are regularly invoked from those called with wrong arguments or never used. Logs containing only final outputs cannot support that diagnosis. Removing dead skills is therefore an evidence-based change to the execution environment.

He et al.'s finding about execution provenance adds another reason to inspect tool history. Tool outputs shape subsequent choices: what the agent has just encountered predicts its next action more strongly than the code graph does. Process evaluation makes this relationship inspectable. Its practical value lies in identifying changes to the agent's working set that improve both completion and efficiency.

How production signal volume at the merge queue exposes eval gaps that pre-merge testing misses

Agent-level improvements do not remove the capacity limits of software delivery. Greptile's “Rise of the Overnight Agents” report in May 2026 found that AI-authored PRs grew from a small fraction of merged PRs in early 2025 to more than a quarter by April 2026. That shift changes the arrival assumptions of review pipelines, CI fleets, and merge queues sized for human output. Producing more patches does not automatically increase the capacity to integrate them. Teams can merge far more pull requests even as their delivery metrics barely change.

Queueing theory explains why this mismatch is costly. As arrivals approach service capacity, waiting times grow nonlinearly. A merge-group CI cycle that adds a short wait when volume is low can add hours of delay at the volumes agents produce. Flaky tests compound the pressure when an agent repeatedly re-queues the same change to get it merged. A mildly wasteful retry pattern can then consume a disproportionate share of CI capacity.

These are process failures with system-level consequences, even when the individual patch appears acceptable before integration. The reject rate on agent PRs therefore belongs in the evaluation loop. It reveals which behaviors and tool-call patterns produce changes that fail integration. Pre-merge testing measures known cases before landing, while merge-queue evidence exposes how agent output behaves under actual integration pressure.

What multi-agent systems add to the evaluation surface and why inter-agent boundaries are a currently under-measured failure point

Specialized-agent pipelines distribute work across infrastructure, implementation, review and testing, security auditing, compliance, and documentation. That distribution adds a failure surface between agents. Each internal trajectory can appear acceptable while the handoff remains unevaluated. The transfer must therefore become a unit of evaluation in its own right. The principle that no agent should mark its own homework also requires an evaluator architecturally independent of both agents involved.

The Linux Foundation reported more than 150 organizations supporting A2A at its one-year mark in April 2026. Microsoft Agent Framework 1.0 was made available for general use on April 3, 2026. A2A's native integration in Azure AI Foundry, AWS Bedrock AgentCore, and Google Cloud makes inter-system boundaries a defined evaluation surface. Adoption and framework maturity, however, do not by themselves establish that handoff quality is being measured.

Souza and Machado's architecture-aware framework explains why single-agent metrics need to change when used with more than one agent. A metric designed for one orchestrator can produce misleading readings when applied to a multi-agent DAG. Responsibility is distributed differently, so the meaning of an observed failure also changes. Current trace-level tooling rarely enforces independent handoff evaluation, leaving a gap between orchestration and assurance. Internal traces remain necessary, but they do not cover the full system.

How composable, purpose-built eval infrastructure fits the software factory model

The software factory model requires evaluation components matched to the work at each stage. Action-level signals describe the agent's next choices, task-level signals describe completion and uncertainty, and step-level analysis asks a narrower causal question. A single monolithic score obscures those distinctions. Purpose-built components preserve them while making each handoff, retry loop, and CI failure an evaluation checkpoint. This is the same discipline that makes a focused tool set more useful than an indiscriminate collection of skills.

Reliable comparison also requires a consistent substrate. Cloud-native version control and consistent runtime environments prevent differences in prompts, models, and environment variables from confounding score changes. For agents hosted on a container orchestration platform, teams should version prompts and RAG datasets as well as code, and set hard resource quotas against runaway loops. Compostable AI's dedicated staging-account pattern illustrates the corresponding release boundary, with agents iterating in a client-specific “digital twin” before promotion to production. Evaluation becomes part of how work advances.

The implementation order follows directly from this architecture. Start with deterministic gates for tool-call structure and output schemas, add calibrated trajectory judgment, and instrument production traffic for drift and novel failures. Use CI failures, deploy failures, revert events, and agent PR reject rates in evaluation as well as tracking them in dashboards. Evaluation helps agents do better, agents produce better output, and the rise in output puts the evaluation system to the test again. That cycle is productive only when the infrastructure is built to turn execution and integration evidence into better gates.