"Why I've Started to Oppose Vibe Coding"

The turtle's face is exactly my expression when I look at our industry.

👦🏻 Author: Mario Zechner

🧑‍🎨 Translation/Layout: Zeoooo

Mario Zechner actually wrote a piece tearing into vibe coding.

Who is he? The author of the PI framework — and also the creator of libGDX, the cross-platform game framework. PI is the underlying agent framework for OpenClaw, a project that went from zero to 250,000 GitHub stars in less than three months.

Yet Mario wrote this article saying:

You're all using agents to paint yourselves into a corner.

This is one of the most unusual articles we've read on AI coding lately, and pretty much the only dissenting voice. Mario isn't preaching "AI will replace programmers," nor is he outright dismissing "AI coding is useless." What he's saying is:

The moment you outsource all AI coding judgment to agents, what you lose isn't workload — it's agency.

The last line of the article is almost worth printing out and taping to the wall —

All of this requires humans.

🚥

It's been almost a year since that generation of coding agents capable of helping you build complete projects from scratch first appeared. There were earlier pioneers like Aider and early Cursor, but they were more assistants than true agents. The new generation of tools is mesmerizing, and many of us have spent countless off-hours using them to finally build all those projects we always wanted to make but never had time for.

I don't see anything wrong with that. Using your free time to make stuff is thoroughly enjoyable, and most of the time you don't need to care about code quality or maintainability at all. If you want to learn a new tech stack, this is also a great opportunity.

Over the Christmas holidays, both Anthropic and OpenAI dropped some goodies that got people hooked on their slot machines. For many, this was their first taste of agentic coding magic. More and more people are getting pulled in.

Now, coding agents are starting to be introduced into production codebases. After 12 months, we're beginning to see the consequences of this "progress."

Here's where I stand so far.

Everything Is Breaking

Though this is all hearsay, software does feel like it's becoming a fragile mess — a mere 98% uptime is becoming the norm rather than the exception, even for large services. And the bizarre UI bugs showing up are the kind any QA team should catch. Of course, this problem predates agents.

But we seem to be accelerating.

We can't see inside companies. But occasionally something leaks out and gets picked up by journalists. Like this supposedly AI-caused AWS outage [1], which AWS promptly "debunked" [2], then internally followed up with a 90-day reset plan [3].

Microsoft CEO Satya Nadella has been touting how much of Microsoft's code is now written by AI [4]. While we don't have direct evidence, Windows sure feels like it's declining. Microsoft itself seems to agree — just look at this blog post [5].

Companies claiming their products are 100% AI-written continue to produce the worst garbage you can imagine. Multi-GB memory leaks, broken UIs, half-baked features, frequent crashes — this is not the quality badge they think it is, and it's definitely not an advertisement for "let the agent do everything" being viable.

Through the grapevine, you're increasingly hearing people at software companies large and small say that they've agentic-coded themselves into a corner. No code review, architecture decisions fully delegated to agents, piles of features nobody wanted.

This is the result.

How We Shouldn't Work With Agents, and Why

We've basically abandoned all discipline and autonomy in exchange for an addiction — your highest pursuit is producing the most code in the shortest amount of time. Consequences? Who cares.

You're building an orchestration layer to command an army of autonomous agents. You installed Beads, completely unaware that it's basically uninstallable malware.

Everyone online says this is how you should work, otherwise you're finished. You're running loops mindlessly.

Look, Anthropic used an agent cluster to build a C compiler — a bit broken, but the next-gen LLM will fix it for sure. God, Cursor used an agent army to build a browser. Yes, it didn't really work, and humans had to nudge the wheel occasionally. But the next-gen LLM will fix it, guaranteed! Distributed, divide-and-conquer, autonomy, dark factories, software problems solved in six months. SaaS is dead, my grandma just had her Claw build her own Shopify!

Again, this might work for side projects that virtually nobody uses (including yourself). Maybe someone can actually make this work on a software product that isn't a steaming pile of garbage and has real users using it seriously. If you've done it, that's genuinely impressive.

