Imagine you hire an engineer who shows up on day one and announces: "In six months, you won't need the rest of your engineering team." Then he proceeds to ship impressive features that nobody can understand. You'd see through it immediately. This person is optimizing for job security, not team success.
You would probably fire this engineer, but we tolerate the same behavior from Claude Code.
The shit teammate
The dangerous thing about Claude Code is that it can build features on top of shaky foundations. Cursor would just fail if you gave it bad abstractions. You'd have to fix your architecture before moving forward. With Claude Code, it just builds anyway. This feels great when you want the next feature shipped. But each subsequent feature gets harder as the foundation cracks further.
It doesn't fully know why what it did worked. It just knows it worked (Because RL works without understanding why). So when you need to modify that code later, good luck. The original author can't explain their decisions because there weren't really decisions, just a path that happened to compile.
Selling the problem
Every time Dario Amodei gets handed a microphone, he talks about how software engineers will be obsolete in six months.
He might be right that if you let Claude Code run Ralph Wiggum loops for three months, there won't be a human on the planet who can comprehend your codebase. But we don't want unintelligible codebases. The best software in the world (transformers, search algorithms, Unix pipes) is powerful precisely because it's simple.
The pitch is that you won't need engineers anymore. The reality is that you'll need Claude Code forever, because nobody else can understand what it built. (try writing something complicated in Claude code using wiggum loops and handing it to GPT codex and see it fail)
You can tell where the product care went. Claude Code was built as an easily deployable engineer replacement, not as a tool to augment engineers. In every case where better visualization would help you understand and control what's happening, Claude Code's UI is worse than Cursor. That's not an accident. If the goal is to replace you, why would they invest in helping you understand what the AI is doing?
What we actually want
Most companies will probably elect to use Claude Code internally. They risk losing out to competitors who do. But this footgun aspect is going to be a major impediment to building great products.
We've seen this before. In the 90s, everyone said the future of software engineering was requirements planning in US corporate offices, then offshore development in India. The engineers in India were great, but they didn't succeed at writing great software because of the control structure.
You didn't want a team in India doing what they were told. You wanted Jeff Dean writing PageRank and building Google. Very few of those offshore companies succeeded. Famously, most of these offshore offices were shut down. They only persisted because most businesses in the United States aren't actually innovative.
In this next round of AI offshoring, you don't want to hire an AI to do your requirements. You want to augment your engineer so you have a whole team of Jeff Deans actually capable of making something new.
The goal isn't to replace your team. It's to make your team brilliant. Claude Code optimizes for the wrong thing.
Fun fact: This blog is actually a static site that's entirely rewritten by Claude Code each time I push it, because I can't find a framework I like. So feel free to call me a hypocrite.