The Six Levels of Adaptive Software

I believe that in the future, products begin to observe, diagnose, repair, optimise and eventually reshape themselves around users and contexts. The shift is not simply from human-made software to AI-made software. It is from software as a fixed artefact to software as a living system.

The automotive industry has a useful way of talking about autonomy, from basic driver assistance through to fully self-driving cars. Software is likely to develop a similar ladder. Not around who has their hands on the wheel, but around who decides how the product changes. Here's my attempt to shape what that ladder might look like, starting with the way we work today.

Level 0: Manually Authored Software

This is the way most software has been designed up to this point.

A team does research. They look at customer interviews, usability studies, support tickets, sales calls, analytics dashboards, funnel reports, session replays, app store reviews and whatever other signals they can gather. Product managers, designers, researchers, analysts and business stakeholders interpret that evidence, turn it into insights, then propose improvements.

Those ideas become features, experiments, backlog items, design briefs, roadmap themes or quarterly priorities. The product team designs the solution, engineers build it, QA tests it, and the organisation releases it. If the team is reasonably disciplined, someone later checks whether the change had the desired effect.

Level 0 software may be heavily instrumented, but the loop is still stitched together by people. Analytics tools do not redesign the checkout flow. Support tools do not patch the confusing settings page. Session replay does not generate a better onboarding journey. These tools produce evidence, but humans decide what matters and push the change into production.

Core loop:
Research and data → human interpretation → human concept → human design → human build → human testing → human release → human measurement

Example:
A subscription product has separate checkout flows for the UK, Germany and the US. Each flow is researched, designed, localised, built, tested and optimised manually. Analytics may show that one market is underperforming, but the team still has to understand why, decide what to change, and ship the improvement.

Level 1: AI-Assisted Software Creation

This is the level most teams are currently moving towards. Humans still decide what to build, but AI helps them think, design and ship faster.

This is the current wave of AI coding tools, design agents, prompt-to-app builders, synthetic users, automated QA, AI-generated copy, AI-generated prototypes and Figma-to-code workflows. Product managers and designers use LLMs to explore ideas, simulate reactions, critique flows, draft experiments and imagine product improvements. Engineers use tools like Cursor, Copilot and coding agents to move faster through the backlog.

This changes the pace of product work. More ideas can be explored. More prototypes can be generated. More tickets can be completed. More experiments can be shipped. In some teams, the bottleneck moves from “can we build this?” to “should we build this, and did it work?”

A lot of product teams, design teams and AI-native studios currently treat this as the destination. In their view, the future of software is smaller teams using AI agents to design, code and ship at a speed that previously required a much larger organisation.

That is a meaningful shift, but it is still a human-orchestrated model. The product team is using AI to make software faster. The software itself is not yet observing, diagnosing, repairing or adapting its own behaviour.

The loop is still not closed. In most organisations, the context needed to make good product decisions is scattered across analytics dashboards, support tools, CRM notes, research repositories, experiment logs, sales calls, roadmap docs and half-forgotten Slack threads. Much of the important context still sits in people’s heads: why a decision was made, which metric can be trusted, which customer segment matters most, which old experiment failed, and which apparent opportunity is actually a trap.

So even when humans are doing less hands-on coding, they are still the glue. They carry the context, interpret the evidence, make the trade-offs, decide what gets shipped and check whether the result was any good.

Core loop:
Human intent → AI-assisted exploration → AI-assisted production → human review → human deployment → human measurement

Example:
A product manager uses an LLM to brainstorm improvements to a subscription checkout, then the team uses AI coding tools to build several variants more quickly. Humans still decide what to test, connect the work to the actual analytics, judge whether it succeeded and decide what happens next.

Level 2: Self-Diagnosing Software

This is the point where a product starts to develop a sense of proprioception.

In humans, proprioception is the sense of where your body is, how it is moving, and when something feels wrong. Level 2 software begins to develop something similar. It starts to understand how it works, where it is under strain, when normal behaviour has changed, and where somebody may need to intervene.

This is the first point where adaptive software feels meaningfully different from today’s product process. The system no longer waits for a product manager, analyst, researcher or growth lead to open a dashboard and go looking for problems. Agents run in the background, constantly watching what is happening across the product.

They monitor usage patterns, funnel performance, error logs, support tickets, session replays, release history, experiment results, performance data and customer behaviour. More importantly, they connect those signals together.

At this level, the system may also start flagging opportunities. It might notice that expert users are slowed down by explanatory copy, that one onboarding step is consistently skipped, that search is being used as a workaround for poor navigation, or that users in one market abandon after seeing a payment method they do not trust.

It may even suggest possible fixes or experiments. But the boundary remains clear: the software diagnoses and recommends. Humans still decide whether the diagnosis is credible, whether the opportunity matters, and whether to act on it.

