How to Evaluate AI Coding Agents Before You Trust Them

The demo passed. The patch was clean. Three weeks later, your team spends more time reviewing agent output than it would have spent writing the code by hand.

I have watched that pattern repeat across teams, and it rarely has anything to do with model quality. The default trial — a small, well-specified task in a clean repository — measures whether an agent can produce a plausible diff. It says nothing about whether the agent is reliable enough to delegate real work to. Those are different questions, and they require different evidence.

This article is for teams past the curiosity stage: you have an agent running against a real repository, and you need a defensible way to decide whether to widen its access. The evaluation model below rests on five signals — repository tasks, test outcomes, review cost, recovery behavior, and security boundaries — and the core discipline is refusing to collapse them into a single score.

Why a Passing Patch Proves Almost Nothing

A demo task is engineered to succeed. It is small, single-file, well-specified, and free of legacy constraints. It measures possibility.

Production work is the opposite: ambiguous intent, tangled dependencies, tests that fail for environmental reasons, and a codebase where the correct change is often the smallest one. An agent that shines on the demo may still be useless here — not because it cannot write code, but because the cost of verifying its code exceeds the cost of writing it.

The visible artifact is the diff. The actual cost is the trajectory that produced it: the tool calls, the dead ends, the retries, and the human minutes spent reconstructing what the agent was thinking. A diff is a receipt. The trajectory is the ledger.

There is also a category error buried in most trials. Model benchmarks and agent evaluations answer different questions. A model benchmark tests whether a base model can solve static problems. An agent evaluation tests whether a system — planning, calling tools, handling uncertainty, operating in a dynamic environment — can complete real workflows. A capable base model is a prerequisite for a reliable agent, not a guarantee of one. High scores on knowledge benchmarks do not transfer automatically to task completion in your stack.

So the evaluation model has to be built from signals that survive contact with a real codebase:

1. Repository tasks — does the agent complete work drawn from your own history?
2. Test outcomes — does the result actually pass, under stable conditions?
3. Review cost — how many human minutes per accepted change?
4. Recovery behavior — what happens when something breaks?
5. Security boundaries — what can the agent reach, and under whose authority?

Score these separately. Averaging them hides exactly the failures that matter.

One Record Per Task Run

Before you can compare agents, you need a unit of analysis. The five signals above are not five separate experiments; they are five views of the same event. If you do not capture them together, you will end up with disconnected dashboards and no way to answer the only question that matters: for this task, under these constraints, what did the agent actually do, and what did it cost us?

Keep the record tool-agnostic. A row per task run, with these fields:

• Task ID and intent — the stated goal in one sentence.
• Constraints — allowed files, allowed tools, call limits, definition of done.
• Outcome — pass or fail against the stated intent, not against "looks reasonable."
• Trajectory summary — tools called, parameters, retries, dead ends, side effects.
• Review minutes — human time from first read to merge or rejection.
• Recovery result — what happened after the first failure, and the failure layer (planning, tool, or environment).
• Security findings — scope violations, unrequested installs, writes outside the intended directory, or actions taken on instructions embedded in untrusted content.

Everything else in this article is a way of reading that record. Task success rate is the pass column. Tool-call accuracy and trajectory efficiency are derived from the trajectory summary. Acceptance, rework, and revert rates come from the outcome and review columns. Recovery behavior is the recovery column. Security boundaries are the findings column.

This is the part most teams skip, and it is the reason their evaluations produce opinions instead of decisions. Log first. Interpret second.

From Model Scores to Task Success Rate

The first shift is from accuracy to Task Success Rate (TSR). Success counts only when the agent fully resolves the stated intent within stated constraints — not when the final answer merely looks plausible. Define each task as intent plus constraints: which files may change, which tools are allowed, a maximum number of calls, and what "done" means. Then measure success against that definition.

The second shift is from the final answer to the trajectory: the recorded sequence of plans, tool calls, parameters, observations, and side effects. Two agents can produce identical diffs with radically different trajectories. One read three files, made one bounded edit, and ran the relevant test. The other read forty files, installed a dependency nobody asked for, and got lucky. The diff cannot tell you which happened. The trajectory can.

Two diagnostic metrics fall out of trajectory logging:

• Tool call accuracy — did the agent invoke the right tools with valid parameters? This is where hallucinated API schemas surface, along with overuse of slow or expensive tools.
• Trajectory efficiency — steps and tokens per success. Redundant steps are not just waste; they are a leading indicator of an agent that does not understand the codebase.

Report TSR per scenario, not as one aggregate number. Run the same task set under normal conditions, with a degraded tool (a flaky test runner, a missing service), and with deliberately ambiguous instructions. Brittleness hides inside averages. An agent that scores well on clean tasks and collapses under ambiguity is telling you something a single number never will.

