Coding Intelligence Asymptotics

December 18, 2025

What happens to software when all coding can be cheaply automated? We typically think of software as being constrained by the intelligence and time budget of the people who develop it. Here we lift that restriction and consider the case of unlimited software development intelligence, where humans are not involved in the coding part at all.

The length of a codebase limits how quickly changes can be made. For a given bug, a smart developer can rule out some proportion of the code that surely doesn’t contain the error, then a debugger or tests can iteratively rule out more and more of the remaining parts. If that last part resembles a binary search over the number of lines N, then this scales as log(N). A search over fixed-length combinations of k lines also scales as log(N).

Since this is a very flat type of scaling, additional developer time buys us many more orders of magnitude of codebase length. Other more prosaic bottlenecks to producing a lot of code, such as typing speed, also fall away. We conclude that by default, codebases will become much larger in the future. It seems silly to think about it, but it could be that the limiting factor will be the compilation time.

The stack used in today’s coding projects is largely determined by what developers are already skilled at doing. It is rare for teams to develop with technologies they’re not previously familiar with; languages, libraries and tools all have switching costs. Observing the recent paradigm of pretrained language models, one could be tempted to assume that this also continues with artificial intelligence: the languages etc. with the most data available get picked. Approaching the limit of infinite developer time though, it first becomes more efficient to eat the switching costs for the most appropriate tools, then to create entirely new tools, and finally to write the best possible binary directly.

The kinds of tools that this enables seem very hard to reason about. Some of today’s areas in programming that are most bottlenecked by developer time might be unusual paradigms (like array programming APL), tools that have a horrible user experience (like FPGA-programming in Xilinx), or difficult ways of reasoning which inherently have an alien, antimemetic quality (like theorem proving in Agda). The programming tools that machines create for themselves might at first feel similarly awkward to humans, that is until they become completely unrecognizable to human programmers.

The above enables much more ambitious specs in the first place. The system writing the spec is finally bottlenecked by the readout of the constraint optimization it is solving for with the software, which could be about human preferences, some other physical process, or an output of a reference piece of software. Specs become longer by default, but here it pays off for us humans to keep oversight and make sure the spec contains the kinds of things we want to see in there. Here we run up against the alignment problem: it might be that ultimately the hardest part of all of this is to specify the correct constraint optimization.

This leads us to a neat feature of the infinite developer time paradigm. We can start asking for code with levels of guarantees that would be practically impossible for human teams. For starters, we need no dependencies, since it costs nothing to write everything from scratch. But we can think much bigger still, like demanding that the spec is logically formalized, to then mathematically prove that the produced code conforms to that spec, and red-teaming all the different ways the spec could fail to be what we actually wanted.

Asymptotics need not be informative for the orders of magnitude we are at (i.e., nobody does matrix multiplication with Coppersmith-Winograd), but some of the ideas laid out here will already play out soon, and are ready for early adopters.