How do you decide what to let Claude Code fully own vs. review line by line?
by•
Solo builder here, using Cursor + Claude Code as basically my whole engineering team. Six months in I still don't have a good instinct for this: some days I let it just run with a whole feature and barely glance at the diff, other days I'm rereading every line like it's a junior dev's first PR.
Right now my rough rule is billing/auth code gets the paranoid review, UI and analytics panels get the "looks fine, ship it" treatment. But that's just a gut feeling, not a real system.
Anyone here have an actual framework for this, or is everyone just winging it based on vibes and how burned they've been before?
101 views
Replies
how did you decide which tasks Claude Code can handle independently?
Honestly just trial and error early on. Let it fully own something low stakes, watched what broke, adjusted from there. The billing/auth vs UI split came out of getting burned once on something billing-adjacent, not from planning it ahead of time
@moddy what type of code do you always reviews before merging?
@moddy what's your biggest concern when letting AI write large features?
@isaacjosepkq6w That it makes a decision three files away from where I'm looking that quietly conflicts with something else in the app, and it all still compiles fine. Small tasks that's rare. Big features, way more surface area for that to happen unnoticed.
I follow a similar approach. Anything that touches payments, authentication, or data gets a careful review, while UI tweaks are usually much easier to trust.
I seperate tasks into low medium and high risk before letting Claude Code finish them. Would adding automated tests make reviewing critical changes much easier for solo builders?
@darly_selby Probably, and honestly that's the gap in my setup right now. I don't have real test coverage on the billing stuff, I just review it carefully by hand every time, which doesn't scale great. Something I know I should fix.
@moddy what was your biggest lesson from using AI as a coding partner?
billing/auth strict, everything else looser is basically my rule too. the axis I'd add: anything that touches how a number gets computed (not just displayed) gets read line by line, because a wrong inference there looks totally fine in the demo and only shows up days later as a quietly bad output. has the paranoid-review code or the ship-it code actually burned you more so far?
my split is less about which files and more about whether I can verify the output cheaply. UI I can eyeball in five seconds so I let it run. anything touching model config or quantization I review line by line, not because it looks risky but because it compiles fine and looks totally reasonable while being numerically wrong, and I won't catch that without actually running the eval.
I don't follow any framework to review the code but when creating a new project i just define the way it will write the code. And define things clearly in Claude.md, and you can have design.md for UI design. Till now I didn't face any issue. Keep a checklist and ask claude itself to review against that while raising PR. It helped me alot.
My version of that split fell apart on the ship-it side. A database view feeding a public page, the sort that gets waved through, turned out to expose every user's email. When I asked the AI about it, it called that 'partial user data'. So now I sort by what data the code can reach instead of which feature it sits in. Pure layout gets the skim, anything that builds a query or a view gets the billing-grade read.