Jev: The AI That Doesn’t Talk — and Why It May Change How We Build AI Systems

Deterministic softwareFast decisionsDeep reasoningHuman judgement

Imagine somebody announced a new AI model and then told you it couldn’t really have a conversation, wasn’t designed to write an article and wasn’t intended to spend minutes reasoning through a difficult problem.

At first glance, that might sound like a step backwards. I think it may be something much more interesting.

I recently watched two discussions about Jev, the new model from TypeSafe AI. The first was TypeSafe co-founder and CEO Diogo Almeida explaining why they built it. The second explored what you can actually build with it.

What caught my attention wasn’t another set of benchmark numbers. It was the architectural idea underneath them.

For the last few years, the AI industry has largely been trying to make increasingly powerful Large Language Models do almost everything:

reason, write, classify, route, verify, decide which tool to call, decide whether another model is required and sometimes even judge whether their own work is correct.

Jev asks a rather different question:

What if we stopped using our most powerful language models for decisions that don’t require our most powerful language models?

That question has significant implications for AI agents, software automation and the work I am doing with GanderKnowledge.

Who is Diogo Almeida?

There is an interesting backstory here, because Jev hasn’t appeared from somebody standing outside the development of modern LLMs criticising them.

Diogo Almeida was part of that development.

Before founding TypeSafe AI, Almeida worked at OpenAI and contributed to the techniques behind InstructGPT and RLHF that subsequently helped shape ChatGPT and modern conversational AI. Before that, he worked at Google Brain.

That makes his current direction particularly interesting.

He isn’t arguing that LLMs don’t work. He helped develop some of the techniques that made them work as well as they do.

His question is different.

If these models have become extraordinarily capable, why is reliable automation still difficult and expensive?

One answer is that we have spent years optimising AI to interact brilliantly with humans, while a significant amount of machine intelligence ultimately needs to interact with software.

Software doesn’t always need another paragraph. Sometimes it just needs a decision.

Jev as a specialised LLM

One way of thinking about Jev is as a highly specialised LLM.

TypeSafe uses the term System One Model, which is probably a better description technically, but the specialisation is what matters.

A model such as Astra is deliberately broad.

It can analyse architecture, understand a new problem, write code, investigate evidence, develop a plan and explain its reasoning.

Jev deliberately gives up much of that breadth.

Its job is narrower:

• classify
• score
• route
• evaluate
• choose
• escalate

Rather than generating open-ended prose, it answers bounded questions and produces structured values, probabilities and confidence.

That difference is fundamental.

Jev is therefore interesting not because it can do everything, but precisely because it doesn’t try to.

Specialisation gives it the potential to perform a narrow class of cognitive work far faster and at far lower cost.

And that may be exactly what large-scale AI automation needs.

Human intelligence doesn’t consciously think about everything

This is where I think the comparison with human intelligence becomes particularly useful.

Humans don’t solve every problem using the same level of conscious reasoning.

Consider something as simple as walking.

You don’t consciously calculate the position of every muscle, reason about the angle of your ankle before every step or deliberately calculate where your foot needs to land.

You decide:

I’m going over there.

And an enormous amount of activity happens automatically beneath that higher-level intention.

The analogy isn’t neurologically exact, but the architectural principle is useful.

Human intelligence works partly because we don’t use our highest-order cognitive capabilities for every activity.

Things that are familiar, repetitive, bounded or learnt become increasingly automatic.

That allows our higher-order cognition to concentrate on the unusual things:

• What is happening?
• Why has something changed?
• What should I do?
• How do I solve something I haven’t encountered before?
• How do I reconcile conflicting information?
• How do I plan several steps ahead?

This is a useful way to think about Jev.

It is attempting to provide something closer to that fast decision layer.

Not:

Think deeply about this problem and explain the answer.

But:

Look at the situation and make a fast, bounded judgement.

And System One thinking like this isn’t peripheral to automation.

It is crucial to it.

The architectural pattern becomes:

