You're the only developer on the project, so nobody reads your diff before it ships. Your first action today: pick the last pull request you merged without a second reader and ask an AI reviewer to list what you forgot to handle in it. Then decide which of those findings a human still has to confirm.
That split is the whole method. AI is a fast first reviewer for mechanical mistakes, automated gates block known-bad code, and you read the dangerous parts yourself. This piece is the quality-control half of my AI-augmented development approach; start there if you want the wider workflow.
What can AI code review catch for a solo developer, and what does it miss?
AI review is good at local, pattern-based problems in a single diff, such as missing error handling, null dereferences and copy-paste drift. It is weak at system-wide context and cannot be trusted to declare code safe.
GitHub's own documentation is blunt about this. The Copilot code review docs say Copilot "is not guaranteed to spot all problems or issues in a pull request," that "sometimes it will make mistakes," and tell you to "supplement Copilot's feedback with a human review" (checked 30 September 2026). Developer sentiment points the same way: in the Stack Overflow 2025 Developer Survey, 84% of respondents use or plan to use AI tools, but 46% distrust the accuracy of their output and only 33% trust it. The top frustration, cited by 66%, is "AI solutions that are almost right, but not quite."
Here's the practical split I use:
| AI reviewer is useful for | AI reviewer can't be trusted with |
|---|---|
| Forgotten error handling and unawaited promises | Whether a tenant-isolation rule is complete |
| Null and undefined dereferences, obvious type mismatches | Which endpoint is the unauthenticated one |
| Naming drift and dead code | Whether a design fits your product and its trade-offs |
| Common security anti-patterns such as secrets in source | Sign-off on payments, auth or data boundaries |
My rule: AI may find problems, but it never gets to declare their absence. A clean AI review means "no obvious local issues," and nothing more.
Why is the boring bug the dangerous one?
The mistakes that slip past a solo developer are rarely clever. A forgotten await, a rule that lets one customer read another's records, a payment webhook that processes the same event twice. Stripe's webhook documentation says endpoints "might occasionally receive the same event more than once" and recommends logging processed event IDs so you skip repeats. None of this needs deep insight to catch. It needs a second look, and an AI reviewer gives you one on demand. A minimal guard looks like this:
// Firestore create() fails if the document already exists,
// so a repeated Stripe event ID is rejected atomically.
try {
await db.doc(`stripeEvents/${event.id}`).create({ receivedAt: Date.now() });
} catch {
return res.sendStatus(200); // already processed
}
Which quality gates should a solo developer run before merging?
Run five gates in order of cost: an AI diff review, strict types, tests, automated lint and security scans, and finally a slow human pass on high-stakes code. Each gate catches a different class of bug, so bad code has to fail several independent checks.
- AI diff review. Paste the diff and ask what you forgot to handle. It's the cheapest gate, so it runs first and often.
- Types. TypeScript's
strictflag enables a family of checks, includingstrictNullChecksandnoImplicitAny, that the docs describe as "stronger guarantees of program correctness." A cleannpx tsc -b --pretty falserules out a whole category of runtime surprises. - Tests. AI is useful for generating the boring permutations, but you choose what to pin down: payment state transitions, auth boundaries, language fallbacks. The tests encode your intent.
- Lint and security scan. Automate these so they run on every change, not whenever you remember.
- Human pass. Read line by line, slowly, with the threat model in mind. Reserve it for code that touches money, identity or cross-tenant data.
The BookBed case study shows why tests earn their place. An early version of its iCal overbooking logic normalised dates in a way that produced the wrong day for bookings stored late in the evening in UTC, which triggered false overbooking warnings. After a rewrite, eight dedicated tests now cover real-world Adriagate imports, full containment, zero overlap and turnover days. The same case study describes structural discipline for solo work: versioned changelogs, path-scoped code rules, and "do not refactor" markers on code that took painful testing to stabilise.
How do you get useful output from an AI reviewer?
Give it a narrow job and the context it can't see. A vague "review this" invites a vague answer and a pile of style nitpicks. A specific request forces it to look for what you care about. Here's the shape of prompt I'd start from:
Review this diff as a skeptical second engineer.
Context: multi-tenant app, every Firestore path is under tenants/{tenantId}.
List only: (1) unhandled errors, (2) places where one tenant could
read or write another tenant's data, (3) logic that runs twice if the
request is retried. For each, quote the line and say how sure you are.
Asking for a confidence level and the exact line helps you triage, because you can check each claim in seconds instead of trusting a summary. It also pays to run the review twice with different framings, for example once as a security reviewer and once as a maintainer who has to debug this at night. Findings that appear in both passes usually deserve your attention first. That last point is a working habit, not a measured result. Treat every AI finding as a lead to verify: open the file, reproduce the problem or write a failing test, and only then change code. A finding you can't reproduce is either a false alarm or a gap in your own understanding, and both are worth knowing about before you merge.
Keep secrets and real customer data out of the prompt. Paste the diff, not the .env file, and replace any production identifiers with placeholders before you share code with a hosted tool.
How do you decide which code needs a human pass?
Decide by blast radius, meaning the worst outcome if this code is wrong: low-stakes code ships on AI review plus automated gates, while code near money, identity or tenant boundaries gets a slow human read.
- Low stakes, AI plus gates is enough. UI layout, static content, internal tooling, a new translation string. Pizzeria Bestek, a React and Supabase ordering site in four languages (EN, DE, IT, HR), is full of this kind of work, where a wrong string is embarrassing, not dangerous.
- High stakes, a human gate is mandatory. Payments, authentication, authorization, and any data that crosses a tenant boundary. Callidus, a React, Firebase and Stripe Connect SaaS for UK aesthetic clinics, keeps everything under
tenants/{tenantId}/…with JWT claims carryingtenantIdandrole, per its case study. That is exactly the layer where a rule read by hand beats a rule skimmed by a model. Firebase's docs show the mechanism: Security Rules read custom claims throughrequest.auth.token, so one wrong condition changes who can see what.
A practical way to apply this is to label the folders in your repository. Mark the directories that hold payment handlers, auth code and security rules as "human review required," and let everything else default to AI plus gates. Path-scoped rules like this are easy to write down and hard to forget, and the BookBed case study lists path-scoped code rules among the structural habits used during six months of solo development. If you open pull requests even when you work alone, add a line to the template asking whether the change touches a marked directory.
The same triage scales across very different products. BookBed ships one Flutter codebase to six platforms, so a formatting bug and its fix both land everywhere at once. Calendar sync and payment logic get the slow read; layout quirks lean on automated checks. For the security side of these boundaries, see SaaS security and compliance.
Does AI review actually make solo development faster?
It can make you faster when it moves your scarce attention onto the small share of code that can hurt you, but the evidence says your own sense of speed is unreliable, so measure it.
The best controlled evidence is a bit sobering. In a randomized trial published by METR in July 2025, 16 experienced open-source developers completing 246 real issues took 19% longer when AI tools were allowed, yet they expected a 24% speedup and, afterwards, still believed AI had sped them up by about 20%. That study covered coding assistance on mature repositories, not review specifically, and tools have changed since, so I read it as a warning about trusting impressions. This suggests tracking something concrete for your own workflow: time from first commit to merge, and bugs found after release.
If you want a place to start, keep one gate per week. Week one, turn on strict types and run the compiler on every change. Week two, paste every diff into an AI reviewer before you commit. Week three, write tests for the one module that touches money. Then email me with the one gate that caught something your own eyes missed, and what it was.