The thing I notice is that we're conflating "faster at writing boilerplate" with "better at learning systems thinking," and they're not the same thing

I'd push back a little here, though I get the frustration. In my last job we had a senior who refused to let juniors use any generation tools, insisted on hand-rolling everything as a form of apprenticeship. Sounded noble. What actually happened was they spent six months writing mediocre implementations of things that had already been solved well, and when they finally shipped, we spent another three months fixing those implementations. They learned *their mistakes* really thoroughly, sure. But they didn't learn the patterns that actually work at scale because they were too busy reinventing. The connection pooling thing is real—your junior absolutely should've understood that before deploying. But that's a code review problem and a deployment process problem, not a fundamental indictment of the tool. The StackOverflow equivalent there is someone copy-pasting a connection pool example without reading it. The difference is now you can ask Claude *why* the pool exists in the first place, and if your junior is even slightly curious, they will. You could also just... test under load before production? That's not new friction. What I've seen work is treating generation as a starting point for the hard thinking, not a replacement for it. Scaffold the thing, then the junior sits with it and has to explain to me why each piece exists and what breaks if you change it. That's faster than starting from scratch, and they still do the learning. The question isn't really whether the tool helps—it obviously does—it's whether your process and senior engineers actually enforce the thinking part. Some places will, some won't. That's probably true regardless of what tools exist.

I ran into almost exactly this last year. We had a mid-level engineer use Claude to build out a batch processing pipeline—looked great, tests passed, shipped it. Three weeks later we're getting these mysterious job timeouts in production that only happen when the queue backs up. Turned out the prompt had generated a reasonable-looking async pattern but the engineer had never actually worked through what happens when you have backpressure on a queue, so he didn't catch that the retry logic was creating a feedback loop under load. The thing that got me is: he could've learned this the hard way if he'd written it himself badly. At least then he'd own the debugging story. Instead the code was *correct-looking enough* that it passed scrutiny, and by the time failure showed up, the original context was gone. He's a smart guy, but he'd basically been handed a solution-shaped thing without the problem-shaped understanding underneath. What I notice now is we're doing more code review theater—looking for obvious mistakes in LLM output instead of actually probing whether someone knows what their code does under stress. The burden shifted from "write it and learn" to "read it, understand it, predict its failure modes." For someone who hasn't built that mental model yet, that's harder, not easier. You can't really code-review your way into knowing what exhausted connection pools feel like.

I'd predict we're going to see a bifurcation in junior engineer quality over the next few years, and it'll show up most clearly in hiring. Right now everyone's noticing the speed gain, so orgs are pushing juniors toward AI-assisted scaffolding. But the ones who still do the "inefficient" thing—actually tracing through a failing test, building something simple from scratch, sitting with the runtime behavior—will be noticeably more capable by year two. They'll debug faster, they'll know when to trust generated code and when not to, they'll have the mental models to reason about failure modes. The trap is that this won't be obvious immediately. The AI-heavy juniors will look equally productive for maybe 12-18 months because they're good at prompt engineering and their code passes initial reviews. But somewhere around the time they need to own a system under real constraints—actual concurrency, actual traffic, actual failure modes—the gap widens. And by then some teams will have already promoted past them or burned out waiting for debugging capacity. My guess is the smarter orgs (and this includes academic institutions, honestly) will start being intentional about which problems they let AI solve for which people. Scaffolding for someone who already knows sockets is different than scaffolding for someone who doesn't. But most places won't bother with that distinction, so yeah, faster ceiling-hitting.

I'd push back slightly on the "insidious" framing because I think it lets the junior off the hook too easy. The real problem isn't that the tool hid the learning—it's that nobody made him do it anyway. I taught high school for years. You could always hand a kid a perfectly written essay to copy. Some teachers pretended it never happened. Others made you *defend* what you'd submitted, made you explain the argument, forced you to sit with your own work. The ones who did that caught the cheating and also, sometimes, accidentally taught something. The ones who didn't just saw faster work and assumed faster understanding. What you're describing with your junior is the same dynamic, just with a different vector. The socket behavior stuff *still* needs to happen—you just have to decide it matters enough to make happen. If your team's code review is "looks reasonable, passes tests, ship it," then yeah, Claude's going to accelerate you toward a wall. But if code review includes "explain why you chose this pooling strategy" or "walk me through what happens if this connection drops mid-request," that's harder to bluff through an LLM-generated scaffold than it is to bluff with one you copy-pasted whole. The tool itself didn't change what matters. It just made it easier to *not care* that it matters, at least for a while.