99% of It Dies on Localhost

A few days ago, Christian Klein, CEO of SAP, one of the largest software companies on the planet, jumped on the trend where CEOs announce that certain professions will soon be nothing but a memory.

In that interview he said there's a possibility that in three or four years nobody will be developing software inside SAP. Nobody. The function most impacted by AI, he said, is software development.

Well, we've known that for a while. Vibe coding — generating code from inspiration and plain-language instructions without knowing how to program — changed the rules. Supposedly. And according to him, what's coming is product managers who vibecode and understand the business, more data scientists, fewer developers.

If you're an ABAPer, or DevOps, or anything ending in "developer," that sentence probably lands right in the middle of your chest. And it comes from the CEO of the company where many of us built our careers.

Before you run off to update your CV or sign up for a data science course, I want to put the other data point on the table. The one Klein doesn't mention in the interview, and that completely changes how you should read his prediction.

99% dies on localhost

There's a phrase circulating among people who actually build software, not among keynote speakers:

Vibe coding has a 99% mortality rate.

The vast majority of applications generated with AI never leave localhost. They never reach a real user. They work on the machine of the person who made them, they get a screenshot, they collect a few likes in the feed, and nobody ever opens them again.

Someone named it: the screenshot economy.

Since 2024 more apps are being built than ever, but fewer and fewer are actually used. Vibe coding made "it compiles and runs" free, so the feed fills up with things that work on localhost, earn a screenshot, and die there.

Two clarifications worth making. Localhost is the address of your own machine, where a server runs and you test an app before anyone else sees it. And "it compiles and runs" was always a small victory for anyone who has seriously programmed. The difference is that from now on nobody will suffer over an extra semicolon or a syntax error that won't let you start anything.

And back to the point, the most honest part of the diagnosis is this: nobody is lying. People simply confuse the easy 20% with the complete job, and post the proof of the 20%.

The same thing happens inside companies, but with a budget. The pilot that dazzles the steering committee is a localhost app with a logo slapped on top. Flawless demo, zero users, zero revenue. Hundreds of hours wasted in useless meetings that nobody counts.

Here's the point that connects everything. Yes, we know building software has never been easier, and that many product managers now believe in a version of the infinite monkey theorem: the idea that a thousand monkeys typing at random (or fewer, thanks to layoffs) will eventually produce a work of Shakespeare.

But it's not easier to build something worth using. The hard part is still exactly the same as always: understanding a real need, building a solution someone wants to use, earning trust over time, and finding a way to reach the right people.

Building is "easy" now. I put it in quotes because it has also become expensive since the big AI companies started un-subsidizing their pricing: there are already companies like Uber that burned their annual budget in four months of this party. But when everyone can build, building was never the advantage. Distribution, trust, the solid architecture behind that app, and someone willing to pay for it twice or more — that was always the scarce part.

So is Klein right or not?

Both, and that's what makes it interesting.

He's right that writing code, the mechanical part of translating an idea into syntax, is being automated fast. That's real and there's no going back. Anyone who makes a living hammering out ABAP piecework without understanding the business behind it is in trouble. Klein isn't wrong there. And on top of that, with the Clean Core policy, people are increasingly boxed in when it comes to getting creative: many customers no longer want to reinvent the wheel. What I'm not clear on is how everyone is going to differentiate themselves doing the same thing, but that's a topic for another day.

Now, where I think Klein makes a language play is here: he confuses, or chooses to confuse, writing code with developing software. At his level I don't think he's confused about anything. It's a message he wants to send. But they are two different things. Writing code is the easy 20% that vibe coding already solves. Developing software is understanding what needs to be built, why, for whom, deciding what NOT to build, keeping the system coherent as it grows, and keeping it alive in production when something breaks at three in the morning. That's judgment, and the 99% death rate proves the machine alone doesn't have it yet. I know we're about to go live at any moment with the "Autonomous Enterprise," but the industry isn't as mature as the PowerPoints argue.

When Klein says "there will be no developers," what he's really describing is the end of one type of developer: the one who only typed. Not the end of the one who understands the system. That one becomes more valuable, not less, precisely because there's now an ocean of generated code that someone has to know how to read, prune and sustain. And even more so when others are vibecoding without judgment and feel empowered to ship anything to production at midnight.

