The Generative Pendulum: Better AI Writes More Deterministic Code, Not Less

Cheap model judgment doesn't swallow the deterministic half of your system. It manufactures it — per step, per question — and throws most of it away. Here's the mechanism, the recursion that makes it a primitive, and the one middle the model must never be allowed to write.

Scott Farrell · LeverageAI · The AI/deterministic boundary, and who gets to place it

The first time I saw recursion do something genuinely clever, I was writing a Negamax chess program. One function evaluated a position by calling itself on the positions that followed it, and the call stack quietly held everything I would otherwise have had to manage by hand: where I came from, what was still unresolved, what to do with the answer when it came back. It was the first piece of code I had written that felt smarter than I was.

Decades later I read the documentation for an agent runtime and had the same feeling for the same structural reason — and then a worse one, because something I had confidently predicted turned out to be wrong.

I had assumed that as models got better they would eat the deterministic half of hybrid systems. That was the obvious trajectory: rules give way to judgment, judgment improves, code shrinks. Instead the most capable setups I have looked at emit more deterministic code than the hand-built systems they replace — a great deal more — and almost none of it is written by a human, and almost none of it survives the afternoon.

That is the mechanism this piece is about. Not "agents can write code now" — that is a statement about output, and it is three years old. This is about the code between model runs: who writes it, when, how long it lives, and the one category of it that must stay out of the model's hands permanently.

The pendulum, and the assumption hiding inside it

A while back, building an article-to-social pipeline, I ended up with a rule I have used ever since. Judging whether a rendered card was correct started as a vision task and moved to deterministic checks. Deciding which passages were interesting started as fourteen hand-written CSS heuristics and moved to a model. The principle that fell out: use AI for nuance and judgment; use deterministic code for reliability and ground truth — and the skill is not picking a side once, but knowing for each sub-problem which kind of problem it actually is, and being willing to move a component the other way when the evidence says so.⁷

I called it the Deterministic–AI Pendulum, and it has held up. But there is an assumption buried in it that I never named, because for years it was invisible — it was simply how software got built.

I was the one doing the allocating. Me, at a whiteboard, before contact with the problem. I drew the architecture:

AI  →  Python  →  AI  →  Python

and the drawing was the architecture. Each arrow was a boundary I placed once, in advance, for a problem whose shape I had guessed. That is not a small assumption. It is the whole design method.

The thing that has changed is not the rule. The rule is fine. What has changed is who applies it, and when. The model now sites the boundary at each step, while it is holding the problem, having seen what the last step returned. And once you let that happen, the deterministic side stops being an architecture and starts being something closer to output.

Before and after: one afternoon, one boundary

Here is the before, in my own hands, because I do not want this to be abstract.

On my own longer agent runs — the ones with a lot of tool calls — I had been working out how to combine and summarise results, because eventually not everything earns its place in the context. That meant deciding, in code, in advance: this tool result gets summarised; this conclusion survives; these ten calls collapse into one line; this previous state gets dropped. Every one of those decisions is a boundary placement. Every one of them was made by me, at design time, for a run whose shape I could not know.

Now the after. I wanted to backtest an alerting policy — to find out whether some proposed changes would have caught things my system had historically missed.

The version I would have built is easy to describe, because I have built things like it. A script to pull the historical articles. A replay harness. A TEST_MODE=true flag threaded through the notifier so nothing actually sent. A summariser to bring the results back into context. A fixed sequence: extract, replay, judge, report. Four boxes, drawn before I knew what the data looked like, each one guessing.

What I actually did was give the agent the invariants instead:

Those are acceptance boundaries. They say nothing about implementation. What came back was an in-memory SQLite database — which had not occurred to me, and which is a better answer than the one I would have specified. It creates a cheap, disposable counterfactual world: the same application logic runs as though it has state, transitions, queues and prior observations, and when the process ends the experimental world simply ceases to exist. Add virtual time, blocked networking and a recording-only notifier and you have a small wind tunnel for the alert system. It was quarantined, and it did not interrupt the live database.