Task or event → fast System One decision → deterministic software, higher-order reasoning or human judgement.

The important point is that expensive intelligence is invoked only when it changes the outcome.

A specialised model such as Jev can classify, score, route, evaluate and escalate, while frontier models such as Astra and Sol remain available for analysis, planning, design, explanation and creation.

That creates two complementary layers of machine intelligence:

Fast intelligence, used frequently.

Deep intelligence, used selectively.

Astra showed me just how far higher-order AI has moved

This became much clearer to me when I first started using OpenAI’s Astra model.

One of the first things I did was point Astra at my GanderKnowledge repository.

GanderKnowledge isn’t particularly straightforward to explain.

It isn’t simply a knowledge-management system, an architecture repository, an AI assistant or a development platform.

It is attempting to create a connected lifecycle between enterprise intent, knowledge, architecture, systems, repositories, evidence, delivery and change.

Previously, getting an AI model to understand that usually required quite a lot of context and steering.

You often had to explain the abstraction you wanted it to see.

Astra felt different.

I asked it to examine the repository and specifically analyse the existing reverse-engineering capability.

And it went off and did it.

I gave it relatively few pointers, yet it understood something important about the intent.

It realised that importing a repository into GanderKnowledge wasn’t simply another form of ingesting information.

A repository could represent a product, a system, a project or one component within a much larger enterprise landscape.

Once connected, it should become part of the GanderKnowledge lifecycle.

Changes occurring in that repository may need to feed back into the enterprise knowledge and architecture.

Changes originating in architecture or delivery intent may eventually flow in the other direction towards implementation.

In other words:

The repository wasn’t simply being reverse engineered. It was becoming part of the knowledge ecosystem.

That is quite an abstract architectural implication.

What impressed me was that Astra got there without me having to painstakingly lead it to the conclusion.

Previous models could produce excellent work, but I often found myself giving them substantial context before they recognised the larger abstraction.

With Astra, it felt much closer to working with another architect who could understand the intent, extrapolate from it and start reasoning about the consequences.

That was a genuine step forward.

Then Astra High consumed my available usage in less than 24 hours

There was another side to the experience.

After the initial analysis, I got Astra to start working on the reverse-engineering capability itself.

I ran the development work using Astra High.

The results were extremely impressive.

But within less than 24 hours, I had effectively exhausted my available model usage.

That was an eye-opener.

This isn’t intended as a scientific benchmark.

It is simply what happened during my own sustained Codex development workload.

But it exposed a problem I think anyone developing substantial systems with AI agents is going to face:

Extraordinary intelligence can consume extraordinary amounts of compute.

Software development makes this particularly obvious.

An agent reads files, reasons about them and changes something. It examines the result, runs tests, analyses failures, retrieves more context and reviews its work. It repeats the process — potentially hundreds of times.

Put your most capable model behind every one of those operations and the economics become uncomfortable very quickly.

By comparison, I have been able to use Sol at Extra High reasoning levels for sustained development activity without anything like the same rate of consumption I experienced using Astra High.

That made something very obvious:

The most capable model should not automatically become the model you use for everything.

Not every coding-agent operation requires Astra

This is one of the problems I have already been trying to solve.

A coding agent such as OpenAI Codex, Cursor or Claude-based coding tools doesn’t perform one type of cognitive activity.

It performs many.

A typical development workflow might involve:

1. Understanding the requirement.
2. Understanding the architecture.
3. Developing the plan.
4. Locating relevant code.
5. Reading files.
6. Making bounded changes.
7. Running tests.
8. Interpreting failures.
9. Making corrections.
10. Reviewing implementation.
11. Verifying evidence.

These aren’t equivalent cognitive tasks.

Understanding a complicated architecture may justify Astra.

Developing a difficult cross-system plan may justify Astra.

Resolving high ambiguity may justify Astra.

But does Astra need to read every routine file?

Does Astra need to make every mechanical code edit?

Does Astra need to execute a known test?

