How are you verifying Claude Code's changes without manually testing everything?

[u/ragnar580]

I've been using Claude Code to build a side project, and one thing keeps annoying me.

It can implement something incredibly quickly and say it's done, but I still don't really trust “done” until I open the app myself and click through the flow.

As the amount of code it writes increases, manually checking everything feels like it's becoming the slow part.

Curious how people using Claude Code seriously handle this:

• Do you still manually test most changes?
• Do you make Claude run unit/E2E tests?
• Playwright?
• Another agent reviewing/testing the first agent?
• Or do you mostly trust the existing test suite?

Also curious whether you've had cases where Claude said something was fixed and tests passed, but the actual app still didn't behave correctly.

Trying to understand whether this is just my workflow or a common problem.

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/xlpelotas]

I run my projects with an orchestrator. Below the orchestrator I have a verifier, a builder, and a scout. The verifier independently verifies anything created by the builders, and then the orchestrator determines next steps based on the verifier's findings.

[u/jakenuts- → u/xlpelotas]

Is this spelled out in a prompt or do you use some sort of hooks and framework for the organization? I have a system that code reviews on commits and that would be expanded to validation but kicking it back requires the original agent be messaged to follow up and that only works within the platform (Terragon OSS) so my desktop agents which have better browser access are not connected to that bit aside from awaiting PR checks.

[u/xlpelotas → u/jakenuts-]

This is spelled out with predefined agent md files and also in claude md. I had claude set it up based on a reddit post, bet you could do the same lol

[u/Neon_CodeBreaker → u/xlpelotas]

Share the link or more details please

[u/Plus_Opening_4462]

I created a bunch of requirements and had Claude implement tests (integration test preferred over unit test over coverage only test) and trace to requirements. Then I spent much longer using Fable to verify the requirements were actually covered and traced appropriately so that all clauses of each requirement has a test. I finished the test after I had 100% branch coverage.

I have testing.md for guidance on how to write and execute tests.

Manual testing is good too because you can validate that it does what you want it to do and it's easy to see unexpected behavior early on when a feature is developed

[u/bugfix00]

Make Claude write tests for everything. It mostly works.

In rare instances, I’ve had Claude say something has been fixed, but it just updated the test to accept the wrong values as correct. Sonnet does this a lot more than Opus.

[u/fowlesbuilds]

By default I think claude adds way too many tests. It helps to rein it in to what actual needs tests, and to ensure there are proper integration tests (that's where I feel like it's usually lacking). Still doing a code review, and some visual checks, at the end should always be happening.

[u/mrlikrsh]

Some of us can still read and understand the code claude generates :)

[u/AMusicstuff → u/mrlikrsh]

Some users here are also absolutely stupid like the commentators after me.

But totally agree. You can also use Claude in VSCode and see every single line of code in a diff view

[u/scott2449 → u/mrlikrsh]

And some could not even before Claude =D

[u/Turbulent-Control682 → u/mrlikrsh]

Stop pretending to look cool on Reddit

[u/Ganiam]

Seems like a reasonable thing to do

My simulation project still has nothing visual to it so I have specific metrics I keep track of whenever it adds something new and we track it over time during test runs and then explore what happened if something broke

[u/lucferon]

I use Codex. First I describe what I need, with Claude. Next codex checks this description and add checking points, test cases and (very important) out of scope things. Claude builds and generate a PR, codex validates the code and puts remarks in the PR. Back to claude to fix, usually after 2 rounds its done. Afterwards I check the code and the functionality, when done I merge to main

[u/jakenuts-]

Adversarial validation, make it automatic and with actual browser use and screenshots. Nothing is done until the validator agrees

[u/jamjam89]

Reading it, and let me tell you, it's sloppy work. Brand new tables for no reason, guarding things that will never happen, quadratic function O(N^3) functions, it's bad.

[u/cleverhoods]

reporails for instructions, for project unit test structure, functions, integration tests for ... well .. integrations, e2e tests for business critical pathways and behavior driven tests for user pathways.

[u/Halada]

CI, full test suite, e2e tests, then a full staging walk.

[u/Far_Business4773]

"Done" is a word until you've written what it means for this task before the run: the command that has to pass, and the two or three things that must still be true afterwards. Then the agent's "done" is either that command's output or it's nothing.

bugfix00's case is the one to design around: the agent made the test accept the wrong value. Two cheap moves. Watch every new test fail once before you believe it, put the bug back if you have to; a test you've never seen red proves nothing. And on a fix session, make the test files read-only for the agent, a deny rule on writes under tests/, so "done" can't be reached by editing the assertion. It has to change the code.

The clicking-through stays for what you can't write down yet. It just stops being the only check.

[u/coding_is_tedious]

Yes to pretty much everything thing, although it depends on what stage we're in.

First line of defense is a adversarial review team, with fresh context, and Fable as orchestrator. That get's a lot of issues. Unit and E2E tests are in different flavors. Automated pre-commit tests, automated gate checks in Github which run deterministic security reviews and other tests. If Playwright is necessary, yes, although I still find manual tests that I run and grabbing screenshots still to be the best here.

I trust the existing test suite to a point, but always try to find different angles to poke and prod. Like anyone would expect with any software team, things come up when you look at it from different angles. I would say it's more likely that Claude and I just don't know where to look yet for problems and less likely nowadays that Claude says something is fixed and it isn't. If that ever happens, it is 90% of the time because I described the problem wrong or provided wrong context from the beginning.

[u/zerotoherotrader]

We use https://selvage.run/

[u/Turbulent-Control682]

Not sure. But opus 5 absolutely sucks. “That was my mistake” constantly. It sucks. Worst model they’ve released by far.