Core loop:
Product observes → product connects signals → product diagnoses → product recommends → human decides

Example:
A subscription product has agents monitoring checkout behaviour across markets. The system notices that German mobile users are abandoning after postcode entry, connects this to a recent release, checks related support tickets and session replays, then flags the issue with a likely cause and possible tests.

Level 3: Self-Healing Software

At level 3 the product can detect and fix narrow failures automatically.

This is where the system stops simply flagging problems and starts making small, safe corrections. It is still not redesigning the product. It is not deciding strategy, inventing new features or rethinking the user journey. It is keeping the existing product healthy.

To do that, the system needs some understanding of developer intent. It can infer that intent from the codebase, unit tests, API documentation, design system rules, FAQs, acceptance criteria, release notes, monitoring thresholds and the behaviour of previous working versions. It starts to understand not just what the software is doing, but what it appears to be meant to do.

A Level 3 system constantly runs checks in the background. It can detect failing tests, broken components, visual regressions, slow services, payment-provider issues, accessibility errors, dependency problems, dead links, API failures, layout glitches, degraded performance, emergent bugs and small security vulnerabilities.

At the simplest level, it may roll back to the last known working version. That alone would remove a lot of stress from engineering teams. But increasingly, the system may be able to fix the issue directly: patching a dependency, correcting a validation rule, restoring a broken API contract, repairing a visual regression, or opening a tightly scoped pull request with the likely cause already explained.

The analogy is less “fully self-driving car” and more modern autopilot in an aircraft: hundreds of small adjustments in response to pressure, wind, turbulence and changing conditions so the flight stays smooth. Or, in car terms, automatic emergency braking. The system is not doing all the driving, but it is watching continuously and reacting faster than a human might to critical issues.

Self-healing software is defensive. It maintains the intended experience rather than inventing a better one. It keeps the system inside safe operating conditions and frees engineers from some of the low-level bug-fixing and technical-debt work that currently eats into product development.

Core loop:
Product observes → product tests → product detects failure → product infers intended behaviour → product repairs or rolls back → human is notified

Example:
A new checkout release creates a spike in failed payments for users in France. The system detects the issue, compares it with tests and previous behaviour, identifies a broken payment-provider integration, switches affected users back to the previous component, opens a pull request with a proposed fix, and notifies the engineering team.

Level 4: Self-Optimising Software

At this level the product starts to generate, run and evaluate improvements to known flows.

This is where adaptive software moves beyond maintenance and starts doing some of the work we currently associate with product, growth and experimentation teams. The system is no longer just keeping the product healthy. It is trying to make the product perform better.

In the early stages, this will probably be supervised. The software might notice a problem, generate a set of possible experiments, and ask a human to authorise the test:

“German mobile users are abandoning at postcode entry. I’ve generated three alternative flows: one with later address validation, one with clearer invoice-payment copy, and one that moves payment selection earlier. Shall I run these as a 10% experiment?”

Once teams trust the system, some of this work can move into autonomous mode. The product can run multivariate tests in the background, allocate traffic, monitor performance, stop harmful variants, promote winners and keep iterating without asking for permission every time.

At this level, the product still has one main version of the software. It is not creating a different interface for every user or designing around dozens of behavioural clusters. It is optimising a known flow toward a single local maximum: the best checkout, the best onboarding sequence, the best upgrade path, the best cancellation save, the best pricing page for an "average user".

The difference is that it can optimise continuously, across more dimensions than a human team could realistically hold in their heads. A mature Level 4 system would understand business goals such as acquisition, activation, conversion, revenue, retention, support cost, basket size, lifetime value, churn risk, margin and customer satisfaction. It would know that improving conversion at the expense of refunds, support load or retention may not be an improvement at all.

This is where governance starts to matter. A self-optimising system needs more than a metric to chase. It needs constraints, trade-offs and a working definition of what “better” is allowed to mean.

Core loop:
Product diagnoses → product generates variants → product runs experiments → product evaluates outcomes → product ships winners → product keeps optimising

Example:
The system identifies friction in a subscription checkout, generates several variants, runs a multivariate test, notices that one version increases conversion but also increases refunds and support contact, rejects that variant, then promotes a slightly lower-converting version that produces better long-term retention and lower support cost.

Level 5: Multi-Optimum Software

Products at this level start to create multiple versions of itself for different groups of users, needs and contexts.

Once a system can diagnose problems, generate variants, run tests and optimise known flows, the next step is to stop assuming there is one best version of the product. Instead of optimising a single checkout, onboarding journey or product page toward one local maximum, the software can start creating multiple local maximums for different types of user.

At first, this might look familiar. The system could automatically design different checkout flows for different geographies: one for Germany, one for the US, one for Japan, one for Brazil. Each might reflect different payment norms, address formats, tax rules, trust signals, delivery expectations and regulatory constraints.