Does Astra need to classify every test result?

Probably not.

This is where describing models simply as better or worse becomes misleading.

The more useful question is:

What level of intelligence does this particular activity require?

A Sol-level model may be entirely appropriate for implementation.

A smaller model may be perfectly capable of extraction or repetitive semantic work.

Deterministic software should perform things that don’t require AI at all.

And Astra should be preserved for the parts of the workflow where its additional ability to abstract, reason and infer actually changes the result.

GanderCoder: applying that thinking to coding agents

Within GanderKnowledge, I describe this architecture-led coding workflow as GanderCoder.

GanderCoder isn’t intended to be another code generator competing with Codex, Cursor or Claude.

Think of it instead as an orchestration and governance layer around coding agents.

Codex, Cursor, Claude and future coding tools provide the coding capability.

GanderKnowledge provides the architectural context:

• what we are trying to achieve
• the accepted architecture
• requirements and constraints
• relevant knowledge and evidence
• decisions already made
• what should and shouldn’t change

GanderCoder connects those two worlds.

It allows the coding agent to work from enterprise and architectural intent rather than simply from a prompt and a repository.

And this is where intelligent model routing becomes particularly important.

A complex coding request might initially go to Astra for interpretation and planning.

From there:

• deterministic software can run tests, validation and file operations;
• Sol can perform implementation and ordinary fixes;
• smaller models can perform repetitive semantic work such as extraction, localised transformations or summarisation.

The outcome can then be observed.

If everything remains normal, continue.

If the work becomes difficult or ambiguous, escalate back to higher-order reasoning.

The principle is straightforward:

Use the highest-order model where its intelligence changes the result — not where it merely increases the cost.

That principle applies equally to Codex, Cursor, Claude-based agents and whatever comes next.

Model routing is only the beginning

This is where Jev becomes particularly interesting.

I have already been trying to rationalise model use by deciding which activities need Astra, which need Sol and which don’t need a model at all.

But that creates another question:

Who decides which intelligence should be used?

Is this genuinely an Astra problem?

Will Sol handle it?

Is this deterministic?

Can a smaller model perform the task?

Has something happened that requires escalation?

We can ask another frontier LLM to make those decisions.

But if we invoke expensive intelligence merely to decide whether expensive intelligence is needed, we haven’t really solved the problem.

We have just moved it.

This is where Jev fits.

Jev as the intelligence that controls the intelligence

Imagine a coding task arriving and Jev evaluating questions such as:

The application doesn’t need Jev to produce a five-page explanation.

It needs those decisions.

Software can then apply policy:

Jev becomes another step in the rationalisation of model cost.

Not by replacing high-order intelligence.

By deciding when it is justified.

From one model to layered intelligence

I think we can describe the evolution of AI architecture in three stages.

Stage 1 — One model does everything

It works.

But it can also be expensive and inefficient.

Stage 2 — Different models do different work

We then introduce routing:

Better.

But something still has to make the choice.

Stage 3 — Fast intelligence controls the routing

Now we introduce a System One layer:

This produces something much closer to a layered intelligence architecture.

The progression is important:

One general model does everything.

Then:

Different models do different work.

And finally:

Fast intelligence determines which type of intelligence should be used.

The architectural principle underneath it is one I increasingly think matters:

Cheap intelligence decides when expensive intelligence is needed.

This changes the economics of AI automation

This is where Jevons' paradox becomes particularly relevant.

The name Jev deliberately references it.

The original economic observation was that making a resource significantly more efficient doesn’t necessarily reduce consumption of that resource.

Instead, it can make the resource economically viable in so many more situations that total consumption increases.

Apply that to machine intelligence.

If a useful semantic decision becomes dramatically cheaper, the most interesting question isn’t simply:

How much can we save?

It is:

Where can we now afford to put intelligence that previously couldn’t justify having any?

Instead of five intelligent decisions occurring during a workflow, perhaps there can be 5,000.

