“Developer Skills in the AI Era” explores the question of what knowledge software developers still need when vibe coding and AI-generated code replace traditional programming skills. Those who neither understand nor evaluate systems cannot recognize when they fail in real-world use. What’s needed is a broad understanding of systems combined with deep knowledge in multiple areas.
Key Takeaways
- The middle tier of developers will be phased out by AI automation because only a few experts with a deep understanding of the system and agent orchestrators will be needed.
- Vibe coding does not solve the fundamental problem: Anyone who doesn’t understand the environment in which code runs cannot judge whether it will actually work under real-world conditions.
- Intrinsic curiosity—that is, the need to understand systems from the inside rather than just using them—determines whether someone will remain competent even in an AI-driven world.
- A T-shaped profile is no longer sufficient for senior roles; what’s needed is a Pi-shaped profile with at least two areas of deep expertise and a broad overview beyond them.
Anyone who builds software must understand where it runs
Writing code isn’t enough if no one understands the environment in which it runs. This is precisely where the gap—which is widening due to vibe coding and AI-generated software—becomes apparent.
A real-world example from Thomas Ronzon illustrates this clearly: A piece of software was deployed to 120 PCs; it ran everywhere except at a single location, where the client kept crashing. The cause was an image that was loaded in a loop; on that one computer, which had an unusually large number of entries, this caused the file handles to expire. The colleague responsible didn’t know what file handles are or how the operating system handles them.
The point here is this: Anyone developing in a virtual machine opens and closes files without knowing what’s happening behind the scenes. As long as everything runs smoothly, this goes unnoticed. It only becomes apparent when a long-running process encounters a condition that never occurred in the developer’s own test setup.
Why Memory Leaks Only Become a Problem in the Field
A bug in the generated code often isn’t visible while writing it, but only in the environment where the software runs continuously. Memory leaks are the classic example.
If a process is restarted every few seconds, a memory leak has no consequences. If the same process runs for hours or days, the system will eventually crash. So the question isn’t just whether code works when you try it out once or write a test for it. The question is whether it will continue to run under real-world conditions.
Generated code behaves deterministically at first. The real risk lies in the environment, which changes. The same pattern is evident in autonomous driving: The systems perform better than any human in many situations, and then a situation arises that they can’t handle, and it all goes wrong.
Vibe-Coding Turns the Testing Question on Its Head
Anyone who uses code generation faces an evaluation problem: How can you assess whether the code will not only run once but also hold up in the field?
A test alone isn’t enough if it’s unclear what the code is actually supposed to do. Thomas Ronzon describes a student who, when asked how he knew AI-generated code was correct, replied that 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 concept to its logical conclusion. If software is continuously regenerated, executed, and deployed, code is no longer a static component. What remains are the requirements that go into it. The test thus shifts to the outside.
If the AIs are good enough to deliver a functioning system that fully meets the customer’s needs, then my test case is viewed entirely from a systemic, external perspective. That’s system testing. The system performs its own unit tests. — Marc Bless
The Middle Tier of Developers Is Under Pressure
The thesis is bold: A large portion of today’s developer roles will disappear because they are no longer needed. Two groups will remain.
On one side are the few who oversee entire systems and understand why things are the way they are. On the other hand, there are people who orchestrate coding agents—and even that will only last until they, too, are no longer needed.
The same pattern emerges in the low-code discussion. As long as the business department can click a few things together and everything runs smoothly, no developer seems necessary. The moment things go wrong, people are needed again—and really good ones at that.
Why Enterprise Organizations Can Fail Due to Lack of Speed
The larger and more regulated an organization is, the harder it is for it to implement the changes that are currently necessary from a technological standpoint. This is less a technical problem than a structural and speed-related one.
Fixed regulations can be easily formulated and automated. Software that calculates taxes and responds to changes no longer requires legions of programmers. The problem lies elsewhere.
Things get interesting when it comes to anything that can’t be neatly described, and when it comes to probability. AI doesn’t deliver 100 percent accuracy—perhaps 99.8 percent. For a bank account, this margin of error is unacceptable; that’s a valid point. For many other business cases, however, it is perfectly acceptable.
Thomas Ronzon cites an example from logistics: An image classification system was supposed to separate aging material from non-aging material, with an accuracy rate of about 97 percent. The project failed because quality assurance wouldn’t accept it, even though a misclassification in this case would have had no consequences.
Added to this is the sluggishness of approval processes. If a business unit wants to deploy a new AI tool this afternoon, but the next board meeting isn’t until three and a half months from now, “shadow AI” emerges. Things get done without the organization’s authorization. Or others jump in ahead of them.
Trust in AI Builds Up Just Like Trust in People
Trusting AI systems works according to the same mechanism as trust between people: there’s an initial leap of faith, and trust grows with experience in the relationship.
No one blindly trusts just anyone who wants something. Similarly, verification mechanisms and experience with a system are needed before entrusting it with tasks. And just as with people, AI will sometimes disappoint you—with the difference that the consequences are a separate issue.
There is a clear double standard here. Thousands of traffic fatalities caused by human drivers are simply accepted as a given. But if an autonomous car crashes into a tree just once after millions of trips, the entire technology is immediately deemed a no-go. This leads to a counter-question: Can we afford not to have autonomous cars?
For testing, this means building on an old insight. Testing serves not only to find bugs or verify requirements, but also to build trust in the system. It is precisely this task that becomes important again with Vibe-coded systems.
No one understands every line of code, and that’s always been the case
The idea that someone must understand the entire code is an illusion—even without AI. In a project with over 100,000 lines of code, no single developer understands every line.
This has been happening for a long time; it’s just not noticed. The usual practice is to address a problem when it arises in production, because that’s when you know something has gone wrong. The defensive reaction—that you have to understand everything rather than just generate it—is understandable. However, it could turn out to be a temporary phenomenon.
What Young Developers Should Learn Today
The most important piece of advice is: Find a side project. Even if you’re just coding for fun, you’ll gain experience that doesn’t come from day-to-day work—and have fun along the way.
Here’s a practical warning: don’t start with smart home projects. If something goes wrong there, you’ll have the whole family’s wrath on your hands and end up becoming the administrator of your own household.
The key difference is illustrated by two students. One built his own keyboard, designed circuit diagrams, sourced controllers, and in the process gained knowledge across all possible layers. He was the administrator, product owner, and quality assurance specialist all rolled into one. The other had no technical hobby and failed the test question. Intrinsic motivation trumps formal knowledge.
From T-Shape to P-Shape
The old image of the senior developer was the T-Shape: deep expertise in one area, with a broad spectrum of knowledge across the board. This model is no longer sufficient.
What’s needed now is a P-shape: multiple areas of expertise that go deep, combined with a broad overview. It’s no longer enough to delve deeply into a single field.
| Model | Depth | Breadth | Relevance Today |
|---|---|---|---|
| I-Shape | one subject, very deep | hardly any | risky, because only one person can handle an interface |
| T-Shape | one subject, in-depth | broad | the former ideal for senior roles |
| P-Shape | multiple subjects, in-depth | broad | what’s needed today |
The reality in many organizations is still that of I-shaped people. As a result, three out of seven product teams end up competing for a single person because only that person can manage a specific interface. This is a bottleneck that comes back to haunt us.
Those who think both broadly and deeply need the ability to abstract in order to keep an understanding of architecture and systems in mind. This ability cannot be replaced by a tool.
Learning Today Goes Both Ways
To blanket-label the younger generation as lazy misses the point. They’re good, and they’re the only generation we have.
The old “master-apprentice” model still holds true, but with a twist. Today, the apprentice or trainee regularly discovers something that the experienced developer doesn’t know. The roles of master and apprentice can switch depending on the situation. Being older doesn’t automatically make you the master.
Respect flows both ways. The breadth of the tech stack that must be mastered today far exceeds the former world of 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 presumption of knowing everything better, but the willingness to contribute their expertise in one area while learning alongside others in other areas.
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, causing the file handles to expire 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—not because of the technology?
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—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 P-shape with multiple deep areas of expertise, underpinned by the ability to think abstractly about architecture and a deep understanding of the system.
