Help, my dentist started coding!

There is a recurring pattern in enterprise software history: technologies that initially promised dramatic productivity gains by hiding complexity eventually created large applications that became difficult or impossible to maintain.

So when my dentist celebrates on LinkedIn that Fable 5 got re-enabled and can’t wait to burn tokens again, I have to ask myself: is this a warning of how much broken software we will have to debug over the next decade? History is repeating itself here.

There is an old saying: if you give a fool a faster tool, all you get is a faster fool.

I see this pattern all the time. It’s not just the dentist who wants to get rid of his old patient management software. It’s CEOs of well-funded late-stage startups and private equity fund managers who suddenly decide that building a CRM is their core business. Marketing agencies start building iOS apps.

The main problem here is IMHO the false advertising by the frontier model providers. The perceived message is: “Everyone can code”.

Sure, if you have decades of experience in building software, Claude Code and Codex are massively powerful tools which can give you that 10x boost. I can confirm this for myself in my daily work.

But after years at the forefront of AI development, trying basically every new tool and model and testing them as thoroughly as possible, my personal conclusion is: we are not there.

Yes, AI can easily build over 90% of your code. That’s exactly what we are doing at Vendis.ai while building our AI-first CRM. BUT: the amount of internal tooling needed to steer these models in the right direction (Rules, Subagents, Skills, Configuration, Orchestration, etc.), plus the amount of manual review required to stop the coding agent from producing simply terrible software, is still remarkable. And that’s despite using a very well-organized, opinionated framework: Ruby on Rails. Every developer at Vendis has 25+ years of coding experience, and right now, that experience is simply not replaceable.

Will we get there at some point, through AGI or simply incrementally improved models? Very likely. As usual, people tend to overestimate the short-term effects of technology and underestimate the long-term effects.

The problem isn’t just the terribly unmaintainable, untested code (my prediction: software agencies and service providers will have a blast cleaning up this mess over the next years). It’s also security. Under EU law at least, you have to report data breaches and hacking attacks to the authorities. Let’s see what happens when these builders have to do that for the first time, because some Russian or North Korea ransomware group knew better how to turn frontier models into money.

At least it’s maybe just a question of time when your patient records will be available on the internet, because access controls have been only implemented client-side (FIFA, anyone?)

The even bigger problem is Day 2: operations. Ask these people how they actually run their software, and they just follow whatever Claude tells them. “Here is your deployment to Vercel.” Done.

Obviously, this results in a nightmare, from simple things like database backups all the way to security bugs. If you are lucky, Claude MIGHT tell you when to upgrade that CVE’d npm package. Or not. Or there is a privilege escalation hiding in the code. Or there are simply no tests.

Can a frontier model find these issues? Likely. But if you don’t ask the right questions, it won’t.

Interestingly, all of this reminds me of how I started my life in software, with my first company, founded in the late 90s, doing B2B software. Every potential customer we visited had proprietary Lotus Notes apps. Lotus Notes was the n8n/Lovable of the 80s and 90s. Most people today won’t remember, but I do, vividly. Lotus Notes was revolutionary. It combined databases, forms, workflows, replication, and email in one product. Business users could build applications with surprisingly little programming. It was a low-code dream that slowly but surely turned into an IT nightmare.

Those NSF databases were completely proprietary and mixed Formula language, LotusScript, and Java. Business logic often lived inside forms. Nothing was tested. There was very little architectural separation. And developers frequently left without documentation.

Employees with almost no coding experience created these apps, and the apps became centerpieces of the business. But they were usually totally unmaintainable, had a completely proprietary data model, were compatible only with themselves, and were very, very hard to modernize. Many Fortune 500 companies still run Notes applications written 20 to 30 years ago because replacing them is too risky.

While companies realized their legacy problem and paid literally millions of dollars to get rid of that Lotus Notes nonsense, the next hail-mary options were already appearing on the horizon: Visual Basic, PowerBuilder (still popular in many banks), ActiveX, Java applets, Silverlight, and Flash. Anyone? Or MS Access, Oracle Forms, Delphi, and the like.

Those technologies made sure that software consultants didn’t run out of work for the next 15 years, cleaning up this mess. If Steve Jobs hadn’t rejected Flash for iOS, I am sure we would still have to deal with that nonsense today (the price: thousands of applications required complete rewrites). Same for ActiveX: many corporate intranets depended entirely on it until browsers killed support, even Microsoft themselves.

And while they were still cleaning up, the next wave was already rolling. This time, everything would be so much easier: SharePoint customizations were the rising stars, with custom Web Parts, workflows, and InfoPath forms. XML everywhere, with hidden business rules. What can go wrong? The result: yet another unmaintainable data silo, and each SharePoint upgrade became a migration project. Organizations still struggle to migrate legacy InfoPath forms today.

These technologies often shared the same traits:

• They optimized for rapid initial delivery rather than long-term evolution.
• They blurred the boundaries between UI, business logic, data access, and workflow.
• They made automated testing and continuous integration difficult.
• They encouraged drag-and-drop development or code generation, producing artifacts that were hard to review and refactor.
• They embedded business rules in visual designers, event handlers, or metadata instead of explicit, version-controlled code.

Today, we see those patterns resurface with exactly the same problems. Those 800-node n8n workflows, putting the whole company to autopilot, built by the company champion “who really gets AI”. Wait until that person leaves.

AI-generated code without review takes this to another level. Same pattern: fast initial velocity, but inconsistent logic and architecture, and gigantic maintenance costs.

Small businesses celebrate what they can build with a $200 Claude subscription, only to amass legacy software that will cost tens or hundreds of thousands of dollars to clean up.

And the startup CEO who dedicates two developers to building a CRM (see what happens when they leave) is basically betting at least $300k in developer salaries against a $100k CRM subscription.

That’s why I think BTW that SaaS standard software isn’t dead, as long as you are a system of record. Or in AI word: System of action as we call it at Vendis.ai.

While I can totally understand the fascination, but if you decide to build a core system (CRM, CMS, ERP, HR software, etc.) yourself, in 99.9% of all cases you are making a terrible mistake.

The underlying lesson has remained consistent for decades: the technologies that produce the most technical debt are rarely the ones that are “bad”. They are usually the ones that make it exceptionally easy to create software before there is enough discipline around architecture, testing, modularity, and ownership. Their productivity gains are real, but they often defer complexity rather than eliminate it.

Building a prototype to show your developers or consultants how it should feel like? Customizing standard software to your needs through new interfaces like MCP? Building a quick internal integration for a data migration between two legacy systems? Sure thing, that’s where Claude really shines.

But building, deploying, and maintaining a secure and stable core application without any clue about software development and architecture? I am not so sure, at least for the next few years.

Better to ask somebody who knows how to do that. Or just pay that SaaS company.

Just like I don’t ask ChatGPT how to drill and repair my teeth.