The scariest AI failures are the silent ones. You ship a change to an agent on a branch, a new feature, a prompt tidy-up, a quick refactor. No errors, no complaints, everything looks fine. But did it still work, or did you quietly break something that worked yesterday? As the engineer Alejandro Aboy puts it in a new field guide from Decoding AI Magazine, "the fact that they're not complaining doesn't mean there's no issue going on". A quiet user is usually not a happy one.

The piece, by Paul Iusztin and Aboy, lays out a discipline they call Evaluation-Driven Development, or EDD. If you ship AI agents, it is the most practical answer yet to a question we keep circling on this blog: anyone can generate code, but few can generate confidence. EDD is where that confidence comes from.

What EDD is

EDD is an offline validation gate that sits between writing a change and merging it. Before a pull request is accepted, it forces you to answer two questions: what is the performance of my new feature, and did my change introduce any regression into what already worked? You merge only when both answers are good.

The mindset is hypothesis-first. Every change starts as a stated hypothesis on a branch, for example "this prompt edit will stop the agent fabricating IDs". EDD then runs a simulation, scores the result, and ends in a PR backed by an experiment with traces and hard numbers. The results are framed as an experiment you can compare against the previous run, which is the only reliable way to catch a subtle regression: you diff two experiments, not two hunches.

The fact that they're not complaining doesn't mean there's no issue going on.

How it works

The setup has three parts: the AI application itself (in the case study, a real product, the Workpath AI Companion, an agent built with Agno), a headless evaluation harness driven by Claude Code, and an observability platform, Opik, that captures traces, holds the datasets and the judges, runs experiments and compares them.

It runs in two modes. Mode one is a quick manual check: fire around thirty fresh traces, read them back, and trigger a judge by hand if you want a score. It is for small, targeted fixes and takes minutes. Mode two is automated: turn those traces into a dataset, run an experiment where the judges score every item, and compare it against earlier runs. A second dial, "aggression", controls how adversarial the simulated cases get, from the happy path up to deliberately hunting the corner cases that break the agent.

The idea worth stealing: simulate the input, not the answer

The clever part is how the test data is made. Claude Code reads the agent's own source code around the new feature, pulls relevant past traces from Opik, and from those generates roughly thirty new test cases, spread across two axes: regression versus new capability, and happy path versus adversarial.

Then comes the rule that makes the whole thing trustworthy. You simulate only the inputs, never the outputs. Each simulated input is fed to a headless copy of the real agent, which actually runs: it selects tools, calls the staging backend, and handles whatever comes back, recording the full tool-call history into its trace. Grade only the final answer and a wrong tool call stays invisible. As Aboy found, synthesising the outputs too meant "losing everything the agent was doing beyond the response". The evaluator has to see the whole trace, because that is where agents actually fail.

The hardest part, they are candid, is state. An agent passes or fails for reasons that only make sense if it was in a realistic state when it ran. Since most of the Companion's tools are API calls, the harness uses a token against a staging account preloaded with data, pulling real goals and OKRs for the happy path and forcing errors or missing data to go adversarial, then injecting that context before the agent boots so it behaves "as if for real". This is not unit tests with fixtures; it is the production system, mocked just enough to stay honest.

What an operator should take from it

You do not need Opik, Agno or Claude Code specifically; the pattern is what matters. Three things carry to any team shipping agents:

  • Make every agent change an experiment. A hypothesis, a before-and-after comparison, a number. Treat "it seems fine" as the absence of a test, not the result of one.
  • Evaluate the trace, not the reply. The final answer can look right while the agent took a wrong tool, hit the wrong API, or simply got lucky. Score the whole path.
  • Generate inputs from reality, then run the real thing. Mine your actual traces for what to test, simulate only the inputs, and let the live agent produce the outputs against a staging backend. Anchor to the hot path, and do not over-optimise for edge cases that never happen.

What we tell clients at AvantiGroup.AI

EDD is, in plain terms, continuous integration for systems that have no single right answer. It is the missing half of agentic engineering: not how to build the agent, but how to know it still works after you change it. The teams that put a gate like this in front of merge are the ones that keep shipping quickly without the slow accumulation of silent breakage that quietly erodes a product.

The model will keep getting better and code will keep getting cheaper to write. The durable advantage is the ability to prove, on demand, that what you shipped does what you claim. Build the eval gate before you need it, because by the time a quiet user has churned, the experiment you needed to run was the one from last week.