Thesis / September 2026

Intelligence,
at runtime.

How decision models will eat code at runtime

01
Software = code written by humans
The human writes every line.
02
Software = code written by models
English at write-time. Code at runtime.
You are here
03
Software = a blend of models and code, both generated by models
English at runtime, too.
Next stop
04
Software = models generated by models
In some cases, only models remain.

Write-time already speaks English. Runtime still does not.Read the thesis ↓

00The premise

Models have completely changed how we create software: humans prompt their goal, and the model writes the code to achieve it. But at runtime, that code is still mostly deterministic. Sure, it may call LLMs, mainly for cases where waiting seconds is fine, or where text generation is the point (chatbots, analysis, research).

So the way we execute code has not changed that much.

01The question

What if runtime logic could be written in English too?

If it’s true that English is the new programming language, what if we bring the flexibility of natural language that took over how we write code also to runtime, to when we execute code?

What does this mean in practice? Application logic is all about flows: conditions, loops, and branching. Conditions are usually composed functions that end in True or False.

What if models become intelligent, fast, cheap, and honest enough to:

iReplace these deterministic conditions
iiRun the branching
iiiand/or generate code at runtime

Imagine the LLM that writes your code also writing runtime logic that blends English and code, putting model intelligence inside software logic:

A runtime filter, in English

with decisions():
    outages = [
        t for t in tickets
        if likely("this is a production outage", t) > 0.7
    ]

Written by your LLM. Reads as N calls. The comparison is what fires the model.

Thesis 1

As they get smarter, faster, cheaper, and more honest, models will eat more and more of your code. In some cases, only models may remain.

02What this unlocks

Five things you couldn’t do before.

1 / 5

Expressing the inexpressible

Before: wasn't doable

# works only if titles exactly match
if new_ticket.title == existing.title:
    merge_into(existing, new_ticket)

After

if likely("same underlying bug", pair) > 0.85:
    merge_into(existing, new_ticket)

2 / 5

One sentence instead of a subsystem

Before

if SSN.search(doc) or CC.search(doc):
    if dest in PUBLIC_BUCKETS:
        block(doc)
    elif "passport" in doc.lower():
        classify("restricted")
elif HEALTHCARE.search(doc) and region == "EU":
    classify("restricted")
# ... 120 more lines of regexes and lists

After

safe = (judge("contains no PII", doc)
        & judge("contains no profanity", doc)
        & judge("is on topic for this channel", doc))

match safe:
    case Yes():    publish(doc)
    case No():     block(doc)
    case Unsure(): queue_for_review(doc)

3 / 5

Real-world input without a parser

The ticket is English. So is the refund policy. Both go into the decision as-is:

Before

fields = parse_ticket(raw)
# breaks when the template changes
if tenant == "acme" and fields["amount"] < 50:
    approve(req)
elif tenant == "globex" and fields["vip"]:
    approve(req)

After

policy = tenant.policy
# "auto-approve small duplicate refunds"
if likely(policy, raw) > 0.9:
    approve(req)

And now the juicy part

4 / 5

Dynamic application logic

The software adapts without needing to be updated, because it generates part of the code at runtime:

Before

if vol_30d > 0.4 and rsi_14 < 30:
    grid.run(portfolio)
elif trend_7d > 0:
    dca.run(portfolio)
# thresholds hand-tuned, logic frozen at deploy

After

