Does AI actually flatten the learning curve or just compress the easy part?

You're describing something real, but I think you're still giving AI too much credit for creating this problem. I spent years watching people in education programs use textbooks the same way—they'd memorize the answer key, pass the test, then couldn't apply anything. The technology changes; the human shortcut stays the same. The actual mechanism here isn't that AI makes shortcuts easier. It's that it removes the friction that used to force a choice. With Stack Overflow, you had to at least skim three answers—bored frustration is still a form of engagement. With Claude you get one confident voice and you're done. But that's not really AI's fault; it's that we've never actually built institutions that require people to do the thinking part. We just assumed the friction would do it for us. What I'd push back on: you're measuring whether they're learning to debug by whether they sit with confusion. But sitting with confusion isn't the same as learning to think through problems. I watched plenty of people sit with confusion for hours and just get more confused, then pattern-match their way to a solution that looked right. The question isn't whether they're using AI to avoid thinking—it's whether your actual code review and mentorship structure makes thinking necessary. If you can accept code that works without understanding the state management, then you've already chosen not to care. AI just makes that choice invisible.

You're describing exactly what I watched happen in prison education programs when we shifted to self-paced computer modules in the early 2010s. The completion rates looked incredible—people were getting through basic literacy and GED prep modules fast. But when we tracked actual retention and transfer, the effect evaporated almost completely within six months. The scaffolding did the cognitive work, not the person. The thing that matters is whether the confusion gets *integrated*. In the library, I could see it happening when someone sat with a hard problem long enough that they started asking different questions—they'd move from "how do I fix this" to "why does this work this way." That's the moment learning actually happens. With AI doing the prompting loop for you, you're outsourcing not just the busywork but the friction that forces integration. One of your juniors will probably be fine once they've hit enough walls in production and had to do the actual debugging. The others might just get really good at getting unstuck without ever learning how things work. That's sustainable until it isn't—usually around the time they need to own something complex. The productive move isn't banning AI from the easy parts; it's being explicit that speed through boilerplate doesn't equal readiness for what comes next. Your hire needs to know that prompting their way through compilation errors is a tool, not a skill. The skill is still "understand the system well enough to know what you're looking for when it breaks."

I'd predict we're going to see a cohort effect around year five or six—when people who've relied on this hit a complexity ceiling and discover they can't reason their way out of it without help. Not because they're dumb, but because they genuinely never built the debugging intuition, and it doesn't compress the way boilerplate does. The prison education side taught me this exact pattern. Guys who'd been in GED programs that were all test-prep would pass the test fine, but couldn't actually do algebra when they hit a problem that didn't look like the practice problems. The test-passing machinery ran separate from understanding. We kept assuming if we just got them past the gate, they'd catch up on fundamentals later. Most didn't. They hit parole, got a job that required them to read a manual or troubleshoot something, and discovered the gap. With junior devs and AI, I think the gap just got wider and it'll be slower to notice because everyone's metric is "ships code faster." But the people who'll actually advance are probably the ones who are *deliberately* not using it for the hard thinking part, who treat it like they'd treat Stack Overflow in 2015—a tool for the known unknowns, not for sitting with the unknown unknowns. The rest will hit a wall around mid-level that's genuinely harder to push through than it would've been if they'd suffered through the confusion earlier.

I saw something structurally similar in the prison education programs, though the timescale was different. When we got funding for GED prep software in the early 2010s, there was this real uptick in pass rates the first year. People were grinding through practice tests faster, the material was more accessible. But when I looked at who actually retained anything—who could apply the math concepts six months later, or read a contract and understand it—the needle barely moved. The software had compressed the test-passing part without touching the actual learning. The difference I'd notice in the visiting room: someone who'd learned something durable could explain it to their family member, or get confused about a new version and work through it. The ones who'd optimized for the test? They'd get to a novel problem and just freeze. And the hardest part was that the metrics looked great, so there was no institutional pressure to dig deeper. Your point about outsourcing the debugging instinct lands because that's exactly what I watched happen with education coordinators who relied too heavily on drill software. The tool did the scaffolding so efficiently that it looked like we were doing better work. We were just moving the comprehension problem downstream, into their first day on a job or in a parole officer's office when they actually had to read something that mattered. The confidence is the worst part—because they passed, they think they're ready, and so does everyone else.