# Interpolative Software


Much of the excitement around AI coding is downstream of the fact that a lot of
software is _interpolative_. This has become especially true as of late, with
the release of Opus 5.5, which is, I’d argue, superhumanly good at generating
mass amounts of high-quality interpolative software.[^1]

This post is mostly a reference post for an idea that I’ve been gesturing to
near daily for the past several months.

**In 2026, software falls on a spectrum between interpolative software and novel
software.**

The vast majority of the software that most SWEs write[^3], most of the time, is
**interpolative software**. Interpolative software is code that is solidly
within the training distribution of models. Sometimes this means that the agents
were (likely) literally trained on examples of building pieces of software
(e.g., “build a todo app”, “build a clone of xyz.com”), or building within
particular APIs (e.g., React). Other times, the software “rhymes” with enough
existing software, or exists in a well-defined position between two pieces of
software, such that the model is able to interpolate between similar examples
it’s seen before.

Interpolative software can often be specified with just a few sentences of
prompting. The question to ask with respect to whether software is interpolative
or not is: how many bits of information do you have to include in your prompt to
get what you want?[^gwern] If the answer is small, it’s interpolative.[^2]
Things like issue trackers, web forms, training pipelines, CI systems, workflow
engines, and pretty much anything that has a canonical reference design in the
Open Source literature will fall somewhat under this interpolative distinction.

On the other end of the spectrum, there’s **novel** software. One develops novel
software when making something that has fundamentally not existed before. This
is usually because either the constituent components do not exist in the
training distribution for agents, or they’re being combined in such a novel way
that agents’ intuition for how to assemble the components is insufficient to
solve the problem without significant human guidance.

Writing novel software with agents feels like “fighting uphill” because there
are enough novel components that you’re not pulling from a training corpus, and
the model is struggling to grok what you want. Not a lot of software is novel.
And this is fine; there’s a ton of value in the interpolative stuff.

At work, we’ve been redeveloping a large-scale distributed system that has a
complex set of specific requirements. I’m sure that a system that satisfies this
specific set of criteria has not existed in any company before. (And if it has,
it’s definitely not public, nor in any public training set.) It’s been
fascinating to watch coworkers push on this system for the better part of a
year, using copious amounts of agents and tokens. Despite it being one of the
most agent-pilled projects I’ve yet seen, it still requires a large amount of
diligent human shepherding to ensure that the system actually performs as
designed.

On the other hand, you can give an agent instructions of essentially “build
Anki” or “build Linear” and it’ll just do it end-to-end. I’ve done both of these
-- I had agents rebuild large chunks of Anki into a personal set of tools. It
only took a few prompts, and was a complete no-op drop-in replacement for all
the features of Anki that I cared about. Ditto Linear.[^linear]

What counts as interpolative software expands over time as
[RL environments become more diverse](https://epoch.ai/gradient-updates/state-of-rl-envs).
The AI industry sometimes measures this with task time horizon (e.g., the
[METR time horizon graph](https://metr.org/time-horizons/)). This is a useful
metric, but it’s a proxy for, roughly, “what level of technical challenge can
you give to an agent and still have it produce something useful at the end”. The
amount of creative interpolation that agents can do is increasing -- and at the
limit, sufficiently general, creative, extrapolative combinations of existing
components begin to look like novel inventions.

Pre-AI, there already was some recognition that a lot of SWE work was spent on
interpolative work. “We want a CI system that works for $OUR_REQUIREMENTS. We
want a workflow engine for X that does Y.” Et cetera. Every project contains a
bit of novelty, but a lot of the work was reassembling existing parts in mildly
novel configurations. I’d take the success of the Open Source movement in the
2010–2020 era as evidence of this. Since a lot of software development was
combining somewhat standard patterns, and the patterns themselves were
complicated to implement competently, standardizing on OSS and sharing in the
benefits of standardization was rational.

To be clear: whether software is novel vs. interpolative isn’t a value judgment.
If anything, you _should_ be trying to push _more_ of your problem into the
domain that can be solved with interpolation, since interpolative subproblems
can easily be solved with a generous application of tokens. Much of the job of a
modern software engineer is applying the bits needed to change a problem from
novel to purely interpolative, such that the maximal amount of hands-on
interactive implementation work can be offloaded to agents.

[^1]:
    GPT Sol 6.1 -- the obvious comparison point -- is not a bad coding agent.
    It’s just abundantly clear that Opus 5.5 has some special “juice” for
    spitting out interpolative software that the GPT models are currently
    slightly behind in.

[^2]:
    Note that this is a function of the training distribution of frontier
    models, not a function of the actual complexity of the software. “Build me a
    memory allocator” is a small prompt that will yield something which, while
    probably not what you’d want to use in any real setting, is still quite
    complex.

[^3]: Well, agents at this point.

[^gwern]:
    There is a parallel here to Gwern’s
    _[Adding Bits Beats AI Slop](https://gwern.net/blog/2025/good-ai-samples)_.

[^linear]:
    Admittedly, I am not a power user of Linear. But I wanted a hackable issue
    tracker that was not modeled on JIRA, and Linear was close enough in
    prompt-space to what I wanted that agents made something quite compelling
    with a one-shot prompt.