How Anthropic Solves the Problem of Technical Debt from AI-Assisted Coding

Erik Schluntz, a researcher at Anthropic, and his team recently shipped 22,000 lines of code to their production codebase in just two days. That kind of work used to take a full development team two weeks. Now a small group of researchers can do it alone. Erik is quick to point out that this kind of speed is only the beginning of the "vibecoding" era, where engineers stop writing code line by line and instead hand tasks off to AI code editors.

But what happens when AI accidentally deletes everything or builds a faulty architecture? A developer at AI Shipping Labs found out the hard way: he let an AI agent handle data migration. As a result, Claude wiped the entire database. It's one thing if you can restore a backup, but it's another if the agent tries to cover up its mistake. The Jason Lemkin and Replit incident, where an AI agent ignored instructions and attempted to hide what it had done wrong, has only deepened public distrust of these tools.

Erik admits hallucinations are a real problem, but he doesn't think they're any scarier than the mistakes a junior developer or intern might make. In this piece, we'll look at how Anthropic manages the technical debt that comes with AI-assisted development, and the practices Erik recommends for shipping AI-generated code without wrecking your architecture or sacrificing stability.

Rethinking code review

The pace of AI-assisted development keeps accelerating. Erik estimates that AI cuts roughly an hour off each of his team's tasks. That raises an obvious question: what happens once AI can do a week's worth of work in a few hours or even minutes?

Code review itself isn't a new problem, but it looks very different now. A tech lead can stress-test a junior engineer's code and gauge its quality. Even a product manager with no coding background can assess whether a new feature works as intended.

Erik draws a comparison to the rise of compilers. As compilers took over, developers wrote less and less assembly, even though everyone knew assembly was the foundation the whole system was built on. While veteran engineers and professors complained that the new generation didn't understand "real" development, compilers had fully replaced the old way of working.

Erik expects the volume of AI-generated code to explode over the next year, making trust in AI editors less of a choice and more of a necessity. Eventually, people will forget what it was like to write code by hand. But they won't forget that the product still has to be functional.

Another problem is figuring out how to track and validate the technical debt piling up from vibecoding. Right now, there's no reliable way to do it.

The "leaf nodes" strategy

Handing an entire architecture over to an artificial intelligence network is both risky and impractical. It's going to be difficult to scale, and the pitfalls buried inside it are hard to spot. Any experienced developer looking at fully AI-generated architecture will just laugh.

That's why Anthropic doesn't let AI get involved in routing, the database, or the server core. Instead, AI is used to build new features on the frontend. Erik calls this approach "leaf nodes." Technical debt in a node doesn't threaten the core product. If the AI breaks something, say, a download button, that failure stays contained instead of causing the whole application to go down.

Erik thinks that the task of architecture building still belongs to human engineers. However, he expects that, as AI tools mature, they'll be trusted with more responsibility over time.

This approach works well for large companies and for fairly typical tasks. But at mid-sized startups, small issues compound fast, and messy AI-generated code can shut down an entire platform. It rarely uses lazy loading and often produces monolithic 3,000-line functions with no real structure. A service that can handle five users fine might start falling apart at fifty.

Thinking like a product manager

We tend to treat AI as if it already understands the full context of our codebase, like a colleague who's been there since day one. But even with a paid subscription, AI is still, at best, a very sharp junior developer with access to the world's knowledge.

That's why, before making any request, Anthropic spends 10–15 minutes walking through the task in detail and identifying where the AI is likely to get things wrong. The rule of thumb: think through the potential failure points yourself before you even hand the task off to the model.

This "product manager" mindset is what lets Erik ship 22,000 lines of code without worrying about runaway technical debt. On top of that, he relies on stress testing. He writes three end-to-end tests for every implementation: one ideal-path scenario, and two that simulate failure. With this safety net in place, Erik trusts his test suite enough that he doesn't lose sleep over hidden technical debt.

So what's the point of vibecoding if it requires this much upfront thought? Isn't the whole appeal supposed to be typing one prompt and getting a finished product? The truth is, most real products start as a problem to solve, not a fully written spec.

Without domain expertise and the right tools, you end up completely dependent on whatever the AI happens to know. What Erik is really describing with his 22,000-line, two-day sprint isn't the fantasy version of vibecoding where you build a complex B2B SaaS product in an hour. It's what he calls "vibe engineering": a discipline where the simple, hands-off methods stop working. Relaxed, frictionless vibecoding was always a myth. What Erik describes is still a demanding process: one that speeds things up, but never replaces expertise.