Humans Drool, Robots Rule — Unless They Delete Your Database, Part Two

In this post 6 sections

1. Quick Recap
2. The Real Job Isn’t Typing Code — It’s Design
3. If Everyone Did What Klaus Did, No One Would Be Left to Catch AI’s Mistakes
4. The Cost
5. To Be Fair to Klaus
6. The Verdict

[This series is a critique of the article “Humans Drool — Robots Rule”. Please read that before reading this. You can find Part One of this series here]

Quick Recap#

In Part 1, we went through Klaus’s specific claims. He said that AI codes faster, safer, and better than humans. The data says the opposite: AI coding tools measurably slow down experienced developers, produce more bugs and security holes than human code, and have already caused serious breaches and outages when people trusted them the way Klaus trusts his.

That’s not the strongest argument against his claim.

The Real Job Isn’t Typing Code — It’s Design#

Coding is not the most difficult or valuable aspect of software engineering. It is not typing the code. Designing something that continues to work next year, fails safely when something breaks, and resists abuse by malicious actors has always been the hard part. That’s called design, and it’s mostly invisible until it’s missing.

First, you must identify a problem. What problem does your software solve? Organize your books? Your notes? Do taxes? Edit your novel? What does the software exist to help you do?

Once you determine that, address it with code. What should your program do? How should it work? How do you design a highly usable system that effectively solves the problems it aims to address? What should the user interface look like? How smoothly should it perform? What technology platform is efficient? What tools should you use?

I think Klaus would acknowledge this. Klaus likely does a lot of this design work himself. He may very well excel at some of this software engineering, based on my experience with him. He excels at identifying problems his software should solve and making it easy to use and visually appealing. How to make an efficient user interface. He is skilled at the design work that visual designers excel at. Good for him!

However, what about the software architecture questions? The technical details he needs to get right to make his vision into properly functioning, well-implemented, and secure software? This is when vibe-coding could cause him trouble.

What happens if someone tries to hack his code? Is he prepared for that?

A few concrete examples:

Big-picture decisions.
Most senior developers say they don’t trust AI to make architecture decisions. They do not trust AI blindly to implement their design. Why? Because AI doesn’t understand the business reasons behind those choices. They use AI to write pieces, not to decide the plan.

Thinking ahead.
Studies show AI tools get worse the longer and more complicated a project gets, because they don’t think about the cost of a shortcut six months from now. Humans do (or should).

Fixing things when they break.
Nearly all engineering leaders say their AI tools can’t tell them what actually went wrong in production when something fails. More than half of serious tech outages get resolved by experienced humans familiar with similar issues, not by AI tools.

Thinking like an attacker.
AI writes code assuming everyone using it is friendly. A skilled programmer knows better and assumes a malicious user will try to hack their software. They will ask questions such as, “What if someone tries to break this?”

Knowing when to say “not yet.”
A good engineer knows when to delay a launch until it’s fully tested. AI has no instinct to say that. It produces exactly what the user requests, including holes. That instinct is the one thing missing from every disaster listed in Part 1.

Klaus didn’t eliminate the need for design when he fired his coding team. He removed the people who thought through to design the software system that best implements his vision. Klaus dismissed the engineers who build for failure, resilience, and security. He didn’t streamline his company. He amputated the part that keeps the software running in a healthy state.

If Everyone Did What Klaus Did, No One Would Be Left to Catch AI’s Mistakes#

This is the part Klaus neglected. Senior engineers who catch AI’s mistakes did not begin like that. They spent years doing the boring junior-level work he’s celebrating the death of: writing simple code, fixing small bugs, slowly learning why things break. That’s how they learn to catch AI’s mistakes; by practical experience with designing properly designed and secure systems. There isn’t a shortcut. They cannot acquire experience in a world where AI does their work.

Microsoft’s research found that when juniors skip design and let AI do it, they get worse at spotting mistakes in AI’s code. The industry calls this “knowledge debt”: skills that look fine until something unexpected happens. And because it takes 5–7 years to turn a junior into a senior, companies that stopped hiring juniors may face a shortage of experienced engineers in the early 2030s.

So if “humans drool, robots rule” became everyone’s actual hiring plan, the result wouldn’t be a world that doesn’t need human judgment anymore. However, it would create a world where no one remains to notice or correct the AI’s mistakes.

Might AI push out junior and intermediate devs at more and more companies? Probably not a good trend!

The Cost#

Here’s the price tag when nobody catches these problems in time. IBM’s 2026 data-breach report — a study that’s tracked this every year since 2005 — found that breaches caused by unapproved AI tools nearly doubled in one year, now averaging $5.39 million per breach. AI-related attacks (deepfakes, AI-written malware, AI phishing) were up 56% and averaged $6 million each. And here is a damning statistic: 92% of companies hit by an AI-related breach had no basic access controls in place beforehand. Not because hackers were geniuses. Their reliance on an AI indifferent to proper security caused issues.

That’s the “omniscient” tool’s actual track record once money’s on the line: not brilliance, just confidence with nobody double-checking it. Klaus is about to conduct that same experiment on Genix alone, using real people’s data.

If someone goes wrong, will Klaus be able to easily fix it? Not without AI — the very unreliable tool which would likely be to blame for the problem in the first place!

Insecure apps that seem safe, but have problems Klaus might not see or be expert enough to identify or easily address.

To Be Fair to Klaus#

Not everything in his post is incorrect. For a solo person building a small, low-stakes app from scratch, AI tools can save huge amounts of time and money — nobody disputes that. AI is also improving fast, and not every study agrees on every point; some earlier research found AI code wasn’t always worse than human code in every situation. This is a fast-moving argument, not a settled one. But I think I have shown that you cut humans out at your potential peril.

The Verdict#

Klaus didn’t discover that robots build software better than humans. He discovered he hates managing people, and that AI removes that annoyance for a small, low-stakes project. That’s a fine preference. But it is not the sweeping proof he thinks it is.

Research shows that AI coding tools slow experienced developers down once you stop trusting the “speed” they seem to give. AI-written code has about twice the security holes and far more bugs than human code, and it makes codebases messier over time. And when non-technical founders skip human review the way Klaus plans to, the result isn’t a faster launch. It’s a leaked database, a hacked app, or a breach that hits the news before the founder even knows something went wrong.

Klaus can keep building Genix his way. He should budget for what happens after he ships it. Because it might not be as painless as he imagines…