Watch enough Jev builds in one place and a shape repeats until it needs a name. Jev Engineering is that name: the practice of splitting an AI system into three layers with strict responsibilities — a language model writes, Jev decides, code acts. The name is new; the pattern is already how the most-copied builds in this directory are put together.

The three layers

The language model writes. Generation is what chat models are for: drafting a reply, summarizing a thread, writing the next action in a plan, producing code. In a Jev Engineering system the LLM is the drafting department. It proposes; it does not commit.

Jev decides. Every branch point — is this draft good enough, which option does the user mean, is this safe to run, which of these nine candidates fits — goes to Jev as typed questions with criteria. The response is a choice with probabilities, a score, or a noul (true/false probability), plus confidence. Because the answers are typed, the deciding layer cannot waffle: it returns a value your code can branch on, or a low confidence you can route to a human.

Code acts. The side effects — sending the email, clicking the button, writing the file, moving the money — belong to ordinary software. Code enforces the rules the model only opines on: allow-lists, budgets, retries, permissions. This is the layer that makes the system auditable, because the decisions are logged values, not vibes in a transcript.

Why the split exists

Each layer exists because the other two are bad at its job. LLMs are unreliable deciders: ask the same routing question three times and you can get three formats of answer. Jev is a fast, cheap, consistent decider — but it cannot write a sentence. And both are the wrong place to enforce policy: a model can be talked around a rule, while code cannot be prompt-injected. The builds that skip a layer show the failure: LLM-only systems are unbranchable and slow; Jev-only systems have nothing to decide about; code-only systems have no judgment at all.

What it looks like in the wild

The pattern shows up across the use cases in this directory:

  • Browser agents (agents and browsers): the LLM narrates the page and proposes actions; Jev picks which action matches the goal; code executes the click with the selectors and guards.
  • Content pipelines (content and growth): the LLM drafts variants; Jev scores each against criteria; code publishes the winner and logs why.
  • Support triage (triage and routing): Jev routes the ticket before any generation happens; the LLM only writes the reply once the destination is known.
  • Trading loops (trading and markets): signals in, Jev judges the setup against criteria, code enforces position limits that no model opinion can override.

The budget shape of a Jev Engineering system

Because Jev answers in 70–500 ms and costs about $0.042 per million input tokens with output free, the decide layer is cheap enough to sit in the hot loop — called on every step, every candidate, every message. The write layer stays expensive and slow, so you call it only when a decision says the writing is worth doing. Cost control becomes architecture: judgments scale, generation is rationed by judgment. Builders reporting costs in this directory almost always describe that shape — many cheap verdicts gating a few expensive drafts.

How to start

Take one branch in something you already run — the if that decides which template to send, which queue to route to, which result to show first. Rewrite it as one Jev call with explicit criteria, and keep the if, now branching on a typed answer with a confidence you can monitor. The state and question design guide covers writing the criteria; confidence and review covers what to do with the unsure cases; Jev vs an LLM covers when you still need the writer at all.

Published 25 September 2026. The pattern name is used descriptively for builds catalogued in this directory; API behavior checked against TypeSafe AI’s published documentation on this date.