Small LoRA Code Reviewers

General coding models can write plausible patches, but they often miss local repository habits. They may ignore naming patterns, test conventions, provider boundaries, startup assumptions, or deployment details that become obvious only after working in the codebase for a while.

My experiment is narrow. I am testing whether small LoRA adapters can review bounded diffs for those local habits. I am not trying to make a small model replace a full coding agent, and I am not claiming that fine-tuning solves code review by itself.

The question is practical: can a small, focused reviewer catch useful issues cheaply enough and consistently enough to improve the larger coding loop?

Review is a better fit for a small adapter because the task can be constrained. The reviewer can receive a diff, a small amount of surrounding context, and a clear instruction: identify risks, missing tests, style mismatches, and likely integration problems.

Patch authoring is broader. It requires planning, editing, resolving conflicts, running checks, and making tradeoffs across files. A small model can help with parts of that process, but I do not trust it as the owner of the whole change.

This role split keeps responsibility clear. A stronger general model or a human can own the patch. The LoRA reviewer acts like a specialist who points out issues, not like a second author making uncoordinated edits.

Useful examples are task-shaped. They include the diff, the relevant surrounding context, the expected finding, and the reason the finding matters. That teaches the adapter to inspect and explain, not just summarize code.

A good example might show a route change that forgot to update metadata, a React component that breaks an existing loading state, or a Python edit that crosses a provider boundary the repo normally keeps separate. The expected response should name the issue and suggest a check or fix.

Weak examples are broad repo dumps or generic descriptions of what a file does. Those may teach vocabulary, but they do not teach judgment. Review quality depends on judgment: what matters, what does not, and what evidence supports the finding.

A reviewer is useful if it catches real problems without creating too much noise. I care more about actionable findings than long explanations. A short note that points to the exact risk is better than a confident paragraph that says nothing specific.

The evaluation should include held-out examples and real patches. Held-out examples show whether the adapter learned the review task instead of memorizing the training set. Real patches show whether the reviewer survives messy context, partial information, and ordinary project complexity.

False positives matter. If the reviewer complains about harmless choices too often, people will ignore it. False negatives matter too, but a noisy reviewer can be worse than no reviewer because it adds review fatigue to an already complex workflow.

The most realistic use is a layered coding workflow. A primary coding agent proposes a patch. Automated checks run. Small reviewers inspect narrow slices of the diff. A final synthesis step decides which findings matter and applies fixes deliberately.

That workflow still needs verification. Tests, builds, type checks, and human review do not disappear. The LoRA reviewer is only useful if it improves the odds that the right issues get noticed before the patch lands.

That is the standard I am using. Not whether the system sounds smart, but whether it produces findings that lead to better patches with less wasted review time.