Every document entering an organisation could potentially be semantically assessed.

Every coding-agent action could potentially be evaluated.

Every repository change could potentially be checked for architectural significance.

Every retrieval result could potentially be judged for relevance.

Every workflow could continuously ask whether it should continue normally, use a more capable model or escalate to a human.

We don’t necessarily use less intelligence.

We dramatically increase the number of places where intelligence can exist.

That connects to something I have written about before:

Intelligence comes at a cost.

Jev doesn’t invalidate that statement.

It gives us another mechanism for deciding when that cost is worth paying.

What this means for GanderKnowledge

This is where Jev becomes particularly interesting for GanderKnowledge.

GanderKnowledge is intended to create and maintain a living representation of an enterprise:

its intent, architecture, applications, systems, repositories, evidence, decisions, delivery activity and change.

Powerful models have an important role in that environment.

They can:

• examine evidence;
• understand relationships;
• identify implications;
• challenge architecture;
• develop candidate designs;
• reconcile conflicting information;
• move from intent towards delivery-ready definitions.

But when I look at the overall architecture, I increasingly see:

A relatively small number of difficult reasoning operations surrounded by a very large number of smaller decisions.

Those smaller decisions are where specialised System One intelligence could become extremely valuable.

A Semantic Decision Layer

Rather than thinking of this simply as “adding Jev”, I think the more important architectural capability is a Semantic Decision Layer.

The inputs into GanderKnowledge are constantly changing:

• documents
• repositories
• architecture
• evidence
• delivery activity
• decisions
• implementation changes

Deterministic policy should always deal with things that can be decided deterministically.

But between hard-coded rules and expensive higher-order reasoning sits a very large space of semantic questions:

• Is this change material?
• Is this evidence relevant?
• Which model should handle this?
• Does this require deeper reasoning?
• Should this be escalated?

The Semantic Decision Layer becomes a traffic controller for intelligence.

It can route work towards:

Deterministic software

for rules, calculations and known workflows.

Frontier reasoning models

such as Astra or Sol when interpretation, abstraction or generation is actually required.

Human judgement

where authority, accountability or significant exceptions require it.

The benefits are straightforward:

• faster decisions;
• better routing;
• lower AI cost;
• fewer unnecessary high-order model calls;
• greater automation.

That is an important architectural change.

Repository changes become intelligence by exception

One of the areas where this is particularly relevant is connected source-code repositories.

A repository may represent part of the actual implementation of an enterprise system.

But repositories change constantly.

A dependency update isn’t the same thing as a new external API.

A formatting change isn’t the same thing as a new data model.

A refactoring isn’t necessarily an architectural change.

Today, it is tempting to send every interesting change to a powerful LLM for analysis.

At scale, that is expensive.

A System One decision layer could first ask:

Most routine changes can continue without expensive reasoning.

Interesting changes can receive targeted analysis.

Significant changes can be escalated to deeper architectural reasoning.

The frontier LLM becomes something closer to an:

Exception handler for complexity.

That is a much more scalable model.

Retrieval becomes intelligence before reasoning

The same principle applies when gathering information for an LLM.

A vector search might return thirty passages that appear related to a question.

But semantically similar doesn’t necessarily mean:

useful evidence for this decision.

A System One model can potentially sit between retrieval and deep reasoning:

This means:

• less irrelevant context;
• fewer tokens;
• less distraction;
• potentially better reasoning.

The cheaper intelligence isn’t replacing the deeper intelligence.

It is creating better conditions for it.

Reusable architecture becomes another System One problem

The same idea applies to reusable architecture patterns and Blueprints.

If an organisation already knows what a good customer-service application normally looks like, an AI shouldn’t have to rediscover that architecture from scratch every time somebody asks for one.

Candidate patterns can first be assessed:

Does this fit?

Which architectural overlays apply?

What is unusual?

Where is the uncertainty?

Only then does higher-order reasoning concentrate on what is genuinely different.

Again, this looks a lot like human expertise.