Then the useful part. Running the real selection logic against historical evidence surfaced a genuine policy defect — one class of first report was consistently silent. I changed what the policy meant, reran the same experiment, and the behaviour changed. That is closer to an empirical development loop than to prompt tweaking, and none of it was possible without a deterministic apparatus that did not exist an hour earlier.

The turn is in one sentence: I did not tell it to use an in-memory database. I specified the invariant, and it compiled that intent into an implementation. This is the doctrine I have written about as tight intent, loose method — be precise about purpose, constraints and proof; leave latitude over procedure¹⁴ — except that the latitude now extends to which parts of the problem get deterministic machinery at all.

And a quarantined database is only one instance of a class. What the execution environment really buys is the ability to construct temporary realities: temporary databases, temporary transformations, temporary evaluators, temporary sub-agents, temporary representations — whatever is needed to perturb an idea safely and see what happens. Because they are cheap and ephemeral, nobody has to correctly predict the right apparatus beforehand.

The traditional developer asks, "What do you want me to build?" The stronger agent asks: "What claim are we trying to establish, and what experimental world do I need to construct to establish it?"

One afternoon, one system, my own observation. That is n=1 and I am not going to dress it as anything else. What makes it worth generalising is not the anecdote — it is that the mechanism underneath it is an argument about prices, and prices are checkable.

Why cheap judgment produces more code, not less

Here is the part I got wrong, and why.

Deterministic code in a hybrid system was never rationed by need. There was always more of it worth having. It was rationed by authoring cost — and the authoring cost of a deterministic component is not just the typing. It is a decision, an implementation, a test, a name, a location in the repo, a review, and a maintenance obligation that outlives the person who wrote it.

That cost sets a floor on granularity. When each component costs a human half a day, you do not write the filter that answers one question; you write the general filter that answers twenty, badly. You do not write a schema per hypothesis; you write the schema. So hand-built systems accrete general deterministic components, and general components fit no specific problem particularly well. That is not a failure of engineering. It is what the price forced.

Drop the authoring cost to seconds and the floor falls through the basement. Now you can afford a filter that serves exactly one question and dies when the question changes. You can afford six probes to find out which one you wanted. The consequence is arithmetic:

The number of deterministic components goes sharply up. The average lifetime of one collapses. The total volume of deterministic code in the system grows — and almost all of it is disposable.

This is not new territory for us; it is the same motion I have described as forging an instrument for the question in front of you and discarding it when the question changes. Grew an eye. Looked. Didn't like the view. Grew a different eye.¹⁰ A thirteen-gigabyte store is not a thought; a query over it that returns a dozen patterns is. The deterministic code is not solving the problem — it is reshaping the world into something the intelligence can reason about.

"But won't a better model just do it in its head?"

This is the objection that matters, and the answer is the mechanism.

The code is not compensating for weak reasoning. It compensates for a category mismatch. Exact counting, reproducible filtering, ground truth, operations at a scale that will not fit in attention — these are not tasks that get easier as judgment improves, because judgment was never the missing ingredient. A model with twice the reasoning ability is not meaningfully better at counting four thousand rows; it is better at recognising that it should not be counting them in its head.

Placement is itself an act of judgment. So the two curves point the same way:

• A weaker model eyeballs the dataset and confabulates a summary. One inference, no code, wrong answer.
• A stronger model writes six lines, gets the exact answer, and spends its judgment on what the answer means. Two inferences, some code, right answer.

Better judgment means sharper placement, and sharper placement means more deterministic components, cut finer. The industry has been reaching the same conclusion from a completely different motive: Anthropic's guidance on code execution for agents is about token economics — filter and transform in code before results ever reach the model, cutting one workflow from 150,000 tokens to 2,000⁶ — but the shape it recommends is identical. When two arguments with nothing in common arrive at the same architecture, the architecture is probably structural.

Disposability is the feature, not the debt

The instinctive objection to "more code" is "more maintenance". It does not follow, because this code is not an asset.

I watched an agent recover a decades-old Lotus Notes archive by manufacturing its own reader, then hit a wall — its own driver could not handle blobs past four gigabytes — and re-engineer the driver in five or six minutes before continuing. The wall was in software it had written ten minutes earlier. It did not nurse the reader; it regenerated it from the same intent.¹² That software had a lifetime of about twenty minutes and needed no product name, no roadmap, no support for every archive ever made. The asset was the recovered history. The code was exhaust.

Which gives the working loop for the whole ephemeral layer:

build the test world → run the idea → observe → throw it away, or keep what worked

And re-forging is not failure. A wrong view is a successful measurement; the next probe is smarter because the last one existed.¹¹ If you find yourself writing a deprecation policy for a sensor, you have misidentified the product.

The trajectory, redrawn

The mental model almost everyone is carrying looks like this:

deterministic software
        ↓
      more AI
        ↓
       all AI

What the mechanism actually predicts looks like this:

cheap AI judgment
        ↓
manufactures vastly more
problem-specific deterministic computation
        ↓
which creates better inputs
for more AI judgment
        ↺

So the deeper version of the pendulum is not that AI replaces deterministic computation. It is that AI makes deterministic computation disposable, abundant, and dynamically fitted to the current thought. The deterministic layer does not disappear. It becomes generative.

Generative recursion: when the procedure is written mid-search

All of the above would still be a story about a fluid pipeline if not for one property, which is where the Negamax memory earns its place.

My chess program looked roughly like this:

value(position):
    for move in possible_moves:
        score = -value(position_after(move))
    return best(score)

The recursive function is fixed. The state changes. That is ordinary recursion, and its power comes precisely from the fixity: one procedure, applied to a changing world, with the stack keeping the bookkeeping.

What a recursive-language-model runtime does is structurally different:

solve(problem):
    inspect(problem)

    maybe write a new algorithm
    maybe construct a new representation
    maybe query reality
    maybe call solve(subproblem)
    maybe call several solve(subproblem_i)
    maybe modify the algorithm based on their answers

    return synthesis

Ordinary recursion: same procedure, new state. This: new state can cause a new procedure, which can launch new cognition.

The recursive search procedure is partly generated while the search is underway. The search tree and the search algorithm co-evolve. That is a different object, and it deserves its own name: generative recursion.

What the runtime actually does — including where my intuition was wrong

Prime Intellect's Prime Agent is the cleanest public specimen I have read, and it is worth reading its documentation outside-in rather than taking anyone's summary, including mine.

The model-facing surface is deliberately minimal: "The default RLM runtime exposes one built-in model tool: ipython. Reading and editing files, running project commands, transforming results, invoking skills, and delegating work all begin from that persistent kernel instead of separate built-in tool calls."¹ That is code-first architecture taken to its conclusion — code as the model's interface to everything, rather than a catalogue of tools someone curated in advance.¹³ And the kernel persists: "Python state survives across tool calls and compaction. Variables, imports, functions, parsed results, and task handles remain available on later turns."¹ Functions the model defines while working are still there several turns later. The machinery accumulates inside the run.

Sub-agents are not a separate feature; they are a call in that same kernel:

handle = await rlm("Review the authentication flow for security issues", name="auth-reviewer")

My first instinct on reading that was that the agent forks itself on the stack. That is wrong, and the correction is more interesting than the guess. The documentation is explicit: "The call returns immediately after task admission with a child handle; it never waits for or returns the child's answer. The TypeScript host creates a normal child AgentSession with an independent context and session directory."¹ Results arrive "only through explicit agent_message replies or files, never as an rlm() return value."¹

So this is a process tree, not a call stack — and the difference cuts both ways. A stack is a promise: you will come back, in order, with the sub-result in hand, and the bookkeeping is free. A process tree makes no such promise. What you gain is concurrency and genuinely independent contexts; what you lose is the discipline the stack gave you for nothing. If you want that discipline back you have to build it — naming children, retaining handles, checking the registry, deciding what a missing reply means. The runtime does hold some of this for you: "The parent-scoped child registry survives compaction, kernel restart, and parent restoration."¹ But the guarantee Negamax got from the language is now an engineering problem.

