Vibe Coding: A Monkey Behind the Controls

The Physical World Problem

I've been using Claude since March 2024. For different things, half the time just to test its limits.

Here's what I've learned: AI knows nothing about the physical world.

It's only useful for "virtual things" – stuff that doesn't exist in physical reality. No atoms. No friction. No consequences that bleed into meatspace.

Code is one of those rare things. A pure human-invented abstraction. Logic gates all the way down. This is where AI shines.

And yet.

Here's the irony: we worry about LLM hallucinations – models confidently stating false things.

But the bigger hallucination problem isn't in the models. It's in the activists.

Due to confirmation bias, AI evangelists hallucinate LLMs into being far more capable and useful than they actually are. They see what they want to see. They share the wins, bury the failures. They extrapolate from demos to revolution.

Yes, these are good tools. But here's the uncomfortable fact:

AI activists today hallucinate more than the LLMs themselves.

The 200 PRs Myth

Everyone's talking about the junior who shipped 200 PRs with Claude.

Somewhere in the bowels of Silicon Valley, an engineer spent last month with zero IDE open, every line written by AI, and 200 pull requests shipped.

This is December 2025. Karpathy called it a "magnitude 9 earthquake" hitting the profession.

But here's the question nobody asks: What happens six months later?

• How many of those PRs introduced subtle bugs that only surface under load?
• How many created technical debt that someone else has to untangle?
• How many were "working" code that nobody actually understands?

Speed without understanding is just technical debt with extra steps.

Where Vibe Coding Works

Let's be fair. AI genuinely accelerates certain categories of work:

For these tasks, AI isn't 10x faster – it's 100x faster.

Google and StackOverflow are being replaced by Claude Code. That part of the job is effectively solved.

But there's a critical caveat:

Where It Falls Apart

Now for the uncomfortable part.

The AI doesn't hold the whole system in its head. You do.

Or at least, you're supposed to.

The Copycat Problem

Why AI Cannot Innovate

AI doesn't think. It pattern-matches.

Everything an LLM "knows" is something a human already wrote, said, or built. It can recombine. It can synthesize. It can find similarities across domains.

But it cannot ask:

• "Why do we do it this way?"
• "What if every assumption is wrong?"
• "What hasn't been tried?"

These questions require something AI fundamentally lacks: skin in the game.

Innovation comes from frustration, curiosity, stubbornness. From waking up at 3am with an idea. From the irrational conviction that everyone else is wrong.

AI has none of this. It's a very fast, very comprehensive copycat.

Good at what's been done a thousand times. Useless for what's never been done.

The Popularity Paradox

Here's something that surprised me: LLMs struggle with Unix terminal programming. Writing a terminal emulator from scratch. Epoll. Terminal character handling. PTY internals.

This is 40+ year old technology. Fully documented. Open source. Man pages exist. POSIX standards exist.

And yet, LLMs fumble it. Why?

Maybe 500 people in the world write terminal emulators. 5,000,000 people write React components.

LLMs know what's talked about, not what's fundamental.

The Monkey Behind Controls

Here's the scenario that keeps me up at night:

A vibe coder who can't actually program. They prompt. They accept. They ship. The code looks fine. The tests pass (the ones AI wrote, anyway).

Six months later, something breaks. Not a simple bug – a deep architectural flaw. The kind that requires understanding why the system was built this way.

The vibe coder stares at the screen. They don't understand what they shipped. They never did.

This isn't hypothetical. It's already happening. The failure modes just haven't surfaced yet at scale.

When they do, we'll discover how much "AI-assisted development" was actually "AI-dependent cargo culting."

The Structure That Never Forms

When you think through something yourself – whether it's code, a strategy, or a system design – something happens in your head.

A structure forms. A paradigm.

It's not just "knowing the answer." It's having a mental architecture that lets new information flow through it. You own the work in a way that's hard to articulate. When someone asks "why did you do it this way?" – you know. Not because you memorized it, but because you built it.

When AI does the work:

The structure forms somewhere else. In the model. In the weights. In a place you cannot access or retrieve in any understandable form.

You get output. You don't get understanding.

For developers:

A lawyer who has manually worked through hundreds of contracts develops pattern recognition they can't even articulate – intuitions about where things break, what's missing, what's subtly wrong.