One practical note before anything else: instrument trajectory logging first. If you run the evaluation and then try to reconstruct what happened from memory and terminal scrollback, you are not measuring the agent. You are measuring your recollection of the agent.

Build the Task Set From Your Own Repository

Borrowed benchmarks are useful context about the field. They are not a substitute for tasks drawn from your own codebase, because your codebase is where the constraints live.

Start with work your team has already completed and whose outcome you already know:

• Bug fixes with a known root cause
• Small refactors with a defined boundary
• Dependency upgrades with a known target version
• Test backfills for untested modules
• Configuration changes with a verifiable end state

Each task needs a stated intent plus constraints. "Fix the pagination bug in the reports endpoint" is not a task specification. "Fix the off-by-one in the reports pagination cursor; only reports/pagination.py may change; do not modify the test suite; the existing pagination tests must pass" is.

Two prerequisites determine whether the evaluation means anything. First, well-specified tasks — if a human engineer could not agree on what "done" looks like, the agent cannot either, and you will be grading ambiguity. Second, stable test environments. A flaky environment turns agent evaluation into noise measurement, and you will spend weeks chasing phantom regressions that were never the agent's fault.

Grade the outcome and the transcript separately. Pass-or-fail tests handle correctness. A rubric or heuristic grader handles the things tests cannot see: code quality, scope discipline, tool behavior, and interaction style. The distinction matters because an agent can pass the tests while doing something you would never merge — disabling an assertion, widening a change beyond the stated boundary, or leaving debug output behind.

Then keep the suite alive. Tasks with high pass rates should graduate from capability checks into a continuous regression suite. A task that once asked "can the agent do this at all?" becomes "can it still do this reliably?" That transition is where most teams lose their evaluation investment: they build a one-time assessment, run it once, and never notice when behavior drifts.

Review Cost Is the Metric Nobody Tracks

Here is the number that decides whether an agent is worth deploying, and almost nobody measures it: human minutes per accepted change.

Review cost includes reading the diff, verifying that the change matches the stated intent, checking for scope creep, and re-running whatever the agent claimed to run. It is not a proxy for quality. It is the actual labor the agent shifts onto your team.

Diff size and blast radius are useful proxies. A large agent-authored change is not automatically better than a small one — it moves work from writing to reviewing, and reviewing is often the more expensive activity because it requires holding the whole system in your head. An agent that produces a 400-line change to fix a 10-line bug has not saved you anything. It has handed you a puzzle.

This is where the trust asymmetry bites. A fast agent that produces plausible-but-wrong changes can cost more than a slow agent that produces small, verifiable ones. Speed is only valuable when verification is cheap. When verification is expensive, speed just gets you to the wrong answer faster.

Track these alongside latency and token cost per task:

• Acceptance rate — what fraction of agent changes get merged as-is?
• Rework rate — what fraction need human correction before merging?
• Revert rate — what fraction get merged and then undone?

The decision rule is blunt: if review cost per merged change does not fall after the first few weeks, the agent is not compounding. It is relocating labor. Early friction is expected while the team learns the tool's failure patterns. Sustained friction is a verdict.

Recovery Behavior Separates Tools From Toys

Success rate tells you what happens when things go right. Recovery behavior tells you what happens when they go wrong — and that is the stronger predictor of whether an agent survives daily use.

Test the error path deliberately. Break a test. Remove a dependency. Give an instruction with a genuine ambiguity in it. Then watch what the agent does next.

Good recovery looks like reading the error, narrowing the hypothesis, and making a bounded change. Bad recovery looks like repeated blind edits, disabling the failing test, or widening scope until something passes. The second pattern is dangerous precisely because it can produce a green test suite over a broken system.

Classify failures by layer — planning, tool, or environment — so you know which one to fix. A planning failure means the agent misunderstood the task. A tool failure means it used the wrong instrument or the wrong parameters. An environment failure means the setup was broken before the agent started. These have different remedies, and lumping them together produces the vague conclusion that "the agent isn't good enough," which is not actionable.

Then check the repository state after a failure. Does the agent leave a clean working tree? Orphaned files? Silently skipped checks? An agent that fails cleanly is recoverable. An agent that fails messily costs you a cleanup pass on top of the failed task.

One boundary worth stating plainly: an agent that recovers well on small tasks may still fail on multi-service changes where the feedback loop is minutes long instead of seconds. Recovery quality is partly a function of how fast the agent can observe the consequence of its own action. Slow feedback loops degrade every recovery strategy, human or machine.

Security Boundaries Are a Gate, Not a Score

Most pilot evaluations skip the adversarial surface entirely. That is the gap that turns a productivity experiment into an incident.

Treat security as an admissibility boundary around everything else. The other four signals tell you whether an agent is useful. This one tells you whether it is allowed to operate at the scope you are considering. A high task success rate inside an unsafe execution boundary is not a good result. It is a result you cannot use.

