The language where the AI doesn't need to re-read your codebase.

The amnesia tax

Every time you ask an AI to change your code, it re-discovers your codebase from scratch. It runs searches, reads files, infers which functions call which, reasons about dependencies. Researchers at Concordia measured this: 54% of all tokens go to re-reading context, and 59% go to iterative refinement loops where the model checks its own work. The actual code generation is a rounding error.

This is the amnesia tax. The model is brilliant, but its structural memory is zero. Next conversation, it pays the tax again. The same files, the same dependencies, the same discoveries — all thrown away.

The Next Claude Code describes the solution: read the codebase once, build a persistent knowledge graph, and query it at millisecond speed instead of re-inferring it every turn. That system is called Grokers.

What Grokers needs from a language

Grokers builds a graph where every function is a node and every call is an edge. For each node, it writes a contract — what the function reads, writes, promises, and can throw. In most languages, deriving that contract requires an LLM to read the function body and write ~200 words of summary. This is expensive, and the summary can be wrong.

U changes this equation completely.

In U, the contract IS the signature

f transfer(sender: Account +R, recipient: Account +R, amount: Q) -> none ! InsufficientFunds
	<< (
		sender.balance < amount ? x InsufficientFunds()
		sender << { balance: sender.balance - amount }
		recipient << { balance: recipient.balance + amount }
	)

Without reading the body, the signature tells you:

Account +R — heap-allocated, refcounted
-M (default for params) — caller borrows read-only
Q — rational, no floating-point rounding
! InsufficientFunds — this specific error, nothing else
No +E — pure, no side effects
No +D — deterministic, same inputs = same result
No +A — synchronous

That's seven facts, derived mechanically. In Java, Python, or TypeScript, an LLM would have to read the function body, its callees, and the surrounding context to infer even half of this — and it might still be wrong.

The comparison

The u keyword — where the LLM fits in

U doesn't eliminate LLMs from coding. It gives them the right job. u f marks a function as AI-managed:

/// Rank products by relevance to query.
/// Prefer exact title matches. Boost recent listings.
u f search(query: S, catalog: [Product]) -> [Product]

// Human writes the wiring — always
f main()
	serve(8080, {
		"GET /search": (req) => Response.json(
			search(req.query["q"], load_catalog())
		)
	})

The LLM generates the body of search. The compiler checks it against the signature, the modifiers, and every call site in the project. The cost is paid once. The result is cached in a .gen.u file. Subsequent builds: zero tokens. u2c --regen regenerates only when a signature, dependency, or call site changes.

This is the efficient division of labor:

LLMs — creative synthesis. Expensive, one-time per change.
The graph — mechanical verification. Exhaustive, instant, every build.

How the pieces connect

Two directions of programming

Bottom-up: humans write frameworks, libraries, stable infrastructure — regular f, battle-tested, production-hardened. This is the Qbix platform, 15 years of engineering, 7M+ installs across 100+ countries.

Top-down: a customer call happens. An agent hears the intent. It writes u f functions that use the bottom-up framework. The compiler checks them against the typed dependency graph — not by searching files, but by walking edges it already knows. In real time.

The stable code is human-owned. The evolving business logic is AI-managed. The typed boundary between them is the u modifier. Remove it to take over. Add it to delegate. One letter.

The thesis

U is designed to be maximally mechanistically interpretable — more than any other complex language. Every function's behavior is derivable from its signature and AST without executing it. This isn't a property that was added; it's what the modifier system was designed to produce.

Why agents fail — and why U doesn't

The HANDBOOK.md benchmark (July 2026) tested whether LLM agents can follow standing instructions — policy documents, standard operating procedures — over extended tool-use horizons. The best of thirty frontier model configurations passed 36.2% of trials under strict grading. Most scored below 25%. The failure patterns: agents let plausible requests override the standing policy, perform a required check and then act against its result, lose rule details over long horizons, and report compliance they didn't achieve.

These failures are structural, not intelligence failures. Open-ended agents improvise their way through tasks. They re-infer constraints every turn. They lose context. They hallucinate compliance.

U's answer: don't let agents improvise. The modifier system encodes constraints in the type signature — -M, -E, ! ErrorType, +R — and the compiler enforces them mechanically. An agent generating u f code can't violate the standing policy because the standing policy IS the type system. The constraint isn't in a 100-page handbook the agent might forget. It's in the function signature the compiler checks on every build.

Code is workflows too

The deeper insight from the Safebots architecture: code modification is a declarative workflow, not an open-ended agent loop. A refactor is: fork a workspace, read context from the graph, propose a change, verify the contract, apply through governance, push a branch. Each step has declared inputs and outputs. Each step passes through the same governance that any other Safebox action goes through.

In U, this is even more mechanical:

Contract verification — the compiler re-derives the contract from the new source and compares against the old signature. No LLM needed for the diff.
Ripple analysis — the typed dependency graph tells you exactly which callers are affected. Walk edges, not files.
Parallel refactoring — Grokers' topological sort gives you the wave order for free. Symbols at the same depth can be refactored simultaneously.
Governance — cross-module changes require M-of-N cryptographic sign-off from module owners. The same Safebox governance that governs email and customer data governs code.

Sequential agent loops dress up improvisation as autonomy. Declarative workflows make the same work auditable, governed, and parallel-safe — without taking the human out of the loop.

The consequence: U is the language where Grokers doesn't need an LLM to build the map. Where Code doesn't need to re-read files to verify changes. Where the amnesia tax is zero. Where intent and code are close enough that mechanical doc generation works in any human language without a single transformer forward pass.

And when LLMs are used — via the u keyword — the cost is paid once, cached forever, verified mechanically on every build. That's the bridge between people describing what they want and systems that build it.