#ai

AI made coding faster, and the common advice now is to cut process everywhere so all that extra code can flow through. But some of those steps were catching risky changes before they reached users. Here are the three questions I ask to tell the process worth cutting from the process worth keeping.

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.

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.

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.

When making something gets cheap but judging it stays expensive, the cost slides downstream...social media did it to your feed, AI code generation does it to your repo. The difference is a bad post washes away by morning, and a bad merge sits there for years.

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.