Solo · No Reviewer
Working alone, nothing stands between a commit and production. That is not because you skip review but because there is nowhere for a review to stand, and a branch is the device that creates that place. Once AI writes the code a solo developer gains a reviewer for the first time — but handing that review to the session that wrote the code makes both fields of view coincide, so they miss the same things.
01Solo · No Reviewer
Concept at a GlanceWorking alone, a commit lands on the trunk and flows straight to production. Nothing stands in between.
So a bad commit ships too. Not because you skipped review, but because there is nowhere for a review to stand.
Add one branch and commits pool there. The point is not to collect an approval — it is to leave a diff you can actually read before merging.
Once AI starts writing, that diff piles up faster and larger. Small diffs used to be a virtue only because writing was slow.
In exchange you get a reviewer for the first time. What solo development gains from AI is not code output but someone to read it.
But hand the review to the session that wrote the code and the two fields of view almost coincide. Sharing the same assumptions means missing the same things.
Give it to a separate session with no shared context and the fields shift apart — whatever stops overlapping stops being missed.
Review and CI plug different holes. Review catches what diverged from the intent; tests catch what diverged in behaviour.
AI-written tests, though, include some that only ever pass. Break the implementation on purpose once and check that the light actually turns red.
Fold the work into one commit when you merge and undoing it is one step too. The thinner your review, the more a shape that is easy to revert does the work.
02 Understand It Simply
For EveryoneRight after writing code you read your intent rather than the text, so the same defect slips past repeatedly. Solo development therefore leaves a diff to read before merging and hands the review to a session without that context.
Alone, put the gate in the structure rather than in a person.
First, make a branch so there is a diff to read before merging.
Second, give the review to a session with no shared context rather than the one that wrote the code — shared context means shared blind spots.
Third, let CI make the final call: review catches what diverged from the intent, tests catch what diverged in behaviour, and the two plug different holes.
AI-written tests do include some that only ever pass, so break the implementation on purpose once and confirm the light turns red before you trust that gate.
- –Introducing a PR flow to a repo you work on alone
- –separating the session that reviews from the one that writes
- –checking whether AI-written tests actually fail
- –and picking a merge shape that is easy to revert
03 Frequently Asked Questions
FAQWhat is Solo · No Reviewer?+
Working alone, nothing stands between a commit and production. That is not because you skip review but because there is nowhere for a review to stand, and a branch is the device that creates that place. Once AI writes the code a solo developer gains a reviewer for the first time — but handing that review to the session that wrote the code makes both fields of view coincide, so they miss the same things.
Where is Solo · No Reviewer used?+
Introducing a PR flow to a repo you work on alone, separating the session that reviews from the one that writes, checking whether AI-written tests actually fail, and picking a merge shape that is easy to revert.
What's a simple analogy for Solo · No Reviewer?+
Right after writing code you read your intent rather than the text, so the same defect slips past repeatedly. Solo development therefore leaves a diff to read before merging and hands the review to a session without that context.