Reviewing is the new 10x

Linear recently launched their diffs, and honestly it gave me a ton of validation, because a few weeks prior I’d landed on the exact same conclusion they did: code review is something that needs to change, and it needs to change soon.

And the reason I think it needs to change comes down to a pretty simple shift. Writing code is getting cheaper by the day. I can describe a feature, step away for a bit, and come back to something that mostly works. That used to be the hard part of the job, and now it kind of isn’t.

But there’s a second cost that nobody really talks about, and it’s quietly moving the other way. Understanding what just got written is getting more expensive. So is making sure it’s actually sound, and so is fitting it into the rest of the codebase. You’ve got more code now, written way faster, by something that doesn’t hold all the context the way I do. And all of it still lands on my desk to make sense of.

So there’s this widening gap between how cheap code is to produce and how expensive it still is to trust. That gap is probably the most important thing happening in our craft right now, and I don’t think enough people are really pricing it in yet.

The 10x engineer flipped

For the longest time, the definition of a 10x engineer was basically raw output. They shipped more, they shipped faster, and they shipped cleaner, so their hands were really the differentiator.

That whole definition is kind of dead now though. When everyone’s got agents that can churn out a thousand lines in under an hour, output just stops being scarce. It’s basically a commodity at this point. What’s actually scarce now is the person who can look at those thousand lines and know, quickly and correctly, whether they’re right, whether they belong, and what they’re going to quietly break three files over.

Which means the 10x engineer today is really the one who can review the most code without their judgment degrading along the way. Leverage pretty much moved from the keyboard up into the eyes.

I mostly just prompt manage now

Nowadays most of my raw code output is written by AI, with me prompt managing the whole thing, and I’m genuinely okay with that. I’m not really sitting down to grind out a component from scratch anymore. Instead I’m pointing agents at problems, letting them take a swing, and then spending my actual energy on the part that’s left over: figuring out whether what came back is any good.

And that part, the judging part, is honestly where my value lived the whole time anyway. The typing was just where I happened to spend most of my hours. So now that the typing is mostly handled for me, all that’s really left is me being the human in the loop, and that loop only works if I’m fast and rigorous about the review.

So I built my own review flow

Once it really clicked that review was the bottleneck, I started reshaping my whole workflow around it. That’s a big part of why I ended up switching to neovim, which is a whole story for another day. But the thing that actually came out of it is a local-only review flow I built into a plugin I call hunk-review.nvim.

And yeah, this is the thing I’d built a few weeks before Linear shipped their diffs. We were both circling the same problem, I just got to mine from the terminal.

Why hunks are the right unit

The thing that unlocked all of this for me was hunk-based review.

A diff isn’t really a list of files when you think about it. It’s more like a list of changes that happen to be scattered across a bunch of files, and most of any given file is just noise I don’t need to look at. The real signal is the hunks, the specific lines that actually moved.

So reviewing file-by-file means scrolling past a sea of unchanged code just to find the three blocks that matter. Reviewing hunk-by-hunk means I only ever look at what changed, in whatever order makes sense to me, hopping straight from one meaningful block to the next. When you’re validating an agent’s work, that second way is really the only one that scales.

How it actually works

When I’ve got an agent’s changes to go through, I just run :HunkReview and the whole diff opens up in a two-pane layout. File explorer on the left, the actual diff on the right, all keyboard-driven so I never have to touch the mouse. I hop between hunks with j and k, peek into the full source file in a floating window with p when I need more context, and cycle between my uncommitted changes, the target branch, and main without ever leaving the buffer.

When I spot something that needs work, I drop a comment right on the block, the line, or a whole range with c. Those comments stick around for the session and pile up in a little sidebar I can jump through later.

But here’s the part that actually closes the loop. Once I’ve walked the whole change, I export everything as structured JSON with Enter. That export carries the file paths, the line numbers, my comments, and the surrounding diff, which is basically everything Claude Code would need to act on my feedback without me re-explaining where I am or what I meant. I can even prepend a custom prompt so the whole thing lands in the agent ready to go.

So the workflow turns into a loop that genuinely feels good to work in:

• The agent writes across however many files.
• I run :HunkReview and walk every hunk, only ever looking at what changed.
• I comment directly on the lines that need attention.
• I export it all back to Claude, and it iterates on exactly those notes.
• And we just repeat that until I’m happy

So I end up reviewing more code, faster, with way less of my attention leaking out into navigation and busywork and more just being in raw flow state.

Going into a review-first future

I think we’re all going to end up here, whether we build the tooling ourselves or wait for it to show up in our editors. The cost of writing code is going to keep falling. The cost of trusting it is going to keep rising. The engineers who win the next few years are the ones who treat review as the main event, not the chore you do after the real work.

And look, I’ve made my peace with the fact that I’m not the fastest hands in the room anymore, because these days the model is, and that’s totally fine by me. I’m still on top of every single thing that ships, and I’m only really able to be because I went and built the tools to fly through all of it.

That, to me, is pretty much what being an engineer means now. And honestly? I kinda love it.