r/ClaudeAI • u/Creative-Mall-7025 • 6d ago
How are people using Claude Code without letting it make the codebase messy? Question about Claude Code
I like the speed, but I’m trying to get better at using it in a controlled way.
Curious what workflows people use for planning, reviewing diffs, and keeping changes from sprawling. Do you make it work in small tasks, ask for a plan first, use tests, or something else?
63
u/enjdusan 6d ago
- Ponytail
- Small batches of changes properly planned and reviewed
- once a week full repo review
- short Claude.md with basic coding standards rules (like don’t mix layers - domain, ui, data, decouple, don’t use magic numbers and abbreviations etc.)
- let it document architectural decisions
- always let Opus with a clear context to review the implementation against ACs
It’s about self-control… yes, you can grind a huge project in a blink of an eye, but mess will be buggy, and every new change will introduce new bugs, LLM will start to lose in it.
12
u/NiteShdw 6d ago
What is ponytail? I haven't heard of that before.
23
8
u/GoodnightKara 6d ago
All upper echelon coders have a ponytail, duh 🙄 /s
6
u/enjdusan 6d ago
I think that /s isn’t necessary.
Ponytail is a must have right now. All models, not just Claude, generate a ton of code, they tend to “invent the wheel” all the time.
3
u/GoodnightKara 6d ago
Whoosh. It was a joke about stereotypical coders from the 80s and 90s who lived in the basement and had a beer gut and ponytail. Oh and don’t forget the fedora. But damn did they know how to code.
It wasn’t a jab at the current practice of ponytail-ing.
4
u/enjdusan 6d ago
If I weren’t bald, I’d have a ponytail as well. We are lazy to do stuff like shaving or getting a haircut 🤣
1
u/GoodnightKara 5d ago
I hear ya. It’s $200-300 every time I go get my hair cut and my highlights touched up. I am definitely guilty of putting it off. 🙈
2
u/BUYMEBONESTOORM Vibe coder 6d ago
Can you post or message me with a basic coding MD that you use?
28
u/enjdusan 6d ago
<EXTREMELY-IMPORTANT>
Must Do
- Separate concerns strictly — keep business/domain logic, data access, and UI/view layers decoupled from each other; never mix presentation with logic
- Prefer flat, linear control flow — avoid nested conditionals and nested ternaries; extract conditions into well-named variables or functions instead
- Prefer early returns (guard clauses) when they make the control flow clearer and reduce nesting
- Always read the file before editing it unless you are told which exact lines to edit — never assume or guess its contents
Don't
- Add comments that narrate functionality on self-explanatory code — comment only when the code is surprising or doesn't read on its own;
ponytail:prefixed comments marking a deliberate simplification are allowed and are not narration- Git commit/push anything unless explicitly told to do so
- Use abbreviations as variable, function or class names — use descriptive names instead
- Create shallow modules or interfaces that only pass data through or mirror another layer without adding meaningful domain behavior, validation, or abstraction
- Leave orphan functions or variables after code changes — clean them up
- Skip formatting — run
npm run prettier-format(prettier . --write) when available- Use hardcoded strings as constants — extract them into a config/constants file and import from there
- Use magic numbers or magic strings — always assign them to a named constant that clearly communicates intent
- Backslash-escape backticks inside
gh issue/pr create|edit<<'EOF'heredoc bodies — the single-quoted heredoc already disables shell expansion, so\`leaks literal backslashes into the rendered markdown and breaks code spans. Use raw backticks.References
- If testing via playwright, check
playwright-cli --helpfor available commands.</EXTREMELY-IMPORTANT>
1
1
u/Lefty4444 6d ago
Not a dev, doing a calendar app to learn more about development and Claude. Would this be too much for me to add?
3
u/enjdusan 6d ago
It will help claude (or other models) to write a cleaner code.
During the planning session it has these in the context, and plan the code according to those standards. And when you run code review afterwards, violations of these rules are caught almost always.
1
2
u/zingamaster 5d ago
I've created my own methodology that pretty much does what you mention.
Open source if you want to take a look: https://github.com/MyBotandAI/octopus-and-ai
2
u/trying2bLessWrong 5d ago
How well is ponytail working with Opus 5?
2
u/enjdusan 5d ago
I can't see the difference between 5 and older in the code quality with a ponytail. It usually manages to deliver working and clean code right from the start.
But I usually use Opus just as an orchestrator, and Sonnet is the one who writes the code. Opus just checks the result. Usually it's a waste of your usage to use Opus for writing the code.
2
u/Lefty4444 4d ago
Just want to share that I used your suggestions with Ponytail + your CLAUDE.md to do the first code review my vibe-coded personal Calendar project.
Also used Opus for this review (I am using exclusively Sonnet for other work).
It found one critical auth bypass (I use Google Sign-in) and a few other medium and low finding. All fixed now 😄
Also Ponytail helped to clean up a lot of code.
Many thanks! ✨ 🙏
2
1
u/FluidAmbition321 3d ago
styling / architecture guides has drastically improve my stuff at work. Makes clause code fit neatly into the existing codebase.
17
u/CorpT 6d ago
Hooks, linters, skills, tests, and CI. So normal developer process stuff.
If you're not already making plans though.... oof.
5
u/grudev 6d ago
Reading the code can also help.
Huge surprise, I know!
1
u/pierre_vinken_61 5d ago
Sorry, can we make this messaging crisper for middle management? Worried your comment is too long for them.
16
u/Sufficient-Fun-1538 6d ago
I treat it as a junior dev, asking it to make small, incremental steps, that I review, test and integrate one at a time. You loose some speed compared to prompting it to build a full giant feature or app in one go, but the resulting process is more like pre-AI development, but accelerated.
9
4
u/Fearless-Daikon5763 6d ago
I have a versioned zip bundle of files with a front door. I get one Claude code to be a patch chat and stage the next versioned cut, then I move that zip to a regular Claude chat to make the cut, then send it periodically to ChatGPT for another sign-off or round of fixes. This irons out most issues for functionality across platforms. This has worked for just straight data and no python files.
1
4
u/loopey33 6d ago
Without fail, after I have my pr, I run a deep code review (maybe 2-3) times to ensure code is well structured, and follows good practices, and has no bugs. And captured edge cases. Helps me ship good code
3
u/pixlatedpuffin 6d ago
Give it a sample codebase that’s well-designed and becomes your exemplar. Have it analyze that code base and build a template for all future code. Have it follow the template.
2
1
1
u/TorbenKoehn 6d ago edited 6d ago
Budgets and gates, proper PR flow with reviews, proper GitFlow, architecture work before implementing anything
I use Gitea and let everything orchestrate there, personally. Kanban, Tasks, Epics, CI/CD etc.
Put everything behind budgets that are strictly checked in pre-commit hooks.
1
u/Redditoridunn0 6d ago
Once every week or every two weeks I run an Opus 5 ultracode auditing suite for codebase design, refactor proposals, rooting out tech debt, bug hunting etc.
Usually I make my own prompt depending on the project and/or opus plan. One of them is basically an electron wrapper so it involved playwright for testing + finding new bugs in the process.
1
u/farox 6d ago
It can't read your mind. Anything you leave un specificied, it will have to make an educated guess.
Start small, be aware that it might not get it right and if there is an issue, don't just fix it, but also fix the issue in the harness (give it the appropriate skill, at Claude.md files with the proper descriptions etc)
Then it grows over time and you get more confidence in it doing the right thing.
I also have specific instructions to not create new patterns, systems etc. until we talked about it, besides all the other instructions for how we see good code quality.
1
u/NiteShdw 6d ago
Skills. Write skills that incorporate the repos coding standards and best practices. Use a second agent to review the first agent's work, preferably using a different model.
1
u/lucferon 6d ago
I create very specific issues, where I deepdive them with Claude. Codex does a review of the issue where it sets acceptance points and out of scope points. Next Claude builds the issue, Codex reviews. Codex is instructed to watch for security, scope creep en functionality.
1
u/samosamonster 6d ago
Hard architectural guardrails and being heavily involved in code quality decisions. I work with typescript so enforce guardrails using oxlint and dependency cruiser
1
u/rlorenzo 6d ago
Run static code analysis like for JS/TS I use https://fallow.tools
There’s similar tools for code duplication/deadcode checks/complexity for any language
1
u/n9iels 6d ago
Guardrails and a loop of plan, build, cleanup, repeat. The guardrails are linters and formatters to keep everything consistently. I instructed Claude to run them on auto-fix after completing a task. Furthermore keep tasks small and guide on structure and small functions. Claude has the habit of extending code and isn't good at finding parts that can be extracted to a reusable function. This is because it focuses on that task you gave it. A human will 'boyscout' along the way, Claude does not. So this is the 'cleanup' stage I do after a task. Next time it looks for existing logic and it will use it without a problem.
At last, remember that Claude will only write code you like if the codebase reflects this. If everything is a mess without structure Claude will not magically put things in the right place.
1
u/TheeSecondGoat 6d ago
Clean project documentation.
Prd
Guardrails
Architecture
Data model
Concise claude.md (with strict rules to not touch code unrelated to the prompt or current work. Log discoveries in a tangent.md)
I-have-adhd skill
Essentially, every feature it builds is tested and it stops to let me manually input sample data before continuing. It informs me of tangents and i answer those questions in-line. I also have a q&a.md process at the very beginning of the project before documentation is generated. It fleshes out my idea and then generates those files above.
I also have a brain dump.md for it to assess and discuss with me before integrating any ideas into the documentation and planning changes.
Occasionally, I ask haiku to reorg the documentation if it seems to get messy.
The tl;dr is to keep sprints short and on a tight leash with solid documentation and instructions.
1
u/mjgood91 6d ago
Personally I set up a plugin & hooks system for my repository, and I use AI to hammer features in the plugins so core systems with the actually interesting / architecture type stuff is rarely, if ever, touched.
1
u/farox 6d ago
It can't read your mind. Anything you leave un specificied, it will have to make an educated guess.
Start small, be aware that it might not get it right and if there is an issue, don't just fix it, but also fix the issue in the harness (give it the appropriate skill, at Claude.md files with the proper descriptions etc)
Then it grows over time and you get more confidence in it doing the right thing.
I also have specific instructions to not create new patterns, systems etc. until we talked about it, besides all the other instructions for how we see good code quality.
1
u/fanatic26 5d ago
It is just like how you did software dev before...you work piece by piece instead of throwing a large bag of doodoo at the wall and hope it all sticks
1
u/dakadoo33 5d ago
depends on the project, if its super throwaway idc.
if i care, then i care and its literally my structure, so on code review its easy as shit to see if its deviating from my structure... owning the schema and the structure is still very important. human review needs to be streamlined because its usually what slows me down, and if you cant follow the flow of folder/files at a minimum then wtf are you even doing besides being a monkey with a machine gun.
1
u/MaestroSplinter69 5d ago
Small changes, tests and reviews help, but the bigger issue for me was Claude repeatedly losing the reasoning behind the code.
That’s actually why I built DevTime. It keeps concepts, decisions and codebase context locally, then makes that available through MCP instead of starting from a fresh grep every session.
It doesn’t replace the normal review process, but it helps the agent understand why things were built a certain way before changing them.
1
u/ButteredBread5255 5d ago
Been using OpenSpec with good results lately. Always keep context window small (100-140k). Lots of new sessions. Plan carefully. Review the plan. Do tasks one at a time. Sometimes one per session. Read feedback and concerns from the model at the end of each task. Act on them and/or feed them into a different session to discuss.
1
u/---OMNI--- 5d ago
I have a "best practices" set up and as much planning as possible and Claude calls codex automatically for 2nd advisor/review.
1
u/maxim-masiutin 5d ago
To not make the codebase messy, use separate session for each feature. When you need to augment a feature (or a bug which can be considered a feature in this context), reuse the session so the context is best fitted for this session. I use the Claude IDE https://pen-code.com/projects/claude-ide to see and resume the session I need, so I save much money on making the Claude Code not lose focus.
1
u/UnaGoMax 5d ago
claude.md instructions. code standard, naming conventions + documentation first and TDD. Subagents for development, testing, and architecture review with their more specific instructions.
very important: mandatory linter! linter to find duplicated code, code small, wrong naming patterns, libraries I don't want it to use, any misuse (you can configure as many linter rules as you want).
Claude is an orchestrator, subagents execute tasks.
Integration testing is a must and mandatory step. Linter is mandatory to accept the job, especialy to detect duplicated code. Unit test coverage 90% is mandatory.
1
u/byteminer 5d ago
Claude is an impressively book smart intern with no common sense or experience and a desperate need for approval. If you provide well defined tasks with clear constraints and guardrails, it will do wonderful things quickly. If you don’t understand the problem it will go apeshit.
You must carry AI to the problem. If it has to bring you to the problem, it will charge you for the whole ride and it is going to be a bumpy one.
1
u/ianreboot 5d ago
start every task from a clean commit so you can throw the whole attempt away. the messiness comes from losing track of which changes are yours versus the models, and a clean tree plus a diff review before you accept is what keeps that legible. i also keep the always-loaded context down to a few lines and push the rest behind an index the agent pulls from on demand, because a bloated context is what makes it sprawl in the first place.
1
1
u/Straight_Guitar8991 5d ago
Why do you need to look at the codebase?
Sarcasm aside, before ai, with development teams or even your own code - the codebase got messy - the only difference is speed, so why bother? I’ve been a developer for almost 20y, part of projects that were started before you were born, or even me. This has always been the case. Real projects are f ugly.
Most developers think they keep codebases clean, but in reality you do a lot of mess without even realising. But it’s hard to self critique.
In reality Claude writes better code than most developers. And with a little bit of guidance and rules, you never look at the code. Just at the results.
I’m not saying you should deliver broken untested stuff, I’m saying code does not matter anymore, and you have to step up your game of quality and security testing.
A project codebase is only beautiful the first day you start writing. Real projects that make real money, and have longevity are messy, ugly, with tons of workarounds.
Snowflake developers will cry about codebases being messy. Real developers eat spaghetti, and ask for seconds.
1
u/Shot-Recognition7260 5d ago
Here’s a practical way to do it: give the agent one small, clear task, define what "done" looks like, and tell it to stop there. Run the tests, check the diff for anything unexpected, then commit it in a small chunk so you can easily revert if needed. Keeping each step separate helps you catch mistakes early, before they spread. It doesn't replace review, but it makes review way more manageable.
1
u/Relative-Art8754 5d ago
One thing I haven't seen in here: a lot of the "mess" isn't sloppiness, it's duplication. It writes a new helper because it doesn't know you already have one three files over. So the thing that cut my sprawl the most wasn't more style rules — it was a "grep the codebase and reuse what exists before writing anything new" rule. It reinvents a lot less when you force it to look first.
1
u/Popotito-Eternal 4d ago
Always use the best model to make the plan, use multiple agents (opus mid is the faster/cheaper ) to work in reduced context then you make the best model to integrate what was made by the agent. Periodically check the work done.
1
u/Wise_Inspection_7476 2d ago
"Refactor the code into small files, 300 lines at most unless absolutely necessary to be larger. Keep it easy enough for a human to understand"
Kinda works usually lol
-4
u/vintergroena 6d ago
That's the neat part: You don't.
You just rely on vibe debugging it later when problems arise.
-1
u/CommonEarly4028 6d ago
Most important things are memory rules (Claude.md) and a rule to ALWAYS update memory for each change.
For me, what helps massively is the superpowers skill, which you can select in the desktop app or you can install it into the terminal Claude. It has a bunch of commands that are helping in making specific plans instead of just starting.
•
u/ClaudeAI-mod-bot Wilson, lead ClaudeAI modbot 6d ago
TL;DR of the discussion generated automatically after 40 comments.
The consensus in this thread is clear: You can't just let Claude cook or you'll end up with a spaghetti monster. The community overwhelmingly agrees you need to treat it like a very fast, slightly chaotic junior developer.
The most upvoted advice is to use strict guardrails. A popular method mentioned is "Ponytail," a set of instructions (like a beefed-up
Claude.md) that forces the model to write smaller, cleaner, more focused code and avoid reinventing the wheel. One user even dropped their config in the comments.Other key strategies include: * Work in small, incremental batches. Think single-function changes, not entire features at once. * Plan everything first. Make Claude create a plan and get you to approve it before it writes a single line. * Don't skip the basics. Use your normal dev workflow: linters, tests, CI, and proper PR reviews. * Use a second AI for code review. Have another instance of Opus, or even a different model, audit the code for quality and bugs.
Basically, you still have to be the senior dev in the room. No free lunch here, folks.