The adjacent possible: why AI is changing what we can build.

There is a recognisable kind of software repository: a promising name, a brief README, three half-finished features and no activity for years. You can picture the person behind it deciding that the idea would take more evenings than they had to spare.

We tend to read abandoned projects as failures, and many are. The original calculation, though, may have been perfectly sensible: expensive infrastructure, too much specialist knowledge, a problem too small to justify a full development team. Those are conditions that can change.

That is where the adjacent possible becomes useful. It gives us a way of thinking about technological progress without pretending that every new tool changes everything overnight.

What is the adjacent possible?

Biologist Stuart Kauffman used the idea in his work on how biospheres expand. An existing system has a set of nearby possibilities: things that could emerge through the next available change. Once one of those possibilities becomes real, the neighbouring possibilities change as well.

His chemical-reaction example is unusually concrete. Start with a set of molecules in a vessel, which he calls the Actual. The new molecules that one reaction step could produce are the adjacent possible of that starting mixture.

That idea is often borrowed to explain innovation. The comparison is useful, though a software industry is not a biological system and the theory does not predict which apps will succeed. It asks a more modest question: what is now within reach because something else became possible first?

The adjacent possible: each branch depends on a capability before it.

AI moves the boundary between expensive and practical

Think of a one-person business that wants a searchable archive of its customer interviews. A few years ago, the owner might have needed several services, an integration specialist and ongoing maintenance. Even a modest internal tool could cost more to commission than the time it saved.

Today, someone with sufficient technical judgement can combine existing speech-recognition models, storage, search and a lightweight interface. AI assistance may shorten the initial development work. The result still needs testing, privacy decisions and care, but the starting calculation is different.

It helps to separate two changes that often get bundled together. Models provide new capabilities, such as recognising speech or generating text. AI-assisted development changes the effort of assembling software around those capabilities. A project can benefit from either change, or both.

Neither step requires the idea to serve a huge market. A tool used every Friday by one person may be worth building if it removes a recurring frustration. Being small is no longer a good reason to dismiss a software idea before examining its cost.

From a research model to something useful

Speech transcription offers a traceable example. In 2022, OpenAI released Whisper, together with models and inference code for speech recognition. The open-source project whisper.cpp then made it practical to run Whisper inference in C/C++ on a range of devices. Buzz, maintained by Chidi Williams, is a desktop application that uses Whisper and related backends to transcribe and translate audio locally.

These projects are not evidence that one breakthrough causes another. Developers still did the engineering. What they illustrate is how shared technology gives later builders a different starting point. Someone making an interview-transcription tool no longer needs to begin by inventing speech recognition.

Reusable technology and the applications built on it.

There is a similar shift in interface development. Vercel describes v0 as a tool that helps people create code and full-stack apps, working from a plain-language description of the idea. A designer can get a working draft into a browser sooner and find out where the idea falls apart. That draft is a beginning, though. It cannot establish whether the interface is accessible, appropriate for its audience or safe to connect to sensitive data.

The interesting part of these tools is not that an ordinary task becomes effortless. It is that the first useful version of an unusual idea may now be close enough to try.

Software for an audience of one

Software has long been judged by business metrics: users, subscriptions, retention and the size of an addressable market. Those things matter when somebody is building a business. They matter rather less when a personal tool solves a persistent problem.

A production coordinator who spends Monday mornings collecting approved assets might build a small system to check naming conventions and flag missing files. A researcher might assemble a private interface for exploring notes and transcripts. Neither project needs to become a startup. The benefit can be the hours it gives back, or the work it makes possible.

Lower development costs create room for this kind of software. They also make experiments less precious. You can test a peculiar idea without treating it as a commitment to maintain a company for the next five years.

Once the cost of trying an idea falls, the questions worth asking begin to change. Who needs this? What has stopped them solving it already? Which part of that obstacle still exists?

Does AI actually make developers faster?

It depends. The measured results vary with the task, the people doing it and the tools available at the time.

In a controlled experiment published in 2023, developers using GitHub Copilot completed one specified task, writing an HTTP server in JavaScript, 55.8% faster than a control group. That is one task, and it does not measure every kind of software work.

Two years later the picture looked different. In a randomised METR study from early 2025, experienced developers using contemporary AI tools were 19% slower on tasks in open-source repositories they knew well.

METR’s February 2026 follow-up suggested that newer tools may be helping more, but the researchers warned that selection effects made their later results unreliable as a measure of overall speedup. Developers reluctant to work without AI were less likely to participate, and some tasks were never submitted for the same reason.

A successful prototype can make it feel as if AI multiplies one developer many times over. The studies do not support that as a general rule for maintaining complex systems, reviewing security-sensitive code or supporting customers over time.

The bigger opportunity may be task substitution: work that would not have been attempted at all because nobody could justify the hours. Traditional productivity studies, focused on completing familiar tasks faster, do not fully measure that change.

The good ideas that arrived too early

Old repositories, archived forum discussions and half-finished prototypes are a record of decisions made under older constraints. Some contain ideas that deserved to be abandoned. Others might repay a second look.

Imagine finding a 2017 project that tried to organise recorded meetings. The code may be outdated and the interface difficult to use. Before rebuilding it, ask why it stalled. Was accurate transcription too expensive? Was search poor? Did the original author need to host more infrastructure than the audience could support?

Then ask whether those constraints still hold. A newer speech model may help with transcription. Cheap local storage may make privacy easier to manage. A coding agent may help rebuild the interface. None of that proves that people now want the product. It does, however, make the old decision worth reviewing.

Looking backwards in this way may teach more about software’s future than looking at today’s popular products and imagining a slightly cheaper copy. A copy starts from what already works. An abandoned problem starts from something people wanted and could not yet have, and the technology of its time may be all that kept it out of reach.

What would it take to test an old idea again?

Testing an old idea again starts with its history rather than its code. Someone was trying to accomplish something, and something stopped them. Whether that was model quality, specialist labour, integration effort, computing cost or simply too little demand matters a great deal, because each calls for a different answer, and only some of them have moved.

The second question is what has actually changed. A released model, an open-source library or a new platform capability can be described generously in announcements, so its original documentation is the better guide to what it really does. Then comes the smallest honest test: one workflow, realistic inputs, the failure cases included, and a count of how much human correction is still needed.

Such a test matters because technological feasibility is only one part of a good product. People may not want to change their habits. The data may be unreliable. Security and maintenance may make the small idea expensive again. Learning that early is still a useful result, and a prototype that exposes a harder problem has still made something real. In Kauffman’s terms, each thing made real changes what lies next to it, even if the project stops there.

When building gets easier, judgement matters more

If many people can produce an application shell, the shell itself offers limited protection. Reliability, customer knowledge, distribution and the ability to improve the product remain difficult to reproduce. Software still needs somebody to understand what it is for and what happens when it breaks.

AI can help write code, but it cannot take responsibility for a system’s behaviour. Anyone handling personal information, making consequential recommendations or connecting an agent to live business systems needs to think through permissions, data protection, errors and ongoing monitoring. A working demo is not proof that those decisions were made well.

The adjacent possible is an argument for curiosity rather than recklessness. It invites us to revisit assumptions about what is practical. It does not require us to mistake every new capability for a good reason to use it.

Most of us have a project somewhere that we judged too complicated, too expensive or too small, and the judgement may well have been right at the time. What the adjacent possible suggests is that such judgements have a date on them. The idea has not changed; the ground around it may have.