“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.
