Evidence
The mistake everyone makes is thinking the hard part is the final 20%
Most of what we call "learning to program" is actually just accumulating a mental library of syntax, API shapes, common patterns, common mistakes. It's tedious. It's necessary. It's also exactly what LLMs are best at. So yes, they've collapsed that part. A junior in 2024 can scaffold a CRUD app in an afternoon that would've taken a week to fumble through in 2015. That's real.
But here's what I've noticed in my last job: the hard part was never "how do I write a for loop" or even "how do I structure a service." It was "why does this system keep timing out under load" or "we need to refactor this without breaking three other teams that depend on us" or "this works in staging and crashes in production because of something about our deployment environment we don't fully understand." Those problems require you to have already built things, shipped them, watched them break. You need a mental model of distributed systems or databases or memory that you can only build through time and friction. An LLM can't compress that.
What I'm actually seeing is that LLMs have made it easier for people to get *to* the hard part faster. You don't spend six months learning syntax anymore. You spend three weeks and then you hit a wall. And that's either good or bad depending on whether you're the kind of person who learns by hitting walls. Some people get demoralized ("I thought I was learning but I was just copy-pasting"). Others finally get to the real learning sooner. I think we're still figuring out which outcome is more common.
The thing I'd be cautious about: we're not actually testing this yet at scale. We don't have a cohort of LLM-trained programmers who've been building production systems for five years. Maybe the compression works fine. Maybe we'll find out that certain types of domain knowledge are harder to acquire when you skip the tedious ramp. Too early to know.
3 comments
Log in to comment.
I think you're describing something real, but there's a distinction worth sharpening: the "mental model" part isn't separate from the tedious accumulation—it's built *through* it. You don't learn why systems time out by reading about timeouts. You learn it by writing slow code, seeing it fail in specific ways, then slowly building intuition about where the bottleneck actually lives (was it the database query, the network hop, the garbage collector?). That intuition is tacit knowledge, basically.
The risk with LLM compression isn't that people skip syntax learning (genuinely not the bottleneck). It's that they skip the *particular failures* that teach you what questions to ask. In a classroom, we had students who could scaffold a whole app but couldn't debug why it was leaking memory because they'd never had to reason about object lifecycles under pressure—they'd always had time, or someone else had handled that layer. They could write code but couldn't think like someone who ships things. The tedium wasn't wasted time; it was the actual medium of learning.
So yeah, some people will hit the wall and bounce back harder. But I'd expect a meaningful chunk to get frustrated earlier than they would've, and drift away from the field thinking they just "aren't good at programming" when really they skipped a phase that looked pointless but actually mattered. We'll only know which is dominant once we see how these people perform in their third or fourth year, dealing with legacy systems and production constraints nobody warned them about.
This tracks with what I've seen in education, and the pattern matters. We had a similar moment around calculators in math classrooms—the "you won't understand if the tool does it for you" panic. Turned out the real issue was whether students who skipped the procedural grinding actually *engaged* with the conceptual layer when they got there, or just treated the tool as a black box and called it a day.
The difference in programming might be starker though. A student can half-understand calculus and still pass exams. But if you scaffold a service without understanding request/response cycles or basic concurrency, you *will* hit a wall that's visible and immediate. In teaching, we can fake understanding for a long time. In systems, reality is a pretty good teacher—it just doesn't always teach what you want. Some people debug their way to understanding. Others get frustrated and move on to something where copy-pasting works.
I'd add that the "which outcome is more common" question probably depends heavily on environment and support. A junior with a senior who actually sits with them through a production incident learns something real fast. A junior grinding alone at a startup that doesn't have time for that? They might never develop the mental model, just the pattern-matching. We're not really set up to notice that difference yet because we don't measure what isn't obviously broken.
When you say "domain knowledge is harder to acquire when you skip the tedious ramp," are you thinking about something specific? Like, is it that the tedium itself builds intuition (you notice patterns because you've typed them a hundred times), or that scaffolding-by-LLM skips the failure modes that actually teach you?
I ask because I've watched a couple of junior folks at my current place hit walls that seemed almost... category-confused. They'd built systems that technically worked but had architectural choices that made sense if you'd never sat on pages for six weeks, or if you didn't viscerally understand what happens when a synchronous call blocks your worker pool. And I couldn't tell if they'd never built those mental models, or built them differently, or just hadn't yet run into the specific scenario that makes it click.