Vibe coding risks start where developers stop understanding the systems they ship. When vibe coding and AI-generated code replace classic programming skills, the question becomes which knowledge developers still need. Anyone who can neither understand nor assess a system won’t notice when it fails in real-world use. What counts is broad system understanding combined with deep knowledge in several areas.
Key Takeaways
- AI automation will wipe out the middle tier of developers, because only a few experts with deep system understanding and a group of agent orchestrators will still be needed.
- Vibe coding doesn’t solve the underlying problem: if you don’t understand the environment your code runs in, you can’t judge whether it will hold up under real field conditions.
- Intrinsic curiosity, the urge to understand systems from the inside instead of just using them, decides whether someone stays competent in a world shaped by AI.
- A T-shaped profile is no longer enough for senior roles. What’s needed is a Pi-shaped profile with deep expertise in several areas plus a broad overview beyond them.
If You Build Software, You Need to Understand Where It Runs
Writing code isn’t enough when nobody understands the environment it runs in anymore. That is where the biggest vibe coding risks sit: the gap in system understanding that vibe coding and AI-generated software keep widening.
An example from Thomas Ronzon’s practice makes this concrete. A piece of software was rolled out to 120 PCs and ran fine everywhere, except at one site, where the client kept crashing. The cause was an image loaded in a loop. On that one machine, which had a particularly large number of entries, the loop made the system run out of file handles. The colleague responsible didn’t know what file handles were or how the operating system manages them.
The underlying point: if you develop inside a virtual machine, you open and close files without knowing what happens underneath. As long as everything runs smoothly, nobody notices. It only shows when a long-running process hits a condition that never came up in your own test setup.
Vibe Coding Risks Only Show Up in the Field
A bug in generated code often doesn’t surface when the code is written. It surfaces in the environment where the software runs continuously. Memory leaks are the classic example.
If a process restarts every few seconds, a memory leak has no consequences. If the same process runs for hours or days, the system eventually falls over. So the question isn’t just whether the code works when you try it once or write a test for it. The question is whether it keeps running under real field conditions.
Generated code behaves deterministically at first. The real risk is the environment, which changes. Autonomous driving shows the same pattern: in many situations the systems drive better than any human, and then a situation comes along they can’t handle, and there’s a crash.
Vibe Coding Turns the Testing Question Upside Down
If you have code generated for you, you face an assessment problem: how can you judge whether the code will not just run once but hold up in the field?
A test alone doesn’t help when it’s unclear what the code is supposed to do. Thomas Ronzon describes a student who was asked how he knew the AI-generated code was correct. His answer: he would write a test for it. The follow-up question exposed the problem. What do you want to test if you don’t even know what this code does?
Marc Bless takes the idea to its logical end. If software is continuously regenerated, executed and deployed, code is no longer a static component. What remains are the requirements that go into it. Testing moves to the outside.
“If the AIs are good enough to deliver a working system that fully covers the customer’s needs, then my test case is purely systemic, seen from the outside. That’s a system test. The system does the unit tests for itself.”
(Marc Bless)
The Middle Tier of Developers Is Under Pressure
The thesis is blunt: a large share of today’s developer roles will disappear because they won’t be needed anymore. Two groups remain.
On one side are the few who oversee entire systems and understand why things are the way they are. On the other are people who orchestrate coding agents, and only until they, too, are no longer needed.
The low-code debate follows the same pattern. As long as the business department clicks something together and it all works, no developer seems necessary. The moment it breaks, you need people again, and really good ones.
Why Enterprise Organizations Can Fail on Speed
The bigger and more regulated an organization, the harder it finds the change that technology currently demands. That is less a technology problem than a problem of structure and pace.
Fixed regulations are easy to write down and automate. Software that calculates taxes and reacts to changes no longer needs an army of programmers. The problem lies elsewhere.
It gets interesting with anything that can’t be described cleanly, and with probability. AI doesn’t deliver 100 percent. It delivers maybe 99.8 percent. For a bank account, that gap isn’t acceptable, and that’s a valid argument. For many other business cases, it is perfectly acceptable.
Thomas Ronzon gives an example from logistics. An image classifier was supposed to separate perishable from non-perishable material with a hit rate of about 97 percent. The project failed because quality assurance wouldn’t accept that, even though a misclassification would have had no consequences in this case.
On top of that come slow approval processes. If a business unit wants to use a new AI tool this afternoon, but the next board meeting is three and a half months away, you get shadow AI. Things get done without the organization having approved them. Or others overtake you.
Trust in AI Builds Up Like Trust in People
Trusting AI systems works through the same mechanism as trust between people: you start with a certain amount of benefit of the doubt, and trust grows with experience in the relationship.
Nobody blindly trusts everyone who wants something from them. In the same way, you need checks and experience with a system before you hand it tasks. And just as with people, AI will sometimes disappoint you. The difference is that the consequences are a topic of their own.
This exposes a double standard. Thousands of road deaths caused by human drivers are accepted as a given. If an autonomous car hits a tree once after millions of trips, the whole technology is instantly a no-go. That leads to the reverse question: can we afford not to have autonomous cars?
For testing, this means going back to an old insight. Testing isn’t only about finding bugs or demonstrating that requirements are met. It is about building trust in the system. That task becomes important again with vibe-coded systems.
Nobody Understands Every Line, and Nobody Ever Did
The idea that someone has to understand all of the code is an illusion, even without AI. In a project with more than 100,000 lines of code, no single developer understands every line.
This has been happening for a long time; people just don’t notice it. The usual practice is to deal with a problem when it shows up in operation, because that’s when you know something went wrong. The defensive reaction, that you have to understand everything instead of just generating it, is understandable. It may turn out to be a transitional phenomenon, though.
What Young Developers Should Learn Today
The most important advice: find a side project. Even if you vibe-code it yourself, you gain experience that daily business never gives you, and you have fun along the way.
One practical warning comes with it: don’t start with smart home. If something goes wrong there, you have the whole family’s wrath on you and become the administrator of your own household.
Two students show the decisive difference. One built his own keyboard, designed circuit diagrams, sourced controllers and picked up knowledge across all kinds of layers along the way. He was administrator, product owner and quality assurance in one person. The other had no technical hobby and failed the testing question. Intrinsic motivation beats formal knowledge.
From T-Shaped to Pi-Shaped Developers
The old picture of a senior developer was the T-shape: one topic in depth and a broad range across the top. That model is no longer enough.
What’s needed is a Pi-shape: several areas of deep expertise, combined with a broad overview. Going deep in just one field no longer cuts it.
| Model | Depth | Breadth | Fit today |
|---|---|---|---|
| I-shaped | one topic, very deep | hardly any | risky, because only one person can handle a given interface |
| T-shaped | one topic in depth | broad | the former senior ideal |
| Pi-shaped | several topics in depth | broad | what is needed today |
In many organizations, the reality is still I-shaped people. Then three out of seven product teams compete for a single person, because only that person can handle a particular interface. That bottleneck comes back to bite you.
Thinking broadly and deeply at the same time takes the ability to abstract, so you can hold architecture and system understanding in your head. No tool can replace that.
Learning Now Runs Both Ways
Writing off the younger generation as lazy misses the point. They are good, and they are the only generation we have.
The old master and apprentice picture still holds, but with a twist. Today the junior or apprentice regularly finds out something the experienced developer doesn’t know. Depending on the situation, master and apprentice swap roles. Being older doesn’t automatically make you the master.
Respect runs both ways. The amount of tech stack you have to master today far exceeds the old world of a simple one-tier architecture. Back then, BASIC and a floppy disk were enough. Today the barrier to entry is far higher.
What experienced developers need is openness. Not the claim to know everything better, but the willingness to contribute experience on one level and keep learning on others.
Frequently Asked Questions
Why Do Memory Leaks Often Go Unnoticed During Testing?
A memory leak has no consequences as long as the process restarts every few seconds. Only when the same software runs for hours or days does the system crash. Test setups rarely replicate such long runtimes. Generated code behaves deterministically at first; the real risk lies in the environment: it changes and creates conditions that never occurred in the test setup itself.
Why Should Developers Know How the Operating System Manages Resources?
Because otherwise, errors won’t surface until in the field. A piece of software ran without issues on 120 PCs, but at a single location, the client kept crashing. The cause: An image was loaded in a loop, which made the system run out of file handles there. The developer responsible didn’t know what file handles were. Those who develop in a virtual machine don’t see such limitations.
How can you test code you didn’t write yourself?
A test is only helpful if it’s clear what the code is supposed to do. When asked about the correctness of AI-generated code, one student replied that he was writing a test for it but couldn’t say what the code actually did. When software is constantly being regenerated and deployed, testing shifts to the outside: what remains is system testing against the requirements; the system handles unit tests on its own.
Which developer roles are particularly at risk from AI automation?
The middle class is under pressure. Two groups remain: the few who oversee entire systems and understand why things are the way they are, and those who orchestrate coding agents, but only until that role, too, becomes obsolete. The same pattern applies to the low-code debate: As long as everything is running smoothly, no developers seem necessary; but at the first sign of trouble, very good ones are needed.
Why do AI projects in large companies often fail, even when the technology is not the problem?
Most often, quality standards and approval processes are the stumbling blocks. An image classification system in logistics was designed to separate perishable from non-perishable goods with about a 97 percent accuracy rate. The project failed due to quality assurance, even though a misclassification would have had no consequences. On top of that: If a business unit wants to get started right away, but the next board meeting isn’t for another three and a half months, “shadow AI” emerges.
Is a 99.8 percent accuracy rate sufficient for production use?
That depends on the use case. For a bank account, the remaining margin of error is unacceptable, and that argument is valid. For many other business cases, however, it is perfectly acceptable, especially where a wrong decision has no consequences. Clearly definable rules, such as tax calculations, can be automated anyway; the difficulty arises with anything that cannot be clearly defined.
How is trust in an AI system built?
Through the same mechanism as trust between people: by giving the system the benefit of the doubt, through verification mechanisms, and through experience in interacting with the system. Disappointments are part of the process, though their implications are a topic unto themselves. This ties testing back to a long-standing insight: it serves not only to find errors or validate requirements, but also to build trust in the system.
Why are highly specialized individual experts a risk for a team?
I-shaped profiles create bottlenecks. If only one person can handle a specific interface, three out of seven product teams will quickly compete for that person. For senior roles, therefore, even the T-shape (in-depth expertise in one area plus a broad overview) is no longer sufficient. What’s needed is a Pi-shape with multiple deep areas of expertise, underpinned by the ability to think abstractly about architecture and a deep understanding of the system.
