# Vibe Coding in Production: How Anthropic Uses AI to Write Code

- Channel: [viki virgon1](https://www.youtube.com/channel/UCYO77OIrfJjh9vp8pC2EZHg)
- Published: 2026-04-20
- Source video: [Watch on YouTube](https://youtube.com/watch?v=78EYLieMpvc)
- Read on ReadTube: https://www.read.tube/p/videos/78EYLieMpvc
- Language: Original (source language)

## Summary

**Vibe Coding in Production Safely**

Vibe coding involves leveraging AI models to generate entire features while shifting the developer's role from writing code to acting as a high-level product manager. By focusing AI efforts on isolated leaf nodes and designing robust verification methods, engineers can responsibly accelerate development while maintaining system stability despite the inherent risks of not directly reviewing every line of code.

Vibe coding represents a shift where engineers leverage AI to handle significant portions of code generation, often operating at a level of abstraction that requires trusting the AI's output without manual line-by-line verification. The core philosophy is to embrace the exponential growth in AI capability, accepting that as task complexity and scope increase, keeping up in lockstep with the code becomes unsustainable. To apply this effectively in production, consider these strategies:

- Act as a product manager for the AI by providing clear requirements, constraints, and context.
- Focus vibe coding efforts on isolated leaf nodes where tech debt poses minimal risk to the core architecture.
- Prioritize systems that are verifiable through acceptance tests and input-output monitoring rather than code inspection.
- Maintain deep human understanding of the core codebase trunks to ensure long-term architectural stability.
- Use iterative planning, such as creating comprehensive project briefs, to keep the AI aligned and prevent it from drifting.

## Article

#### Introduction to Vibe Coding in Production

Welcome. I am here to talk about everyone's favorite subject, vibe coding, and somewhat controversially, how to vibe code in production responsibly. First of all, I am Eric, a researcher at Anthropic focused on coding agents. I was the author, along with Barry Zang, of "Building Effective Agents," where we outlined our best science and practices for creating agents. This subject is near and dear to my heart. Last year, I broke my hand while biking to work and was in a cast for two months; Claude wrote all of my code for those two months. Figuring out how to make this happen effectively was really important to me.

#### What is Vibe Coding?

A lot of people conflate vibe coding with just extensive use of AI to generate code, but I think this is not quite true. People using Cursor or Copilot are using a lot of AI, but when you are in a tight feedback loop with the model, that isn't truly vibe coding. As per Andre Karpathy's definition, vibe coding is where you fully give into the vibes, embrace exponentials, and forget that the code even exists. The key part here is forgetting the code exists. This was a massive unlock for people outside the engineering industry—someone who didn't know how to code could suddenly find themselves coding an entire app by themselves. 

However, there were downsides: people coding without knowing what they were doing, maxing out API keys, or creating random entries in databases. The positive examples were largely low-stakes side projects or games. So, why care about vibe coding for real products?

#### The Importance of Exponentials

The length of tasks that AI can perform is doubling every seven months. Right now, we are at about an hour of work. You don't need to vibe code for an hour-long task; you can have Cursor or Claude assist while you remain intimately involved. But what happens next year or the year after? When AI generates an entire day's or week's worth of work at once, we cannot keep up if we must move in lockstep. We must find a way to responsibly leverage this. 

My favorite analogy is compilers. In the early days, developers didn't trust them and would read the output assembly. Eventually, systems became too large to do that, and we just had to trust the system. My challenge to the software industry is to learn how to vibe code in production safely—by forgetting that the code exists, but not that the product exists.

#### Managing Technical Debt and Responsibility

This is not a new problem; how does a CTO manage an expert in a domain where they are not an expert? How does a PM review an engineering feature they can't read? How does a CEO check an accountant's work? We have solutions for this:

*   **Acceptance Tests:** A CTO can write tests for an expert even if they don't understand the implementation.
*   **Product Validation:** A PM can use the product to ensure it works as expected.
*   **Spot Checking:** A CEO can check key data slices to build confidence in financial models.

We must move away from the expectation of understanding the full depth of the stack. However, there is one caveat: **tech debt**. There is currently no good way to validate tech debt without reading the code. Therefore, we must be smart and target our use of vibe coding.

#### Targeted Vibe Coding: Leaf Nodes

I recommend focusing on **leaf nodes**—parts of the codebase where nothing depends on them, such as end features or bells and whistles. 

| System Component | Strategy |
| :--- | :--- |
| **Leaf Nodes** | Vibe code; tech debt is acceptable here as they are unlikely to change. |
| **Trunks/Branches** | Core architecture; must be deeply understood by engineers to ensure extensibility. |

#### How to Succeed: Be the PM

When vibe coding, you are basically acting as a product manager for Claude. Ask not what Claude can do for you, but what you can do for Claude:

1.  **Provide Context:** Give it a tour of the codebase, requirements, and constraints.
2.  **Pre-planning:** I often spend 15–20 minutes collecting guidance into a single prompt. I treat this as a separate conversation to build a plan, then let Claude execute it.
3.  **Ask the Right Questions:** If you are fully non-technical, you may not be able to guide the model effectively.

#### Case Study: A 22,000-Line Change

We recently merged a 22,000-line change to our production reinforcement learning codebase, written heavily by Claude. How did we do it? 

*   We embraced our roles as product managers.
*   The change was concentrated in leaf nodes.
*   We performed heavy human review on extensible parts.
*   We designed stress tests for stability and verified inputs/outputs to ensure correctness.

This saved us a significant amount of time and allowed us to think differently about our engineering velocity. Things that would have taken two weeks now take a day.

#### Closing Thoughts

1.  **Be Claude's PM.**
2.  **Focus on leaf nodes,** not core architecture.
3.  **Prioritize verifiability** without reading the code.
4.  **Remember the exponential.** If you demand to write or read every single line of code, you will become the bottleneck as models continue to advance.

This is going to become one of the biggest challenges for the software engineering industry over the next few years.