Now the property that makes this a primitive rather than a pattern. The runtime supports Python-backed skills — real packages installed into the persistent kernel and exposed by import name — and of those it says: "They may also call rlm(...) themselves when a capability needs recursive delegation."¹ The agent can also author them: "Prime Agent can create skills. Ask it to build one for your use case."³

Read that composition slowly, because it closes the loop. The model writes code. The code it writes can install itself into the environment the model thinks in. And that installed code can invoke fresh cognition as an ordinary instruction. Cognition writes computation; computation shapes cognition; and either can recursively invoke more cognition.

Why this is a primitive and not a pipeline

In a pipeline — including the good ones I have designed — the model is a stage. Something else owns the sequence, and the model's job is to be excellent inside a slot. Here, "call a model" is an instruction available inside code the model just wrote, in a kernel whose state persists, with the result landing back as an ordinary object. The composition is open, and the topology is not drawn in advance by anybody.

I have argued a version of this before: code as the step between model runs, where a hard-coded workflow primitive is a cage built by someone who had to guess the problem in advance, and letting the agent write the orchestration means the shape of the loop matches the shape of the problem.⁸ Generative recursion is that idea with one thing added — the orchestration the agent writes can call for more judgment from inside itself, so the loop is not merely fitted to the problem, it is fitted as the problem is being understood.

It would be easy to dismiss this as one vendor's architecture taste. Two results published this year make that harder, because both hold the model fixed and change only the machinery around it.

The Recursive Language Models paper treats a long input as an external environment the model can "programmatically examine, decompose, and recursively call itself over snippets of the prompt." With GPT-5 as the backbone, it reports roughly 26% improvement against compaction and 13% against Claude Code across four long-context benchmarks, at comparable cost.⁴ A second group, building on that work rather than arriving at it separately, names the code-first version of the same move — "harness recursion, the code-first extension to the model recursion of RLMs," in which "a parent agent generates and runs an executable script that spawns subagent harnesses in parallel" — and, with the backbone held fixed at GPT-5, improves a Codex coding-agent baseline from 71.75% to 81.36% on Oolong-Synthetic, "a gain attributable to the harness rather than the model."⁵

Hold the model constant, change who writes the deterministic middle and how it recurses, and capability moves by double digits. That is the strongest available evidence that we are looking at a primitive rather than a preference — and it is the reason this is worth your attention now rather than in a year.

The costs, stated flat — and a correction I already published

Three costs, no hedging, because I have paid all of them.

It is non-deterministic: generated orchestration is sometimes simply invalid, and you find out mid-run. It is expensive, in a way that scales with how far the agent decides to take the structure. And it costs you legibility — you can no longer point at a fixed pipeline and say what will happen tonight. That is a real loss, not a philosophical one.⁸

There is also a correction I owe this argument, which I published a while ago and which still stands. I once framed the loop-that-writes-its-own-loop as where the durable value of this era would land. It is not. Seven weeks of building put the value somewhere much duller: a meta-loop dies with the session; a sentence you can paste into the next one does not. The durable unit of reuse is a compact, promptable invariant — short enough for a human to carry, precise enough for an AI to regenerate — not a clever runtime.⁹

I am not quietly re-inflating that here. Nothing in this article says the runtime machinery is the asset. What changed is not the status of the invariant — it is the price of the layer beneath it. You still carry a sentence between sessions. What sits under that sentence is now manufactured per step, in far greater volume, and deleted.

Which brings us to the sentence in that same correction that this article exists to refine. I wrote that the shape that works is AI judgment → deterministic compilation → AI judgment: variation at the ends, compilation in the middle, and a self-structuring loop is fine at the ends of your pipeline and dangerous in the middle of it.⁹

That is still exactly right. It was written with one middle in view. There were always two.

The two deterministic middles

Everything above says: let the model site the boundary. This section is the part that makes that safe to act on, and it is not a governance appendix — it is half the mechanism.

The test that sorts them

You do not need a taxonomy. You need one question, applied to each deterministic component you own:

If this code is wrong, do I get a bad view — or a changed world?