But geography is only the obvious example. An ecommerce product might discover that older customers behave differently from younger customers around payment, reassurance, font size, product detail, returns information or customer support. It might learn that some users prefer card payment, while others expect wallets, bank transfer, invoice payment or instalments. It might find that different groups respond better to lifestyle imagery, technical specifications, comparison tools, video, reviews, sizing guidance, augmented reality previews or social proof.

This is where things start to get weird. There is no longer a single source of truth in the traditional product-design sense. You cannot print out the user flows, stick them on the wall, and say, “This is how the product works.” The product may have 20, 50 or 200 active versions, each optimised for a different cluster of users, needs and contexts.

At that point, teams may stop fully understanding the product in the old way. They will understand the system, the goals, the constraints, the component library and the rules of adaptation. But they may not know every expression of the product that users are seeing. The product becomes less like a designed artefact and more like a managed ecosystem.

This is still bucketed personalisation. Users are being assigned to clusters. But the clusters are increasingly discovered by the system rather than invented in a workshop. The product is no longer asking, “What is the best version of this flow?” It is asking, “Best for whom?”

That creates a serious governance challenge. Some categories, such as age, gender, geography or inferred intent, can quickly become sensitive or reductive if used crudely. A mature Level 5 system cannot simply optimise whatever appears to work. It needs rules about fairness, accessibility, manipulation, exclusion, brand consistency and what kinds of personalisation are acceptable.

Core loop:
Product identifies clusters → product generates tailored journeys → product routes users → product evaluates outcomes by cluster → product refines the experience set

Example:
A shopping site discovers that different groups need different checkout and product-page experiences. It automatically creates one checkout for invoice-heavy B2B buyers, another for younger mobile-wallet users, another for older customers who need more reassurance, and another for users in markets where delivery trust is the main barrier.

Level 6: Individually Adaptive Software

Products at this level have the ability to create a different a difference experience for every user, interaction or session.

Once a system can generate dozens or hundreds of versions of a product for different groups, the final boundary starts to look arbitrary. If the product can adapt to geography, payment preference, confidence level, device context, previous behaviour, buying intent, accessibility need and stage in the journey, why stop at buckets?

At Level 6, the product no longer routes users into a pre-existing segment and serves the best available version for that group. It assembles the interface around this user, in this moment, for this task.

The same person might get a different version of the product on Monday morning than they do on Friday evening. They might get a different interface when browsing casually on a phone, comparing options on a laptop, returning after abandoning a basket, buying under time pressure, using assistive technology, or contacting support after something has gone wrong.

At this level, every interaction becomes its own design brief.

The system is not choosing between Checkout A, Checkout B or Checkout C. It is dynamically assembling the journey from components, content, interaction patterns, business rules, accessibility requirements, brand principles, regulatory constraints and live behavioural signals. Sequence, density, copy, reassurance, navigation, visual hierarchy, defaults, support prompts and payment options can all shift according to the user’s needs and context.

In Level 5, the system creates local maximums for groups. In Level 6, it tries to create a local maximum for every individual interaction.

That could be extraordinarily useful. A novice user gets more explanation. An expert gets shortcuts. A nervous buyer gets reassurance. A returning user skips steps. A user with accessibility needs gets a structurally different interface. A user in a regulated market gets additional compliance content without making the product heavier for everyone else.

It could also become manipulative very quickly. A product that can adapt to someone’s needs can also adapt to their weaknesses. So Level 6 is not just a technical endpoint. It is a governance problem. The question is no longer only, “Can the product adapt?” It is, “What is it allowed to adapt around, and in whose interest?”

Core loop:
Product understands the individual context → product assembles the experience → product evaluates the outcome → product updates its model → product adapts again

Example:
Two people arrive at the same subscription checkout and receive meaningfully different experiences: different sequence, density, explanation, payment emphasis, reassurance, support prompts and interaction patterns. Later, one of those same users returns on a different device, with a different intent, and receives a different version again.

The underlying shift

The future of software is not simply that teams will use AI to build products faster. That is Level 1.

The larger shift is that products themselves will begin to observe, diagnose, repair, optimise and eventually reshape their own interfaces.

Most software today is designed around a small number of assumed use cases. This requires trade-offs and those trade-offs require human input. Adaptive software moves from one local maximum, to many local maximums, to a local maximum for every individual user interaction. And this all happens live, in the background, and without needing additional resource.

When this happens, product development stops being a human endeavour and becomes a "lights-off" activity, much like factories or warehouses that have such a high level of automation, they can run mostly in the dark, because humans rarely if ever need to visit the factory or warehouse floor.

Not every product team will operate like this, just like not every car will be self driving in 10 years time. But this is defnitly the direction of travel and I'm already starting to see products hitting levels 3, 4, 5 and crude versions of 6.