There's a specific kind of frustration I see a lot from developers using Claude for real projects.
Not "the AI wrote broken code." The code works fine, at least at first.
The problem is: three weeks later, you can't touch it.
Functions are 200 lines long. State is managed in three different ways in the same file. There's no clear separation between business logic and UI. You ask Claude to add one small feature and it rewrites half the component, breaking two things to fix one.
This isn't a prompt quality problem. It's a structural problem — and it comes from how most people use Claude by default.
The speed trap
When you're moving fast with AI assistance, the feedback loop feels incredible. You describe what you want. You get working code. You ship it. You describe the next thing.
The problem is you're not accumulating clarity — you're accumulating complexity. Every session adds a new layer. Claude doesn't have a global view of your project architecture. It fills in gaps based on what it can see in the current context window.
Over time, the codebase starts to look like it was written by a dozen different developers, none of whom talked to each other.
The false confidence problem
Here's what makes this worse: it works.
You run it. It does the thing. Tests pass (if you wrote any). You move on.
What you don't see is that:
- The abstraction level is inconsistent
- There are implicit dependencies between modules that nobody documented
- The "state" for a feature lives in three places
- The naming conventions shifted partway through and nobody reconciled them
Claude will happily build on top of all of this and make it worse.
What actually helps
The shift that made the biggest difference for me wasn't better prompts. It was treating each Claude session with the same discipline I'd apply to working with a capable-but-new contractor.
Specifically:
1. Give Claude an explicit scope boundary before starting.
Not "add user authentication" but "we're adding auth to the user module only — here's the current structure, here are the interfaces we're using, don't touch the data layer."
2. Break work into verification checkpoints.
Don't hand Claude a 2-hour task and come back to review. Decompose into smaller pieces where you can check the output before it becomes load-bearing.
3. Write the structure before you write the feature.
If Claude is about to create a new module, have it write the interface/contract first and get that right before any implementation. It's much easier to fix a bad interface before there's code depending on it.
4. Treat "refactor this" as a high-risk request.
Claude refactors aggressively and correctly-looking. But correctness and equivalence aren't the same thing. If you're not carefully reviewing refactors, you're accumulating silent semantic drift.
5. Reset context intentionally.
If your session has gotten long and tangled, starting a new one with a clean summary of where things are is usually better than trying to steer a confused long conversation.
The thing nobody says out loud
A lot of "Claude got worse" complaints I've seen recently are actually "my project structure accumulated enough debt that Claude can no longer navigate it without making things worse."
That's not a model problem. That's a workflow problem. And it's fixable — but it requires being intentional about how you work with AI tools, not just what you ask them to do.
One more thing
I put together a free starter pack specifically for builders who want to use Claude to ship real projects without the codebase becoming a maintenance nightmare: Ship With Claude — Starter Pack
It covers workflow structure, prompt templates, and a shipping checklist — the things that are hard to find because everyone writes about prompts but not about the layer underneath them. It's free ($0), no upsell required to get value from it.
Happy to dig into any of this in the comments — especially if you've found patterns that work or patterns that reliably blow up.
Top comments (0)