Is Anything in Software Still Novel?

In June 2023, DeepMind published a result in Nature that the coverage almost universally described as a machine inventing an algorithm. AlphaDev, a reinforcement-learning system, had found a sorting routine a few assembly instructions shorter than the one that had shipped inside the C++ standard library for more than a decade. For very short sequences it ran up to 70% faster. The saving was real enough that it was merged into LLVM’s libc++, where the routine now runs billions of times a day on machines that will never know a model wrote it.

Read the result carefully and the story inverts. AlphaDev did not invent sorting. It did not invent sorting networks, which are older than most of the languages you use. What it found was a shorter instruction sequence for a fixed, tiny input under a brutally specific constraint: minimize instruction count when sorting three, four, or five elements on one instruction set. The novelty was not in the component. It was in the constraint: narrow enough, and squeezed hard enough, that a search process could recover the last few instructions a human had left on the table. That is where novelty in software now lives: not in the components, which are almost all known, but in the constraints, which are the only thing that keeps changing.

What follows: why component-level novelty went nearly extinct without anyone sending an announcement, where the genuine novelty relocated to, and why that relocation is the whole reason you should be handing AI a different half of your job than the half you’re guarding.

The strongest version of “software is still full of invention”

I want to give the it’s-all-still-novel view its best shot, because a weak version is too easy to knock down. Software has produced genuine new categories inside a single career: the transformer architecture, vector databases as a product class, the modern data lakehouse, CRDTs moving from paper to production, WebAssembly as a portable target. These are not repaints of old ideas. Someone had to see them, and seeing them was hard. If you were in the room when any of them clicked, calling your work “recombination” feels both wrong and a little insulting. Concede all of that. It is real invention, and it is not going away.

The part that doesn’t survive contact with the actual artifacts is the assumption that the invention lived in a component. Look closely and almost every one of those breakthroughs is old parts meeting a new constraint. The transformer is attention (Bahdanau and colleagues published additive attention in 2014) recombined and scaled under the constraint that training had to parallelize across GPUs, which is exactly what the recurrent networks it replaced could not do. Vector databases are approximate-nearest-neighbor indexes, HNSW from 2016 and IVF older still, wearing the new constraint of embedding-scale similarity search at production latency. The genius was real. It was almost never in a brand-new component. It was in recognizing which known parts the new constraint made suddenly viable, and paying the engineering to make them hold.

So the honest version of the steelman is this: invention is alive and well, and it almost always lives one level up from where we keep looking for it: in the constraint, not the component.

The category error

The mistake that follows is small to state and expensive to make. If you believe the scarce, valuable, human contribution is inventing novel components, you will staff for that, interview for that, and spend your own attention on that. And you will be optimizing for a supply that a recombination engine now produces faster than you can. Because that is what a large language model is, at its core: the most capable recombination engine ever built, trained on essentially every pattern the field has already written down. Handing it “produce a component-level solution from known patterns” is not asking it to do the hard part. It is asking it to do the part it is structurally best at.

The genuine novelty, the part that was never in the training distribution because it did not exist yet, sits in four places, and all four are constraints. New hardware realities: NVMe and flash reshaped storage engines, and the log-structured merge tree got re-tuned for a medium whose erase, write, and read costs are wildly asymmetric. The data structure was from 1996; the constraint was new. New scale: distributed consistency is a discipline that exists because old components break in new ways once you span datacenters; Jepsen is a career built entirely on that one constraint. New adversaries: Spectre and Meltdown, disclosed in January 2018, recombined known primitives, but the constraint they announced (that microarchitectural timing is now inside your threat model) was genuinely new, and no amount of cleverness at the component level had anticipated it. And new component types: the large language model itself, a part that is stochastic, promptable, and injectable, generating a failure class (prompt injection) with no real precedent in fifty years of software.

Notice what those four have in common. None of them is a thing you invent. Each is a thing you recognize and specify. The scarce skill was never conjuring a component out of nothing. It was seeing the constraint clearly enough to say what the component has to survive.

What this means in practice

If the recombination is the cheap half and a machine is better at it than you are, then the correct move is not to guard the recombination. It is to give it away, deliberately and at volume, and spend the attention you recover on the constraints.

This repository’s own engineering history is a clean demonstration. One engineer, six months, more than 1,400 commits, five distinct technology stacks: a LibreChat fork, a Python rewrite, a Rails iteration, a Go backend, a Flutter client. Almost none of that code was novel at the component level. Authentication flows, streaming endpoints, RBAC middleware, CRUD against a schema: known patterns, recombined faithfully, at a velocity no human typing could match. The human calls were the constraints: which stack the streaming-gateway workload actually demanded, where the ownership boundaries between services had to sit, when a direction was wrong and it was time to stop. As that engineering series put it plainly: AI-assisted development “does not make you faster at building the first thing you think of. It makes you fast enough to build several things and choose the best one.” The building was recombination. The choosing (which is constraint work wearing a different coat) was the job.

That is the reframe the rest of this series runs on. You are not competing with the model to invent components. You are the one who defines what the recombination has to satisfy, and then the one who checks, adversarially, whether it did. Everything in between is increasingly tokens.

What this requires architecturally

A reframe you can’t operationalize is a slogan. Giving the recombination away only works if handing work to a machine doesn’t cost you more in coordination, review, and cleanup than you saved. That is an infrastructure problem, and it is precisely the problem DevFlow (the AI-native development harness that runs on top of Claude Code) is built to solve: structure the recombination into discrete, verifiable units, one atomic commit per task, with verification that checks whether the objective’s goal was actually met rather than whether a task was marked done. The point of that machinery is not speed for its own sake. It is to make the recombination cheap and trustworthy enough that your scarce attention is never consumed by it, so it stays free for the constraints, which is the only place it earns a return.

This is also the through-line of how AOCyber reads the current frontier: capability commoditizes; trust infrastructure compounds. A component-level solution is a depreciating asset: the next model produces a better one next quarter. The systems and definitions wrapped around it are what accumulate.

What to build first

So start by drawing the line honestly through your own work. On one side, the recombination: the endpoints, the migrations, the glue, the second and third and fourth version of a thing you already understand. Hand it over, at volume, behind a harness that keeps it reviewable. On the other side, the constraints: the hardware reality you’re actually bound by, the scale that breaks your easy assumptions, the adversary who gets a move after you ship, the new component type whose failure modes have no precedent. That side is yours, and it is where the series goes next, because knowing that novelty lives in constraints is only useful once you can tell which of your problems are closable by a machine loop and which ones an adversary will keep open forever. That distinction is the next post.

For now, the correction is enough to change how you spend Monday. Stop asking whether the thing you’re building is new. Almost nothing is, and that was always true; AI just made it undeniable by producing the recombination faster than you can pretend otherwise. Ask instead what constraint the recombination has to survive, because the components are old, and the constraint is the work.