The testing suite proves what you specified. The bugs live in what you did not.

A regression testing suite is an argument about what you already know. Every scenario in it exists because somebody once thought of it, wrote it down, and agreed it mattered. That is its strength: it is a contract, it runs unattended, and it holds up in front of an auditor. It is also its limit. The suite will never find the thing nobody thought to specify, and that is where a stubborn share of production incidents actually comes from.

The testing suite does not move

Our position on test automation has not changed and is not about to. A framework-supported testing suite, with scenarios written in Gherkin so that the business reads the same sentence the engineer automates, running unattended at every step toward release. We have written about the difference between that and a ticked box in a spreadsheet, and it remains the single largest lever on whether software holds its value over five years.

What follows is for people who already own a regression suite and are wondering what models change about it. Without the systematic base, exploration still turns things up. It just has nowhere to land them. A finding gets fixed once, nothing stops it coming back, and testing becomes something you report rather than something you own.

Mapping what a feature can do is a writing problem

Before anything can be tested, somebody has to say what a feature is even capable of doing. The inputs it accepts and where their limits are, which roles are allowed to do what, every language and tax rate it has to get right. The states an order or a patient record can be in, and the jumps between them that are supposed to be impossible. Done properly this is slow work, and in many teams it happens at the end of a sprint, which means it is done badly.

This part is writing, and small fast models are good at it. We use them for it routinely now: list the dimensions of a feature, produce the boundary cases, cross the permission table against the state machine, and hand a human a list to prune rather than a blank page. The model is generous and occasionally silly, the engineer strikes out two thirds of it, and what survives covers more ground than the same engineer would have written unaided in the same hour. The same goes for keeping the suite alive: selectors through a redesign, a scenario ported across three languages, or which of the forty failures in a red pipeline share one root cause.

That is most of what we mean when we say AI buys speed, not permission. The suite got bigger and cheaper to keep, and the map got better drawn. Neither of those things walks the territory.

Walking every path is a judgement problem

Exploratory testing is the discipline of going looking for the unspecified: a tester with product knowledge driving the application, forming a hunch, following the odd thing, and knowing a screen is wrong even though no assertion says so. In our experience it turns up a category of defect the suite is not looking for, for a simple reason: the suite only knows what was already written down.

We already point small models at this, and it works. A cheap model can be asked whether a screen looks broken, whether a path has been covered already, whether an error message is a real defect or the validation doing its job. It does not get tired after ninety minutes, and it does not skip the boring corner of the table.

What it does not do is come free. Every one of those questions is a written answer: tokens out, a second or so of waiting, and a line on the bill. The cheap tier is genuinely cheap now, and it spans more than one vendor:

• The Claude Haiku family: the small, fast end of the Anthropic range.
• The Gemini Flash-Lite family: Google’s high-volume tier.
• Open models, self-hosted in Switzerland: Llama, Mistral, Qwen, Gemma. The strongest protection your intellectual property can get, because nothing leaves your own infrastructure at all.

Any of those is comfortable at a few hundred decisions in a run. At a few hundred thousand, which is what genuinely walking a large application looks like, the waiting becomes the binding constraint long before the invoice does. So exploration stays rationed: broader than it was, still rationed.

A model that gives up writing

In September 2026 TypeSafe AI released Jev, the first of what it calls System One models, a name borrowed from Kahneman’s fast, intuitive mode of thinking. The trade it makes is unusual: it gives up writing entirely, and cannot produce a sentence, a test, or a justification. What it returns instead is a typed value with a calibrated confidence attached, in a single pass.

Three shapes cover most of it: one probability for a yes-or-no question, a spread across options you defined in advance, up to 255 of them, for multiple choice, and a weighted value on a scale you set for a rating. Because nothing is being written, the whole thing lands in 70 to 500 milliseconds, and the cost of the tokens produced disappears entirely. Against the cheap writing tier, that is a different order of magnitude, not a discount.

Jev is not alone in the shape: Laya explored the same idea as an open model in 2025 and is faster still, and a handful of open peers have appeared since. The category matters more than the vendor, which is fortunate, because Jev itself is behind a waitlist.

Where a decision model sits

A decision model cannot explore anything by itself. What it does is answer the judgement questions an exploration run throws off, and the structure of that run is the same whether a small writing model or a decision model is sitting in the judgement seat.

That is the loop we run today. Handing that judgement to a decision model does not change its shape. It changes what a step costs, and cost per step decides two things. The first is how much of the application a run can afford to walk. The second is how quickly the verdict comes back, which is the half operations actually feels. On one client system, a quick check walks the ten user journeys a change could have touched on the test environment, and comes back while the developer still has the change in mind. What it catches most often is a feature broken as a side effect: something adjacent to the change that nobody thought to reopen. The full suite runs as it always did and confirms it later, often after the fix is already in. A recent paper wires Jev and Laya into an open-source penetration-testing harness at exactly four such points and reports decision latencies of roughly 250 milliseconds for Jev and 35 for Laya. The authors are clear that it was a single run against a single target: a design proposal with motivating observations, and we read it as one.

One technique is worth stealing whatever model you use: these models are much better at relative judgements than absolute ones. Do not ask for a score on every candidate action. Feed them in batches and run a second pass on the winners.

What actually leaves the building

Sending anything to a model you do not operate is a question worth asking out loud, particularly for clients who answer to a regulator. For this loop the answer is comfortable.

What gets sent is small and dull. A fingerprint of the current screen, a list of candidate next actions, and one narrow question about them. No document, no record, no history. And it is pointed at a test environment: invented patients, invented orders, invented people. The production database is never in the loop, because the whole point is to run against a build before anybody real is on it. What comes back from a decision model is a number, and a number cannot leak anything it was not given.

Where a client needs more than that, the options are good now: an open model self-hosted in Switzerland, which we reach for when the concern is intellectual property, or a Swiss endpoint such as Infomaniak, which serves the same open models from data centres here, keeps no record of the queries, and operates under FADP and GDPR. It is the same jurisdiction argument that already decides where we run client platforms, applied to one more piece of the stack: no customer data in public models without explicit consent, and a Swiss or EU endpoint when the work calls for one.

What we are excited about

Judgement was the expensive input, and a decision model changes exactly that: an order of magnitude, not a margin.

We have not run Jev. It is days old, behind a waitlist, and does not take images yet, so a run has to work from the page structure rather than from a screenshot. Its own documentation puts numbers, dates, and adversarial input in the weak column. None of that dampens the interest much. Jev is the first credible answer to the half of testing that never got cheaper, and we will point it at our own applications first, next to a suite that already passes. The bar is not an impressive demo. It is finding something the suite missed, twice, without burying us in false positives. We will report what happens either way.

Two problems, two kinds of model

The testing suite is still the asset. Nothing here moves a scenario out of Gherkin, and nothing here changes what has to be green before a release goes out.

What has changed is that mapping out what a feature can do and walking through all of it are different problems. Mapping is writing, and small fast models do it well enough today that we no longer start from a blank page. Walking is judgement, one call at a time, thousands of times over. Judgement is the input that has stayed expensive.

Keeping the suite current and the exploration runs cheap is a standing job here, not a project. Decision models are the most interesting thing to happen to the second half of it in years, and we are watching them closely.