Is Jev useful for AppSec?

Jev is fast, cheap, and honest about its confidence. It can't tell you whether code is risky, but it can tell you when to ask.

TypeSafe AI shipped Jev last week and people reacted like it was a new SOTA model. Vercel says it's the fastest-adopted model in the history of their AI Gateway. LangChain had an integration inside three days. It's safe to say our appetite for AI news hasn't slowed. But, the founder has serious credentials, so let's take it seriously and consider it in software security.

Jev is not an LLM, and it doesn't generate text. You hand it context and a decision shape (pick one of these options, score this on a scale, give me the probability this statement is true) and it returns a typed answer with a calibrated confidence in about 100 milliseconds, for a few hundredths of a cent. TypeSafe calls it a "System One" model,[1] after Kahneman:[2] fast, intuitive, no deliberation. The pitch is that most of what we ask LLMs to do in production is actually a classification, and we're paying System Two prices for it.

So the obvious question for anyone building security tooling: can I use this to save my customers some scratch?

The checklist

A task is a fit for Jev when it clears three bars:

1. It needs speed or volume. Sub-second latency inside a loop, or millions of decisions where LLM pricing doesn't pencil out.

2. It decomposes into a workflow of classifiers. You can write down the decision tree in advance, and each node is a pick, a score, or a yes/no.

3. It doesn't require thinking. A System One model gets one forward pass. No chain of reasoning, no "wait, let me check." There are two ways a decision needs thinking: reasoning over evidence you have, and going to get evidence you don't. Jev doesn't really do either.

TypeSafe says Jev matches frontier models on System One tasks. That's their eval, on their definition of System One, and the early independent results are mixed: Vercel reports better accuracy than an LLM on command safety, another early adopter reports slightly worse than Gemini on email classification. The fair reading is that for a decision that really is a pattern match, it's competitive. So the question is whether your decision is a pattern match.

Hard AppSec fails all three

The central question in appsec is some version of "is this code risky?" Is this PR safe to merge? Does this new endpoint need auth? Is this dependency going to hurt us? Did this refactor just remove a check somebody was relying on? Every one of those looks like a classification, and every one of them fails the checklist.

Speed or volume. At first glance appsec looks like a volume problem. Every commit, PR, and dependency bump raises the question, and across a big org that's a lot of questions. But most of that volume is noise you don't need a model to throw out: docs, tests, vendored code, generated files, formatting-only changes. A few if statements handle it. Once that's gone, what's left is a modest number of changes that each take real time to evaluate, and nobody is sitting there waiting on a security review with a spinner. The speed doesn't buy you anything.

Workflow of classifiers. We've been here before. A few years ago there was a run of research and startup effort on training neural networks to look at a chunk of code and say "vulnerable" or "not vulnerable," no rules, no dataflow, just a classifier.[3] The papers reported accuracy in the 90s. When somebody finally tested those models on code they hadn't been trained near, performance fell by more than half, and it turned out they had mostly learned which variable and function names show up in the vulnerable examples. The problem wasn't the models. It's that the classifier only sees the chunk you hand it, and the risk in a chunk of code is almost never completely in the chunk alone.

Doesn't require thinking. Appsec fails this bar in both ways. Take a PR that adds a next query parameter to the login handler and redirects to it after authentication. Is that an open redirect? Whether it's risky depends on a URL validator defined in a helper the diff never touches, whether the framework's redirect call already rejects off-host targets, and whether this handler is even reachable through the router config. The evidence for the verdict is not in the diff. It's in the codebase, and the skill is deciding what to open next. Jev can't open anything.

FIG 1 — Whether the diff is an open redirect depends on three files the diff never touches. A model that cannot open them is guessing at the base rate for redirects.

Now suppose you paste all four files into the prompt — does that solve the problem? The verdict still isn't a reflex. Does the validator's allowlist include the host the attacker would use? Does it run before or after the redirect is built? Is the auth requirement on the route or on the controller method the route skips? Each of those is a step, and the answer to one changes which step comes next. A model built to skip deliberation has to have already memorized the shortcut, and there's a different shortcut for every codebase. You could imagine an agentic orchestrator which invokes System One thoughts, but if we're already eating the penalty of LLM calls, how much can we be gaining by adding these types of primitives in?

Why not just chain a bunch of Jev calls?

