I built a lot of apps last year. I approved most of the code and commits that went into them, and a good portion of it I could not explain.
Not "c...
For further actions, you may consider blocking this person and/or reporting abuse
This is an interesting distinction. AI can make implementation faster while quietly weakening the review loop because the code “looks reasonable” before you’ve actually challenged the assumptions behind it.
I’ve found the harder part isn’t reviewing more code — it’s knowing which assumptions are worth questioning first.
The 'vary the question and only fire on non-trivial diffs' constraint you name as a hope is something we've been running for about six months on data pipeline code, roughly. Before any merge, the reviewer has to tag the three paths through the diff they're least confident about. It's imperfect and people do game it on small changes, but it's caught several issues in exactly the category you describe: code that looks right because the shape is familiar, not because anyone checked the assumption underneath. We still haven't solved the 'monotone answers' problem on long-serving reviewers, where the same three paths get tagged every time.
This is why I have been thinking of what to build to remedy this problem, both for solo devs and teams
This is where review becomes the hidden tax. The model saves time on the first draft, then spends part of that gain on checking diffs, tests, and edge cases you would have noticed while writing it by hand.
Yep, and the question now becomes, how can we ensure we always check, and could this new and current flow be the best for us?
The distinction between reviewing code and actually understanding it is important. A green test suite can tell us that the current behavior passes, but it doesn't tell us whether the reviewer understands why that behavior exists or what assumptions it depends on. Making reviewers explain the change before seeing the implementation could be a surprisingly effective way to expose that gap.
Love the article, but love the list of sources at the end just as much.
I swear to you, I was talking to my friend sitting next to me as I read through it and TWICE our conversation brought up some non-specific study we half remembered that was was relevant... only to see the exact study referenced a section or two later.
A great analysis of the state of engineering learning and decay in our modern world with sources. Thanks!
There is a nice operator angle here: the best implementation is often the one that makes a bad state obvious early. A clear signal, an owner, and a reversible response path beat a more sophisticated design that fails silently.
I wanted to disagree with this. Instead I counted, and the number sided with you harder than your thesis does.
Of the 204 automated checks in my repos that stand in for my judgment as a reviewer - the ones asserting "no workflow pulls its cache over the network", "every page uses the same filter" - only 22 can prove they are able to fail. 11 %. The other 89 % have never seen a known-bad input. Green because everything's fine, or green because they're incapable of finding anything? Until last week I couldn't have told you, and I wrote them.
So I'd sharpen your line: AI didn't make us worse reviewers. It promoted us all to reviewers - and nobody tested the reviewer. My application code has coverage requirements; my review tooling had none.
It inspired me to write a full article about this - I'll post the link here once it's live. Honest question back: what's the greenest check in your pipeline that you now suspect has never been able to fail?
Just maybe code review is not your thing 😂
Don't make the reviewer carry the history. Make the system's structure carry the reason.
What if we design the artifact so cognition doesn't have to carry unnecessary historical load?
That's a very different solution to the problem you're describing.
To clarify: I'm not suggesting architecture replaces judgment. I'm suggesting we distinguish necessary judgment from judgment spent reconstructing things the artifact could have made explicit. The former can't be outsourced; the latter can often be designed away.
love your writing style and content thanks you for your time
AI makes review discipline essential.