Paper Compute’s Brian Douglas uses expert objections to generated Rust and Go code as training data for a reviewer. His Twin Review is a sensitive-data prototype, not a public release or measured improvement over a held-out baseline.
Capture what never reaches a PR comment
- An experienced teammate may correct a coding agent in a local session: “this API is organized differently” or “don’t duplicate a service we already have.” A final PR can hide those decisions.
- Douglas logs sessions, labels pushback, successful runs and regressions, then looks for recurring conventions the agent did not know.
- His own limited Rust expertise means he might accept code that compiles but violates team choices; labeled expert feedback can surface those issues earlier.
Start with reviewable guidance
- He demonstrates a Twin Review prototype that uses a teammate’s labeled corrections to comment on a PR. He corrects himself: the prototype is not open source, because the underlying data is sensitive.
- Skills and focused evaluations are his recommended first step. Fine-tuning a smaller model is an optional, more costly experiment, not required for the useful feedback loop.
- Preserve consent, access controls and human verification for recorded sessions; a simulated teammate’s comment is a prompt to review, not that person’s approval.
“Whenever he pushes back, it’s a good signal that he has knowledge that the agent does not.” — Brian Douglas