Jev is the if statement of AI

Daniel Baden — Fri, 02 Oct 2026 08:35:11 +0000

You would never call an LLM to compare two numbers. Yet that is roughly what we all do with AI right now: we hand a model that could draft a legal opinion a question with two possible answers, and we pay it to write a paragraph. Recently, a model arrived that is built for exactly that question. It is called Jev, and to us it is the if statement of AI.

The branch you can't write down

"Does this really need an LLM?"

Every AI feature is full of branches. Is this email a complaint or a change request? Is this inquiry for a catalog part or a custom build? Does this change request mean the drawing has to be released again? Does this invoice match the purchase order?

An if needs a condition you can write down. A comparison you can write down. "The customer sounds annoyed" you can't. So the condition moves into a prompt, and the if turns into a call to an LLM.

What that call really costs

The LLM answers in prose: "This is most likely a complaint, since the customer…". You parse it, and tomorrow the wording shifts. Or you force structured output, and the model still generates your one-word label token by token. Either way you run a generative model to produce a label. Ask it how sure it is, and it writes you a number that nobody computed.

For a yes or no, that is the most expensive if you can buy.

We do it ourselves. When a file lands in the inbox folder of our repo, an LLM reads it and writes a paragraph about where it belongs. This is the actual table it chooses from:

What it is	Where it goes
Brand-wide asset (logo, scene, wave)	`brand/assets/`
Study, reference, mood sample	`brand/assets/referenzen/`
Image for one piece of content	`content/<piece>/images/`
Legal text	`legal/`
Research, channel or SEO material	`strategy/`
Raw material for a story	`strategy/story-series/` if it belongs to the series, else the matching `content/stories/` folder, as input for the draft

Six destinations. A choice, dressed up as a conversation.

What Jev does differently

Jev, from TypeSafe AI, generates no text. You give it unstructured input and the set of answers you allow, and it returns one of them with a calibrated probability. The maker's own summary: "unstructured state in, typed probabilistic decisions out". An answer outside your schema can't happen, the maker says. The class name, System One model, borrows the split between fast, intuitive System 1 thinking and slow, deliberate System 2.

By the maker's numbers, Jev is about 194 times faster and 445 times cheaper than an LLM on this kind of task. Its example: 0.11 seconds against 8.6. Alex Xu of ByteByteGo puts it as 1,500 emails for about three cents.

The else belongs to a person

A probability gives the branch a real else. Above your threshold, the email goes straight to quality assurance. Below it, someone in customer service reads it first. You set the threshold, not Jev. ByteByteGo calls this a confidence gate.

That is the part we like most. An AI that tells you when it isn't sure is something we have wanted for a long time. A calibrated probability is only as good as its calibration, though. Until you have checked it against your own data, your threshold is a guess, so that check comes first.

What it can't do

Jev writes no reply to the customer and gives no reason for its choice. It can still be wrong, just within your list. And for now it is only available in early access, through a waitlist.

Our bet

Alex Xu splits the work like this: the LLM for generation, Jev for the decisions around it. We go one step further. A year from now, hardly any AI feature will let an LLM make its decisions. The LLM will only write.

Go through your prompts and count the ones that end in "answer yes or no". How many ifs are hiding in there?

This report was written in German for decision-makers at knopfdruck.ai.

Your AI had questions. It answered them in the code.

Daniel Baden — Tue, 22 Sep 2026 14:16:31 +0000

If you build with AI every day, you know the pattern: the AI delivers, it runs, the tests pass, you nod. A few weeks in, nobody asks why it built things the way it did. With a UI you would notice, because you can see it. With logic in the background you see nothing.

We caught ourselves doing it. This post is about the mechanism behind it, and what we changed.

A paragraph and a few samples

Say a quote price comes together like this: material cost and setup time, plus a surcharge that depends on quantity. You write that down in one paragraph, attach a few old quotes as samples, and hand both to two people: a new colleague and an AI.

The colleague comes back an hour later with questions. What about a material that appears in none of the samples? At what quantity does the surcharge kick in, and does it jump or grow? And a third one you hadn't thought of.

The AI comes back a minute later with a calculation that runs and hits every sample to the cent.

"Looks good."

The AI had the same questions. It asked none of them and answered all of them, in the code, without a word.

Why green tests can't see it

A paragraph plus samples doesn't define one rule. It defines a family of rules: every rule that reproduces the sample results. A stepped surcharge and a linear one can agree on every quote you attached. So can a fallback that prices an unknown material like steel and one that throws an error.

The AI has to pick one member of that family. It picks one that fits the samples, and it doesn't mention that there was a choice.

Now look at where your tests come from. If they are built from the same samples, they check exactly what the AI already optimised for, and every rule in the family passes them. Green means the code fits the samples. Whether it implements the rule you meant, those tests can't say.

The difference shows up with the first input that isn't like the samples: the unusual material, the odd quantity. It shows up in production, not in the test run.

We saw this ourselves. When we asked the AI how exactly it calculates, its answer described a different rule from the one we meant. The tests had passed anyway, because the samples fit both rules.

Getting the questions out first

The fix isn't less AI. It's a different start: the AI has to surface its decisions before it writes any code.

So before anything gets built, the AI answers in prose, with no code:

how it understood the paragraph, restated in its own words
which cases it sees, including the ones no sample covers
where it would have to decide something by itself: a default, a threshold, a rounding step, what happens with input it doesn't know

We answer, and it restates again. Round by round, until its restatement and our rule are the same rule. Only then does it build.

That changes two things downstream.

The tests come from the agreed rule, not just from the samples. Every question that came up in the rounds becomes a test case, so the suite finally holds inputs the samples never had. A passing test now confirms a rule both sides know.

And we still read the code, even when it runs. The quickest thing to look for is a constant or a special case that appears in the code and nowhere in the agreed rule. Each one is a decision nobody asked for.

Skip the rounds, and the decisions still get made. You've just handed them to someone who doesn't ask.