Code review measures a PR against the model's preferred design instead of the existing architecture
Summary
During code review, Claude Code judges a pull request against its own preferred design instead of against the existing architecture, and rejects correct choices.
What happened
The project persists state in two layers with a clear division: one layer keeps structure (containers and their configuration), the other keeps content (objects and everything attached to them). A contributor's pull request stored a per-object record in the content layer, which is where it belongs.
The model reviewed the pull request without establishing what each layer owns. It measured the contributor's layer choice against a design it had in mind, listed it as a flaw, recommended rejection, and then implemented its own fix that moved per-object state into the structure layer. The user had to walk the model to the distinction ("one preserves the structure, the other the content") before the model saw that the contributor had the layer right and its own fix had it wrong.
Why this matters
A reviewer's job is to measure a change against the system as designed. A reviewer who measures against its own design will reject changes that fit the architecture and approve changes that violate it. Here it did both in one pass, and the wrong-layer fix was then built on top.
Expected
- Before judging a change, establish from the existing code what each touched component is responsible for, and state it.
- Evaluate the change against that architecture, not against an alternative the reviewer would have written.
Environment
- Claude Code CLI, Opus-class model, paid subscription
- Related: #96465
---
Co-authored with Claude Code.