Future Horizons

The Democratisation of Software: When Anyone Can Build an App

Vibe coding put a working prototype within reach of anyone who can describe one, and the market paid $60 billion for Cursor to prove it. The evidence on speed, security and maintenance says the hard 30 percent has not moved.

Gabriele Masetti · 2026-09-02

A new word for an old ambition

In February 2025, Andrej Karpathy, a co-founder of OpenAI and former head of AI at Tesla, posted a short description of how he had started building software: "There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists." He added that he barely reads the diffs anymore, that when an error comes back he pastes it into the model without understanding it, and that the code works "way more often than not."

The phrase spread quickly because it named something real: a growing population of people, including experienced engineers, who were building working software by describing intent in natural language and letting a model handle implementation.

The democratization thesis that follows from this is straightforward and, on the evidence, partly true: the cost of turning an idea into a working piece of software has fallen further and faster in the last three years than at any point since the arrival of spreadsheets and drag-and-drop website builders. But "partly true" is doing real work in that sentence. The same body of evidence that shows barriers falling also shows, in unusually rigorous detail, where the barrier has not fallen at all — it has just moved to a part of the job most new builders don't yet know exists.

The tools, and the numbers behind the hype

The infrastructure for this shift is no longer speculative; it has revenue and users attached to it. GitHub Copilot, the first mainstream AI coding assistant, had reached roughly 20 million users by mid-2025, with more than 4.7 million paying subscribers and adoption across the large majority of Fortune 100 companies. GitHub's own data puts the average share of code accepted from Copilot suggestions at around 46 percent of a user's committed code, higher still in some languages.

Cursor, the AI-native code editor built around models like Claude, is the starker growth story: it crossed $100 million in annualized revenue in January 2025, passed $500 million by June, and reported more than $1 billion by November 2025 — reportedly the fastest run to nine and ten figures of recurring revenue any software company has posted. It kept going. By May 2026 the trackers put Cursor between $3 billion and $4 billion in annualized revenue, disagreeing on the exact figure, with a company forecast above $6 billion by the end of that year.

Then it stopped being a startup. SpaceX signed a definitive agreement on 16 June 2026 to buy Anysphere, the company behind Cursor, for $60 billion in stock; the deal closed on 14 August 2026, and Cursor now runs as a wholly owned SpaceX subsidiary folded into the SpaceXAI team. A code editor three years old became one of the largest acquisitions of a venture-backed company on record, which is itself a statement about how much money believes the democratization thesis.

A second, distinct tier of products goes further than assisting a programmer — it aims to remove the programmer from the loop for a large class of simple applications. Replit's Agent, Lovable, Bolt.new, and Vercel's v0 all let someone describe an app in a chat window and receive a deployed, functioning product, complete with a database, authentication, and hosting, often within minutes.

Lovable, widely reported to have reached $100 million in annualized revenue faster than almost any software company in history, hit $500 million in June 2026 and confirmed a $400 million Series C at a $13.3 billion valuation on 12 August 2026, led by Menlo Ventures and the Scaleup Europe Fund. The analyst firm Sacra estimates Replit at $525 million in annualized revenue in April 2026, up from about $300 million at the end of 2025, with more than 50 million users. Bolt reportedly reached $40 million in annualized revenue within about five months of launch. Whatever the precise figures settle at as these young, fast-moving companies mature, the direction is unambiguous: a market has formed around the promise that building an app no longer requires knowing how to code.

All of it sits inside a longer-running trend that predates generative AI. Gartner has tracked the low-code and no-code platform market for years and has forecast that a majority of new enterprise applications will be built using low-code tools, with the population of "citizen developers" — employees building software without a formal engineering role — projected to keep growing faster than the population of professional developers. Generative AI has not created this trend; it has accelerated it by replacing rigid drag-and-drop interfaces with something closer to conversation.

What the productivity evidence actually says

The more interesting and more honest story is in the studies that measured what these tools do to real work, rather than what vendors say they do.

The foundational result is a 2023 controlled study, run with Microsoft and GitHub researchers, in which 95 professional developers were asked to implement an HTTP server in JavaScript. Developers with access to Copilot finished the task 55.8 percent faster on average — 1 hour 11 minutes versus 2 hours 41 minutes — a large, statistically significant effect. That study, more than any marketing claim, is the empirical anchor for the idea that AI assistance meaningfully speeds up software creation, at least for well-scoped, greenfield tasks performed by people who already know how to program.

A very different study complicates the picture considerably. METR, an AI evaluations research group, ran a randomized controlled trial between February and June 2025 with experienced open-source developers working in large, mature codebases — repositories averaging roughly a million lines of code, the kind of environment most real software actually lives in. The developers, using Cursor with Claude 3.5 Sonnet, predicted the tools would make them about 24 percent faster.

They were instead measured to be roughly 19 percent slower, a result the researchers attributed to the extra cognitive load of reviewing, correcting, and context-switching around AI-generated suggestions in unfamiliar or complex code. The gap between how fast developers believed they were working and how fast they actually were is arguably the single most important data point in this entire debate: it shows that the subjective sense of acceleration and the objective reality of it can point in opposite directions, and that the effect depends heavily on whether the codebase is small and new or large and established. The obvious objection is the date. Claude 3.5 Sonnet was a 2025 model and several generations old by 2026, and whether a current model reverses the sign of the result is an open question.

