A while back, my colleague and I were evaluating Promptfoo as a candidate for our LLM testing workflow. One of the things we wanted to find out was simple: how well does AI-assisted test generation hold up when you actually lean on it? So we had it generate three test suites – cases, assertions, the works – and ran them.

The pass rates came back between 80% and 92%. For a first pass, that's the kind of number that delivers a small, very satisfying hit of dopamine and makes you want to screenshot the dashboard.

Then we did the part the evaluation was really for. We read the tests. Line by line.

At least 15–20% of them had the same problem: the system that wrote the test was, in effect, the one grading it. The assertions rested on assumptions the generator had made up along the way – and those assumptions were flaky at best. The tests weren't passing because the behavior was right. They were passing because the test and the grader agreed with each other. False positives, dressed up as coverage.

We revised every one of them – and since we're still very much in pilot mode, none of it has gone anywhere near our real workflow. What stuck with me wasn't the rework, though, it was how good the numbers looked right before we found the problem.

That's exactly why you pilot a tool before you commit to it. But I have a feeling plenty of teams don't – and that pushing for fast generation and a wall of green checkmarks is happening a lot more often than most of us would care to admit. When an agent can produce a hundred tests before lunch and the dashboard says 85%, reading them line by line starts to look like the thing slowing everyone down. It isn't. It's the only part that tells you whether the 85% means anything.

That leaves three questions I want to work through:

• When AI writes, reviews, tests and heals our software, where does accountability actually sit?

• Does "shift-left" still mean anything when the machines are standing to the left of us too?

• If all the outcomes look fine, what should QA be looking at instead?

The closed loop nobody designed

Lay out the modern AI-assisted SDLC and it looks like a relay race where every runner is the same species. A coding agent writes the feature. A test agent generates coverage. An LLM – or, increasingly, a decision model like Jev – judges whether outputs are acceptable. Eval and red-teaming frameworks like Promptfoo score the prompts. Self-healing keeps the regression suite green when the UI drifts.

Every step is reasonable. Some are brilliant. Promptfoo mattered enough that OpenAI announced it was acquiring the company in March, by which point its tools were already used by more than a quarter of Fortune 500 companies.¹ Jev, launched by TypeSafe AI in mid-September, returns typed decisions with calibrated probabilities instead of prose,² and eval frameworks like DeepEval are already routing judge verdicts to it.³ Cheap, fast judgment is suddenly everywhere.

But chain it all together and you get something none of us designed on purpose: a system that grades its own homework, just with a different pen each time. Our Promptfoo pilot was that loop in miniature.

Confidence isn't correctness

Jev is genuinely interesting here because it's honest about uncertainty. Instead of a confident paragraph, you get a probability. Research on using it as a judge frames the value neatly: accept the decisions it's confident about, and escalate the uncertain ones to a stronger model.⁴

Read that twice. Escalate to a stronger model. That's a perfectly sensible design for benchmarking. As the only safety net in a release pipeline, though, it quietly removes the human from exactly the decisions that need one the most.

Then there's the question of what "confident" means once you leave the lab. One study found Jev's probabilities rank cases well but don't transfer cleanly as thresholds across benchmarks.⁵ Another showed injected malicious content can shift its action probabilities – rarely enough to flip the decision, but enough to move the numbers.⁶ So the threshold you tuned in staging isn't a law of physics, but a hypothesis, and somebody needs to own re-testing it.

The same logic applies to self-healing. A healed step is a test change that happened without a pull request. When a healer – DOM-based or vision-based – picks the wrong element and the test still passes, that's a false positive with a very good alibi. And it's another checkmark with no name next to it.

Shift-left is really shift-ownership

For years, "shift-left" meant testing earlier. AI has made testing almost free at every point in the pipeline, so "earlier" isn't the scarce resource anymore. What's scarce is intent – a clear, human-owned answer to "what are we actually trying to prove?"

QA Wolf's recent write-up on semantic assertions with Jev captures the pattern better than most process docs I've read: code owns the workflow and the requirements, and the model only supplies narrow judgments where rigid rules get brittle.⁷ Their rule of thumb is to permit variation only outside the requirement. That's not just a testing technique, but an ownership model – someone decided, in advance and in writing, where the machine is allowed to have an opinion.

That decision is the shift-left. It happens at design review, not in the pipeline, and the SDET should be the one asking: What must never vary? What's allowed to? What would convince us this works – and what would convince us it doesn't?

Look at the test, not just the outcome

When everything is green, outcomes stop being informative. So the review has to move from "did it pass?" to "is this worth passing?" Here's the checklist I've started using on AI-generated and AI-healed tests:

• Trace it. Which requirement does this test protect? If nobody can say, it's decoration.

• Separate the writer from the grader. If the same model generated the test and judges the result, you're measuring agreement, not correctness.

• Break it on purpose. Introduce the bug the test claims to catch. If it still passes, you've learned something important and slightly embarrassing.

• Diff the test, not just the code. Healed selectors, rewritten assertions, and "updated snapshots" are test changes. Review them like it.

• Ask who set the threshold. Every AI judge has one. Who picked it, when was it last checked against negative examples, and where is that written down?

• Keep a name on it. Every test and every judge config should have an owner who can explain it without asking the agent.

Accountability doesn't autoscale

In my last post, I argued that "AI generated it" should be the start of a conversation, not the end of one. The same goes for "AI approved it" and "AI healed it". The tools aren't the problem – I use most of them daily and wouldn't go back. The problem is that each one quietly absorbs a decision, and decisions without owners are how you end up with a pipeline that's always green and a product that's occasionally on fire.

Good requirements are where that ownership starts. They're the one artifact in the whole loop that a machine can't write for you – or rather, it can, and that's precisely the problem.

A green checkmark doesn't come with an owner by default. Someone has to sign for it.

References

1. TechCrunch, "OpenAI acquires Promptfoo to secure its AI agents," Mar 9, 2026 – https://techcrunch.com/2026/03/09/openai-acquires-promptfoo-to-secure-its-ai-agents/
2.  AWS Builder Center, "Jev Isn't Another LLM: Could Decision Models Become a New Layer for AWS Agents?" – https://builder.aws.com/content/3Jm5jYPrskJbBEqxoNZaYYcAYk6/jev-isnt-another-llm-could-decision-models-become-a-new-layer-for-aws-agent
3. DeepEval, "Introducing Jev for Evals" – https://deepeval.com/blog/introducing-jev-in-deepeval
4.  "JEV-as-a-Judge: Accept When Confident, Escalate When Unsure," arXiv – https://arxiv.org/pdf/2609.26550
5.  Ruoqi Guo, "Just Ask Jev: Reinforcement Learning for Calibrated Decisions as a Zero-Shot Detector of AI Alignment Failures," arXiv – https://arxiv.org/pdf/2609.29429
6.  "Decision Hijacking: Prompt Injection Attacks on Jev's Typed Probabilistic Decisions," arXiv – https://arxiv.org/pdf/2609.28613
7.  QA Wolf, "Semantic assertions: Using Jev to make rigid tests flex" – https://www.qawolf.com/blog/semantic-assertions-using-jev