Who wouldn’t want a “Bob the Builder” for their own four walls, who immediately springs into action when something crumbles or molds appears? Such doers are hard to come by, and even the band “Das Lumpenpack” sings about their disappointment at having only educators instead of craftsmen in their circle of friends.
That’s how it is with building a house… but what about software development? Software engineers are also notoriously hard to find, and once you’ve fallen into the clutches of SAP, you might get your specialist, but you’ll have to pay a lot of money for even the simplest feature.
But that is changing dramatically because of AI.
Suddenly, thanks to AI, everyone can supposedly code, and developers—especially juniors—are being shown the door, replaced by AI agents that are willing to work and available everywhere. Jensen Huang even proclaims the end of computer science and says quite openly:
“IT-Teams will become HR departments of AI.”
Regardless of whether Jensen Huang is right or not, enough is changing to prompt a fresh approach to a rather old question that has surely occupied the minds of many a homeowner:
Modernize or demolish?
Metaphors are like pirates—they limp, but they get the job done.
When we talk about digital products, we like to use analogies such as the “house building metaphor” mentioned above.
Good software impresses with “clean code.” It runs smoothly and has a tidy user interface with “shiny” user interface elements. Conversely, we describe digital products that have seen better days as dusty, confusing, and difficult to access.
Yoder and Foote, who have dealt extensively with the topic of good software architecture, simply refer to bad software as a “big ball of mud.”
A “big ball of mud” is a haphazardly structured, sprawling, sloppy jungle of spaghetti code held together with duct tape and binding wire. Such systems show clear signs of unchecked growth and constant makeshift repairs. The information contained in these systems is randomly distributed across the most distant elements, often to the point where almost all important information is global or duplicated. The architecture of such systems may never have been properly defined, and if it was, it has eroded beyond recognition. Programmers with a shred of architectural sensibility avoid such swamps. Only those who don’t care about architecture and perhaps even enjoy laboriously plugging holes in leaky dikes day after day enjoy working with such systems.
— Yoder and Foote, Big Ball of Mud
This deliberately repulsive image suggests the temptation to abandon such legacy systems and simply rebuild them from scratch on the much-cited and equally metaphorical “greenfield site.” If we now even have AI agents available for the new build—at virtually no cost—why should we bother with these legacy systems at all?
Requirements, Baby
Once again, the answer lies very early on in the development process – in the requirements. An old system may have been created without architecture or planning, but it has always grown in line with requirements.
In other words, no one builds software into a “big ball of mud” over the years just for fun! There were simply too many requirements to be implemented in too short a time, without sufficient time for verification, prioritization, and consolidation. Some of these requirements even contradicted each other and ultimately led to features that were “neither fish nor fowl.”
Everyone can code!
Since the triumph of agile approaches such as Scrum and SaFE, good requirements management is no longer as en vogue as it once was. Instead of writing good user stories, many creative POs prefer to jot down a few solution ideas in the backlog and hope that the team will implement them in the best possible way. After the sprint, you can always see whether the result is any good or not. And if software engineers could program faster and didn’t cost so much, then it would take much less time and money to create the perfect software.
AI agents can communicate with each other, operate digital tools, generate code, and make joint decisions, which ultimately enables them to form software development teams. The “multi-agent” framework MetaGPT initiated by DeepWisdom.ai, for example, has implemented such a team of AI agents and allows it to collaboratively develop software as an AI team.
Bot the Builder
So, can’t a creative PO simply convey his solution ideas to his team of AI agents, who then build the software for him exactly as he envisions it? At the head of this team, a construction manager AI agent would take over coordination and delegate the detailed work to other AI agents.
Yes—technically, this is now possible. And doesn’t it sound a little familiar?
So let’s say “hello” to “Bot the Builder,” our wise AI construction manager, and his talented AI agent friends Backie, Frontie, Testie, and whatever else they might be called.
What sounds so flippant and also a little implausible is actually the driving idea behind many current (and in some cases financially exuberantly supported) vibe coding tools and AI-driven IDEs.
At this point, I would like to mention only the best-known tools, knowing full well that by the time this article is published, the next such product will probably already be in the starting blocks:
- Cursor IDE
- Replit
- Roocode
- MGX
- Cline (VS Code Plugin)
- Lovable
- Kiro IDE (Amazon)
- V0 (Vercel)
- GitHub CoPilot (Microsoft)
The tools mentioned are, of course, completely different in terms of their philosophy and handling! But many of them, such as MGX, Lovable, and V0, have at least one thing in common: they love greenfield projects and can very quickly build a completely new, executable application from scratch. This is probably partly because it is more impressive for VCs to see software created at the snap of a finger than to migrate complex legacy software that first needs to be thoroughly understood. As they say in Silicon Valley…
“Move fast and break things.”
… as if breaking something were a heroic deed in itself. Admittedly, I tend to be more of a “move fast and improve things” kind of person, but before I come across as too much of a Silicon Valley critic, let me get back to the topic at hand, because:
On closer inspection, the many vibe coding, prototyping, and app generation tools are not as similar as they may seem at first glance.
They can’t necessarily be divided into “new builders & modernizers,” but at least into “planners & doers”: While Cline, for example, allows you to store a requirements specification and switch between the two modes “Plan & Act,” Cursor IDE requires you to prompt each next implementation step.
If you want to see me experimenting with Cursor IDE for yourself, I recommend my latest Accessibility Podcast, “2025: Odyssey Accessibility”… a real rollercoaster ride of emotions.
Big Ball of Mud 2.0
My Vibe Coding self-experiment with Cursor IDE taught me one thing above all else: even though we can now write code faster and more cheaply, we won’t necessarily get to perfect software any faster. Above all, we run the risk of quickly creating a beautiful “big ball of mud”… a “big ball of mud 2.0,” so to speak.
Despite AI, the biggest risk in software development is still that we don’t know whether we are building something that will actually be accepted from the perspective of users and the market. It is therefore important to emphasize that the strength of the AI tools mentioned lies particularly in prototyping, but not in building scalable architectures.
Low-risk software modernization
To minimize the greatest risks in software development, it is therefore worthwhile to consider not only the code-generating capabilities of AI agents, but also the possibilities for arriving at better requirements. I have already highlighted prototyping as a legitimate and proven means of doing this.
However, if you look a little deeper, you can also use AI to leverage the existing legacy system as a “requirements factory” for a modern, intuitive, and architecturally clean system.
Of course, such AI-driven migration also carries certain risks, and a mere “Yeah, we can do it” will not be enough (here either).
The second part of my article series therefore deals with the question of how to approach AI-driven software migration step by step in order to get users on board and minimize the risks of failure.
