Most AI applications in production right now were shipped on instinct. A developer ran a few favorite queries, liked what they saw, and pushed.
Laurie Voss has watched this pattern play out at scale. As co-founder of npm (the package registry that now serves hundreds of millions of JavaScript developers), a DevRel leader at Netlify, and now Head of Developer Relations at Arize, she has spent her career at the intersection of data and developer behavior. She knows how software communities learn, and she knows how they avoid learning.
The current moment in AI development, she argues, looks a lot like the early days of software testing: everyone knows tests exist, and most people are not writing them.
Rob Zuber, CTO at CircleCI, sat down with Laurie to talk about what “real evals” actually are, why the eval loop is going to change how software gets built, and whether we are anywhere close to agents building production software without humans in the loop.
1. Evals are just tests. Stop calling them anything else.
The first problem Laurie has with the word “evals” is the word itself. It is borrowed from the world of ML, and it lands with a thud in the ears of engineers who came up through web development, backend systems, or platform work.
“As soon as you say traces are logs and evals are tests, AI engineers get the story much better. You’re supposed to be writing tests.”
Laurie Voss, Head of DevRel, Arize
The terminology barrier is not trivial. If engineers hear “evals” as an ML research concept, it stays over there, in someone else’s domain. If they hear “tests,” the mental model clicks and the excuses disappear. The biggest competition for an evals company, Laurie points out, is not a rival product. It is engineers who just do not do any evals at all.
The implication is worth sitting with: a large fraction of AI applications going to production right now have no systematic validation. If you are running evals, you already have an advantage.
2. “Vibe-based testing” is why people hate AI.
There is a phrase that stuck: vibe-based testing. It’s what happens when a developer makes a change, runs a favorite query or two, feels good, and ships. It works fine for the happy path. It does nothing for the other 80% of inputs users will eventually throw at the application.
“A whole lot of software is getting all the way to production right now using nothing more than vibes. And it is showing up as really poor reliability. And it is making people hate AI because they interact with AI that’s busted all the time.”
Laurie Voss, Head of DevRel, Arize
This is not a new failure mode. Anyone who has watched engineers click-test a UI before a release will recognize the shape of it. The specific damage here is that broken AI applications have the potential to erode trust in AI as a category. The cost is the whole wave of adoption getting slower because people have been burned.
If you are building AI applications, the quality of your evals is now a competitive differentiator.
3. LLM-as-judge is the only way to scale, but it needs its own tuning.
Non-determinism is the real wrench. Traditional tests are essentially string matching: you put in an input, you expect an output, you check if it matches. With AI applications, the same input can produce a million different outputs, and a meaningful fraction of them will be correct. You cannot just check for a specific string.
For some cases, smarter string matching helps: check for “one hour ago” and “60 minutes ago” and other valid phrasings. But for anything requiring judgment, you need a judge. In production, at scale, that judge has to be another LLM.
The catch is that the judge LLM introduces its own layer of non-determinism. It has its own prompt, and that prompt needs to be tuned against real output to confirm it is actually measuring what you want it to measure, rather than producing good/bad labels at random.
If you are running evals in CI, where they need to execute reliably thousands of times a day, this is the architecture you are building toward: a test suite powered by an LLM that has itself been validated as a good judge.
4. Regression evals vs. capability evals: two different jobs.
One of the most useful frames in the conversation was the distinction between regression evals and capability evals. They are not interchangeable, and conflating them leads to poorly designed test suites.
Regression evals are what most people think of first. They are close to traditional tests: can my application still do the things I already know it can do? They are the safety net you run continuously.
Capability evals are different in a fundamental way.
“Capability evals are a test I expect you to fail. This is a test where I expect you to score 20 percent and then do better the next time and climb a hill of capability.”
Laurie Voss, Head of DevRel, Arize
The combination opens up serious possibilities. Because evals powered by LLMs include an explanation field alongside a score, you can feed the failure explanations from 100 runs back into a coding agent and ask it to improve the software based on what went wrong. No human required. The eval loop drives the development loop. This has not been fully productionized yet, but the pieces exist.
5. Context engineering is the whole game.
The conversation shifted toward agentic coding and the question of how close we are to agents that can build production software end to end. Laurie’s answer was grounded in a single concept: context engineering.
Every capability question in AI development comes back to context. Can this LLM be a doctor? That requires a human lifetime of context, and it does not fit in a window. Can this LLM build a website? Websites are a narrow enough domain that Laurie thinks we are close to an agent harness that can handle it reliably. Can this LLM build production software in general? Software development as a domain is too large for any current window or graph structure to cover well enough to one-shot it.
Context graphs, one of the tools Arize is working on, are a form of context compression: a way of defining which topics connect to which other topics so an LLM can navigate a large domain without losing things out the bottom of its window.
The practical takeaway for engineering teams building on AI today: the investment in skills files, harnesses, and structured context is what determines whether your agent makes good decisions or system-level mistakes.
6. Software developers always solve their own problems first.
There is a pattern in software development that Laurie named plainly: the community perfects tooling for its own domain before solving anyone else’s. The reason there are so many frameworks is that developers made their own environments excellent before turning to enterprise software, which is still, by most measures, remarkably bad.
The same dynamic is happening now. AI coding tools are improving fast because developers are building them and using them on their own work. The patterns being developed in AI coding evals, harness design, and context engineering will eventually transfer to other domains. But that transfer comes later.
For teams building AI products now, the implication is to pay attention to what the software development domain is learning. The patterns being forged here will be the foundations for whatever comes next.
If this episode got you nodding your head, subscribe to Confident Commit for more conversations like this one.