@adaptive("swing between a grid and a DCA strategy
           based on market conditions")
def trade(portfolio, market): ...

The body is written by the model at runtime, and rewritten as the market moves. Not a condition replaced: a block of code replaced.

5 / 5

Train/evals on the entire software

CI/CD stops checking that the application still works and starts measuring how well it performs. When a number moves the wrong way, the pipeline has two levers: change the confidence thresholds in the ifs, or retrain the models those likely() calls hit.

So models and knobs change in order to pass the tests. The same rigor we already apply to train/evals on a model, extended to the entire application.

tests/test_welcome.py · runs in CI on every PR

def test_welcome_email():
    email = render_welcome_email(user)
    assert likely(
        "addresses the user by name and contains exactly one call to action",
        email,
    ) > 0.95
    assert not likely(
        "contains placeholder text like TODO or lorem ipsum", email
    ) > 0.3

Then the suite scores the whole app against last week's traffic

$ eval --suite app --against traces/week-32.jsonl

Controller	Knob	Now	Proposed	Metric
refunds.auto_approve	p>	0.90	0.74	escalate 41% → 12%
refunds.external_bank	p>	0.50	0.50	hold
feed.spam	p>	0.80	0.80	hold
feed.scam_or_fraud	p>	0.50	finetune	new pattern in traces
agent.block_tool_call	p>	0.85	0.88	3 false-allows this week
app score0.91 → 0.94
actionwrite knobs.json, queue finetune on feed.scam_or_fraud

You stop asking “do the tests pass” and start asking “did it get better”. The entire application, not the model.

03Are we ready?

Models have to clear four bars. Today:

IntelligentYes

FastNope

Used as software controllers, they need tens of milliseconds, not seconds.

CheapNope

Frontier models are still too expensive for this pervasive, high-frequency use.

HonestNope

Honest means the model tells you how sure it is, and says so when it isn't. Today's models sound equally sure when the answer is solid and when it is not. Fine for chat. A disaster for software that must branch on confidence.

Which is fine. They were built for what they are mainly used for: chatbots.

Thesis 2

While today’s LLMs are designed above all to talk to humans, a new category of LLM-like architectures, decision models, will emerge to be used at runtime inside software.

04A different kind of model

A decision model has to be:

01
Smart
As capable as the models we built for people.
02
Machine-fluent
Instead of bloating you with text, it speaks the native vocabulary of software: branching yes/no, the probability that something is true, estimating, choosing, ranking, sorting, classifying, and generating code quickly at runtime.
03
Fast
Milliseconds, so it can be called abundantly, hundreds of times in a single run.
04
Cheap
Cheap enough that hundreds of calls in a single run is not a budget decision.
05
Honest
It shares its confidence with every answer, and admits when it is unsure, so the calling controller can act, escalate, or ask a human. Real confidence, calibrated to how often it is right, not next-token-prediction theatre (= the most likely continuation of a JSON string that happens to print a confidence score).

05The reasonable objections

The reasonable objections.

Determinism is actually pretty good.+

We used “models” on purpose, and kept it generic: anything you fit to data. What runs at runtime could be a deterministic decision tree, or a hybrid random forest. Read “models” in this thesis as a superset of both probabilistic and deterministic controllers.

Models will never be fast enough to generate code at runtime.+

Ehm, look at how tokens per second are accelerating, then just project the curve, please :)

Isn’t this the same as small models? Why a new category?+

Decision models will definitely benefit from small and nano model progress. But:

The objective is different. Small models are still optimized for chat. Here you optimize for runtime software. Architecture and inference both change: that’s a different stack. E.g. if you are classifying, you don’t need generation at inference time.
They still have no real confidence, only next-token-prediction theatre.
Why small? In many cases you need large-model-like intelligence.

“One model for everything” is a slogan, not an architecture.

Generating code at runtime is reckless.+

Sure? Look at how coding quality has improved in the last 18 months, then project the line.
The thesis does not require every program to generate large parts at runtime. That has tradeoffs, and you should do it only when it makes sense: for the specific pieces that are valuable to generate at runtime because the design of the application logic benefits from inputs that were not available at coding time.

English from the outside is an attack surface.+

The dangers of a thing must not defeat the reasons to do it. Mitigate it. External inputs already exist, they are already dangerous, and we are already using them, btw.

Smart, fast, cheap, and honest may never arrive together.+

Possible. It’s always about tradeoffs. Read this thesis as a direction, not a date.