I let my AI agent merge most of its own pull requests. Here's the tiering that keeps it safe.

A workflow question I keep going back and forth on, and how I landed.

I ship a lot of AI-written code as a solo founder, and I hit the wall you probably know: if a human has to review every agent PR, you didn't buy leverage, you hired yourself as a full-time code reviewer. So I stopped asking "should I approve this PR" and started asking two things instead: how confident am I it works, and how bad is it if I'm wrong.

That splits everything into three lanes:

• Zero blast radius (docs, copy, an endpoint nothing depends on yet): the agent merges it. If it's wrong, I revert it - costs me nothing.

• Most feature work: a QA agent buys the confidence instead of me. It opens the preview in a real browser and clicks through the change like an impatient user until it's actually green — not "the tests pass," because agents are dangerously good at writing a green test over broken behavior. (I use screencli.sh that runs QA agent on every PR; I also run my own QA loop on bigger features.)

• Auth, billing, anything that charges a card or drops data: I review personally, every time. No exceptions.

The half I think makers under-use: instead of only raising confidence, I lower the cost of being wrong. Low-risk changes ship straight to prod because my rollback is one click, and a monitoring loop watches production, reproduces real breakage in a browser, and files a ticket automatically — so a transient blip fixes itself and I'm not the smoke detector.

Honest caveat: this is safe because I'm solo with a small user base and instant rollback. If a bad merge could bill the wrong customer or corrupt data for thousands of users, keep the human gate — the whole point is to gate by the cost of being wrong, not to remove the gate.

So I'm curious how the rest of you draw the line: what do you still review by hand on agent-written PRs, and what have you handed off to a check that isn't you?