Let’s be honest about what AI took from us. It wasn’t the typing. Typing was never the good part.

The good part was hitting a wall. Some bug you had no clue how to solve, the kind where you smash your face on the desk for two hours, go for a walk, come back, and then finally crack it. That little hit of “I figured it out!” We were all quietly addicted to that. And then AI took our supplier.

So now we’re a bunch of dopamine junkies, wandering around looking for a new fix. That’s what I want to talk about… how you find enjoyment in a job after AI walked off with your favorite part of it. Good news, up front: it didn’t disappear. It moved up a level. And self-review is the most immediate hit still on the table.

The dopamine moved

Name the loss plainly, because pretending it isn’t real is why so much AI-assisted work feels hollow even when you’re shipping more than ever. The reward of programming was never producing the code. It was the eureka moments. You run into a wall, you flail at it until something gives, and you get your fresh little bump of dopamine. Ahhh. Feels great. That loop is what trained you and kept you coming back for more. And it’s the exact loop AI short-circuits, because now the wall just… isn’t there. You describe the wall and something hands you a door.

But the hit didn’t vanish. It moved to the second-order work. Same dopamine, higher up the stack. You just have to know where it relocated to.

Two places, mostly.

First, self-review. This is the fastest fix still available, and I’ll spend most of this post here. You can still earn real mastery of a system and speak to it in detail. That “oh, I get it now” moment is completely intact. You just get there by interrogating the code instead of typing it. And I do mean interrogating. Not skimming, not nodding along because the tests are green. Actually pinning the diff to the wall and asking it questions until it confesses.

Second, the design doc. You still draft the plan. The plan can still be your idea, born from your understanding of the system and the tradeoffs you car about. It’s totally fine to run that idea past AI, poke holes in it, let it argue back. But a clean design that makes a genuinely messy problem look obvious? That’s a bigger hit of dopamine than any single bug I ever fixed., That one still lands.

Here’s what made all of this click for me. AI is a member of your team who is executing on your plan. You didn’t get replaced as the author. You got promoted to the person whose plan gets executed. That’s not a demotion dressed up in a nice sentence, it’s actually the thing a lot of us said we wanted, back when we were buried in implementation and wishing we had time to think. It’s what Senior ICs have been trying to do all along.

You’re an editor now, not an author

When you write code yourself, understanding comes free. It’s a byproduct of typing it out, line by line, making a hundred tiny decisions you don’t even register as decisions. When you accept code, that understand is a separate step. A step you have to consciously choose to take. And a lot of people are skipping it, because the code already looks finished. It’s formatted, it has comments, the tests are passing. Why would you read it like a hawk?

Because of the gap that didn’t used to exist. The can be completely correct and you can still have no idea why it works. “Correct, but not understood” was basically impossible when you were the one writing it. Now it’s the default state of every diff that lands in front of you.

Think about what an editor in journalism actually does. An editor doesn’t write every word, but they stand behind every word. They can defend any choice on the page, explain why it’s there, tell you what they cut and what they kept and why. That’s the job now. Self-review is where you turn “AI wrote this” into “I’m putting my name on it”.

So put the diff on trial. The questions we should be asking are…

• Do I understand why this works, or just that it works?
• Would I have made these same tradeoffs? If not, why am I letting them stand?
• What breaks that nothing here is testing?
• Is there a simpler version the model didn’t bother reaching for?

Yea, this is a lot slower than hitting submit, but that slowness is the job now. It’s not overhead getting in the way of the work, it is the work.

The tell

Reviewers can always tell when someone doesn’t understand their own PR. Always. I have never once been fooled by it and neither have you.

It surfaces the second anyone asks a real question. Why this approach over the other one? What happens if that value comes in null? What does this dependency even do? And the author just… shrugs? Maybe pastes the question into a chat window right there in the meeting.

That shrug used to read as careless. Someone rushed, someone junior, someone who’ll learn. Now it reads as something worse: you shipped the machine’s first draft without reading it, and you’re asking the rest of us to be the review step you skipped.

And loo, “it passed the tests” is the new “it compiles.” Necessary, sure, but nowhere close to sufficient. Especially when you didn’t write those tests either, and the model that wrote the code also wrote the tests, and they’re both quietly agreeing to only check the happy path.

Don’t be the person defending code you never actually ready. It’s a bad look at every level, and it gets worse the more senior you are.

And while I’m on my soapbox… I talk to AI all day long. When I am talking to you, a human, I want a human interaction. Don’t copy my questions into Claude, then copy Claude’s response to me. If I wanted that, I’d ask Claude myself and get a better contextual answer in faster time. I want your answer.

Where to actually put your attention

I’m not going to give you fifteen bullet points. Three things carry most of the weight.

Read it like a stranger wrote it. A stranger did write it. Drop the reflex to trust the polish. BE SKEPTICAL.

Explain it out loud. If you can’t narrate why each piece is there, to a rubber duck or a coworker or the empty room, you didn’t review it. You skimmed it. The narration is the test.

Review the tests harder than the code. This is the one that’s skipped most often. The model tends to test the exact happy path it just built for, so the tests confirm the thing you’re already worried about instead of challenging it. Go find the case that isn’t in there.

I’m Matt Wagner and I approve this message.

I spent years learning to write code I’d be proud to put my name on. That didn’t die when the machine started writing it. It just moved. The pride isn’t in the authorship anymore, it’s in the review. You didn’t write the first draft, but self-review is where you decide whether you actually stand behind it. And standing behind it, not writing it, is what your name always meant anyways.

And that hit you’re chasing, the one from cracking a hard problem at 11pm with cold coffee and three tabs of Stack Overflow open? It’s still there, it just comes from somewhere else now. From reading a diff and genuinely getting why it works. From watching a plan you drafted get executed cleanly by a teammate who happens to be a machine. Same dopamine. Better leverage. You just have to know where to look for it.

At least that’s what I keep telling myself. lol