-05-01.png)
Erik Schulntz, a researcher at Anthropic focused on coding agents, is here to talk about a subject near and dear to his heart: vibe coding. If you've heard the term, you might associate it with engineers using AI tools like Cursor or Copilot for extensive code generation. But Eric, who remarkably had Claude write all his code for two months after breaking his hand, argues that's not quite the full picture.
True vibe coding, according to Andre Carpathy's definition, is when you "fully give into the vibes, embrace exponentials, and forget that the code even exists". The crucial part? "Forget the code even exists".
Initially, this concept brought excitement beyond the engineering world, allowing non-coders to suddenly build entire apps. It was revolutionary! However, this freedom came with downsides: people coding without knowing what they were doing, leading to issues like maxed-out API usage or bypassing subscriptions. The successful early cases of vibe coding were often low-stakes, like building video games or fun side projects where bugs were acceptable.
So, why bother with something that seems suited only for "toy examples"? The answer lies in the exponential growth of AI capabilities. The length of tasks AI can handle is doubling every seven months. While an AI generating an hour's worth of code might still allow for intimate human review today, what happens when it generates a day's or even a week's worth of work?
Eric emphasizes that to leverage this exponential growth, we cannot remain in "lockstep" with traditional review methods. We must find a way to "responsibly give into this".
Think about compilers. In their early days, developers might have scrutinized the assembly output to ensure it matched their manual coding. But that approach doesn't scale for complex systems. At some point, you simply have to trust the system.
The same applies to AI-generated code. The challenge for the software industry is: "how will we vibe code in prod and do it safely?". The answer, Eric proposes, is to "forget that the code exists but not that the product exists". Just as we build good software without understanding every line of assembly, we'll need to do the same with AI-generated code.
This isn't a new problem for the business world. Consider:
These problems, "as old as civilization," have solutions. A CTO can write acceptance tests, a PM can use the product, and a CEO can spot-check key facts. The key is to find an "abstraction layer that you can verify even without knowing the implementation underneath it". Software engineers, traditionally used to understanding the full depth of the stack, need to embrace letting go of some details to maximize productivity, much like managers do.
Currently, there's one significant caveat: tech debt. It's hard to measure or validate tech debt without directly reading the code, unlike other systems where verification is possible at a higher level.
So, how do we proceed? Eric's advice is to focus vibe coding on "leaf nodes" in your codebase. These are parts of the system that nothing else depends on—think end features or "bells and whistles". It's acceptable for these to have some tech debt because they're unlikely to change or have further things built upon them. The core architecture (the "trunks and underlying branches") still requires deep human understanding to ensure extensibility and flexibility. However, as models like Claude 4 improve, Eric anticipates we'll gain more trust in them to write extensible code with less tech debt.
The core advice for successful vibe coding is: "Ask not what Claude can do for you but what you can do for Claude". When you vibe code, you are essentially acting as a product manager for Claude.
This means:
Anthropic recently merged a 22,000-line change to their production reinforcement learning codebase, written heavily by Claude. How did they do this responsibly?
This allowed them to be as confident in the change as any other, but deliver it in a "tiny fraction of the time and effort". It also fundamentally changed their engineering mindset, making them willing to tackle much bigger features because the "marginal cost of software is lower".
This shift begs the question: how do we learn and become better engineers when AI handles so much of the low-level coding? While there's a valid concern about losing the "struggle in the grind", Eric is optimistic. He finds he learns much faster with AI tools. Claude acts as an "always there pair programmer," explaining libraries or design choices.
Furthermore, by collapsing the time it takes to implement large architectural changes (e.g., from two years to six months), engineers will be able to learn from four times as many lessons in the same calendar time, provided they put in the effort to understand.
The models aren't just getting better; they're getting better faster than we can possibly imagine. Just as computers evolved from kilobytes of RAM to terabytes over 20 years, AI capabilities will advance millions of times over.
It's okay not to vibe code today, but in a year or two, it will be a "huge disadvantage" if you insist on reading or writing every line of code yourself. You risk becoming the bottleneck, unable to leverage the powerful new wave of models. This is poised to be one of the biggest challenges—and opportunities—for the software engineering industry in the coming years.
By responsibly embracing vibe coding, focusing on verifiable abstraction layers, guiding AI like a product manager, and wisely choosing where to apply it, we can unlock unprecedented productivity and innovation in software development.
Watch Eric's full video here: