AI made writing code cheap. It did not make approving code cheap.
Every team that has put coding agents to work has hit the same wall. The agents produce more, and the work piles up at the places where a person has to say yes: spec sign-off, code review, test approval, release. The gates were built for human-speed output. Now they set the pace for everything behind them.
The obvious answer is to let a machine make some of those calls. The less obvious question is which ones.
An LLM writes. A System 1 model decides.
Until recently, "use AI for the decision" meant asking a large language model. That works, but it is a heavy tool for a yes or no question. An LLM reasons in text, token by token, takes its time, and costs real money every time you ask.
A new kind of model is built for the yes or no. TypeSafe AI calls it a System 1 model, after the fast, intuitive half of human thinking in Daniel Kahneman's framing. Its first one, Jev, does not write anything. You hand it the state of the work (a ticket, a pull request, a set of logs) and a typed question. It hands back a structured answer with a calibrated probability that code can branch on. TypeSafe reports decisions in roughly 70 to 500 milliseconds, at a fraction of a cent each.
The questions come in three shapes:
- Pick one. Which of these options fits? Route this ticket to the right queue, or choose the model that should handle this task.
- Score it. Where does this fall on a rubric you define? How clear are these requirements? How risky is this change?
- Yes or no. Does this condition hold? Is this ticket ready to start? Is this action safe to run unattended?
One request can ask all three about the same piece of work.
A System 1 model can still be wrong. What it cannot do is ramble, invent a format, or bury its uncertainty in prose. The probability tells you when to trust it.
In that framing, LLMs are System 2: slow, deliberate, and good at producing things. Most real work needs both. System 2 drafts the change. System 1 decides whether the change can move. The LLM only gets involved when words are the deliverable, or when the System 1 model is unsure.
Speed is not the hard part
A fast, cheap decision is only useful at the right gate. Hand the wrong gate to a model and you trade a review queue for rework, incidents, and a team that stops trusting the automation.
So the real questions are about your process, not the model:
- Which gates are worth automating? The good candidates take a lot of human review time and almost always end the same way. A gate where reviewers wave through nearly everything is a strong candidate. A gate where a few decisions carry most of the risk is not.
- Does the decision have the context it needs? A System 1 model only judges the state you send it. Approving a change well means knowing the ticket it came from, the code it touched, how the checks went, how similar work went before, and what the agent did along the way.
- Did it work? Automating a gate should shorten cycle time without raising rework downstream. If the work comes back from QA or production more often after the switch, the gate was not ready.
- Can you show what was decided? In regulated work, an automated approval is only acceptable if you can see each one and why it went the way it did.
Confidence is also how you sort the gates. Decisions the model is always certain about can become plain rules. The uncertain middle is where a System 1 model earns its keep. The truly ambiguous calls go to an LLM or a person.
These are the questions Bloomfilter is built to answer. We map how work actually moves, by people and by agents, from ticket to production. That shows where review time goes, which gates are predictable, and what happens downstream of every decision. The same history (similar tickets, how long they took, which process rules apply, what agents did) is the context that makes a gate decision good. It is the evidence you need before you hand a gate to a model, and the measure you need after.
A concrete example: Flora's Auto mode
We are putting this to work in our own product first. Flora, Bloomfilter's AI assistant, takes actions in the systems your teams already use, like creating and updating work items. Until now, every one of those actions waited for a person to approve it.
Flora now has two approval modes. In Ask mode, nothing happens without a person saying yes. In Auto mode, an action that needs approval goes to an approval gate instead of waiting in a queue. The gate hands Jev the context Flora already has (the task, the conversation, the action and its details) and asks one yes or no question: is this action safe to approve? Lower-risk actions go ahead and Flora keeps working. Risky actions, and anything the check cannot assess, are blocked and wait for a person. If the risk check is ever unavailable, Flora falls back to Ask mode rather than guessing.
An organization sets the default, and individual chats and automations can choose their own. Every action shows whether Auto approved it, blocked it, or could not assess it, so the record of what the machine decided sits right next to the work.
That is the pattern we expect most teams to follow. Start with a gate where the stakes are clear, let the System 1 model take the routine calls, and keep a person on the uncertain ones. Then monitor the new system live, not just downstream. We track every call Jev makes in Auto mode and weigh its decision against what we would expect. That is how we make sure our weights are configured properly and are not approving any harmful decisions.
Beyond approvals
The same pattern fits anywhere a pipeline makes a pick-one, how-much or yes-or-no call:
- Model routing. Send simple asks to a fast, cheap model and hard ones to a reasoning model, so you only pay for reasoning when the work needs it.
- Ticket readiness. Check whether a ticket is clear enough to start before an agent picks it up, and have an LLM draft clarifying questions only for the ones that fail.
- Risk scoring. Score a task, epic or initiative for risk as it moves, and escalate the ones that cross a line.
Where to start
You do not need to automate every gate, and you should not. Pick one. Choose a gate where people spend real time and almost always agree.
Then run the model in the shadow first. Let it make the call on real work without acting on it, and compare its decisions with what your people decided. Once you trust the threshold, switch it on and track cycle time, rework and how often people override it, against the baseline you measured before. Keep the uncertain calls with a person.
The teams that get this right will not be the ones with the fastest models. They will be the ones who know their process well enough to say which decisions a machine should make, and can prove it was the right call.
If you want to see which of your gates are ready, talk to us.