claude-codeai-agentssetup

Why Claude Writes Bad Code (and How to Fix Your Setup)

·Terrell Gentry·7 min read
Why Claude Writes Bad Code (and How to Fix Your Setup)

You told Claude to build one feature, and it rewrote three files you didn't ask about, invented a function that doesn't exist, and burned through your credits doing it. Now you're staring at a broken codebase wondering if AI coding is just hype. Before you quit: the problem is almost never the model.

Quick answer: Claude writes bad code mostly because of a broken setup, not a broken model. Give it a CLAUDE.md with your rules, keep context clean, use plan mode before it edits, and force a verification loop that runs tests. Do that and Claude stops handing you code you have to fix.

Why does Claude write bad code?

Because you're throwing prompts at a powerful model with none of the guardrails it needs to be reliable. Reddit and MEXC threads describe Claude Code as "a roulette wheel of disappointment," burning credits on output that breaks. Shawn on dev.to put it plainly: "if you just throw prompts at Claude and accept the first output, you'll waste hours fixing hallucinations."

That's not a model failure. That's a setup failure. A capable agent with no project rules, a bloated context window, and no way to check its own work will confidently produce garbage, the same way a brilliant new hire would if you gave them zero onboarding and no access to your test suite.

The fix pattern comes from builder iwoszapar: build the rails, then let the agent run. Rails first. Then speed.

Claude Code not working? Start with these four failure points

Nine times out of ten, broken Claude output traces to one of four missing pieces. Here they are, in the order they cause the most damage.

1. No CLAUDE.md file

CLAUDE.md is a plain-text file at the root of your project that tells Claude how your codebase works: the stack, the conventions, what to never touch, how to run tests. Without it, Claude guesses, and guessing is where hallucinated functions and rogue refactors come from.

A minimal one looks like this:

# Project rules
- Stack: Next.js 14, TypeScript, Tailwind. Do NOT add new dependencies without asking.
- Tests: run `npm test` before claiming a task is done.
- Never edit files in /legacy without explicit instruction.
- Match existing code style. Do not reformat unrelated lines.

That file is the single highest-leverage fix on this list. It turns "guess what I want" into "follow these rules." If you're setting Claude Code up for the first time, our Claude Code setup guide for business walks through the full install click by click.

2. Dumped, bloated context

Claude gets worse as its context window fills with irrelevant history. If you've been chatting in one long session, pasting whole files it didn't need, and never clearing, it's now reasoning over noise. Quality drops and hallucinations rise.

The fix: keep sessions tight and scoped to one task. Use /clear to reset between unrelated jobs. Point Claude at specific files instead of dumping your whole repo into the prompt. A clean context is a sharp Claude.

3. No plan mode

Letting Claude edit files immediately is how you end up with three rewritten files you never asked about. Plan mode makes Claude propose what it intends to do before it touches anything. You approve the plan, then it executes.

In Claude Code, you enter plan mode and Claude returns a step-by-step approach for review. You catch the "I'll refactor your auth system" surprise while it's still a sentence, not a git diff. This one habit prevents most codebase disasters.

4. No verification loop

This is the difference between an agent that hands you work and an agent you have to babysit. A verification loop means Claude runs the tests, checks the output, and fixes its own mistakes before handing anything back, instead of you being the quality check.

The mechanism is simple: tell Claude in CLAUDE.md and in your prompt to run the test suite and report results after every change. When a test fails, it iterates. You review a working result, not a first draft.

The manual way vs the rails way

Here's the same task, "add a rate limiter to the login endpoint," run two ways.

StepNo setup (roulette)Rails-first setup
RulesNone. Claude guesses your stack.CLAUDE.md states stack, conventions, test command.
ContextWhole repo dumped in one long chat.Scoped to auth files, fresh session.
ExecutionEdits files instantly, touches unrelated code.Plan mode: proposes steps, you approve.
CheckingYou read every line, find the bug.Claude runs npm test, fixes failures, then reports.
Your roleFull-time quality check.Reviewer of a working result.

The rails setup takes ten extra minutes up front. It saves the hours Shawn warned about, and the credits you'd otherwise burn on retries.

Common pitfalls that still trip people up

Even with rails in place, a few habits keep the roulette wheel spinning:

  • Vague prompts. "Fix the bug" gives Claude nothing to aim at. Name the file, the expected behavior, and how you'll verify it.
  • A stale CLAUDE.md. If your stack changed and the file didn't, Claude follows outdated rules confidently. Update it like any other source of truth.
  • Skipping plan mode "just this once." That's usually the once it rewrites something load-bearing.
  • No tests to verify against. A verification loop needs something to check. Even a handful of tests on your critical paths beats none.
  • Blaming the model after one bad run. Adjust the rails, not your opinion of AI. The same setup that produced garbage often produces clean code once the context is scoped and the plan is approved.

This is the exact shift behind the value prop we build the whole Claude Community around: with the right setup, you stop being the quality check. If you want the same rails-first discipline applied to non-coding work, 10 copy-paste Claude Code automations shows the pattern for real business workflows.

FAQ

Why does Claude keep writing code that doesn't work?

Usually because it's missing a CLAUDE.md with your project rules and has no verification loop to catch its own errors. Add both and most "doesn't work" output disappears. Claude follows your conventions and runs the tests before handing anything back.

Is Claude Code not working a model problem or a setup problem?

Almost always a setup problem. A model that can pass hard coding benchmarks doesn't suddenly forget how to code, but it does hallucinate when given a bloated context, no rules, and no way to check its work. Fix the setup before blaming the model.

How do I stop Claude from rewriting files I didn't ask about?

Use plan mode so Claude proposes its changes before editing, and add a line to CLAUDE.md telling it not to touch unrelated files or reformat lines outside the task. Approve the plan, and rogue refactors stop.

Does a better model like Sonnet 5 fix bad code output?

A stronger model helps, but it won't rescue a broken setup. Sonnet 5 launched with introductory pricing of $2/M input and $10/M output through August 31, 2026, which improves the economics of text-heavy agent work. Rules, clean context, and a verification loop still do the heavy lifting on code quality.

The fastest way to stop fighting broken output is to learn the rails-first setup from builders who've shipped it across 100+ agent systems. Join the free Claude Community and run through the Claude Masterclass to set Claude Code up the right way from day one.

About Terrell Gentry

Founder at 6omb

Terrell is the founder of 6omb and runs Claude Community, the #1 Skool community for Voice AI agents. Over 16 months his team has built 100+ AI agent systems delivering $10M+ in business value, including voice agents like Emily, which booked 453 new clients for a law firm in 8 months. He is a Y Combinator Startup School alum (SUS20) and a Gold Retell partner.

AI AgentsClaude CodeVoice AIBusiness AutomationGrowth Marketing

Join 10k+ founders going AI-first with Claude

The Claude Masterclass, 50+ copy-paste Claude Code skills, agent-building workshops, and a community actively building the same thing you are. Free for now.

Join the free community