The five roles that are coming

Boris Cherny, from Anthropic, one of the people who built Claude Code, published an observation the day before yesterday that gives this shape. He says that as traditional roles (engineer, product manager, designer) merge into something new, what he sees in his team are five archetypes no longer tied to the title in your job description:

• The Prototyper, who throws out new ideas at high volume, most of which go nowhere.
• The Builder, who turns a prototype into a real product.
• The Sweeper, who cleans up, simplifies the code and the system, dismantles what's redundant, optimizes.
• The Grower, who takes something that already works and iterates it to fit the market better.
• The Maintainer, who takes ownership of a mature system so it's secure, reliable and fast at scale.

The interesting part isn't the list. It's that almost everyone who uses AI to work operates in two or three of those roles at once, and that the role you need changes depending on the product stage.

Now cross that with the vibe coding death rate. AI is brutal at the first archetype, the Prototyper. It churns out prototypes at infinite speed. That's why the feed fills up with localhost demos. But the 99% death rate happens exactly at the jump from Prototyper to everything else. Cleaning up, simplifying, deciding what to dismantle, making something mature and hold up in production: that's where human agency remains irreplaceable. Vibe coding produces an army of orphaned prototypes nobody knows how to turn into a product.

The professional who becomes irreplaceable in this world isn't the one who prototypes fastest. The machine always wins that. And people will eventually realize that the slides with new ideas from every townhall die right there. The irreplaceable one is the Sweeper and the Maintainer with judgment: the one who knows what, out of that ocean of generated code, deserves to live, what needs pruning, and how to sustain what's left.

The real underlying problem is whether today's organizations have the maturity to build high-performance teams around these roles, gradually letting go of the old schools that shaped the business, without neglecting it and evolving at the pace the industry imposes.

What I'd do with this if I were starting today

I'm not going to tell you to ignore Klein. He's right about the uncomfortable part: whoever only types is in trouble. But the conclusion isn't "learn to vibecode and boom, you're a product manager," because that turns you into one more person filling the feed with dead demos, and GitHub with clones and "projects" that are the product of a couple of midnight prompts.

The move is the inverse. Let AI do the easy 20%, the prototype, and put your energy into the 80% it can't: understanding the real business problem, deciding what deserves to be built and what doesn't, and developing the muscle to prune and maintain systems instead of just generating them. In a world where building demos is relatively free, whoever knows what's worth building, and what to dismantle, is the one in charge. Well, sometimes the one in charge is someone else and not the one who knows most, but you get the idea.

Klein says SAP will need product managers who understand the business and vibecode. Read it again: the scarce thing there isn't the vibecoding, anyone will do that. You're not a hero for talking to Claude Code for a while, even if it gives you that feeling. The scarce thing is understanding the business. The judgment about what to build. That part of the sentence is what matters, and it's the part nobody repeats because it doesn't scare you as much as the headline.

Building stopped being the bottleneck. It stopped being the bottleneck for every technology area, not just the SAP world, for you, and for the thousands who publish a screenshot of their localhost app and collect likes. The only question worth asking about any AI project today is the same one as always: did you build something people need, or something you could ship in a weekend?

Whoever understands the difference isn't afraid of Klein's sentence. Klein's sentence is about the person who only types. The one who thinks is still the one who orchestrates, and becomes more and more immovable in this increasingly artificial world.

Pablo / En Producción

P.S. If this was useful, send it to the ABAPer who panicked at the SAP CEO's headline. Tell them to read to the end.

---

References:

• Smith, Paul. "SAP chief predicts AI will replace its human coders within four years." Australian Financial Review, June 21, 2026. Interview with Christian Klein.
• Cherny, Boris (@bcherny). Reflection on the five role archetypes (Prototyper, Builder, Sweeper, Grower, Maintainer) in product and AI teams. X, June 2026.
• The "localhost economy" / "screenshot economy" concept and the vibe coding mortality rate. Discussion circulating in the development community, June 2026.