11–20 of 24 posts
Trying to enforce "deep understanding" is optimizing wrong layer. Focus on: . Fast rollback . Good observability . Small PRs Understanding become emergent, not enforced.
You still need other humans to validate and check. For any design docs, have them do a walkthrough with the team. If they have to speak to their plan live and answer questions, it will be obvious if they've put thought into it or not. The same thing can be done for any PRs that have some depth to them like if they touch critical logic or involve complexity.
Code reviews don't catch bugs, tests do. AI writes docs fine if your tests work. Juniors learn by shipping, not memorizing patterns. Stop forcing explanations. Build systems that auto-rollback and alert you. That's engineering.Understanding every line is dead. Monitoring and fast feedback matter way more.
Code reviews don't catch bugs, tests do. AI writes docs fine if your tests work. Juniors learn by shipping, not memorizing patterns. Stop forcing explanations. Build systems that auto-rollback and alert you. That's engineering.Understanding every line is dead. Monitoring and fast feedback matter way more.
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?”
I ended up building a small OSS tool around this idea called Tears: https://github.com/Thillel/tears
The slogan is a bit tongue-in-cheek, but it captures the point: vibe-code responsibly.
What works in my experience:
1. Code review with "explain this to me" questions. Not gotchas, genuine "walk me through why this works." If they can't explain it, it doesn't merge.
2. On-call rotation for what you ship. Nothing motivates understanding like being woken up at 3am by your own code.
3. Pair programming on complex features. Not watching - actually driving together.
The real question is: are they shipping code they don't understand because they're lazy, or because the codebase is so complex that nobody fully understands it? If it's the latter, the problem isn't the engineers - it's the architecture.
Of course that is perfect for MVPs, speed runs, getting the general shape of something before you commit to an implementation but for many classes of production code that is too high of a risk to take.
I'd like to hear other's experiences however. Has anyone found a way to get >10X productivity gains with AI in production code with AI?
Diff reading is not a practice forced on developers from above. On the contrary, it is the only way for a developer to stay competent enough to lead the next session properly.
Instead of discussing how to ensure that developers will understand the importance of diff reading, the question here is whether the developers understand they cannot shift the responsibility of creating a mental model of the system away from themselves and still maintain effective control over the agent's behavior.
Having said that, if you want to know if an engineer really gave it a thought before having the AI do the work - you can ask things like "why did you decide to design it like this" - in person