Divers and CNC Machines: Yegge and Kim on What's Coming

Steve Yegge and Gene Kim, authors of Vibe Coding, recently gave a talk at AI Engineer Summit. Yegge’s been using Claude Code 14 hours a day. He still says it “ain’t it.”

Not because the technology is bad. Because developers aren’t adopting it.

The Power Tool Problem

Claude Code is very much like a drill or a saw. How much damage can you do as an untrained person with a drill? You can cut your foot off, but you can also be really skilled and do precision work like a craftsman.

— Steve Yegge

This is the adoption problem in a nutshell. Current coding agents reward skill. An experienced operator gets precision work. An untrained one burns context, fights hallucinations, and ships bugs. That’s fine for early adopters willing to invest hundreds of hours building intuition. It doesn’t scale to the average developer who just wants to ship features.

The cognitive overhead is too high. The tools “lie, cheat, and steal” (Yegge’s words for hallucination, context exhaustion, and unpredictable behavior). Most engineers try it for an hour, decide it’s useless, and go back to their IDE.

Saws to CNC Machines

Yegge’s prediction: 2026 is the year we move from power tools to CNC machines.

A CNC machine doesn’t give you a bigger drill. It straps a drill to coordinates and moves it precisely. You stop being the operator and start being the programmer.

All code within a year, year and a half will be written by giant grinding machines overseen by engineers who no longer actually look at the code directly anymore.

— Steve Yegge

This is a bold claim. But the direction is clear: the future isn’t better individual agents. It’s orchestrated systems of agents.

The Diver Metaphor

Yegge’s best insight from the talk: your context window is an oxygen tank.

Current tools send one diver down into your codebase. We keep giving that diver bigger tanks: 100k tokens, 200k, a million. But a single diver still runs out of oxygen. The codebase is too big, the task too complex.

You should send a product manager diver down first, then a coding diver, then a review diver and a test diver and a git merge diver. Nobody’s doing this. Everyone’s building a bigger diver.

— Steve Yegge

This is the “world’s biggest ant” problem. Nature builds ant swarms. We’re building one muscular ant that bites you in half and takes all your resources. Every message goes to the expensive model, whether you’re analyzing a codebase or checking if your gitignore file exists.

The solution is task decomposition: specialized agents for specialized tasks, orchestrated by something that understands the workflow. Not one giant context window trying to hold everything.

The Resistance Is Real

At OpenAI, some engineers use Codex and some don’t. The productivity difference is “so staggering” that alarms are going off at performance review time. How do you compare two engineers at the same level when one produces 10x the output?

Yegge’s answer: they’re freaking out and may have to fire 50% of their engineers.

Who’s refusing to adopt? Senior and staff engineers.

This is just like what happened to the Swiss mechanical watch industry. The craftsmen were doing the same thing our staff engineers are doing today. ‘No cheap.’ That’s word for word what they say.

— Steve Yegge

The parallel is uncomfortable. Swiss watchmaking was built over centuries and killed by quartz in a few years. The craftsmen’s objection wasn’t technical. It was identity. Their value was in the craft itself, not the outcome.

60% of Your Org

Yegge showed a LinkedIn post from Jordan Hubbard (Nvidia) sharing tips on getting the most out of coding agents. One reply dismissed it as “a serious step backwards.”

This is 60% of your org right here. This guy’s not an outlier. The backlash is very real.

— Steve Yegge

This isn’t a fringe opinion. It’s the majority position in most engineering orgs. And it creates an awkward dynamic: the people with the most institutional knowledge, the most seniority, the most influence over architecture decisions are the same people refusing to adopt tools that could multiply their impact.

The productivity gap compounds. Engineers who adopt early keep getting better. Engineers who dismiss it stay where they are. Six months later, the gap is too large to bridge casually. A year later, it’s a career problem.

Kim’s data from the DORA research confirms this: trust in AI correlates linearly with time spent using it. The engineers calling it “terrible” made that judgment after an hour. The engineers calling it transformative invested hundreds of hours. Both are describing their actual experience. But only one group kept going.

FAFO: Why It Matters Anyway

Gene Kim introduced their acronym for why vibe coding matters despite the resistance:

• Faster: Obvious but superficial. Speed is the least interesting benefit.
• Ambitious: The impossible becomes possible. The tedious becomes free. The Claude Code team fixes customer issues in 30 minutes instead of grooming Jira backlogs.
• Alone/Autonomous: No more waiting for developers to “get in line.” Anyone frustrated by quarters-long backlogs can now vibe code features into production themselves.
• Fun: “Steve says vibe coding is addictive. I force myself to go to sleep at night because otherwise I’d be up till 2 or 3 in the morning.” I feel this one. I’m doing 12-16 hour days, 7 days a week, and can’t stop. It’s a problem.
• Optionality: More swings at bat, more parallel experiments. Option value compounds.

The first point (speed) is what skeptics argue about. The other four are what converts people.

Trust Grows With Time

Kim shared an unpublished finding from the DORA research: trust in AI increases linearly with time spent using it.

Every person who says ‘I tried it and it’s terrible at coding’ - on what basis did they make that conclusion after maybe using it for an hour or two?

— Gene Kim

The skill curve is real. The 10,000 hours rule applies. Most people haven’t even started climbing.

This explains the adoption gap. Early adopters invested hundreds of hours building intuition. They know when to trust the output, when to push back, how to structure prompts, how to recover from failures. Skeptics tried it once, got burned, and concluded it doesn’t work.

Case Studies

Kim shared several examples that hint at where this is going:

• Booking.com: Double-digit productivity increase across 3,000 developers
• Travelopia: Legacy app replaced in 6 weeks. Before: team of 8 needed. Now: maybe 2.
• Fidelity: A director spent 5 days vibe coding an app his team said would take 5 months. Senior engineers refused to maintain it. The most junior engineer on the team took over and is now “probably outearning everybody.”
• Cisco Security: 100 top leaders required to vibe code one feature into production last quarter. Kim’s prediction: parts of that organization will reshape as leaders realize what’s possible.

The Fidelity example is the most telling. A leader bypassed his own team, shipped in days instead of months, and the junior engineer who embraced it is now the one delivering value.

The Hot Take

If you’re using an IDE starting January 1st, you’re a bad engineer.

— Steve Yegge

That’s deliberately provocative. But the underlying point is serious: the tools are changing faster than adoption, and the gap is widening. Engineers who refuse to adapt are making a career bet that the technology won’t improve. History suggests that’s a bad bet.

The talk captures something important: current AI coding tools are powerful but inaccessible. They reward skill investment that most developers haven’t made. The next generation of tools needs to lower that barrier, not just expand context windows.

Divers with bigger tanks aren’t the answer. Orchestrated swarms are.