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.
Hey, I'm Jake.
I build fast, solve problems, and lead engineers.
Right now I'm building Merge Lantern, risk intelligence that tells small teams which pull requests need senior eyes before they merge.
I'm an Engineering Manager and Technical Architect. I turn ambitious roadmaps into shipped reality, broken and bloated systems into modern marvels, and chaotic sprints into calm, dependable releases — all without losing the human part along the way.
13 years in and I still love this stuff...the hard problems, the good teams, the moment it all clicks. Poke around; the rest of the site fills in the details.
Currently Reading
Latest Blog Posts
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.