I think there are two different problems that get mixed together here:
1. Did the engineer personally understand this change?
2. Is this change allowed to affect critical parts of the system?
The first one is hard to enforce mechanically. You can require design docs, tests, PR explanations, walkthroughs, etc., but a determined person can route all of that through an LLM too.
The second one is more enforceable, and I think it matters a lot in the AI-coding world.
Not all code deserves the same review posture. A dashboard, script, prototype, migration helper, etc. should be able to move fast. But auth, billing, security-sensitive logic, and core business rules should not quietly depend on code that was “just agent output” or barely reviewed.
The pattern I’ve been experimenting with is explicit trust/review tiers in the codebase:
- low-risk / vibe-coded code can exist
- agent-touched files get marked as lower-trust
- humans can restore trust after review
- CI enforces that high-trust code cannot import lower-trust code
- critical directories can be required to stay high-trust
This doesn’t prove the engineer understood the code. Nothing really does.
But it does create review memory in the repo. If a file was touched by an agent, that state is visible in the diff. If someone promotes it back to a trusted tier, that promotion is also visible in the diff, and reviewers can ask “did you actually read this?”
Super frustrating to develop side features so quickly with claude code, then to be stuck forever on code review. some code is less important than others. I developed tears to mark code that was vibe-coded for future memory, and to enforce it never gets used by critical code paths, and to enforce critical files never go unreviewed. its a small cli linter, integrates with coding agents and your ci-cd. or as i call it - Vibe Code Responsibly