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 ...
For further actions, you may consider blocking this person and/or reporting abuse
Writing the prediction first is such a useful habit because it separates learning from post-hoc agreement. Without that step, it is too easy to read the AI answer, accept the parts that sound good, and forget what you actually believed before seeing it. The small friction is the feature.
"The small friction is the feature" is such a clean way to put it, because the temptation is always to remove friction from the workflow, and this is one of the rare cases where the friction is doing the actual work. The moment you remove it you're back to post-hoc agreement dressed up as review, and the learning disappears with it. It's not friction for its own sake, it's friction that creates the gap between your prior and the output, and that gap is the whole point.
That is the line I keep coming back to: not all friction is waste. Some friction is the shape of thinking. If the prediction step feels slightly annoying, that is often a sign it is doing its job, because it prevents the model output from becoming the first and only frame for the problem.
"Some friction is the shape of thinking" — that's a really good way to put it, and it flips the usual instinct completely. The default assumption in most workflows is that friction is inefficiency to be optimized away, and usually that's right. But the prediction step is one of those rare cases where the friction and the value are the same thing — if it stopped feeling like a small effort to commit to something before seeing the answer, it would mean the commitment had stopped being real. The slight annoyance is evidence that you're actually doing it rather than going through the motions of it.
Yes, and that is why I would be careful about optimizing the prediction step too much. If it becomes effortless, it may stop forcing an actual commitment. A little friction creates a timestamped mental position. Without that, the model answer can quietly rewrite what you think you thought.
"Quietly rewrite what you think you thought" is such an accurate description of what happens without the friction — it's not that you consciously change your mind, it's that the model answer becomes the first frame so fast that your prior never really had time to exist independently. And because the rewrite is quiet you don't even notice it happened, which means you can't learn from the gap because you no longer remember there was one. The slight resistance of actually committing to something before you see the answer is the only thing that keeps the prior real enough to compare against. Optimize it away and you're back to post-hoc agreement with extra steps.
Writing the prediction first is a useful anti-hallucination habit for humans too. It forces you to separate your own model of the problem from the model's answer. The comparison becomes more valuable than the answer because it shows where you were vague, biased, or missing constraints.
"The comparison becomes more valuable than the answer" is a really good way to put it — the answer is just output, but the comparison is actually diagnostic. It tells you something about your own model of the problem that the answer alone never could, because the answer only shows you what the model thinks, not where your thinking and the model's thinking diverge and why. The places where you were vague or missing constraints only become visible when you have something to diff against, and without the prior prediction you'd just absorb the answer and move on without ever seeing the gap.
Yes. The prediction turns the AI answer into a diagnostic tool.
Without the prior guess, the model output is easy to consume passively. With the guess written down, the gap becomes visible: missing constraints, weak assumptions, hidden ambiguity, or a place where the model had useful context you did not.
The "useful context you didn't have" direction is one I find genuinely interesting and don't think about enough — most of the framing around predict-then-diff is about catching where the model went wrong or made a different call than you would have. But sometimes the gap runs the other way, the model had something right that your prediction missed, and that gap is also diagnostic in a useful way. It shows you a constraint you weren't modeling or an assumption you were making implicitly. Being wrong in that direction is just as informative as being wrong in the other one, maybe more so because it's less comfortable to sit with.
That uncomfortable direction is probably the most valuable one. It is easy to notice when the model is wrong and you were right. It is harder to notice when the model exposed a constraint you did not even include in your mental model. That is where the prediction log becomes less about scoring the AI and more about auditing your own assumptions.
"Auditing your own assumptions" is the reframe that changes what the whole exercise is actually for — because if it's just about scoring the AI, you're looking for places where the model was wrong and you were right, which is satisfying but not always the most useful direction. The prediction log as an assumption audit is harder to sit with because it means looking for the places where your model of the problem was incomplete, and those are exactly the gaps you didn't know you had. The model exposing a constraint you never included isn't a win or a loss, it's just information about where your mental model had a hole, and that's worth more than catching a mistake you already knew to look for.
I don't know if this makes sense or not, but would it work if you'd ask the AI tool to explain what it just generated, and to question how it came to the decisions it made?
But, I realize that that might just result in some vague and/or defensive answers, and you're non the wiser - "predicting" the result and comparing it to what was actually produced allows you to ask more specific questions ...
I also like the idea of
c0d3l0v3rbelow - you scaffold a file with some comments or pseudo code, which already encode some of your expectations, and then ask the AI tool to "fill in the blanks", using the comments and/or the pseudo code as a guide ...Okay so the instinct to ask the AI to explain its decisions — I've been there, done that, multiple times 😄 And you actually already spotted the problem yourself, which is exactly it. The explanation lands after the output, which means it's already anchored to whatever was produced. The model is genuinely very good at generating a confident, plausible-sounding rationale for whatever it just did — which sounds helpful until you realise you have no independent prior to check it against. So you end up nodding along to an explanation that may or may not reflect what actually happened, and you're none the wiser, like you said.
The predict-first approach kind of sidesteps this whole problem because your expectation existed before you saw anything. So when something diverges, you're asking why it did X instead of Y from a place of genuine curiosity rather than trying to evaluate a justification for something you've already half-accepted.
And yes, I love the c0d3l0v3r approach you mentioned — encoding your assumptions into the prompt itself before anything gets generated is a really clever variation of the same instinct. It's upstream rather than parallel, if that makes sense. The structure you scaffold forces the AI to work within your mental model rather than arriving in a vacuum and presenting you with its own. Might actually complement predict-then-diff well — scaffold first, predict the specific implementation, then open the result. Different shapes of the same underlying discipline. 🌸
Yeah point is also that normally it wouldn't have remembered the decisions it took (if you can even say it "takes decisions" - that might already be too much of a anthropomorphic view) ...
Let it write a plan first - the "plan and act" pattern, instead of only "act"? If the plan doesn't look good, you don't go ahead with the code generation ...
Or ask it to generate the code and write an explanation of why it did what it did? Lol at this point I'm just making things up more than making sense, probably ...
The problem with both 'manual prediction' (before the fact), and with 'manual review' (after the fact) is that it's labor intensive, partially negating the alleged performance gains - but, maybe both ('prediction', and 'review') can be AI-aided ...
The memory point is a good one — even if the explanation sounds confident, it's reconstructed from the output rather than retrieved from an actual decision log, which means you're getting a plausible story rather than a record. That's part of why asking after the fact feels less reliable than having your own prior before anything was generated.
The plan-and-act pattern is interesting and I've tried versions of it — the thing I've noticed is that a plan that looks good is still pretty easy to nod along to, for the same reason a diff that looks good is. You're still evaluating someone else's output rather than committing to your own expectation first. Though I think it's genuinely better than act-only, especially for anything architectural where the shape of the solution matters more than the specific lines.
On the labor intensity question — yeah, that tension is real and I don't want to pretend predict-then-diff is free. It's a deliberate slowdown, and the honest case for it isn't that it's efficient, it's that the thing it costs time on is exactly the thing that pays out later when something breaks and you actually understand what you're looking at. Whether that trade is worth it probably depends on what you're building and how long you need to live with it. AI-aided prediction and review is an interesting direction though — if you could get a model to generate adversarial predictions against its own output before you see it, that might be something. 💕
The "predict then diff" pattern is for sure interesting, I'm keeping that one in the back of my mind ... yeah for anything that's labor intensive, it can of course be worthwhile to try and have AI help with the "grunt work", while you remain at the steering wheel and in control of the 'strategy' - guiding the agent, but remaining in control ...
Yeah, that's probably the most sustainable version of it, honestly—you handle the judgment calls and let the AI handle the mechanical parts, rather than letting it handle both and wondering later which decisions were actually yours. The steering wheel framing is a good one. The problem is that it's easy to drift from steering to just approving, especially when things are moving fast and the output looks fine, and by the time you notice you've drifted, it's usually because something broke and you're not sure why. Predict-then-diff is kind of just a forcing function to stay at the wheel rather than quietly becoming a passenger.
That "Frieren moment" analogy is absolutely spot on. Over the last few months of heavily relying on AI tools, I’ve quietly noticed my own coding instincts getting incredibly rusty. You stop evaluating the logic deeply and just pattern-match the general "shape" of code you've seen before. The prompt-and-accept loop makes you feel like an absolute speed demon until something weird breaks in production and you realize you don't actually understand how the code you "wrote" works under the hood. The mild suffering of forcing a prediction is probably exactly the kind of friction we need to keep our brains from rotting.
The "pattern-matching the shape" thing is so real and I think it's the sneakiest part of it — because it still feels like you're reading carefully, you're looking at the code, it seems familiar, it looks right. But familiar and right aren't the same thing and the prompt-and-accept loop trains you to treat them as equivalent until something breaks in production and the difference becomes very obvious very fast.
"Speed demon until something weird breaks" is exactly the arc honestly 😄 The velocity feels genuinely good in the moment, there's nothing obviously wrong, features are shipping, and then one day you're staring at a bug and you realise you don't have a hypothesis because you never built the mental model that would let you form one. That's the moment the bill arrives.
The mild suffering framing is the one I keep coming back to too — it's not about making things harder for the sake of it, it's that a small amount of friction at the prediction stage is so much cheaper than the large amount of confusion later when you need to understand something you accepted without thinking. The Frieren analogy felt right to me because it's not that the skills disappeared, it's that they quietly atrophied from disuse while everything looked fine on the surface. 🌸
"Completely. It's like the difference between active recall and just skimming a book. The 'mild suffering' of forcing your brain to actually figure out the next step before looking at the AI suggestion is the only thing keeping those cognitive muscles from wasting away. I've started forcing myself to write out the logic in plain comments first before letting any autocomplete trigger, just to make sure I'm still the one driving the architecture."
The active recall analogy is exactly right — skimming feels like learning because you're processing words and concepts, but the actual retention comes from the retrieval effort, and autocomplete short-circuits that effort in exactly the same way that reading the answer short-circuits flashcard practice. Writing out the logic in plain comments first is such a clean version of this because it forces the thinking to happen before any suggestion arrives, which means the architecture decision is genuinely yours before the AI has a chance to anchor you to its version of it. The comment then also doubles as documentation, which is a nice side effect of a habit that's already doing useful work.
I take a different approach i write the code functions and the basic structure and the comments along with that say if i want to define a postgres connector then after making the function to connect the db i write
'''
// add the connector to postgress, take the DB_URL,DB_PORT from env
'''
inside the connect function. This way i predict before the AI predicts it.
By doing this i am sure AI does not break any assumption in the codebase.
I also think this might feel like old school but i prefer it because it is good for learning.😅😁
This is actually a really elegant variation of the same instinct — instead of predicting what the AI will do after the fact, you're encoding your assumptions into the prompt before the AI even starts. The comment-as-specification approach means the prediction is baked into the structure rather than written separately, which is clever because it also doubles as documentation. 😊
And honestly, "old school" is doing a lot of work as an insult these days — writing your intent down before generating is exactly the discipline that keeps the AI from quietly making assumptions you didn't agree to. The learning benefit you mentioned is real too. 🌸
Predict-then-diff is basically a lightweight eval you run in your head, and the Day 5 catch shows why it works: the silent fallback returning a cached value only looked wrong because it did not match your prediction. That silent-failure class is the hardest to catch in review because nothing throws and the output looks reasonable. I have started writing the prediction down as an assertion where I can, so the gap becomes a failing check instead of a gut feeling I might skip on a busy day.
Writing the prediction as an assertion is such a clean extension of this — you're basically externalising the gut feeling into something the system can actually enforce, which means it doesn't depend on you having the discipline to catch it on a busy day. That's the exact failure mode I'm most worried about with the mental version, honestly. The predict-then-diff habit works great when I'm paying attention and have the time to be deliberate about it. But on a busy day, under deadline pressure, the temptation to skip straight to accepting the output is strongest exactly when slowing down matters most.
Making the prediction a failing check rather than a feeling is a really smart way to close that gap — the check doesn't care whether you're tired or in a hurry, it just fails if the assumption was wrong. And the Day 5 silent fallback is the perfect example of why that matters, because nothing threw, the output looked fine, and the only thing that made it suspicious was having committed to a specific expectation beforehand. Without that, a careful read would have just seen plausible code and moved on.
I'm curious—did making a prediction first reduce the number of follow-up prompts you needed with the AI?
Really good question, and honestly one I'm still working through myself! 😊 The approach that's resonated with me most is mutation testing — deliberately introducing small bugs into the code and checking whether the tests actually catch them. If a test passes even when the code is broken, it's not really testing anything meaningful, just providing coverage theatre.
Beyond that, the predict-then-diff habit from the article applies here too — before reading what tests the AI generated, writing down what edge cases you think should be covered, then comparing. The gap between your list and the AI's list is usually where the meaningful missing coverage lives. Code coverage tells you what was touched, not whether the thing that was touched is actually verified.
What sells this for me is the Day 5 networking story, because it shows the method catching something a careful read wouldn't. You'd committed to a prediction with no silent fallback in it, so the moment the output had one, the mismatch made you suspicious enough to dig. A top-to-bottom read has nothing to be suspicious against, it just sees plausible code and nods. I'd stretch your "trivial stuff is theater" caveat a bit further: the trick isn't predicting every line, it's predicting the shape of the risky decisions (error handling, edge cases, anything that fails silently) and letting the boring parts slide. That's the only place the gap actually pays out.
The "nothing to be suspicious against" framing is exactly why a careful read isn't the same thing as a prediction — a read starts from the output and works backwards, which means it can only find what it already knows to look for. The prediction gives you an independent prior, so when the output diverges from it, the divergence itself is the signal, even before you understand why.
Your stretch on the caveat is the right one. Predicting every line is just overhead — the value is specifically in the decisions that fail silently, which is exactly the category where "it looks plausible" is the most dangerous response. Error handling, edge cases, fallback behavior, anything where the wrong choice produces code that compiles and runs and does the almost-right thing. That's where the mismatch between what you expected and what actually showed up is actually informative rather than just noise.
The networking story worked because I'd thought about error handling specifically when I wrote the prediction — not because I was being methodical, honestly, but because that was the part I was most uncertain about. Which is maybe the practical heuristic: predict hardest on the parts you're least sure about, because those are the parts where your prior is weakest and the model's choice is least likely to match what you'd have done. 🌸
predict-then-diff is basically forcing yourself to hold a hypothesis, and the discomfort you felt is the exact muscle junior devs are being told to skip. What I find interesting is that the same move scales past personal learning into system evaluation. When an agent runs fifty clean demos and then breaks, the only reason you can debug it is that someone recorded what it was supposed to do beforehand — the gap between predicted and actual is the bug report.
So the question becomes whether you can push this upstream: make the agent assert its own prediction before each action, then diff at runtime. The risk is it trades speed for self-awareness, and most production agents are optimized the other way. Have you tried turning predict-then-diff into a runtime check rather than just a habit, and did it actually catch the failures worth catching?
The scaling point is the one I hadn't thought through fully until you put it this way — the same gap that tells you something about your own understanding when you're reviewing code tells you something about the system when an agent breaks, and in both cases the gap only exists if someone committed to a prediction before the output arrived. Without the prior, you just have a failure and no baseline to diff against, which is why debugging agents that ran fifty clean demos feels so disorienting. The demos looked fine, nothing was wrong, and then something was wrong, and you have no record of what it was supposed to do that would let you isolate where it diverged.
On pushing it upstream into runtime — I haven't tried it in any systematic way, mostly because the predict-then-diff habit for me has been very manual and very personal, more about keeping my own understanding honest than about building infrastructure around it. But the idea of an agent asserting its own prediction before each action and diffing at runtime is genuinely interesting, and your framing of the trade-off is exactly right — it costs speed for self-awareness, and most production agents are optimized hard in the other direction. The question is probably whether the failures worth catching are the ones that show up fast enough that a runtime check could intercept them or whether the expensive ones are the kind that accumulate slowly and wouldn't trip a per-action assertion anyway. That's what I don't know yet.
Writing the prediction first is a simple way to protect your own reasoning. It turns AI from an oracle into a comparison tool. I like that because it creates a small audit trail: what did I expect, where did the model disagree, and did I change my mind for a real reason or just because the answer sounded confident?
"Did I change my mind for a real reason or just because the answer sounded confident" — that question is doing a lot of work and it's the one that's hardest to answer honestly after the fact, because by the time you've read the output your original expectation has already started to blur. Writing it down first is the only way to make that question answerable at all, because otherwise you're just reconstructing what you thought you expected, which is a very different thing from what you actually expected before you saw the answer.
The audit trail framing is a good one too — it turns the whole exercise from a vibe into something you can actually look back at and learn from, instead of just having a general sense that you approved something that seemed reasonable.
the
predict-then-diffframing is the first thing I've seen that makes 'are you losing judgment' actionable instead of just anxious.we did something adjacent without naming it: required engineers to write a short expected behavior note before agent generated changes got merged. the gap between expectation and actual output became the most useful part of code review, more than the diff itself.
the 'nodding along like it's gospel' line is the exact failure mode. what did your gap analysis look like on day 5 vs day 1 — did the gaps shrink noticeably, or just change character?
The required expected behavior note before merge is a really clean institutional version of this — because it makes the prediction a artifact of the process rather than a personal discipline that depends on remembering to do it every time. The gap becoming the most useful part of review is exactly what I'd hope for, because the diff alone just shows you what changed, the gap between expectation and actual shows you whether the change made sense to the person closest to the problem.
On day 1 vs day 5 — honestly the gaps didn't shrink so much as they got more specific, which I think is actually the better outcome. Early on the gaps were vague in both directions, I'd predict something loosely and the output would diverge loosely and I couldn't always tell if I was wrong or just imprecise. By day 5 the predictions were sharper, which meant the gaps were also sharper — I could say specifically what I expected and specifically where it diverged, rather than having a general sense that something was different. The networking catch on day 5 was the clearest example of that, I'd predicted no silent fallback and found one, which was a clean specific miss rather than a fuzzy one. Whether that counts as progress or just calibration I'm still not sure, but it felt more useful than the early days.
Well, the one thing that I've been doing for the past week was learning Playwright E2E testing. I always pass my own "attempt" for a test first and ask AI if it's best practice and cross-reference it to latest documents.
Sure, it feels like I'm an idiot since it shows me that there are parts of my own code that could have been done better. But that's okay, I learned to live with it. I noticed that it's okay to get annoyed because I'm traversing a new territory and that's normal. Being the dumbest one in the room will only become a privilege if I set my ego aside and allow myself to learn. In my case, learning from the internet, documentations, and AI.
Okay the Playwright approach you're describing is actually a really clean version of this — you write your attempt first, then use AI and the docs to pressure-test it rather than to generate it. That's exactly the right order, and I think the fact that it sometimes shows you parts that could have been done better isn't a sign you're dumb, it's a sign the process is working. If your attempt always came back perfect you'd just be confirming what you already knew, which isn't really learning anything new.
The ego thing you mentioned is the part I think about a lot honestly. There's something genuinely uncomfortable about writing your best attempt and then watching it get improved, especially when you've been coding for a while and you feel like you should know better. But that discomfort is kind of the point — it means you made a real prediction that could be wrong, and being wrong about something specific is so much more useful than never committing to an answer in the first place.
"Being the dumbest one in the room will only become a privilege if I set my ego aside" — that's going to stick with me for a while. 🌸
"This is a good way to keep your own debugging instincts active. I’ve caught myself accepting code just because it looked familiar.
Having a prediction forces you to ask why it works."
"Looked familiar" is such a good way to describe it — familiarity is just pattern recognition, and it can fire on plausible-looking wrong code just as easily as correct code. The prediction forces you past the surface read into actually having a position.
I do something close to this already, though I never had a name for it until now. Before I open the diff an agent produced for anything nontrivial, I write one line for what I expect it to touch and why. The gap between that line and the real diff tells me more than a close read does, because it shows whether the model made a deliberate different choice or just found a shortcut around the real problem. Your networking example is the failure mode that worries me most, an agent quietly handling a symptom instead of surfacing the cause passes every test you have and only shows up in production. Do you predict at the file level too, or mostly at the behavior level? I suspect the file level catches more of the real surprises.
"Whether the model made a deliberate different choice or just found a shortcut around the real problem" — that distinction is exactly what a close read alone can't tell you, because the output looks the same either way. The gap between the prediction and the diff is the only thing that makes the difference visible.
The networking example is the one that stuck with me most too for exactly that reason — it passed every surface check and the symptom was gone, which is the definition of a test suite that's measuring the wrong thing.
To your question: mostly behavior level so far, which I suspect is why I'm still missing things. File level prediction forces you to commit to a theory about where the change lives before you see where it actually landed, which is a much harder and probably more revealing test. Going to try adding that layer and see what it surfaces.
Excellent perspective. Predicting the solution before reading AI-generated code is a simple but effective way to strengthen critical thinking and improve real programming judgment.
Thank you! 😊 The "simple but effective" part is what surprised me most about it — it doesn't require any extra tooling or process, just the discipline to write something down before you open the diff. That's both the appeal and the hard part, because the temptation to skip straight to the answer is strong precisely when you're moving fast and the answer is right there. But that one small pause before looking is where most of the value lives.