Anthropic researcher Erik Schluntz (co-author of "Building Effective Agents") once spent two months in a cast after breaking his hand, which forced him to hand all of his coding work over to Claude. That experience led him to a methodology for vibe coding responsibly in production. Developers on X have called it "better than 100 paid courses".

What Real Vibe Coding Is

Many people equate generating code with Cursor or Copilot to vibe coding. Schluntz doesn't think that's accurate. As long as you are still reviewing and editing AI-generated code line by line, it isn't vibe coding.

Karpathy's definition is more precise: give yourself over to the vibes, embrace the exponentials of the technology, and completely forget that the code exists.

It means going from "the person who writes the code" to "the product manager who manages the AI".

Why Embrace the Exponentials

The length of tasks AI can handle independently roughly doubles every 7 months. Today, AI can reliably finish a 1-hour coding task, and you still have the energy to review line by line. Next year, when AI generates the equivalent of 1 day or even 1 week of work in a single pass, line-by-line review will become impossible.

It's like the history of compilers: early developers didn't trust compilers and would inspect the assembly output. As systems grew, they had to learn to trust higher levels of abstraction.

The Core Method: Find a Verifiable Abstraction Layer

The core idea of vibe coding: forget that the code exists, but never stop paying attention to the product's existence.

A CTO governs technical experts through acceptance tests, a product manager validates feature design through the experience, a CEO audits the finances through data slices. None of them reads the underlying details. Software engineers need to build similar abstraction layers that can be verified without reading code.

The "Leaf Node" Strategy

End-of-chain features or add-ons in a codebase that no other module depends on are "leaf nodes". In these areas, taking on technical debt is acceptable, because they rarely change. But for the system's trunk and underlying architecture, engineers still need to understand them deeply and defend them rigorously.

In Practice: Be the AI's Product Manager

Onboard the AI the way you would a new hire on day one. Throwing "implement this feature" at it is guaranteed to fail.

The Standard Up-Front Workflow

Before letting Claude write any code, Schluntz spends 15-20 minutes on the following:

1. Have the AI explore the codebase and locate the relevant files
2. Work out a clear execution plan together with the AI
3. Pour all of the context and specifications into a single prompt
4. Only then let Claude execute

Under this workflow, the task success rate improves exponentially.

The 22000-Line Extreme Case

Anthropic recently merged a 22000-line code change into the production environment of its reinforcement learning codebase, the vast majority of it written by Claude. Four core strategies:

1. Deep, product-manager-style onboarding: days spent on up-front planning and requirements sorting
2. Tightly scoped changes: restricted to leaf nodes where technical debt is acceptable
3. Human involvement in core areas: strict human review of core logic
4. Verifiable checkpoints: long-duration stress tests designed to ensure the system has clear input/output criteria

Work that would normally take two weeks was compressed into under 1 day.

Advanced Tips

On Test-Driven Development (TDD)

TDD is extremely useful in vibe coding. Even if you can't read the test code, it helps Claude stay more self-consistent. Just beware that Claude tends to write tests that depend too heavily on the specific implementation.

Recommended approach: Force Claude to write only 3 end-to-end tests -- the happy path plus two error scenarios. As Schluntz put it: "When vibe coding, the tests are usually the only code I look at. If the tests pass, I consider it solid."

On Context Management

Whenever you hit a pause point where "a human programmer would stop for lunch", run a context compaction (Compact).

Recommended opener: First have Claude find all the relevant files and draw up a plan, write all of that into a document, then compact right away. This compresses the 100,000 tokens spent on planning into just a few thousand clean tokens.

On Multi-Tool Collaboration

Schluntz uses Claude Code and VS Code/Cursor side by side:

• Claude Code: handles the major changes and the big tasks
• VS Code/Cursor: for reviewing code on the go, or making precise small edits

When facing an unfamiliar codebase, have Claude explore it for you first: "Where is the code that handles auth?" "Which features are similar to this one?" Build a global picture before you start.