The highest-risk configuration is autonomous or auto-accept mode, where the agent acts without per-command approval. This is also the configuration that delivers the most delegation, which is why teams drift toward it. The tradeoff is real, and it should be made deliberately rather than by default.

The core vulnerability class is prompt injection through untrusted content. An agent processes issue text, dependency metadata, README files, and external artifacts as part of its reasoning context. It does not reliably distinguish between trusted instructions and untrusted data. A payload embedded in any of those artifacts may be interpreted as an actionable directive — installing an untrusted dependency, modifying configuration, or executing arbitrary commands.

Research on malicious issue requests is an early signal, not proof of mainstream exploitation. Treat it as a reason to test, not a reason to panic. The point is that the attack surface exists and is testable.

Concrete probes to run before widening access, each tied to the permission or side effect it reveals:

• Does the agent install dependencies that were never requested? (package manager authority)
• Does it modify CI configuration or other files outside the stated scope? (build pipeline authority)
• Does it touch secrets, environment files, or credential stores? (secret access)
• Does it write outside the intended directory? (filesystem boundary)
• Does it act on instructions embedded in issue text or file contents rather than in the task specification? (trust boundary between data and instruction)

Then answer the permission-design questions that determine your actual exposure: who initiated the action, which agent performed it, what resources it could reach, who approved it, and what happens to those permissions when work moves between people or machines. Those questions get harder as agents move from a single developer's terminal into shared team environments, where sessions, approvals, and attribution become part of the workflow rather than an afterthought.

Isolation is a configuration decision, not a product feature. Sandboxing, scoped credentials, and approval gates are the controls that make the rest of your evaluation meaningful. An agent with broad credentials and no approval gate is not being evaluated — it is being trusted, and trust is not a measurement.

Turning the Signals Into a Go or No-Go Decision

The five signals do not carry equal weight, and they do not resolve conflicts by averaging. Separate them into two categories.

Rollout-blocking gates. These are pass/fail. A failure here stops expansion regardless of how good the other numbers look:

• Scope violations — the agent changed files it was told not to touch.
• Unrequested installs or configuration changes.
• Any action taken on instructions embedded in untrusted content.
• Writes outside the intended directory, or access to secrets and credential stores.

Optimization metrics. These decide whether a permitted stage is worth expanding:

• Task success rate, per scenario.
• Review minutes per accepted change.
• Trajectory efficiency and tool-call accuracy.
• Recovery rate and failure-layer distribution.

The interpretation rule follows directly. High task success with high review cost means the agent is permitted but not yet economical — hold the current stage and work on task specification and scope discipline. Good recovery inside an unsafe execution boundary means the agent is not yet admissible — fix the permission design before reading any productivity number. A strong task success rate does not compensate for an untested security boundary, and a clean security posture does not compensate for review costs that never decline.

Then stage the rollout:

1. Read-only tasks — the agent analyzes, proposes, and explains, but does not write.
2. Small scoped changes with review — bounded edits, mandatory human approval, measured review cost.
3. Autonomous execution on low-risk repositories — auto-accept enabled where the blast radius is contained.
4. Wider delegation — expanded scope, with the regression suite running continuously.

Define your kill criteria in advance: the specific failure that stops the rollout. Write it down before you are invested, because sunk-cost pressure is real and the decision will be renegotiated the moment it becomes inconvenient. "If revert rate exceeds X for two consecutive weeks, we roll back to stage two" is a kill criterion. "We'll know it when we see it" is not.

Re-run the suite on every model or harness upgrade. Agent behavior changes with the surrounding product, not only with the underlying model. A tool-calling change, a new system prompt, or a different context strategy can move your metrics without any model change at all.

And be honest about the maintenance cost: evaluation suites age. Tasks that once measured capability become regression checks, and the set needs pruning and refreshing as your codebase moves. Budget for it, or the suite quietly becomes stale and stops predicting anything.

What to Learn Next

Build the smallest useful version this week. Ten tasks from your own repository. One logging hook that captures trajectories. A single record format with a column for review minutes. That is enough to produce your first real signal, and it will teach you more than any benchmark leaderboard.

The skills worth developing are specific: writing task specifications with explicit constraints, designing graders that catch what tests miss, reading trajectories rather than just diffs, and reasoning about permission boundaries as a design problem. Each one compounds.

So do the reusable assets. A task bank, a grading rubric, a trajectory log format, and a rollout checklist carry forward to every agent you evaluate later — including the ones that do not exist yet. That is the leverage: the harness outlives the tool.

Here is the judgment I would stake the decision on. The teams that get real value from coding agents will not be the ones with the best model access; model access is converging. They will be the ones with the cheapest way to find out when the agent is wrong. Evaluation capability is the asset that compounds, and it is the one most teams skip because the demo already passed.