Stack Overflow's own developer survey found a matching sentiment story, and it has sharpened since. The share of developers using or planning to use AI tools rose from 76 percent in 2024 to 84 percent in the 2025 survey, with 51 percent of professional developers using them every day. Over the same period favorable sentiment fell from more than 70 percent in 2023 and 2024 to 60 percent, and 46 percent of respondents said they distrust the accuracy of what the tools produce, against 3 percent who highly trust it. Usage is rising while confidence is falling — a pattern usually associated with a tool that people feel obligated to use rather than one they are certain is making them better.

The 70 percent problem

No one has stated the practical limit of these tools more precisely than Addy Osmani, who works on developer experience at Google, in an essay published in December 2024. His observation, drawn from watching AI adoption inside a large engineering organization, is that AI models can now produce roughly 70 percent of a solution extremely quickly — the boilerplate, the obvious logic, the first draft of a feature.

The remaining 30 percent is disproportionately the hard part: edge cases, integration with existing production systems, and making sure security and API credentials are handled correctly. That last 30 percent, he argued, takes just as long as it always did, because it was never really about typing speed.

The result, in his account, is engineers who report feeling dramatically more productive while the software people actually use does not obviously get better at the same rate — productivity gains that are real at the level of an individual coding session and much less visible at the level of shipped, maintained products.

That is the mechanism by which "anyone can build an app" and "software quality is not obviously improving" turn out to be compatible facts rather than a contradiction. A tool that reliably produces the easy 70 percent for free is exactly the tool that will feel like democratization to a first-time builder — because the 70 percent was always the visible, satisfying part of writing software — while remaining largely irrelevant to the 30 percent that determines whether the resulting product is safe, correct, and durable.

Security and the bill that comes due later

That 30 percent is not evenly hard across every domain, but security is one of the areas where the evidence is now specific and unflattering. Veracode's 2025 GenAI Code Security Report, which tested code produced across more than 100 large language models on a standardized set of 80 coding tasks, found that 45 percent of the resulting code samples introduced at least one vulnerability from the OWASP Top 10 list — the industry's standard catalogue of the most common and dangerous web application flaws, including SQL injection and broken access control. That failure rate did not meaningfully improve across newer model releases tested through the report's later cycles, despite vendor claims of steady improvement.

The finding is not new so much as confirmed. A 2023 Stanford study, published at the ACM Conference on Computer and Communications Security, gave participants access to an AI coding assistant built on OpenAI's Codex model and asked them to complete a set of security-relevant programming tasks.

Participants with the AI assistant wrote measurably less secure code than a control group working without it — and, in the study's most striking result, those same participants were more confident that their code was secure than the developers who had no AI help at all.

The direction of that miscalibration is the entire risk in one sentence: the tool that makes people faster is the same tool that makes them more certain, and those two effects compound badly when the person at the keyboard is a first-time builder with no security background rather than a professional reviewing generated code against a specification they already understand.

Who owns the code afterward

The part of this shift that receives the least attention is what happens to an application after it ships. A citizen developer using Lovable or Bolt to build an internal tool, or a professional shipping a feature with a coding agent's help, inherits a codebase they may not have fully read, containing patterns they did not choose, running dependencies they did not select.

Traditional software engineering built decades of practice — code review, style conventions, documented architecture, ownership norms — precisely to make a codebase legible to someone other than its original author. Vibe-coded software, almost by definition, skips that legibility step at creation, on the promise that the model can regenerate or patch the same way it generated originally.

That promise holds up reasonably well for small, disposable, single-purpose apps: an internal dashboard, a prototype, a weekend project with no real users. It holds up far less well as scale, users, and business dependence on the software increase, because bugs, security patches, and new feature requests eventually require someone to understand why the code does what it does — not just what it does.

Gartner's own long-running forecasts about low-code adoption already anticipate this tension by projecting that a growing share of mission-critical applications, not just disposable internal tools, will run on these lower-code foundations over the coming years. Mission-critical is precisely the category where the cost of an unreadable, unreviewed, or insecure codebase stops being hypothetical.

The honest version of the thesis

The democratization of software is real, but it is a democratization of a specific stage: the distance between having an idea and seeing a working prototype has collapsed, verifiably, for a huge range of simple applications, and the revenue of Cursor, Replit, Lovable, Bolt, and v0 — capped by a $60 billion exit for Cursor in August 2026 — is the market's clearest evidence that the collapse has commercial weight behind it.

What has not collapsed, and what the METR trial, the Veracode report, the Stanford study, and Osmani's own essay all point to independently, is the distance between a working prototype and a piece of software that is secure, maintainable, and trustworthy at scale. That distance is still measured in engineering judgment, not tokens, and no model has yet closed it.

The realistic outcome is not a world where professional software engineering disappears, but one where the profession's center of gravity shifts further toward reading, verifying, and securing code that a growing number of non-engineers can now produce on their own — a division of labor the industry has not yet built the norms, tools, or job titles for.