So a few days ago I was in a comment thread arguing about whether AI is quietly ruining junior developers' ability to develop actual judgment, and someone dropped a phrase that's been rattling around in my skull ever since: predict-then-diff.
The idea, roughly: before you even look at what the AI generated, you write down what you expect it to look like. Then you compare your prediction against the actual output. The gap between the two is the lesson. It's basically forcing yourself to have a hypothesis before you're allowed to see the answer, instead of just reading the answer and nodding along like it's gospel.
I decided to actually try it for a week instead of just intellectually agreeing with it in a comment section like a coward. Here's what happened.
First task, I needed a function to paginate through a list in SwiftUI. Normally I'd just prompt it and glance at the output, mentally file it under "looks fine," and move on with my day like a functioning member of society.
Instead, I sat there and actually wrote out what I expected: probably some kind of LazyVStack
, maybe an onAppear
trigger near the bottom of the list to load more, some state variable tracking the current page.
Then I looked at the actual output. It used .task
instead of onAppear
, which, fine, reasonable, slightly more modern. But it also introduced a Task.detached
I did not predict, was not expecting, and did not understand the reasoning behind at all.
And this is the part nobody warns you about: the gap didn't feel satisfying. It felt like being wrong on a pop quiz. My brain, used to just accepting whatever compiled, was mildly betrayed by being asked to have an opinion first.
Immediately understood why nobody does this voluntarily. It's uncomfortable in a very specific, very unfamiliar way.
Okay hear me out. There's this bit in Frieren where she's spent so long assuming magic works one specific way, based on centuries of pattern, that she genuinely doesn't notice when something breaks the pattern right in front of her, because she stopped predicting and started just recognizing shapes.
That's what "just reading the diff and moving on" had quietly turned me into. I wasn't evaluating AI output anymore. I was pattern-matching "looks like code I've seen before" and calling that comprehension. Predict-then-diff was the first thing in months that actually made me stop and go "wait, do I actually know why this works, or do I just recognize the shape of it."
Turns out, for a genuinely humbling number of things, it was the second one.
By day three I caught myself predicting a force-unwrap in a spot where the AI instead used a guard clause with a proper early return. My prediction was the worse code. The gap taught me something real, and it wasn't even about the AI being smart — it was about me finally noticing my own instinct was rustier than I thought.
Here's the one that made the whole experiment worth it. I was reviewing some networking code, predicted the error handling would use a simple do-catch with a generic error message, standard stuff. The actual output silently swallowed a specific network timeout case and returned a cached value instead, with zero comment explaining why.
If I'd just read it top to bottom without predicting first, I'm being honest with myself, I probably would've accepted it. It compiled. It looked plausible. Looked exactly like the kind of "smart caching fallback" pattern I've seen in real code before. But because I'd already committed to a prediction that didn't include silent fallback behavior, the gap actually stopped me. I asked why. Turned out the fallback was masking an actual bug in how the timeout was being detected upstream. Would've shipped a caching bug pretending to be a feature. The prediction is what made me suspicious enough to dig, instead of just vibing my way past it.
That's the whole argument for this technique in one story, honestly. The catch didn't come from being smarter than the AI. It came from having a committed hypothesis on record that the actual output failed to match.
I'm not going to pretend this is sustainable for every single line of code, every single day, forever. Some things are genuinely trivial and predicting them first is just theater. Nobody needs to write down their hypothesis for a getter.
But for anything with actual logic, anything where a wrong call could compound into a real bug later, I think the method is legitimately doing what it claims: it's relocating the reps. It's manufacturing the exact moment of "wait, is this actually right" that used to only show up naturally after you'd already been burned by your own mistake in production. Except now it shows up before shipping, on purpose, for free, if you're willing to sit in the mildly annoying feeling of being wrong on a pop quiz a few times a week.
The posture really is the whole thing. Reading a diff and nodding treats the output as an answer. Predicting first treats it as a hypothesis you're allowed to be wrong about. Only one of those postures actually builds anything.
Has anyone else actually tried something like this, on purpose, instead of just agreeing it's a good idea in the comments and never doing it? Did it stick for you, or did you quietly drop it after day two like every other good habit I've ever attempted?
And be honest: last time you accepted AI-generated code, did you have any prediction at all going in, or did you just read it once and go "yeah that tracks"?
Disclaimer: This article was written based on my own experiences and opinions. AI tools were used to help with grammar and structure, but the story, ideas, and voice are entirely my own.