A bad view is cognition. A changed world is authority. Most components answer in under five seconds, and the interesting thing is what happens to the ones that do not: the components where you hesitate are, almost without exception, the ones that have been quietly doing both jobs. A "summariser" that also decides which alerts are suppressed. A "filter" that also determines what enters the audit record. Those are not ambiguous cases. They are two components wearing one name, and the classification is the refactor.

Two secondary tests, for when the first one is close:

• Reversibility. Can I undo this by doing nothing? If waiting fixes it, it is cognitive. If waiting entrenches it, it binds.
• The gate test. Can the cognition change this component? If yes, it is a policy that happens to be obeyed, not a boundary — regardless of what the diagram says.¹⁷

This line exists in a shipped system

The reason I am confident this split is real engineering rather than a nice diagram is that a shipped runtime draws it explicitly, in the same document that hands the model the keys to the cognitive middle.

Prime Agent's model-facing surface is a permissive Python environment. Its authority surface is not. Skills reach authoritative operations through typed host requests: "the TypeScript host validates the request and owns the state transition," and the effect of that design, in the documentation's own words, is that it "keeps credentials, provider execution, transcript writes, worker routing, and scheduling out of Python while retaining a programmatic model interface."¹ The architecture overview says the same thing from the other side: "IPython is the model-facing control environment. Typed host requests return authoritative operations to the TypeScript session."²

That is the two middles, implemented. Maximum discretion above the line; the things that bind — credentials, the transcript, scheduling, the state of record — held on the other side of a typed, narrow interface the Python cannot widen.

The doctrine underneath

None of this is new security thinking dressed up for agents. It is the rule I have argued at length elsewhere: discretion and privilege should move in opposite directions — the more capable, general and unpredictable a component is, the narrower its access should be. And the structural property doing the real work: no single actor both sees the raw world and changes it unilaterally. That absence is what makes a system auditable rather than merely monitored, because there is never a component you simply have to trust with both halves at once.¹⁵

The generative pendulum makes that rule more load-bearing, not less. A component that manufactures its own deterministic machinery per step is the most capable and least predictable thing in your system by a wide margin. The correct response is not to fence its cognition — small approvals around every act of thought strangle the capability and still do not produce a boundary, because a sufficiently capable operator composes permitted primitives into unpermitted outcomes. The correct response is to move the protection outward, so the model gets an enormous permissive middle and no ability to touch the gate.

And the second protection problem — what the operating system will actually let that process damage — has its own machinery, which also lives outside the cognition: tokenised data, scoped keys, a proxy that hydrates real values only at the moment of execution.¹⁵ Containment limits what a contained agent can reach. Constitution decides what world it is shown in the first place. Neither is a thing you ask the model to respect.

And "gate" here means the strong version. Policy says you shouldn't; architecture says you can't. Governance that runs after the decision documents failure; governance that runs with the decision prevents it.¹⁶ If the model can talk its way past your boundary, or compose its way around it, you have a user-experience feature.

Let the model write the machinery of thought. Do not let it write away the machinery of authority.

What to do about it on Monday

This is a placement protocol, not a maturity model. You can run all six steps on a system you already have.

The pendulum did not stop swinging. It started building

I expected capable models to absorb the deterministic half of my systems. What they are doing instead is manufacturing it — in far greater volume, at a granularity no human could have afforded, fitted to a problem nobody drew in advance, and thrown away when the question changes. The rule I named a while back survives intact. What changed is that I am no longer the one applying it at every step.

The recursion I first met in a chess program has come back with the one property it never had: the procedure can be written while the search is underway, and the search can call for more judgment from inside the code it just produced. Search tree and search algorithm co-evolve. That is not another harness feature. It is a candidate new computational primitive for agentic systems — and I use "candidate" deliberately, because the evidence is a shipped runtime, two fixed-backbone results and my own field observations, not a settled literature.

But you do not have to wait for the literature to make the decision this forces. There are two deterministic middles in your system right now, and you almost certainly have one policy covering both. The model may write the machinery of thought. It must never write away the machinery of authority. Everything else — how much freedom, which language, which vendor — is a detail underneath that line.

Run the classification on your own system this week and tell me which component surprised you: the one you had been guarding that turned out to be a probe, or the one you had been letting the model regenerate that turned out to bind.