When the Same Names Fill the Reviewer Column
When review depth follows risk, the high risk work falls on the same two or three seniors every week. Here are three ways to spread that load without lowering the bar.
#engineeringmanagement
9 posts tagged #engineeringmanagement.
How Hard Should You Review This? Ask What It Touches.
When an agent helped write a pull request, the first question most reviewers ask is who wrote it. I think the better first question is what it touches. Here's how I'd set review depth by risk, where authorship still fits, and why some changes may need very little review at all.
Where Trust in Automated Review Actually Comes From
When your team stops trusting its AI code review, the obvious fix is to add a second AI. I don't think that buys you much...two models trained on the same internet share the same blind spots. What actually helped me was checking the evidence outside the diff. I tried it on a real queue of 58 open PRs, and here's what it caught.
Pair Programming Earned a Lighter Code Review. AI Hasn't.
On a lot of teams, code that a pair of devs wrote usually gets a lighter code review. Nobody wrote that rule down and nobody voted on it, but pairing earned it. Here's what the research actually says about that discount, why it's never one flat size, and what happens when dev + agent starts getting filed under the same category.
The Warning That Took My Site Down Was in the Log the Whole Time
A one-line warning in my deploy log took my site down for thirty minutes. It didn't stop anything, the command exited zero, and it looked like every other line scrolling past. Software risk stays invisible until traffic hits it, and that invisibility is why the work that prevents incidents is the first thing a deadline cuts.
The Stale Feature Flag We Deleted That Turned a Feature Back On
Deleting a year-dead feature flag turned a forgotten feature back on and broke production...here's why flag cleanup is a runtime change, not tidying, and how the context you need decays while the flag sits there looking harmless.
The Real Reason Your PRs Get Big
Big PRs don't come from lazy engineers. They come from a skill almost nobody gets taught: how to cut a piece of work down into small, reviewable chunks. Here's why that's still the highest-leverage habit in engineering... and why AI just made it matter more, not less.
Merge Standards That Actually Get Followed
Most merge standards are wiki decoration. What makes a team actually follow them isn't the list...it's enforcement, consistency, and the why.
The Code Review Checklist I Actually Use
Most code-review checklists ask "does this work?" The harder question is "what happens when it doesn't?" Five things I check on every PR that the standard checklists miss... plus the comment grammar that makes reviews actually move.