Coding-agent-operated AI quality control

Most of what we built software-quality practice around assumes the program does the same thing twice. Unit tests pin an input to an expected output; code review reads a diff and reasons about what it will do. Both rest on a quiet assumption — that behavior is a function of the code you can see. For an AI application, that assumption no longer holds. The same prompt can produce different output on consecutive calls; a model the vendor updated under you can shift a product overnight; a retriever fed new documents can change every answer without a single line of your code changing. LLM inference is non-deterministic enough in practice that, as one engineering lab put it, the same prompt can yield different results even at temperature zero.¹

So the thing you most need to know after a change — did behavior get better, worse, or just different? — is precisely the thing your existing tools can't tell you. They inspect the diff. The behavior moved somewhere the diff doesn't reach. Closing that gap means measuring the behavior itself, against examples drawn from your own product, every time something changes. That is what "AI quality control" names, and it is now a normal part of shipping AI — OpenAI's own evaluation guidance argues that because generative AI is variable, traditional software testing is insufficient and evals are how you test despite it.²

The newer move is who operates that measurement. You are likely already building with a coding agent — Claude Code or Codex — that reads your repo, edits files, and runs commands. That agent is the natural operator for evaluation work: it already has the context, and it can scaffold checks, run them, and explain the results in the same conversation where you made the change. Coding-agent-operated AI quality control is that arrangement made deliberate — and made safe by one boundary the rest of this guide is about: the agent operates the work, but it never gets to decide that its own work counts.

Why code review can't see what changed

It helps to be precise about what code review is good at and where it goes blind. Review is a judgment about a change to the code: is this diff correct, readable, safe to merge? For ordinary software that is usually enough, because the behavior is downstream of the code. An AI application breaks the link in three ways at once.

First, the behavior can move while the code stands still. A model version bump, a change in the documents your retriever indexes, or a shift in live traffic can each alter outputs with no diff to review. Second, a change that is in the diff — a reworded prompt, a swapped model — can look like an improvement in a demo while quietly regressing the long tail of cases the demo never exercises. Third, and most specific to agents, the final answer can be right for the wrong reasons: the workflow called the wrong tool, skipped a required step, and recovered by luck. OpenAI's agent-evaluation guidance is built around exactly this point — it grades an agent's whole trace, "the end-to-end log of decisions, tool calls, and reasoning steps," not just the final output.³

Code review asks whether the change is correct. Quality control asks whether the behavior still is. Only the second re-measures when nothing in the diff moved.

None of this makes review obsolete; the two answer different questions and you want both. The practical consequence is only that you need a second instrument — one whose subject is your application's behavior across runs, not the source you can read — and a way to run it as often as the behavior can drift.

Three actors, one governed loop

The clearest way to hold the arrangement in your head is to name the three actors involved and keep their jobs separate. The danger in agent-operated evaluation is not that any one actor is untrustworthy; it is that the roles quietly collapse into each other.

1. authority

   Human / host owner

   Owns product intent, validation, thresholds, calibration, baselines, and gates. The agent never takes this over.

2. operator

   Coding agent

   Inspects, scaffolds, runs, compares, explains, and suggests. It operates the work — it does not authorize results.

3. subject

   AI application / agentic workflow

   Performs behavior across calls, tools, retrieval, steps, trajectories, and sessions — the system under evaluation.

The host owner — you, and the reviewed records in your repo — owns everything that confers authority: which examples count as ground truth, what threshold is a pass, whether a judge is trustworthy, which run is the baseline, and which checks are allowed to fail a build. The coding agent is the operator: it inspects the repo, scaffolds checks, runs them, compares results, and explains the scorecard. The AI application is the subject under evaluation — the behavior being measured. EvalGlass is the governed loop that connects them and returns a scorecard that says no more than the run actually established.

The boundary that keeps this honest fits in three words: capability is not authority. The coding agent is highly capable — it can do most of the evaluation work faster than you would by hand. But the actor that creates evidence cannot also be the actor that authorizes it, for the same reason you don't let a function grade its own output. EvalGlass enforces that structurally: there is no gate, approve, or certify verb for the agent to call. Turning a check into a gate is a host edit you make in your own config; the agent can type it at your direction, but it cannot grant the authority behind it.

How the work actually happens

In practice the operating model is a loop you drive in natural language. You don't learn a query language or a dashboard; you ask your agent a product question and it reaches for the right /evalglass verbs. The loop has six moves, and each one carries a constraint that keeps the result honest.

Read top to bottom, the loop is unremarkable — it is how any careful engineer would test a change. What makes it load-bearing is the right-hand column: at every step the agent's reach stops exactly where authority begins. It can observe, but only evidence you already exported. It can shape checks, but they arrive as drafts. It can run and read, but the runtime, not the agent, computes the verdict. The full loop, with the verbs behind each move, is on how it works.

What a first run can — and can't — claim

The most common way agent-operated evaluation goes wrong is reading more into a green run than it earned. EvalGlass is built so a fresh install starts with empty authority: nothing gates, so the first run is informational and exits cleanly. It reports — what was measured, what moved, what it couldn't measure — but it decides nothing until you approve a threshold. That is deliberate. A tool that gated out of the box would be manufacturing confidence from data no human had reviewed, which is the exact failure it exists to refuse.

Where this sits in the field

Coding-agent-operated quality control is an application of well-established practice, not a new invention, and it is worth being explicit about the lineage. The case for evaluating AI behavior comes from the labs building the models: OpenAI frames evals as the answer to generative variability,² and Anthropic's engineering team argues that without evals, debugging agents is reactive and teams cannot distinguish real regressions from noise — adding that the people closest to the product are best positioned to define what success means.⁴ That last point is the seed of the authority boundary: the criteria are a human responsibility.

What is genuinely EvalGlass's own is the structural separation of operation from authority — "no self-approval." None of the sources above prescribe a local-first, repo-native tool or a deliberate absence of a gate verb; those are EvalGlass's design choices, presented as such. EvalGlass is pre-alpha: Claude Code is the primary runtime, Codex is supported with a public listing still to come, exported-trace import works today while live tracing-platform pulls are planned, and there is no hosted platform and no telemetry. The category is real and practiced; the specific way EvalGlass keeps it honest is the part to evaluate on its own terms.

Sources

Field context for why AI behavior needs measurement. None of these sources describe EvalGlass; the no-self-approval design is EvalGlass's own answer to the problems they document.

1. Thinking Machines Lab — Defeating nondeterminism in LLM inference (2025): LLM inference is not deterministic in practice, even at temperature 0.
2. OpenAI — Evaluation best practices: generative AI is variable enough that traditional software testing is insufficient; evals are how you test, run on every change.
3. OpenAI — Trace grading & Evaluate agent workflows: grade an agent's end-to-end log of decisions, tool calls, and reasoning steps.
4. Anthropic — Demystifying evals for AI agents (2026): without evals, debugging is reactive and teams can't distinguish real regressions from noise; the people closest to the product are best positioned to define success.