State of Startups 2026: 61% of Startup Codebases Are Majority AI-Written

The number

Supabase's State of Startups 2026, drawn from roughly 2,000 startup builders, reports that 61% of startups now have more than half their codebase written by AI. Forty per cent put the figure at 76 to 100%. Only 2% report none at all.

Read the distribution rather than the headline. The interesting group is not the 61%. It is the 40% for whom human-written code is now the minority case, the exception inside a codebase whose default author is a model.

The broader developer population is moving the same way from a different starting point. JetBrains' State of Developer Ecosystem 2025, across 24,534 respondents, found 92% using at least one AI coding assistant, agent, or editor, and 85% using AI tools regularly. The same survey found 92% expressing some concern about AI in software development. Adoption and unease are running at identical rates.

What that does to the review budget

Every governance mechanism most teams rely on assumes a particular ratio: a human wrote it, another human checks it. Code review, architectural review, pairing, the informal correction where a reviewer says we do not do it that way here. All of them are priced in human attention per change.

That pricing survives a 20% AI-written codebase. It does not survive 76%. The volume of changes rises while the number of people available to read them does not, and the gap does not close by trying harder. It is arithmetic.

What gets dropped first is not correctness. Tests still run, CI still gates, obvious defects still get caught. What gets dropped is the slower judgement: does this belong here, does it match how we decided this system works, is this the third time someone has introduced this pattern. That judgement was never encoded anywhere. It lived in the reviewer.

The correlation worth reading carefully

The report includes a finding that is easy to misuse. The more AI-generated a startup's codebase, the less likely it is to be monetising yet, and the more likely it is to name customer acquisition as its biggest challenge.

That is a correlation, and the obvious causal reading is almost certainly wrong. Pre-revenue startups build prototypes fast because they are pre-revenue, not the other way around. A team validating an idea should generate aggressively and worry about structure later. The report itself notes that non-technical founders sit at the heavy end of the distribution, which fits the prototype explanation rather than a story about AI harming businesses.

The useful version of the finding is narrower. A large share of majority-AI codebases are early, unvalidated, and were built to answer a market question rather than to be maintained. Some of those companies will find product-market fit. At that point the prototype becomes the production system, and nobody planned for it to be one.

The transition nobody schedules

There is no moment where a team decides the throwaway codebase is now permanent. It happens when a customer depends on it, and it is recognised months later.

By then the architecture is whatever accumulated. Not chosen, not reviewed, not documented, and not obviously wrong, because every individual change worked. This is drift arriving without anyone having drifted from anything, because there was never an explicit decision to depart from.

Gartner's framing of the consequence is the enterprise-scale version of the same problem: architectural technical debt is expected to reach 80% of all technical debt by 2027. Startups get there faster because they had less structure to begin with and generated more of the codebase per engineer.

What to do before the prototype becomes production

Not much, and early. The failure mode is a seed-stage team adopting enterprise governance, which is its own kind of waste.

• Write down the handful of decisions that would be expensive to reverse. Not the whole architecture. The three or four choices about persistence, boundaries and integration that a rewrite would be needed to undo.
• Give each one a scope. A decision that names the paths it governs can be checked. One written as prose cannot, and prose is what an agent reads and interprets rather than obeys.
• Enforce mechanically where the rule allows it. A prohibited dependency, a forbidden import direction, a persistence layer that must be routed through. These are cheap to check and cost nothing per change, which is the only property that scales with generated volume.
• Leave everything else alone. Most of a young codebase should stay negotiable. The point is to protect the decisions you would have to pay to unwind, not to constrain the ones you are still exploring.

The question the data actually raises

Not whether startups should generate most of their code with AI. That question is settled by the distribution: they already do, and it is working well enough that only 2% abstain.

The question is what happens to the 40% when the thing they built quickly turns out to matter. Generation is no longer the constraint on how fast a startup can build. Whether anyone can still say why the system looks the way it does is becoming the one that binds.