If you're tempted to wire Jev into a risk-scoring pipeline, consider what you'd be building. Does this diff touch input handling? Does it look sanitized? How risky is it, one to ten? Chain enough of those together and you've rebuilt the code-classifier idea from a few years ago with a much better classifier at each step. That's an improvement, but it's the same architecture, with the same ceiling: the model can only decide over what you handed it, and the work of deciding what to hand it is the whole problem.

FIG 2 — Swap the old code classifier for Jev and you get a better step and a real probability. The dashed step is unchanged, and it is where the risk actually gets decided.

The failure mode is already well-understood for these types of classifiers. In one early hands-on test, Jev was given three department options with no "other" and asked an unrelated question. It picked "sales" at 0.31 confidence. Forced-choice models don't abstain, and so they'll lead to derangement in situations where no clear answer is correct. In a support router, that's a misrouted ticket. In a PR gate, that's a risky change potentially waved through.

It's a lot of work to build, and it doesn't generate the assurance that a full-on SOTA model could give.

Where it actually fits

I can definitely imagine some places Jev could help in AppSec. Not answering the hard question, but deciding whether it needs asking.

Here's the version I'd build. An agent watches every file edit in a repo. Almost all of them are boring, and calling an LLM on each one would be cost-prohibitive. What you want is a gate that answers, in a hundred milliseconds, "did this edit add a dependency?" or "did this edit touch an auth check, a new route, or a place user input enters?" and only wakes the expensive model when the answer is yes. That gate is a perfect Jev task. The evidence is entirely in the diff. The choice has a natural "no." The volume is enormous. And the asymmetry works in your favor. If the gate says yes and it didn't need to, you've wasted one LLM call. If you're worried about it saying no when it should have said yes, you lower the bar: wake the analyst at 20% instead of 50%. That knob only works because Jev's percentages are meant to be real probabilities, not the vibes an LLM gives you when you ask how confident it is (ok, well, Jev is still kinda vibes too, but they're calibrated vibes).

This is roughly how Kahneman describes the two systems working together anyway. System 1 is running all the time, and part of its job is noticing when something deserves a closer look so System 2 gets pulled in. Deciding whether the code is risky is beyond Jev's scope. But you can ask it whether the change is definitively safe, or can be ruled out, and let that decide whether something smarter takes a look.

The second place is the harness around the analyst. When you run an agent that investigates code, that agent is constantly making small System One decisions that have nothing to do with security expertise. Is this shell command destructive? Does the web page it just fetched contain instructions aimed at it? Does the success claim it just made match the tool output it just got? Those are the checks where an LLM is slow and poorly calibrated.

FIG 3 — Every cyan chip is a decision Jev is shaped for: fast, forced-choice, evidence in hand. The top chip decides whether the pink box gets woken up at all. The pink box is the one that still has to go and look.

Both roles lean on the one thing Jev has that LLMs don't: a probability you can threshold on. When an LLM reports a confidence score, the number means very little. If TypeSafe's calibration training holds up under adversarial input, a real 0.94 versus a real 0.31 at a gate is worth a lot. That's where I'd spend it.

The analyst still has to be System Two. The evidence isn't solely in the prompt, and the verdict isn't a reflex. But deciding when to call the analyst is a reflex, and that appears to be a job Jev can handle in many cases.

We'll be looking at this deeper in our own product, for sure. The question I keep coming back to is what enterprise AI governance teams do with models like this. The review process most of them have built assumes a handful of big models with big vendors behind them. A hundred tiny classifiers making a hundred tiny decisions a second, each one too cheap to log and too fast to review, is a different thing to govern.

Notes

1. TypeSafe introduces the term in their launch post, Introducing System One Models & Jev (September 15, 2026), along with the speed and cost claims quoted here.

2. The System 1 / System 2 labels were coined by Keith Stanovich and Richard West in "Individual differences in reasoning: Implications for the rationality debate?" (Behavioral and Brain Sciences, 2000) and popularized by Daniel Kahneman in Thinking, Fast and Slow (2011). System 1 is fast, automatic, and associative. System 2 is slow, effortful, and sequential. The distinction is a useful metaphor for what Jev does and doesn't do, not a claim about the model's internals.

3. VulDeePecker (2018) and Devign (2019) are the well-known examples. Chakraborty, Krishna, Ding, and Ray's "Deep Learning based Vulnerability Detection: Are We There Yet?" (IEEE Transactions on Software Engineering, 2021) is the paper that measured what happened when those models met realistic code: performance dropped by more than half, and the models turned out to be keying on specific variable and function names rather than anything about the vulnerability.