I came across a short post by Ben Congdon this week, Interpolative Software, and it put a name on something I have been bumping into for months while building Calendrz with AI agents. His idea is simple: in 2026 software sits on a spectrum. At one end there’s “interpolative” software, code that is “solidly within the training distribution of models”, the sort of thing you can describe in a few sentences and get back in decent shape (issue trackers, web forms, CI systems, workflow engines). At the other end there’s novel software, something that “has fundamentally not existed before”, where working with an agent feels, in his words, like “fighting uphill”.

His test for telling them apart is the bit I liked the most: how many bits of information do you have to put in your prompt to get what you want? Not how complex the code is (a memory allocator is complex, and yet “build me a memory allocator” is a short prompt), but how much of what you want the model can’t already guess.

I think he’s right. And I think most engineering leaders are drawing the wrong conclusion from the AI coding numbers because they don’t make this distinction.

Most of a Product Is Interpolative

Let me explain with my own code. Calendrz is a Spring Boot backend, an Angular front end, a MySQL database, Google and Microsoft sign-in, Stripe for billing, transactional emails, an admin area and so on. Needless to say, none of that is new. Thousands of open source projects have done every one of those bits, and as such an agent has seen them all a million times. For a new Stripe flow or another sign-in provider, a paragraph of prompt and a careful review of the PR get you most of the way there. That’s interpolative software, and it’s a big chunk of the codebase.

Congdon rebuilt large parts of Anki and Linear with a handful of prompts, and I’m not surprised in the slightest. Truth be told, most of what any SaaS company ships is a recombination of patterns that already exist (no insult intended: that’s how software has always been built).

And Then There’s the Bit That Isn’t

The crux of Calendrz is availability mirroring: when you’re busy in one calendar, it puts a “busy” marker in each of your other calendars, without the private details, so nobody double-books you. Sounds trivial, right? A few sentences of prompt, surely?

Well, no. Think about what that one sentence leaves out. Calendrz has to know which entries are its own markers, so it never mirrors a marker back into the calendar it came from (or you get a lovely feedback loop). It has to know exactly which original each marker belongs to, so that when a meeting moves or gets cancelled the marker follows it. It has to cope with several sync runs at once, because a push notification from Google can arrive while a full sync is already going. None of that is in a textbook, and none of it is the sort of thing a model can infer from “mirror my availability”.

And yes, this is exactly where my bugs have lived. A few examples from the repository:

• Earlier this year markers were created perfectly well but then never updated when the original meeting moved. The root cause was a comparison between two different kinds of identifier (an event’s unique ID on one side, an email address on the other). They could never match, so the update was quietly skipped. Every individual line looked fine.
• In the spring we found duplicate markers. A full sync and a push-triggered sync could both decide, at the same moment, that a marker was missing, and both would create one.
• Back in 2024, an attempt to clean up some failed markers set off an avalanche of updates, with markers appearing and disappearing in people’s calendars, and the fix was to stop the notifications and reset the channels by hand. Not pretty!

Don’t get me wrong: the fixes for the first two were written together with an AI agent, and it did a great job of them. But to get there, somebody had to know what a marker IS, what it must point to and what must never happen, and that somebody was me. That’s novel software in a nutshell: the information isn’t in the training data, it’s in your head.

So What Should Leaders Do About It?

Congdon makes a point at the end which I’d underline twice: a lot of the modern engineer’s job is adding the information that turns a novel problem into an interpolative one. I’d go a step further: with agents writing most of the code, that IS the job now.

In practice, for Calendrz that meant writing things down. The repository has a root cause analysis for the marker bug, with a diagram of the mirroring flow, and a set of rules files that the agents read before touching anything. Each of those documents adds the bits a prompt would otherwise be missing, and every time I write one, the next change in that area becomes a bit more interpolative. I’m firmly of the view that this is where software engineering is heading: a “lights out” setup where we “code” through specs, and agents write, test and ship. The specs are the part that can’t be outsourced, because they’re where the novel bits get written down.

For engineering leaders, I think this changes a few things:

• Stop quoting one productivity number for the whole team. A huge speed-up on the CRUD screens and a modest one on the core engine can both be real at the same time, and averaging them tells you nothing.
• Know where your novel code is. Every product has a small core that is genuinely its own (your pricing engine, your matching logic, your sync). That’s where you want your best people and your most careful reviews, AI or no AI.
• Treat documentation of invariants as engineering work, not a chore. “A marker must always point to exactly one original” is worth more to an agent than another thousand lines of examples.

I’ll give you that the line between the two moves over time, and Congdon says so as well: today’s novel trick is tomorrow’s training data. My bet is that the line will keep moving, but there will always be a front edge, and that’s where the differentiation (and the fun!) is.

Bottom line: if an agent can build your whole product from a few sentences, so can your competitors. The bits you have to explain are the bits worth building 🙂