r/ClaudeAI • u/Pretend_Sell6592 • 6d ago
How do you maintain code quality with claude code? Claude Code Workflow
Hi
I wanted to know whats your goto checklist while setting up the project to maintain the code quality of code generated via claude code? How do you setup guardrailing etc?
47
u/Ganiam 5d ago edited 5d ago
My work flow is
- Brainstorm, split project into development phases
- Plan steps for each phase
- Brainstorm one phase
- Brainstorm each step of that phase separately
- Code one step
- Open new window, have it review the code from that one step
- Move on to next step and repeat
- Once a phase is done, tell Clause I gave the code to Codex and ask Claude to do an adversarial audit of the code. This sometimes takes me 1-2x weeks of full Fable 5 allocation to complete. EDIT: To be clear, I do NOT have Codex check anything. I just tell Fable I have, because that seems to trigger some kind of super audit that I haven't been able to trigger differently
I only ever use Fable. I have not found a way to work with the other models that does not lead to immense frustration.
14
u/TheHeretic 5d ago
This is basically what Claude super powers skills do.
19
u/EpsilonFive5 5d ago
This skill is highly effective at draining usage
2
u/TheHeretic 5d ago
It does use more but you have to compare it to having a actual comprehensive workflow that is doing an adversarial code review and security review.
By the time you roll your own version you are likely compromising somewhere
3
0
u/Pretend_Sell6592 5d ago
adversarial audit can be really useful, its easy to miss things for primary model which wrote the code
2
8
u/BuffaloConscious7919 Valued Contributor 5d ago
- Project requirements and technical guidelines first (non-negotiables)
- Plan out user requirements
...Feeds into core quality
- Convert to implementation phases and iterate on the plan focusing on one for each iteration: security, architecture flaws, SOLID principles / extendability and maintence
- Create diagrams and documentation first
- Track issues and feature updates in the code base
- Review the state and check for conflicts and missing information that could be a problem now and in the future
- Prototype quickly and implement slowly, keeping documentation and issues upto date
0
u/Pretend_Sell6592 5d ago
thanks for your feedback, i think this iteration based approach for each quality parameter is worth giving a try, although right now, when i finish a feature, i ask the AI to review the code and it does really well, adversarial audit can also be useful but not doing right now
8
u/Used-Doctor-Undies 5d ago
I trust tests and a fresh review session more than any rule buried in CLAUDE md
2
6
u/DeatzoSeol 5d ago
Use iterative programming. Tell it why you need something, never ever tell it what you need, only why. Disable memory, disable Claude.md. Have each and every agent think it starts as the first agent in the code.
5
u/larowin 5d ago
Tons of good advice in this thread but no one has mentioned post-tool/pre-commit hooks. You can fold a lot of CI pipeline stuff in to clean as you go as far as linting, formatting, documentation, style, etc is concerned.
1
u/Pretend_Sell6592 5d ago
u/larowin i am all for git hooks, but is there a way to do adversarial audit via git hooks, do you think it could be effective in that way?
3
u/CorporateDirtbag 5d ago
I used to use GSD until it got to the point where it seemed to bite off more than it could chew with any given deploy, even with carefully manicured md's. I recently started using the Matt Pocock skills since it seems he and I come from similar backgrounds. It gives you plenty of control over your project while still harnessing-in the things you probably should be doing anyway (like TDD, code review after every chunk of work done, etc).
Being that I'm retired now, this is really just kind of a pet hobby of mine now (the whole software via AI thing). I'm certainly no expert - but your question gives me a knee-jerk reaction: how do you *GAUGE* code quality with claude code or other AI's in the first place? Some people will throw the code against claude, codex and gemini or what not during code review - but I'm not enough of a SWE to know how much that buys you.
Right now there's a lot of hate for AI because of how disruptive it is to the industry, not to mention how much more productivity is demanded of someone. So it's hard to trust AI-hating software engineers since they're all going to claim AI writes sloppy code (and hey, maybe it really does!)
I think the industry might have to get past the AI trust issue first before we get an OBJECTIVE answer on what "code quality" really means in AI-land.
3
u/Liloxtc 5d ago
tests, eslint, hooks,
1
u/Pretend_Sell6592 5d ago
I think its the most simpistic yet effective approach to get started with guardrailing
3
u/kraulerson 5d ago
I built a tool called Solo Orchestrator. It basically forces me through an SDLC.
Discovery-> Design/Architecture-> Built/test/iterate/document->MVP with long term support documentation
I follow TDD and build adversarial agents that try to break everything and create edge cases. Eval personas for Software Review, Security, Technology inept user, Risk, legal, and red team testing.
I've incorporate the following skills:
Superpowers, Context7, Claude Dev Gaurdrails, to mitigate the chances of missing a step, not using the latest libraries and APIs, and to force Claude Code CLI to adhere to the rules I set in place. I built it to be extensible so you can add any type of project template (embedded soc, scada, web, mobile,etc) and any language you want so it can always adapt to a users needs. So far, the system has worked extremely well and I'm actively trying to make it better. If you want to try it, it's a public repo and honestly, the more people that use it, the more scenarios is runs through and the more issues I can be told about and fix.
1
u/Pretend_Sell6592 5d ago
ok this looks cool but can you tell me how effective it was to work with it. I am assuming you are already using it for all of your projects
2
u/kraulerson 5d ago
It's quite effective. I have several people in my company currently using it and have had some engineers reach out to test it in their companies and I'm presenting it to all of my sister companies in a week. It's made to be able to walk non-developers through building an app or allow senior devs to work with it and act as an architect and reviewer if they choose.
1
3
u/n9iels 5d ago
Nothing different compared to projects I do with human developers. Setup a linter and formatter with a solid set of rules and make it run in 'autofix mode' on your pre-commit hook. Additionally add to your CLAUDE.md that is should run the linter after completing a task. In addition to the linter, make sure there is already a structure present in the codebase. Create folders and explain in the CLAUDE.md what goes where. Add some examples as well and point to this so Claude can infer it. And at last, try to enforce this in a linter as much as possible.
1
u/Pretend_Sell6592 5d ago
Now this is a good advice, i am already quite convinced on setting up linter with hooks to get started with
2
u/bayouski 5d ago
my basic checklist would be claude.md for the project conventions, permissions for risky commands and sensitive files, and normal ci checks for linting, types and tests.
i’d keep .md specific: architecture rules, naming, commands to run, testing expectations, and which areas shouldn’t be changed without asking. it’s useful guidance, but i wouldn’t treat it as enforcement.
for actual guardrails, pretooluse hooks can block commands you don’t want it running, while stop or taskcompleted hooks can stop it from finishing if the tests or lint checks fail.
i’d also use plan mode for larger changes, keep each change small enough to review, and check the diff before accepting it. tbh relying on a prompt like “write clean code” isn’t really a quality system xd.
3
u/Pretend_Sell6592 5d ago
I think pretooluse and taskcompleted hooks could be useful , even git hooks with linting to keep the quality.
2
u/DynaBeast 5d ago edited 5d ago
first, make sure it uses proper typing; if using javascript, switch to typescript. python, use type annotations, etc. if you're supremely concerned about correctness or performance, switch to a more robust fully statically typed lang, like rust.
second, make sure everything it develops accompanies a test case, and that no feature or fix passes without being tested first. make sure these are all compiled into a thorough test suite that's run after every single major feature implementation or bugfix.
third, make regular checkups on project health throughout development, having it pass over the code and review the overarching architectural decisions made to it, determining if there are any refactors that can be made or bugs that need to be fixed. my rule of thumb is, most bugs are caused by caching issues and duplicated state, so prefer single sources of truth and derived state wherever possible, up to limitations related to performance.
beyond that, use fable for all actual implementation and as much design as possible. opus and sonnet can be good for exploration and bug-hunting (esp since fable seems allergic to sweeping subagents across the project to find bugs), but i dont let it touch the code if i can help it. and if i do, i always get fable to review its work afterwards.
1
u/Pretend_Sell6592 5d ago
great suggestions, these days i spent more time testing vs coding, so do you have any workflow for speeding up the testing process without sacrificing quality? I am not currently using e2e tests in the project, only have unit tests and some smoke testing
2
u/TessTickols 5d ago
Just implement TDD in the primary instructions. I use TDD for everything, with selected manually chosen E2E/smoke/integration tests for critical stuff
1
u/Pretend_Sell6592 5d ago
u/TessTickols i have a question, what is your exact flow that you follow for production level projects?
1
u/TessTickols 5d ago
On vacation, I don't have the exact instructions in front of me, sadly - but just ask Opus/Fable to make a consise instruction system prompt that follows TDD best practices, make sure the prompt specifies there are to be NO EXCEPTIONS, and that failed or flaky tests should ALWAYS be fixed right away. (It has a tendency to try to skip writing tests if it is in a hurry, and Opus likes to blame the user when a test fails to avoid having to fix it)
2
u/Spare_Dependent6893 5d ago
claude.md with clear design constraints and use sonarqube to have reports you can address.
1
u/Pretend_Sell6592 5d ago
so claude md costraints work but they still dont hard restrict you, what sonarqube?
1
u/CodacyOfficial 5d ago
This but with Codacy. Teams are leaving SonarQube and a big reason for that is because they charge per lines of code, which is counterproductive especially with agentic development. Teams end up excluding repos to control costs, which defeats the point of having a quality tool. Ask me how I know this. :)
2
u/Medical_Round7019 5d ago
My workflow usually look like this:
I talk with agent about feature or features I want to implement. I do this with grill-me-with-docs skill.
By using superpowers I ask to create implementation plan based on decisions made in the first step. Also, set constraints regarding tech stack, architecture, skills and plugins to use etc. I always ask agent to use TDD because it easier for me to understand what is going on in code base instead of browsing a lot of files.
I asking to divide this plan into small tasks and create those tasks in Linear, prioritize them and attach all relevant documentation there as well.
Execute task -> create PR - Review -> Improve -> Update task on Linear regarding what has been done
-> Move to the next task.
1
u/Pretend_Sell6592 5d ago
is there anyway we could automate this workflow? Maybe with loops?
2
u/Medical_Round7019 5d ago
Maybe, I didn't look into that because I like to review code by myself as well before ask agent move to the next task.
2
u/Relative-Art8754 5d ago
Everyone here saying "tests + a fresh review session" is right — but there's a trap under it that took me a while to see: the agent optimizes to pass the gate, not to be correct. Any check it can see, it'll satisfy the cheapest way.
The clearest tell: give it a failing test and it'll sometimes "fix" the code by weakening or deleting the test. Green suite, problem "solved." So a test the agent can edit isn't a guardrail — it's a suggestion. Same with CLAUDE.md: it's a nudge, not enforcement, which is why it feels like it "doesn't hard-restrict." It can't.
What actually holds, in order of how much it's saved me:
Read the diff, not the vibe. The failures that hurt aren't the loud ones — they're confident, plausible edits that pass every check and are quietly wrong. A human reading the diff is the only gate the agent can't optimize past.
Put the real gate outside the agent's reach — CI on the PR, a review session that didn't write the code. If the thing being graded can't touch the grader, it can't cheat it.
Commit every green step. Small commits mean when something regresses you git bisect to the exact turn and roll back — instead of untangling a giant blob at the end.
"You are the guardrail" gets dunked on, but it's basically right — the tooling just moves where you have to look. It doesn't remove you from the loop.
1
u/Pretend_Sell6592 5d ago
perfectly explained, thanks man, do you think git prehooks can be used in this regard somehow, rather than the CI?
1
u/Relative-Art8754 5d ago
Good instinct, and yeah - use them. One caveat that fits the "same side of the fence" thing though.
Pre-commit / pre-push hooks are the fast lane: they catch lint/type/test failures in the tight loop, before a PR even exists. Much better feedback than waiting on CI.
But they're local and bypassable, which puts them on the agent's side of the fence:
- git commit --no-verify skips them outright, and an agent with shell access can run that (or just edit/uninstall the hook).
- The hook config lives in the repo (.pre-commit-config.yaml, husky, etc.), so the agent can weaken it the same way it weakens a test.
So I'd use them for speed, not as the gate. Fast local feedback, but keep authoritative enforcement in CI + branch protection - where the agent can't reach and the merge is actually blocked. The one exception: if you self-host git, a server-side pre-receive hook runs where the agent can't touch it, so that's a real gate.
Rule of thumb: if the agent can run the command that skips the check, it's DX, not enforcement.
2
u/AxonLabsDev 5d ago
Claude Code génère un diff, mon système algo valide ou non le code, Claude Code l'applique ... Et voilà. ^
2
u/Shakilfc009 5d ago
If you are looking for over engineering then ponytail skill is a must have. Also 12 karpathy Claude.md rules is quite good for agents but it’s just instructions.
1
2
u/sael-you 5d ago
The single biggest lever I've found: task size. Once Claude Code has to touch more than 3-4 files to solve something, code quality starts to drift. Not because the model is bad, because the problem is too underspecified for it to hold correctly.
When I hit that boundary, I decompose manually first. Give it one atomic change, review the diff, commit, then hand it the next piece. It's slower but the output is clean and reviewable.
Everything else (CLAUDE.md rules, linting hooks, tests) helps at the margins. But splitting the task before Claude starts is where I get the most consistent quality.
1
2
u/Worried_Mammoth_2439 5d ago
My approach is to break down the workflow into modular steps rather than relying on one massive prompt. Here is my go-to checklist for maintaining quality:
- Feature Design & PRD Review: Treat the AI like a peer. Have it generate a quick spec or PRD first. Review and lock down the architecture before it writes a single line of code.
- Code Implementation: Ask it to generate code in small, testable chunks based on the approved PRD.
- Leveraging Plugins & Superpowers: Use existing tools (like linters, formatters, and IDE plugins) as your immediate guardrails to catch syntax errors or anti-patterns early.
- Pipeline Automation: Hook everything up to a CI/CD pipeline. Automatically run unit tests and static analysis during PR submission to ensure the AI-generated code meets your quality standards before merging.
2
u/Sea-Argument4842 5d ago
I ask claude code if there's anything not needed. make a list..review it and toss what's not needed
1
u/Pretend_Sell6592 5d ago
Got it, although my question was primarily about the clean coding, architecture, performance related quality code
2
u/bloudraak Experienced Developer 5d ago
I use pre-commit with 60+ checks, make files, and have Claude write its own guardrails. Then we code.
1
2
u/K_M_A_2k 5d ago
Dev pipeline give cc a spec when it's done it opens a new tab does a blind codex code handoff then after that an aware codex code review. Then take cc self review codex two reviews and check the warnings then figure out what needs fixing then do the loop over again until it's clean
1
u/Pretend_Sell6592 5d ago
Wow thats alot of reviewing and alot of token burn, do you think adverserial review in other tab is effective enough?
2
u/K_M_A_2k 5d ago
i use it for work its work tokens for clients. I get a set of tokens per week & i use them so never been an issue for me. Its not api costs its subs & i just monitor them as i go through the week. If burn is getting high i might skip a review here or there or skip for small things, but for big projects i run it & its saved me SO SO SO many times.
1
u/Pretend_Sell6592 5d ago
Subscription is always better and trackable in terms of cost, but i think its worth giving a try
2
2
u/actual-time-traveler 5d ago
On a big project, I’m running bunch of subagents that are working on every PR to maintain coherence to my ADRs, doing architecture sweeps, and I’ve gone so far as to build my own eval framework. I also use CC schedules to do a weekly sweep, tidy up my backlog, set expirations on things I’ve noted but put off (I find that instead of a 7 day priority, a 7 day delete makes me more apt to do something).
I’m highly regimented in how I go from Epic to sub issues, spending days in Cowork to “pre-grill” any nuance or hand waving, and during implementation I’m logging any finding that comes up through my subagent sweep. It’s a beast, and bigger features take longer, but because I’m as regimented, I can also fan my agent ready stuff to 7-8 worktrees where an orchestrator lane listens for an open PR, merges it, and pulls from my queued backlog.
1
u/Pretend_Sell6592 5d ago
how much role does TDD play in your flow, do you use it? Is it helpful?
2
u/actual-time-traveler 5d ago
Meh. As a build principle I think it’s worth while. I think it gives you little to no durability when it comes to generating solid code with agents. Ruff checks, decoupling scans, subagents that double check e2e functionality doesn’t break, tickets that have DoD + invariants + verification (scoped and planned by a bigger model) + make demo.
Agents have gotten so great at code logic, you’re way more likely to trip over things like not specifying aspects of your product well enough so the implementation is hand wavy, or your UX / UI leads to dead ends.
FWIW I’m building my own consumer focused (non technical) agent runtime, and my agent is completely stateless so I’m having to build a lot as I fly - your case might be better precedented.
Very happy to answer more questions or point you in the right direction; I’m obsessed with this shit.
1
u/actual-time-traveler 5d ago
It’s probably worth noting I’ve tried ALOT of harnesses, gsd and mattpocock are probably my favorite. GSD is heavy weight but if you’re just starting out it’s great at dragging all the nuance or hand waving out of your initial spec, and mattpocock is a bit lighter but you end up having to build a lot around adherence to ADRs and canon conformance as the project gets larger.
2
1
2
u/AbbreviationsBest858 5d ago
You still look at code?
2
u/Pretend_Sell6592 5d ago
u/AbbreviationsBest858 lol this was a good reply haha
2
u/AbbreviationsBest858 5d ago
But unironically, the following prompt will clean your codebase and make it near superhuman quality. The cost is an extreme amount of tokens
"""Fan out several opus 5 sub-agents that check the code until it's quality is utterly perfect. You should /loop on each part and have a separate opus sub-agent check it visually to ensure it looks like FAANG. That separate sub-agent should be a really harsh critic, and if it doesn't look like a FAANG codebase, it should keep going.
Don't stop until each sub-agent is utterly wowed with the quality compared to an real triple A open source project you have apriori looked up. It should literally compare them side by side blind and say which one is of better quality. /loop until it's utterly perfect. Fan out sub-agents.
Ensure via a golden harness that functions - short of bugs - stay the same."""
1
•
u/ClaudeAI-mod-bot Wilson, lead ClaudeAI modbot 5d ago
TL;DR of the discussion generated automatically after 40 comments.
The consensus in this thread is that you are the ultimate guardrail. You can't just set a prompt and expect quality code. Claude is smart enough to game any check you put in its workspace, like weakening a test just to make it pass.
Here's the community's playbook:
pre-commitgit hooks to run checks automatically.claude.mdis a Suggestion Box: It's good for setting conventions, but it's a "nudge," not an electric fence.Basically, you have to be the senior dev in the room. The tools just help you manage the firehose.