An experienced architect doesn’t reconstruct forty years of architectural knowledge from first principles every time they look at a new system.

Much of that knowledge has become pattern recognition.

The higher-order thinking is concentrated on the unusual parts.

AI systems should increasingly be able to work the same way.

Automation is where System One thinking really matters

This is perhaps the most important point.

Automation contains enormous numbers of small decisions.

An agent needs to decide:

• Should I use this tool?
• Did that operation succeed?
• Does this change matter?
• Is this request unusual?
• Should I continue?
• Should I retry?
• Is this within scope?
• Do I need better reasoning?
• Should a human see this?

That is why System One intelligence matters so much.

Higher-order LLM reasoning is astonishingly capable.

But high-volume automation cannot economically depend on using the most expensive reasoning capability for every decision.

Jev introduces another layer:

Fast enough to be used constantly.

Cheap enough to be used constantly.

Intelligent enough to make semantic decisions that deterministic code cannot easily make.

That combination is what makes it interesting.

But probability must not become authority

There is an important architectural boundary.

Jev produces constrained decisions.

That reduces one class of LLM problem dramatically.

If the possible answers are:

• Architecture
• Security
• Operations

the model isn’t going to produce a paragraph of unrelated prose.

But:

Type safety isn’t truth.

It can still choose the wrong valid answer.

A perfectly formed probability can still be wrong.

A classification can conform perfectly to its schema and still misunderstand the situation.

So probabilistic intelligence should inform authority, not automatically become authority.

Deterministic security controls should remain deterministic.

Accepted architectural truth shouldn’t be replaced because one model produced a probability.

Irreversible actions need appropriate controls.

Human accountability remains essential where consequences justify it.

That fits naturally with one of the core principles behind GanderKnowledge:

AI develops. Humans decide.

The bigger change is architectural

The most interesting thing about Jev may ultimately not be Jev itself.

TypeSafe may succeed spectacularly.

Other companies may produce better System One models.

Frontier LLM providers may develop similar capabilities.

We may end up with an entire ecosystem of specialised models optimised around:

• semantic accuracy;
• confidence calibration;
• latency;
• cost;
• routing;
• classification;
• risk;
• evaluation.

The provider isn’t the most important part. The architectural decomposition is.

For the last few years, we have increasingly built systems that look like:

I don’t think that is where AI architecture ends up.

I think it increasingly becomes:

Some things should be deterministic.

Some require fast semantic pattern recognition.

Some require expensive higher-order reasoning.

Some require human judgement.

Different forms of intelligence should do different forms of work.

Perhaps the real lesson is not to think about everything

What makes human intelligence powerful isn’t simply our ability to think deeply.

It is also our ability not to think deeply when we don’t need to.

We walk without reasoning about walking.

We recognise familiar patterns without reconstructing them from first principles.

We filter huge amounts of information before deciding what deserves conscious attention.

And when something genuinely unusual happens, higher-order cognition takes over.

That may be the most useful way to think about Jev.

It isn’t trying to make Astra less capable.

It doesn’t need to.

My own experience with Astra demonstrated just how valuable higher-order AI has become.

Once you’ve seen a model understand an architectural abstraction that previously required substantial steering, you don’t want to give that capability up.

The challenge is different:

How do we preserve extraordinary intelligence for the problems where extraordinary intelligence creates value?

For me, that now leads to three architectural principles:

Jev is interesting because it operationalises that final idea.

Not as another general-purpose model trying to do everything.

But as an enabler sitting inside a much larger intelligent system.

And that may be considerably more important than it first appears.

Because the future of AI may not be about finding one model intelligent enough to do everything.

It may be about learning how to combine different forms of intelligence so that each one does exactly the work it is best suited to do.

Further viewing

• Why We Made Jev — Diogo Almeida, TypeSafe AI

• Build Anything With Jev — David Ondrej

• TypeSafe AI — Introducing System One Models & Jev

• LangChain — Building a Harness with Jev