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.¹

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², 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?³ If the answer is small, it’s interpolative.⁴ 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.⁵

What counts as interpolative software expands over time as RL environments become more diverse. The AI industry sometimes measures this with task time horizon (e.g., the METR time horizon graph). 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.