When Code Becomes a Commodity: The Rise of AI Native Companies

Back in 2003, I was doing an "architect" training and was taught that one of the main challenges I'd face in my career—aside from naming things and cache invalidation—would be answering the Build or Buy question.

And indeed, we constantly had to find the right balance between building software or buying it off the shelf. Open source existed, of course—I could mention MySQL or Apache—but there wasn't nearly as much complete open source software as there is today.

Over time, the rise of open source changed the game.

Today, for instance, I can run an application on a self-hosted open source PaaS (Coolify), use Metabase for data analysis, OpenPanel for web analytics, Listmonk for newsletters, and so on. I can choose to host and run many software solutions that were previously only available as proprietary products.

So it wasn't just Build or Buy anymore, but Build, Buy, or Run. Running your own software brings its own set of constraints and trade-offs.

But since last year, we're witnessing another shift, and the problem has become Build, Buy, Run, or Vibe (BBRV).

(Vibe refers to vibe coding, though today we're moving beyond simple vibe coding toward a true industrialization of AI usage.)

The Illusion of Code Quantity as a MOAT

A moat is a durable defensive advantage. When building software, we often try to create a moat—a competitive advantage. For a long time, that moat could simply be that rebuilding a piece of software would take too long, even if it wasn't critical to the business.

Take feature flag management software (Unleash or LaunchDarkly), for example. It's not inherently complex, but it's rarely core to a company's business. So in the classic Build or Buy dilemma, Buy was often the preferred choice. What would be the value of rebuilding it?

But now, many "simple" software products can be reproduced with AI-powered coding assistants.

Put differently, I now have to weigh taking an off-the-shelf product that might cost me €100 to €1,000 per month against having an engineer spend a day reproducing only the features I need—plus the cost of running it myself.

This is a massive challenge that every software creator, especially SaaS builders, needs to account for.

The ability to produce code is no longer a competitive advantage.

If code becomes a commodity, does that mean all SaaS products are doomed? Obviously not, but let me illustrate this point.

I recently came across two initiatives to recreate LinkedIn, both built with AI:

• https://nolto.social/ — very promising, based on ActivityPub, self-hostable, open source, and started with Lovable.dev (an AI coding assistant)
• https://ponos-job.eu/ — simpler, also open source, also built with AI

Both products look solid and demonstrate that one or two people can now build very complete software.

To borrow an analogy I've seen several times online: if software production used to be like slowly and meticulously laying bricks one by one, today we can code entire walls at once. What limits a developer is their domain knowledge. But the more well-known and documented a piece of software is, the easier it is to reverse-engineer that knowledge when you have a good head on your shoulders and functional domain expertise.

But here, the barrier to replacing LinkedIn isn't the code itself.

With AI, we've shifted from a scarcity economy of production (coding was hard and expensive) to a scarcity economy of trust and distribution. LinkedIn will keep that advantage over these two initiatives—for now.

And there are other barriers that remain effective:

• Exclusive access to specific data (e.g., Palantir).
• Network effects: LinkedIn, WhatsApp, or X only have value because everyone else is there.
• Regulatory certifications: Accreditations that grant access to protected markets (Banking, GovTech, Defense).
• Ecosystem lock-in: Deep integration into existing workflows (Jira, Salesforce, Okta).
• Captive data: When your data is "held hostage" by a system's complexity, making switching costs prohibitive.
• Service guarantees: Some companies pay for a "throat to choke"—they don't want to be responsible for the "Run."
• Physical infrastructure: Cloudflare or AWS own datacenters. Hardware cannot be replicated by an LLM.

Several of these items are also directly tied to distribution capabilities. For example, I can create a Slack or Teams clone, but I don't have the distribution power (sales force and ecosystem integration) of Microsoft or Salesforce to spread it everywhere.

Those who have the data (whether they buy it or accumulate it) keep the advantage because they can also solve more use cases. And it's no surprise that access to this data is protected. Conversely, those who only manipulate and display data are in danger.

Beyond this, I believe we're witnessing a new generation of companies: AI Natives.

From Cloud Natives to AI Natives

I experienced the Cloud Native era when I founded Malt in 2012.

It meant we owned nothing—no servers, no offices. Everything was decentralized and distributed. It was a purely online company. Every building block of the business was an off-the-shelf SaaS.

With this extreme dematerialization, Cloud Native companies became liquid—easy to modify and evolve. Resource management became a rental model. I rented a service and could switch "easily" (modulo integration costs, of course) without having to manage internal teams, server reallocations, etc.

IT became a kind of giant Lego set.

And for someone who had experienced non-Cloud Native companies—who had gone to the server room to code directly on a failing machine, or suffered through air conditioning failures that brought down the entire infrastructure—the difference is striking. I went from an era where requesting a CI server could literally take three months, with endless network access forms, to a single click on an interface.

Being Cloud Native also naturally became a simple way to embrace modern security concepts, like Zero Trust architecture, which is by definition unavoidable in this context. You can't trust the network because your internal network is the Internet.

This became an advantage during the COVID crisis. I didn't experience, like some companies, having to rotate login times in the morning because the internal network and corporate VPN weren't sized for so much external access. I didn't have to go back to the office to pick up mail or revalidate my PC on the internal network.

And I can tell you I've seen people join the company from traditional businesses who never managed to understand this culture—always questioning the number of services we used, unable to grasp the true nature of what we were.

I know it's still hard, even today, to make people realize that the Cloud was literally one of the major drivers of tech in the 2010s. Many see the cloud as a simple marketing gimmick—just moving your servers to someone else's premises, basic outsourcing. In 2026, there are still many companies that aren't Cloud Native. And that's normal. You don't switch from one world to another overnight, if it's even possible.

When I say it was a driver, you have to understand that it created flexibility and therefore speed—speed that was decisive for all post-2008 companies (in France: Blablacar, Doctolib, Malt, Back Market, etc.). This technological shift also created many opportunities to rebuild existing services, but as online building blocks (the famous SaaS products).

But today we're seeing AI Native companies emerge. Companies for which code production has become a commodity. Production capacity has dramatically increased.

If Cloud Native "simplified" infrastructure, AI is "simplifying" implementation.

(*And yes, I know "simplify" is probably the wrong word because running things in the cloud or producing quality code with AI isn't that simple.)

• 2010: We killed infrastructure complexity (hardware).
• 2024+: We're killing implementation complexity (software).

Consequence: The "AI Native" developer becomes an architect of intent rather than a code craftsman.

The Culture Shock

Just like with the Cloud, AI will create many opportunities. I'm willing to bet we'll see more and more initiatives (like the LinkedIn ones mentioned above) where existing software gets completely recreated by companies with 10x or even 100x fewer people—not to mention the many open source projects that will emerge to replace "commodity" software, like the feature flag management I mentioned earlier.

So that's the first shock. Expect to see many fast-moving competitors emerge in the coming years against well-established software.

But there's a corollary to this, because just as in 2026 we still have many companies that aren't Cloud Native and never will be, many companies won't become AI Native without friction.

Yes, some software will maintain its lead, but an AI Native company will be able to compete on price (with lower production costs) or make higher margins, meaning more investment.

As I said earlier, I can't see many "non-AI Native" companies becoming AI Native, because the social impacts within the company would be massive. It's a question of culture—culture being how you systematically respond to a given problem. An AI Native company isn't trying to reduce costs by 20%; it's trying to operate with a fundamentally different cost structure (10x or 100x fewer staff for the same output).

In short, it's not "just" AI companies that will represent the new generation of post-2020 startups, but probably also a whole bunch of very lean small businesses with few people that will hit many well-established businesses head-on.

And if there's one profile that should come out on top, it's the Product Engineer: the person who can understand the problems to solve and put themselves in the user's shoes.

And you, in your current roadmaps, what portion of your software has already become a "commodity" that AI could rebuild in a weekend? What's the real moat you'll have left tomorrow?