Same with engineers. Debug enough systems, and you develop a sense. "This feels wrong." "Check the state management." "I bet it's a race condition."

That sense doesn't come from reading code. It comes from wrestling with code. From being stuck. From the 3am frustration that finally resolves into understanding.

AI skips the wrestling. Which means it skips the structure.

The uncomfortable truth:

You can't retrieve the structure from AI. You can only retrieve output. And output without structure is just text – plausible-looking, confident-sounding text that you have no way to evaluate, extend, or defend.

The Decay

Here's what nobody talks about: expertise doesn't just fail to grow. It actively erodes.

When you stop wrestling with details, the mental structures that let you evaluate outputs start to fade. Days without hands-on work, and your judgment gets fuzzy. Weeks, and the paradigms start dissolving.

Now combine that with a critical fact: LLMs are non-deterministic. Slightly different output every time. Same prompt, different result.

Without solid mental models to evaluate against, you're not directing the process. You're just accepting whatever the machine happens to produce. You're trailing behind the output, not leading it.

The orchestra metaphor:

AI evangelists love saying "you'll become a conductor, orchestrating AI outputs."

But a conductor who has never played an instrument makes a poor conductor. The baton means nothing without the years of practice behind it.

And if you replace all the musicians with AI, what exactly are you conducting?

The Procurement Manager Problem

We've seen this movie before.

It's called "outsourcing expertise."

Companies and public sector organizations are full of procurement managers who lost domain expertise years ago. They used to have engineers who understood what they were buying. Then they "optimized" those roles away.

Now they waste client and taxpayer money buying nonsense – because they can't evaluate what they're buying anymore.

They drift along the procurement process. RFP in, vendor out. Checkboxes checked. Nobody asks if the thing actually works, because nobody understands it well enough to ask.

Some don't even realize their work has become essentially corrupt – not in the bribery sense, but in the systemic failure sense. Process without understanding. Motion without progress.

It's irresponsible to claim we won't need programming skills in the future. We're not automating expertise. We're laundering its absence.

The Leak Waiting to Happen

Here's what's happening right now in thousands of companies:

• Employees paste confidential code into ChatGPT to "fix a bug"
• Managers feed strategic documents into Claude to "summarize"
• Executives connect Slack, email, and CRM to AI assistants for "automation"
• Developers push proprietary algorithms through Copilot

All of this data flows somewhere. Gets stored somewhere. Gets trained on – maybe.

The question nobody's asking:

What happens when one of these AI providers has a breach? Or a rogue employee? Or a subpoena?

Your "productivity boost" just became discovery material.

And here's the governance problem: shareholders have no idea this is happening.

No board approval. No risk assessment. No disclosure. Just thousands of employees individually deciding to feed company secrets into third-party AI systems – because it's "more productive."

When the exposure hits – and it will – nobody will be able to say they were informed. Because they weren't.

A Note to Executives

For managers and executives who don't write code:

Keep your fingers off the keyboard.

If you're hoping AI will do your thinking for you – or give you expert advice in domains where you're not an expert yourself – stop.

Here's what will happen:

• You will annoy everyone above and below you.
• You won't understand what you're producing.
• You'll put LLM-formatted documents in front of people, full of details you never wrestled with yourself.
• People will notice. They always do.

The result? Intellectual DDoS – up and down the org chart.

You lack the mental structures. You lack the paradigm. You're just dragging along behind the LLM process, pretending you understand.

What you CAN use it for:

This is the same way developers use AI – for tools you work with daily, where you understand the output and can verify it works.

Stay in your lane. Accelerate what you already know.

The Bottom Line

Summary

The senior engineer who uses AI as a tool will always beat the junior who lets AI drive.

Not because seniors are smarter. Because they have mental models that let them evaluate what AI produces. They can spot when it's wrong. They understand the system it's trying to modify.

The junior who prompts without understanding is building on sand.

The Real 10x Opportunity

Learn the fundamentals. Use AI to accelerate, not to replace understanding.

The 10x boost is real. But only if you know what you're boosting.

Books, independent work, deep understanding – AI doesn't replace any of that. It just makes the gap between those who understand and those who don't even wider.

The question isn't whether AI will change programming.

The question is: Will you be the one driving, or the monkey behind the controls?

"Those who don't understand systems are doomed to ship code they can't debug."