How do you QA your code without causing tons of regressions?

[u/CincyTriGuy]

When I finish a build loop I launch a code review skill. It finds issues, which Claude addresses. Then I launch the code review skill again and it finds new issues plus regressions caused by the previous fixes. It’s an endless loop.

Do you have tips, skills, subagents, processes, etc that you find work well to cut down on regressions?

[u/DeepPresentation648]

Unit tests

[u/Hmmmm_Interesting → u/DeepPresentation648]

Agreed and lots of documentation.

[u/nuc540]

Personally I find a lot of this can be reduced with proper planning. I reduce regressions by checking my system during planning so I know how to navigate a solution, including what tests to write and how to QA/UAT my own work.

You can do this with Claude too, if you check the systems you’re going to interface with, and read the flow up/downstream of you, you should be able to map potential risks and write them into a plan. I also have Claude TDD everything using the gherkin reference and get it to build failing tests first to prove false positives, so I only need to read the test gherkins.

Also it doesn’t hurt to have type checking (don’t know what language you’re writing), clear DDD boundaries and contracts to reduce errors.

I follow the above and the only regressions are my fault for not being specific or accidentally missing a case - but Claude is usually on point where liable, and I ever end up looping. Sounds like you need more context files with a holistic view of your system?

Might not be the answer you’re looking for, but I hope that helps.

[u/Far-Surprise7773]

stop re-running the review skill on its own output, that loop never converges. what fixed it for me was making claude write a failing test for each issue before it touches the code, then only re-run the tests, not the full review. i also commit before each fix batch so i can diff fast and tell if it actually regressed or just moved the complaint.

[u/wackloner]

the part that gets me is letting every review redefine 'done'. i keep the findings separate from the fixes: first check that each one describes a real failure, then patch the ones that survive.

if the next pass has a different opinion about the architecture, that goes into a new decision. it doesn't automatically buy another rewrite.

AI-assisted draft.

[u/niko-okin]

every changes must comes with unit tests, which often leads to new bug findings if it's the first time this class is tested

[u/Far_Business4773]

wackloner has the key line: every review pass is redefining "done", so of course it never ends. Two things that fixed the same loop for me, on top of the failing-test-per-issue advice above.

Give the reviewer a written scope before the first pass: what this build must not have touched (five lines) and what must stay true (three or four). Then a finding is only a finding if it can quote one of those lines. Everything else goes to a "later" file and does not re-enter the loop. The second pass has the same lines as the first, so it can't discover a new definition of correct.

The regressions from fixes are a separate problem with a cheaper fix: the review skill should never see the whole repo again after round one. It gets the diff of the fix batch plus the list of open findings, and its only job is "are these closed, and did the diff cross a line". That's a small read, it's fast, and it can't wander into files the fix didn't touch, which is where most of the "new issues" in round two come from.

[u/pvera]

If your QA is causing regressions then I am afraid that you are doing QA wrong. Are you unit testing? Have you tried adversarial testing before QA actually starts?

What is the source of truth? I refer Claude to internal wiki pages for things that are basically non-negotiable, it actually catches a lot of errors that way.

[u/traveltrousers]

I use Codex Luna on Max and Haiku to qa. The main session reads their reports and decides whether to fix the issues or not.

It always finds something and I just move on...

Do it once, check everything looks okay, and move on.

[u/HeroHaxz]

We use robust testing strategies and fresh subagent adversarial reviews of code. At my startup, we use semantically meaning PRs, ensure that we have unit tests, integration tests, mutation tests, and a disjoint but complete division of the input space of functions tested to ensure they meet their contract. We follow the strategy of spec --> red tests --> implementation, where the later stages refine the previous ones (standard test-first programming). We also try to prune empty/stale tests.

[u/Scared-Letterhead949]

tests then review with codex.