The explosion and democratization of software in the age of AI

Picture an operations manager who opens Lovable on a Friday evening to replace the three Excel files and the dozen weekly emails her team uses to track supplier returns. By Monday morning, the team is already using the new application, without the IT department having been consulted and without anyone really knowing where the data is stored.

This kind of scene is no longer fiction, and it is very good news, because vibe coding is doing for software what the spreadsheet did for calculation: putting it in everyone's hands.

But shipping a first version of an application is not the same as building software, and that difference is what this article explores.

Software is changing scale: one month of 2026 outweighs all of 2025

Just two years ago, code was a scarce resource: getting even the smallest tool required developers, time, a budget and a slot on the roadmap.

Today, a single month of commits on GitHub exceeds the whole of 2025, and this acceleration shows no sign of slowing down.

Source: Kyle Daigle, COO of GitHub, April 2026. Only April is measured; the other months are projected at the same pace.

It started out as vibe coding, when people described what they wanted to an AI and simply checked whether the result worked, then came vibe engineering and agent-assisted engineering, terms for a more professional and rigorous practice.

The vocabulary changes every six months, but what is happening day to day looks above all like industrialization: like many other industries before it, software is moving from craft to large-scale production.

One figure should still give us pause. Developers using these tools write about 25 times more lines of code, yet ship only 1.3 times more releases, which clearly shows that writing code is no longer the bottleneck.

Source: NBER Working Paper 35275, Demirer, Musolff and Yang, September 2026 revision.

More software means less Excel and fewer errors

This shift is first and foremost an opportunity. In most companies, a huge share of the work still runs on shared spreadsheets, email threads and copy-paste, not by choice but because building a real tool cost far too much to serve the needs of a team of ten.

When the cost of software collapses, these needs finally become worth equipping, and even a very simple application brings what an Excel file never will:

• business rules written down in black and white, rather than kept in one person's head;
• a record of who did what;
• data you can cross-reference without retyping it.

The end result is fewer errors, less wasted time, and team knowledge that no longer walks out the door when someone leaves.

The United Kingdom learned this the hard way in 2020, when nearly 16,000 positive Covid cases were not reported in time because an Excel file had hit its maximum size, and every company has its own, more modest version of this kind of incident.

The sweet spot: high business complexity, low technical complexity

Not every application benefits from vibe coding in the same way. The ones that gain the most are business applications, which combine high business complexity with low technical complexity. In practice, that means:

• entering data through forms;
• transforming it with business rules;
• displaying it again in dashboards;
• sending emails and running scheduled tasks;
• importing and exporting Excel files.

None of this is technically hard. The real difficulty lies in understanding the business, writing the right rules, anticipating edge cases and checking that everything works correctly, and that is exactly where coding agents and the latest reasoning models have become genuinely capable.

Within this scope, what we see in the field is software that is 5 to 10 times cheaper and 5 to 6 times faster to build than with a traditional development team. It is obviously not a universal law, but for this type of application the gap is very real.

The trap: the illusion of mastery

There is a trap, though, and it goes well beyond code. When you use an LLM, you very quickly get the feeling of becoming an expert in whatever subject you are tackling: you ask it a legal question, it answers with great confidence, and you feel you have understood.

Except that the model often makes small mistakes you are unable to spot, quite simply because you don't know what you don't know.

In software, this trap takes a very concrete form. Someone who has never written code opens Claude Code or Lovable, describes what they need and, in an afternoon, gets a polished, working application, so they feel they have built software they can deploy, without always knowing what deploying actually means.

More worrying still, the tool tends to reinforce the problem it creates, since the more you delegate to AI, the less you build the skills needed to check what you delegated.

The real cost comes after the first version

What you see of an application is its interface, while what really matters in the long run sits behind it: the back end and, above all, the database. A screen can be rebuilt in an hour, but a poorly designed data model drags on for years and ends up dictating what can and cannot evolve.

The real cost of software is not in its first version but in everything that follows: evolving it with the needs of the business, fixing bugs and applying security updates. According to the research, this accounts for 60 to 80% of its total cost over its lifetime.

Every development team knows this cycle well: when a new service needs to be built, everyone is excited to start again on clean, healthy foundations, then one, two or three years later that service has become legacy like all the others, technical debt has piled up and the team's velocity has dropped sharply.

It is fairly hard to explain to someone who does not work in tech, but shipping the first version of a piece of software, which is often little more than a prototype, is the easy part. The real challenge is keeping that prototype alive over time, so that it keeps working, stays up to date on security and follows the evolving needs of the business.

Tools cover the code, much less the operations

Stepping back a little, the lifecycle of software breaks down into six main phases:

1. Scoping the business need and the product
2. Design of the user experience
3. Development, meaning the code and the tests
4. QA and user acceptance testing
5. Deployment
6. Operations, when you gather user feedback, fix bugs and update dependencies

The tools developers use, such as Claude Code or Codex, are excellent, but they remain specialized and highly technical, and at best cover scoping, design and code. App builders such as Lovable or Replit go a little further by handling deployment, but they remain fairly weak on code, QA and operations. A third category, AI software factories such as Maleus, aims to cover all six phases, operations included.

The result is a paradox: most of the tooling has concentrated on the phases that were already the cheapest, leaving aside operations, the most expensive one.

According to Bain, writing and testing code accounts for only 25 to 35% of the time from idea to launch, which largely explains why we write 25 times more code without shipping 25 times more software.

Quality comes down to maintainability and security

That leaves the question of the quality of generated code, which plays out on two levels.

Maintainability: avoiding regressions

Maintainability means a solid architecture and, above all, test plans thorough enough to prevent regressions. Regressions are truly the worst thing when iterating on a product, since every new feature risks breaking an old one and you end up spending more time repairing than moving forward.

Security: what a first version forgets

On the security side, a business application must at the very least:

• authenticate its users correctly;
• enforce a reliable permission system;
• isolate data between users and between customers;
• withstand denial-of-service attacks.

In early November, a study of more than 159,000 Lovable projects found personal data readable without logging in on 7,403 sites, most often because of a misconfigured database.

Excel file import, the most mundane feature of any business application, is another good example: the libraries in the Node.js ecosystem that read these files are vulnerable to denial of service, and a single booby-trapped file is enough to bring the server down.

At Maleus, we ended up wrapping existing Rust libraries to protect ourselves, in an open-source package: @maleus/xlsx, which reads untrusted files within bounded memory, without blocking the server. A beginner, however, has no reason to know about this problem, and the AI will probably not flag it.

The current context makes this question even more pressing, since LLMs are not only used to write code but also to find vulnerabilities:

Sources: Google Threat Intelligence Group, BleepingComputer.

Security must therefore be designed in from the start, following the secure by design principle, then kept up to date continuously.

Equip, but across the whole lifecycle

Should companies ban, regulate or equip vibe coding? Banning will not work, because business teams have had a taste of this autonomy and will not give it up, but letting it happen would mean silently piling up dozens of applications that nobody will be able to maintain two years from now.

The right answer is therefore to equip, provided tools are judged on the entire software lifecycle rather than on the quality of their demo.

The question to ask is not so much whether a tool generates a good-looking application, but who will run it, fix it and secure it two years from now.

It is now the second version of a piece of software, far more than the first, that represents the real challenge.

---

Cover photo: Francesco Ungaro on Unsplash.