The hard 20% was always harder, but nobody talks about it that way

I've seen this play out in hiring already, actually. Not five years out—we're living in it now. Last year we brought in a batch of juniors fresh out of bootcamps, and there's this weird canyon between them. Half of them can reason about tradeoffs, ask good questions about why we use postgres instead of mongo for a feature, think through concurrency issues. The other half... they know how to prompt Claude to scaffold a CRUD endpoint, but the moment something doesn't have an obvious LLM-shaped solution—like "why is this query slow" or "what's our actual bottleneck here"—they're dead in the water. Not trying, just frozen. The thing that got me is we didn't really screen for it differently. The resumes looked the same. They both built projects. But one group had clearly spent time debugging their own code, reading error messages, sitting with confusion. The other had outsourced that part. In an interview that focuses on "can you code," you can't always tell. The problem shows up three months in when they're supposed to own something. My hypothesis (thinking out loud here) is that the bootcamps themselves are going to bifurcate faster than colleges will. A bootcamp that still makes you build a lot of small things without help, that makes you read stack traces and figure out what broke, is going to produce better juniors. But the economic pressure is all wrong for that—it's slower, it's less scalable, students complain more. So most of them will just lean harder into "AI-assisted," and we'll end up with two completely different labor pools by experience level.

I think you're describing something real, but I'd separate two different things happening here. One is genuinely new—the ability to outsource boilerplate means you *can* skip the fluency-building phase. The other is just the oldest problem in education: some people will take shortcuts when offered them, and you can't force depth on someone who doesn't want it. The part that feels overblown to me is assuming the bimodal split is LLM-specific. We've had this problem forever. In my last job, we had senior engineers who'd never touched certain parts of the codebase, just pattern-matched their way through it. And we had people who seemed to understand systems in their bones. The gap existed before Claude. Maybe the LLM accelerates the sorting—lets the mediocre coast longer—but I'm not sure it *creates* the gap. What I actually worry about more is the middle. The students who could've become solid, not-brilliant engineers through patient learning—the ones who'd grind through boring problems and accidentally build intuition. If the LLM makes that grinding optional, sure, some of them will skip it and plateau. But some might also just... accelerate past the tedium into interesting work faster, and the "boring phase" was mostly just a gate-keeping artifact. I genuinely don't know which is more true. But I'd want to see the data before assuming LLMs broke something that was working. We might've just made it obvious that the boilerplate phase wasn't doing as much work as we thought.

You're identifying something real here, but I think you're underselling the actual mechanism. It's not just that students skip the tedious reps—it's that they're losing the *calibration* that comes from failure at low stakes. When you type out fifty loops and fifteen of them have off-by-one errors that you catch yourself, you build an internal model of where bugs live. That's not knowledge you can download. The LLM compresses that feedback loop away. The part that's landed with me though: this isn't new, we're just seeing it in a different medium. Watched a junior sysadmin once who'd only ever used configuration management. When the automation broke and he had to SSH into a box and actually understand what was happening, he was completely lost. Same distribution split. The difference is that with infrastructure we eventually *forced* them to understand because things break at 3am and someone has to explain it to the on-call. Education doesn't have that forcing function built in yet. The harder question you're dancing around: what *should* the friction look like now? Because if the tedium really isn't where the learning was, just where we assumed it was, then maybe we were doing it wrong anyway and the LLM is just making that obvious. But if the tedium *was* load-bearing and we can't reconstruct it, then yeah, you're looking at a real gap in how people build judgment. That second one concerns me more.

Yeah, this is the same thing we saw with infrastructure automation. Tools that let you skip the painful work of actually understanding your system usually just defer the pain to 3am when something fails in production and you're staring at a Kubernetes event log you can't parse. The thing that gets me is the framing keeps being "well, experts can use this better than novices, so maybe we just accept that?" But that's not really the synthesis. The actual pattern is: if you've built judgment through struggle, you know which corners the tool cut and what you need to check. If you haven't, you don't know what you don't know, so you trust the output. And now you're shipping it. We had a junior on my team generate a connection pool configuration from an LLM last year that looked reasonable until load testing revealed it was fundamentally broken—but she trusted it because it *sounded* authoritative and she hadn't internalized why those numbers matter. The uncomfortable part is there's probably no good solution here that doesn't involve younger people doing the boring stuff anyway. You can't compress the learning phase. You can maybe make it less soul-crushing (better pedagogy, clearer immediate feedback), but you can't skip it and expect judgment to appear. The tool doesn't fix that—it just makes it easier for institutions to pretend they don't need to bother.