But at least in my circle of peers, I haven't found any evidence that this works. Maybe we all have technical problems.

Zero Learning, No Bottleneck, Delayed-Explosion Compounding Booboos

What's a booboo? — A single small bug, a small mistake; a useless method, a duplicate code block, a type that makes no sense.

The problem with agents is that they make mistakes. That's fine, humans make mistakes too. Maybe just correctness errors, easy to spot and fix, add a regression test, bonus points. Or code smells that linters can't catch — a useless method, a type that makes no sense, some duplicate code over there. Individually, these are harmless. Humans make these booboos too.

But robots aren't humans. Humans will make the same mistake a few times, then eventually learn not to — either because someone yelled at them, or because they actually grew. Agents don't have this learning ability, at least not out of the box. They'll repeat the same mistakes, and depending on training data, they might even creatively mix and match errors into new varieties.

You can try to train your agent, of course. Tell it in AGENTS.md [6] not to make that booboo anymore, design the most elaborate memory system, have it consult past mistakes and best practices. This can work for specific types of errors. But only if you actually observed the agent making that error.

There's another more important difference between robots and humans: humans are the bottleneck.

Humans can't pump out 20,000 lines of code in a few hours. Even if humans produce booboos at a high frequency, the number of booboos they can introduce into a codebase per day is limited. Booboos compound at an extremely slow rate. Usually, when the pain from booboos reaches a certain threshold, pain-averse humans will take time to clean them up. Or the person gets fired, and someone else cleans up. So the pain subsides.

With an orchestrated army of agents, the bottleneck disappears, and so does human pain. Those tiny, harmless booboos suddenly compound at an unsustainable rate. You removed yourself from the loop, so you have no idea those innocent booboos have merged into a codebase monster. You only feel the pain when it's too late.

One day you look back and want to add a new feature. But the architecture — which by now is basically a pile of booboos — won't allow your agent army to make modifications in a functional way. Or your users are yelling at you because something in the latest version broke and deleted some user data.

You realize you can no longer trust this codebase. Worse, those tens of thousands of unit tests, snapshot tests, and e2e tests that you had the robots write are equally untrustworthy. The only thing that still reliably measures "does this thing work" is manually testing the product.

Congratulations, you played yourself (and your company)!

Vendors of Complexity

You have no idea what happened because you delegated all your autonomy to your agents. You let them run wild, and they are vendors of complexity. They've seen too many bad architectural decisions in their training data, and they've been through RL training. You had them architect your app. Guess what happened?

Endless complexity, a hodgepodge of cargo-culted "industry best practices" — and you didn't rein it in before things became irreversible. But it doesn't stop there.

Your agents can't see each other's runs, can't see your complete codebase, can't see all the decisions you or other agents made before they made their changes. Therefore, agent decisions are always local, which is the root cause of the booboos described above. Massive code duplication, abstraction for abstraction's sake.

All of this compounds into an irredeemable mess of complexity. The exact same kind of mess you see in hand-written enterprise codebases. That kind of mess forms because pain is distributed across many people — individual pain never reaches the "I need to fix this" threshold, individuals may not even have the ability to fix it, and organizational pain tolerance is extremely high. But hand-written enterprise codebases take years to rot to that degree, and organizations evolve in a pathological symbiosis with complexity, learning to cope with it.

With agents and a two-person team, you can reach that level of complexity in weeks.

Agentic Search Has Low Recall

Now you want your agents to fix this mess, refactor it, make it fresh and clean again. But your agents are already overwhelmed. Because the codebase and complexity are too large, they can only see local views of this mess.

I'm not just talking about context window sizes or long-context attention mechanisms failing in the face of million-line behemoths — those are obvious technical limitations. This is more insidious.

Before your agent tries to help you fix the mess, it needs to find all the code that needs changing, and all existing code that could be reused. We call this agentic search. How the agent does this depends on what tools it has. You can give it a Bash tool to rip through the codebase with ripgrep; you can give it a queryable codebase index, an LSP server, a vector database. Ultimately it doesn't make much difference. The larger the codebase, the lower the recall. Low recall means your agent literally can't find all the code it needs to do a good job.

