That first review can work well. Your engineers may already run /review in Claude. They’ve written down what they care about, Claude knows how to read a diff, and it catches bugs. If I were opening a pull request this afternoon, I’d run the command too. When we talk to engineering teams about Proofline, that useful workflow often prompts the question: why add another tool?
The strongest reason to build a reviewer yourself is control. You want to know which model reads your code, where the money goes, and why a comment deserves an engineer’s attention. Those are good things to insist on. Keep them in mind as you consider the work a shared reviewer needs to handle.
Take a small change to a database connection pool: an engineer raises the limit from 10 connections per process to 30. Claude points out that a larger pool could exhaust the database. Good catch. But the author explains that this is a backfill worker and only one copy runs at a time. For this worker, they’re comfortable with the change.
What should the reviewer do with that reply? Repeating the warning on the author’s next push wastes their time. On another pull request, though, someone might make the same change to an API service that runs dozens of copies. There, the warning deserves a close look. Simply adding “we’ve accepted larger connection pools” to CLAUDE.md would teach the reviewer exactly the wrong lesson. Your engineers can tell those cases apart. The software has to carry that distinction forward.
This is what the last 20% looks like. Each detail sounds small enough to handle when someone asks for it. But then the engineer who built your reviewer has a customer feature to ship. The reviewer still runs, so the feature wins. The duplicate warning stays for another month, and every developer who sees it pays a little less attention to the next one. The cost of stopping at “good enough” shows up in their time as well as the maintainer’s.
Proofline handles that distinction by attaching an accepted-risk decision to the finding and the code the reviewer saw. An unchanged finding then doesn’t earn a fresh comment on every push. If a reply contains guidance worth reusing, Proofline can propose a preference for someone to approve. When a risk recurs across independent changes, the team can inspect the pattern and the reviews behind it. In the pool example, seeing the same warning on three pushes tells you something about your reviewer. Seeing it on three different services may tell you something about your architecture. How Proofline handles repeat findings · How review patterns work
Suppose that pattern leads the team to check connection budgets whenever a change touches its database clients. The engineers who own those services should write that rule: they know which paths matter and where an exception makes sense. Proofline can then apply it across the organization, limit its scope to the relevant files, and preserve existing guidance in CLAUDE.md. How it applies those instructions matters too. If a pull request edits its own review instructions, Proofline reads the version from the merge base. The proposed instructions take effect only after they merge. Otherwise, the same pull request could delete a rule and violate it. How review rules apply to a diff
You retain choices over models and spending as well. With Proofline, you can keep Claude, choose which model proposes possible failures and which investigates them, and override those choices for a particular repository. You can also use your own API key. On the Free plan, reviews fully funded by that key carry no Proofline subscription charge; you pay your provider for the tokens you use. That control extends to inspecting disputed findings: either engineer can open the review and inspect the exact commit, the cited lines, and the decision the team recorded. Model choice and billing · What a review records
Those review records still leave a harder question in the pool example. Thirty connections per process is right there in the diff, but how many processes run in production? What else shares that database? The model can do the arithmetic, but someone still has to supply the numbers and establish when they were true.
That’s why we’re building Kian, Proofline’s model of the cloud environment. Its job is to record facts such as what runs where and which limits apply, so a reviewer can cite the basis for a claim about production. Environment checks are currently disabled while that work rolls out. For now, a code review of the pool change can identify the multiplication that matters. Until the runtime evidence is available, though, the production connection budget remains an open question. How Kian represents infrastructure evidence
To judge the reviewer available today, pick a repository your team knows well and run Proofline alongside your usual review for a few pull requests. If you already have a review prompt you like, bring it. Keep the trial running through the second push, after the author has answered a finding, and into the next pull request, where a similar change deserves a different answer. Use that time to judge whether the system remembers the right things, stays quiet when it should, and gives your engineers enough evidence to disagree with it. It’s also a fair test of how much of that work you want to own. Try Proofline on a repository