Goedecke argues the productivity gains from LLMs are bimodal: seniors with taste can spot when models hallucinate and pick the architecture that won't fail in production, while juniors ship the first output that compiles. The tool isn't broken — it rewards the expertise you already have and papers over the expertise you lack.
By surfacing Goedecke's post to 1,299 points, the submitter and upvoters endorsed the framing that expertise is the variable that determines whether LLMs help or hurt. The thread's consensus treated the bimodal-user hypothesis as more explanatory than 'LLMs are bad' or 'LLMs are good' in isolation.
Rather than debating Goedecke's thesis, the top reply reframed the problem: if juniors are trained to defer to autocomplete instead of reading code, where do mid-level engineers come from in three years? Code review was software's apprenticeship mechanism, and LLMs are quietly dismantling it.
METR's controlled study found experienced open-source maintainers were on average 19% slower using Cursor than without it, because time saved on generation was spent cleaning up subtle wrongness. This finding cuts against the dominant narrative and suggests even the 'seniors benefit' half of Goedecke's thesis deserves scrutiny.
Sean Goedecke's post *LLMs reward expertise* hit 1,299 points on Hacker News over the weekend, which is roughly the threshold at which a blog post stops being a blog post and starts being a Rorschach test for the industry. His thesis is short enough to fit in a tweet: LLMs make senior engineers dramatically more productive and make junior engineers only marginally more productive — sometimes negatively so. The seniors know when the model is lying. The juniors don't. The seniors know which of five plausible architectures is the one that won't page them at 3 a.m. The juniors ship the first one that compiles.
Goedecke isn't the first person to notice this. METR's controlled study earlier in 2025 found that experienced open-source maintainers were, on average, 19% *slower* when using Cursor than when they weren't — because they spent the saved time cleaning up subtle wrongness. But that finding cut against the narrative and got buried. Goedecke's framing landed because it flips the story: the tool isn't broken, the *user distribution* is bimodal. If you already have taste, the LLM is a force multiplier. If you don't, it's a confidence multiplier, which is worse.
The HN thread mostly agreed, then quietly turned into an argument about something else: what happens to the pipeline. The top-voted reply wasn't a rebuttal — it was a manager asking, plainly, how they're supposed to hire mid-level engineers in three years when the current crop of juniors is being trained to defer to autocomplete instead of reading the code.
Every skilled trade has an apprenticeship problem, and every generation solves it slightly differently. Software's version, for the last twenty years, was code review. A senior looked at a junior's PR, said "why did you catch the exception here," and the junior learned — slowly, painfully, correctly — what the shape of a real system feels like. It was inefficient. It was also the only mechanism we had for transferring taste.
LLMs are quietly dismantling that mechanism from both sides. Juniors now write their first draft with Claude or Cursor, which means the code arriving in review is no longer a window into how the junior thinks — it's a window into how the model thinks, lightly edited. Seniors, reviewing that code, increasingly reach for the same tools to speed up review, which means the feedback is also mediated. The apprenticeship signal in both directions is getting compressed into a channel neither party fully controls.
The result is a workforce that looks fine on the dashboard and hollow underneath. Velocity metrics are up. PR throughput is up. Time-to-first-commit for new hires is down. But the tacit knowledge that used to accrue in a junior's head over their first two years — *this is what a race condition smells like, this is why you don't put that in a loop, this is the difference between a fix and a patch* — is not accruing. It's being handled by a system that will happily hand the same knowledge back to them on demand and never once explain why.
Goedecke's post is polite about this. The community reaction is less polite. A refrain repeated a dozen times in the thread: *my juniors ship faster and understand less*. That's not a temporary onboarding artifact. That's the new steady state if nothing changes.
There's a second-order problem too, which the post gestures at but doesn't name. If LLMs only pay off after roughly five years of practitioner experience, and the industry stops producing engineers with five years of un-augmented experience, the pool of people who can actually get the promised productivity gains is a fixed, aging cohort. The tool works best for the people who least need it, and the people who most need it can't develop the skills to use it well without doing the un-augmented reps that the tool was supposed to eliminate. This is the same trap aviation ran into with autopilot in the 90s. It did not end well until the FAA started mandating that pilots hand-fly enough hours to keep the skill alive.
If you manage engineers, the boring answer is the right one: budget for un-augmented work. Not as a punishment, as a training regimen. Pick one non-trivial ticket a week per junior and require it be done without an LLM. Not because the LLM is bad, but because the junior needs to know what it feels like to be stuck, to read the docs, to trace a bug through four files with nothing but grep. That's the exercise that builds the model in their head. Without that model, they'll never be the senior who can spot the LLM's plausible-looking lie.
Second, change what code review is for. Reviewing LLM-generated code line-by-line is a waste of everyone's time — the model already knew how to write a for-loop. Review the *decisions*: why this data structure, why this boundary, why this error is swallowed here and propagated there. Force the junior to defend the design in prose, not the syntax. If they can't explain why the code is shaped the way it is, the review isn't done, no matter how green the CI is.
If you *are* the junior: the winning move is not learning to prompt better. The market is saturated with people who can prompt. The scarce skill is being the person who reads the 400-line diff the model produced and says *this is subtly wrong, and here's the specific line where it goes off the rails.* That skill is built one boring, painful, un-augmented debugging session at a time. Do the reps. It sucks. It's also the only moat you're going to have in three years.
The interesting question isn't whether LLMs reward expertise — Goedecke is obviously right, and the pushback is mostly people who don't want it to be true. The interesting question is what the industry does about it. My bet is that the companies with a functioning apprenticeship pipeline in 2028 will be the ones that treated 2026 as a training crisis rather than a productivity opportunity. The rest will spend the decade wondering why their senior bench keeps aging and their juniors keep plateauing at a level that used to take eighteen months to clear.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.