The solo developer's missing second pair of eyes.

The shape of a side project is: Sunday night you push a feature, Tuesday morning you wonder why anyone would write a function like that. The reviewer who would have caught it doesn’t exist. You are the reviewer, but you don’t review your own code the same way you’d review someone else’s — and you couldn’t, even if you tried, because the context is too close.

I built CommitBrief partly because I live in that gap myself. Every weekend project, every OSS contribution, every late-night fix to a sleeping repo — there’s no second engineer to glance at the diff. The tooling around code review assumes a team. It’s been a long-standing absence in the indie and OSS world, and it deserves an honest treatment of what an LLM can fill in and where you should not pretend it’s filling anything.

The gap a solo developer actually has

When I review a teammate’s PR, I bring two things to it: technical scrutiny and a kind of distance from the code. The distance is what catches the “this function answers the wrong question” critique the manifesto talked about. I don’t have that distance for my own code. Twenty minutes after writing it, I read it the way I wrote it, not the way someone reading it cold would.

An LLM has neither my context nor my emotional attachment. It reads the diff as a reader, not as the author. That isn’t the same as a human reviewer, but it produces a different category of finding than self-review does. The LLM points at the line where I forgot to check the error; I would have explained that error away to myself.

This is the comfort an LLM provides to a solo developer. Not “second engineer,” but “second reader.”

What it concretely fixes for the indie context

The default --staged workflow works the same way I described in the pre-push post, but the value calculus shifts. For a team developer, the LLM finding might be the second or third detection of an issue; for a solo developer, it’s often the only detection. That changes how you weight even small findings.

A few specific places I lean on the tool in solo work:

• Friday-night refactors. I’m tired, I want to move a function, I trust myself less than I should. commitbrief --staged is the smoke test before I let myself push.
• OSS contributions to other people’s repos. I don’t know the codebase well; I don’t know what the maintainer cares about. A COMMITBRIEF.md in the project (if it has one) substitutes for tribal knowledge I don’t yet have.
• Re-running the same diff cheaply. The local cache means I can run commitbrief ten times on the same staged diff without paying for ten reviews. The second through tenth runs are free. I tend to run once, take the feedback, change something, run again — the cache makes the “again” essentially gratis.

Cost matters more, not less

For a team, a few cents per review disappears into payroll. For a solo project running on personal money, the same few cents are visible. CommitBrief shows them with --verbose:

tokens: in 1,840 · out 612 · provider cached: 1,400
Cost: $0.0042

Across a month of a single side project, I rarely cross a dollar. But you can also choose to cross zero, which brings us to Ollama.

The Ollama escape hatch

The Ollama provider talks to http://localhost:11434 and asks for no API key. Pick a coder model that fits your machine, point CommitBrief at it, and you have a review tool that runs without any cloud cost. The quality is not the same as a Sonnet 4.6 review — being honest about that matters — but the gap between “no review” and “Ollama review” is dramatically larger than the gap between “Ollama review” and “commercial-model review.”

For me, the Ollama path is what I run when I’m working on a private repo I don’t want leaving my machine for legal or ethical reasons. For an indie developer working on a paid-customer product, it can be the difference between “I can afford to review every PR” and “I rationed reviews to the ones I felt nervous about.”

What it does not fix

Solo developers don’t have anyone to mentor them, anyone to push back on architectural choices, anyone to say “you wrote this whole module to solve something that could be three lines.” An LLM does not fix that. It catches the easy stuff — pattern violations, typical bug shapes, consistency drift. It does not catch the hard stuff that a senior engineer would catch, because the hard stuff requires context an LLM doesn’t have.

So I want to be careful with how I close this. The tool is not a substitute for a community of practice. If you’re a solo developer who’s been at it for a while, the highest-leverage thing you can do is find one person to review your code occasionally — even one PR a quarter from someone you respect is worth more than a thousand LLM runs.

But the LLM fills a real gap. If you’re going to push the PR anyway because there’s nobody else, running the diff through commitbrief --staged first is the single biggest improvement you can make to your solo workflow with zero coordination cost.

The next post is about something tangential but related: how that workflow extends into air-gapped environments, where even sending the diff to a cloud provider isn’t an option.

---

← all posts