This is also why those code smell booboos happen in the first place. The agent misses existing code, reinvents the wheel, introduces inconsistency.

Then they bloom into a beautiful 💩 flower of complexity.

How Do We Avoid All This?

How We Should Currently Work With Agents

Coding agents are sirens, luring you with their code generation speed and uneven intelligence, often completing a simple task with high quality at blazing speed. Things start falling apart when you begin thinking "oh my god, this thing is amazing, computer, do my job!"

Delegating tasks to agents is fine, of course. Good agent tasks share some common characteristics:

• They can be scoped so the agent doesn't need to understand the whole system
• The loop can be closed, meaning the agent has a way to evaluate its own work
• The output isn't mission-critical, just a temporary tool or internal software that no one's life or income depends on
• Or you just need a rubber duck to bounce ideas off — bounce your ideas against the compressed wisdom and synthetic training data of the internet

If any of the above apply, you've found the perfect task for an agent — provided you, the human, are the final quality gate.

Karpathy's [7] auto-research [8] for speeding up your app launch time [9]? Great! As long as you understand the code it spits out is nowhere near production-ready. Auto-research works because you gave it an evaluation function that lets the agent measure its work against some metric (like launch time or loss). But that evaluation function only captures a very narrow metric. For metrics the evaluation function doesn't capture — like code quality, complexity, or correctness when your evaluation function itself is flawed — the agent will happily ignore them.

The point is: let agents do the boring stuff, the stuff you won't learn anything new from, or trying various approaches you otherwise wouldn't have time for. Then you evaluate what it gives you, extract the ideas that are actually reasonable and correct, and do the final implementation yourself. Yes, of course, you can use an agent for this final step too.

Slow the fuck down, that's the right path. Give yourself time to think clearly about what you're actually doing and why. Give yourself the chance to say, fuck it, we don't need this. Set yourself a limit on how much code you allow machines to generate per day, matching what you can actually review.

Anything that defines the shape of your system — that is, architecture, APIs, and so on — write by hand.

Maybe use tab completion for some nostalgia. Or pair program with your agent. Stay in the code. Because the simple act of having to write things out by hand, or watch them get built step by step, introduces friction that helps you better understand what you're trying to build and how the system "feels." This is where your experience and taste live, and this is precisely what current SOTA models cannot yet replace.

Slow the fuck down, endure some friction, and you'll learn and grow.

The end result is systems and codebases that remain maintainable — at least as maintainable as our old systems before agents showed up. Yes, those weren't perfect either. Your users will thank you, because your product is now delightful rather than a hack job. You'll ship fewer features, but they'll be the right features. Learning to say no is itself a feature.

You can sleep soundly because you know exactly what's going on, you hold the reins. Your understanding solves the recall problem of agentic search, leading to better robot output that needs fewer revisions. If things go wrong, you have the ability to step in and fix them. If your initial design isn't ideal, you can understand why it's not ideal and how to refactor it into something better. With or without agent assistance.

All of this requires discipline and autonomy.

All of this requires humans.

References

[1] AI-caused AWS outage: https://www.ft.com/content/00c282de-ed14-4acd-a948-bc8d6bdb339d

[2] "Debunking": https://www.aboutamazon.com/news/aws/aws-service-outage-ai-bot-kiro

[3] 90-day reset plan: https://www.businessinsider.com/amazon-tightens-code-controls-after-outages-including-one-ai-2026-3

[4] How much of Microsoft's code is now written by AI: https://techcrunch.com/2025/04/29/microsoft-ceo-says-up-to-30-of-the-companys-code-was-written-by-ai/

[5] Blog post: https://blogs.windows.com/windows-insider/2026/03/20/our-commitment-to-windows-quality/

[6] AGENTS.md: http://agents.md/

[7] Karpathy's: https://x.com/karpathy

[8] auto-research: https://github.com/karpathy/autoresearch

[9] Speeding up your app launch time: https://x.com/badlogicgames/status/2035469013480869912