The demo worked. The production system does not. So the team swaps in a newer model, rewrites the prompt, and runs the demo again. The model is rarely the problem. Nobody wrote down what good means, so nobody can prove this version is better than the last one.
Kerrigan Baron (they/them), CTO & Co-Founder9 min read
Last Wednesday I sat in a room in Amsterdam with a few dozen people who build AI systems for a living. Lena Shakurova of ParsLabs opened by asking how many of them would trust their own LLM outputs. A handful of hands went up.
Her title slide said the rest.
Vibe Testing Doesn’t Work.
That is the honest state of the field, and it is the same answer I get from enterprise teams sitting on a stalled pilot with a budget question to answer. The demo worked. The production system does not. The instinct is to blame the model, so the team swaps in a newer one, rewrites the prompt, and runs the demo again.
The model is rarely the problem. The problem is that nobody wrote down what good means, so nobody can prove the new version is better than the last one.
Unreliable is a different problem at enterprise scale
Shakurova started where any risk conversation should start, with the fact that the same input does not produce the same output. Everything downstream follows from that.
She split the consequences by likelihood rather than lumping them together, which is the useful move. Hallucinations and inconsistent output arrive free with the technology, so every team has them. Jailbreaks, injection attacks, and data leaks are far less common, and when they land they are critical. A risk register that treats those four as one category will underfund the second pair.
Her line on what that means for a product was the sharpest of the night. Working most of the time is not good enough. For a consumer novelty, most of the time is a feature. In finance, healthcare, or any regulated operation, it is the reason legal will not sign.
The ladder every team climbs, and the step they stop on
Most teams follow the same progression. They start in the playground, checking whether the thing works at all. That is vibe testing, and it is fine as a sanity check. It fails because you test different things in different ways every time, and you forget to re-test what already worked, so regressions ship silently.
Next comes structured manual testing, usually a spreadsheet the team walks before each release. Better, and unaffordable. It costs human hours on every change.
Then automated evaluation, whether that is a local script, a platform, or checks wired into the pipeline on every pull request. This is where most well-run programs stop and declare the problem solved.
It is not solved, and her summary slide said why in one line.
Automatic tests are to scale your human judgment.
Lena Shakurova, ParsLabs
Automation does not replace the human. It extends a judgment a person made, across a volume no person could read. Take the person out and you have a system that reliably measures the wrong thing.
The step before the tooling
Which puts the real first move outside engineering entirely. Before any test set exists, someone has to write down what an acceptable answer looks like in your domain.
She was blunt that this cannot be delegated to the system being tested. Ask the model what matters and you have automated your own opinion out of the process.
You yourself as a human define what is important.
Lena Shakurova, ParsLabs
The method is unglamorous. Run a workshop with the team. Read production logs by hand. Bring in the subject matter experts. Mine the standard operating procedures you already have. The output is a plain-language checklist, written by people who would be accountable for a bad answer, saying what the system must and must not do.
Buyers skip this because it looks like the least technical step in the program. It is the step every number downstream inherits its meaning from.
The loop
The three stages repeat rather than finish, and the definition of quality at the center is written by people. Framework presented by Lena Shakurova, ParsLabs, at AI Builders Amsterdam, 22 July 2026.
Three stages, and they repeat rather than finish.
Her procedure for that last stage is the part worth copying exactly. Select the problematic traces. Extract the conversation history up to the point where it went wrong. Write evaluators that check whether the conversation passes criteria, either as unit tests or with a model as judge. Then maintain a golden dataset of expected question and answer pairs that must never regress.
That last phrase is the one to bring to your own team. Most enterprises have no such dataset, which means they have no floor.
One score hides the failure
Four metric families, each asking a different question. Metric families as presented by Lena Shakurova, ParsLabs, at AI Builders Amsterdam, 22 July 2026.
Her metrics slide split into four families, and the split matters more than any individual metric. Retrieval quality asks whether the system found the right source material. Tool and function calling asks whether it acted on the right system with well-formed arguments. Generation quality asks whether the answer itself was any good. Conversation quality asks whether the whole exchange reached its goal, measured by task completion, context retention, and steps to resolution.
A single aggregate score cannot tell you which of those four broke. Teams that report one number spend the next sprint guessing.
Two constraints that bite harder in Europe
Two audience questions surfaced things a consumer-scale team can wave off and a regulated European operator cannot.
The trap on the other side
The failure mode after buying the tooling is treating the purchase as the finish.
It’s not enough to set it up. You have to use it and you have to maintain it.
Lena Shakurova, ParsLabs
An evaluation suite that never changes measures last quarter’s product. Every real failure found in production is supposed to become a new test case, and the standing routine has to include a random sample of conversations the automated labeling never flagged, because that is the only way to catch what your labels are blind to.
Which brings the whole thing back to the inversion she closed on, borrowed from a practice most engineering leaders already run. First update your test set and your judges. Only then update your prompt. Do it the other way around and, in her words, you were prompting for the sake of prompting. You changed something, the demo felt better, and you have no evidence either way.
What to do on Monday
None of this requires new procurement.
The first four are engineering. The last two are operating model, and they are where most programs quietly stop.
Sitting on a pilot that will not cross into production?
That is the conversation we have most often. Talk to us about getting a stalled pilot into production, starting with what it would take to prove the next release is better than the last one.
Shakurova maintains a public library of evaluation tooling, sorted into no-code tools, Python libraries, safety and moderation guardrails, and voice agent evaluation, which she puts at sixty or more entries. It is email-gated and worth the address. Her worked references on logging and on evaluating multi-turn conversations both point at Langfuse documentation, which is a reasonable starting point whatever platform you land on.
Evaluation is not a phase of a build. It is a capability an organization either has or does not, which is why it belongs in the Modernize stage of our ATOM method, Assess, Tailor, Orchestrate, Modernize, and inside the AI Center of Excellence operating model rather than in a project plan that ends at launch.
If you have systems in production and no answer to how you would prove this release is better than the last one, that is the gap worth closing first.
Kerrigan Baron (they/them)
CTO & Co-Founder
Kerrigan leads the technical side of Fidget Labs. Twenty years of enterprise delivery across composable architecture and AI enablement, most recently as Senior Technical Director for MACH and composable technologies at Valtech. They lead delivery for the MACH AI Exchange under contract with the MACH Alliance Tech Office, and write Focal Point.
