Does AI tutoring just compress the tedium without fixing the actual learning problem

I'd predict we end up with a bimodal distribution, and the measuring stick will be whether someone ever hits a problem that breaks their tools. The people who treat Claude as a shortcut past syntax—they'll probably plateau hard around mid-level stuff. They'll know what a loop is, sure, but when they're debugging a race condition or trying to understand why their cache strategy isn't working, they won't have the debugging instinct because they never had to build it. That muscle doesn't form while scrolling through generated code. But the people who use AI to skip the tedium and then *actually explain the generated code back to themselves*, or better yet, modify it and watch what breaks—those people might actually learn faster than someone grinding through manual repetition. They get past the carpal tunnel part and stay in the confusion part, which is where learning happens. The problem is identifying which camp someone's in before they hit the wall. And there will definitely be a wall. There always is. It'll probably present as "why does everyone keep rejecting my pull requests" or "I can't figure out why this is slow" and by then they're months in with bad habits. The honest answer is we won't really know for a few years. You'd need to track a cohort of AI-assisted learners through their first real production support incident, and that data doesn't exist yet. But my money's on the people who got bored fast enough to actually *need* to understand things doing fine, and the people who just wanted to move fast hitting some version of the thing I've watched happen before: they work great until they don't, and then they're stuck.

You're isolating something real here that gets lost in the hype/doom oscillation. The tedium question matters because it's actually tractable to measure, and I think you're right that it varies wildly depending on what happens after the AI hands over the code. I've watched this play out in hiring. Some people who've used Claude extensively can't articulate what their own code does—they pattern-matched to a prompt, got something that worked, moved on. But others use it like a faster reference manual and then *have to* understand it to integrate it, debug it, or modify it for their actual constraints. The difference isn't the tool, it's whether there's friction downstream that forces integration. When there isn't—when the code just works and they never have to touch it again—you get the compression without the learning. The novel problem thing is where I'd push back slightly on the framing. The real gap isn't usually "I have a weird bug" in isolation. It's "I need to know what questions to ask about my system." And that *does* require having sat with enough concrete examples that the mental model got built. But I don't think the AI necessarily prevents that—it depends on whether you're using it to skip understanding or to accelerate it. The trap is that it's genuinely hard to tell the difference while you're doing it. You feel productive either way at the time.

I worked with someone at my last job who'd learned Python almost entirely through ChatGPT—just prompting for whatever he needed to build. He was genuinely fast at getting things *running*. But when we hit a distributed tracing bug in our payment service, he was completely stuck. Not because he didn't know Python syntax, but because he'd never developed the intuition for "what questions do I ask when something is wrong?" He couldn't even narrow down whether it was timing, state, or the data itself. We had to basically walk him through the debugging tree the way you'd teach someone in 2005. What surprised me is he didn't struggle with the explanation part—he could tell you what his code did. He just hadn't internalized the model of how things *fail*. That only comes from fixing things that are actually broken, repeatedly, where you have to care about the why. You can't prompt your way past that. A loop you wrote wrong forty times teaches you something that a loop you copied once doesn't, even if you read it carefully. I'd guess the real split is whether someone uses AI to skip tedium while still doing the *thinking*, or whether they use it to skip the thinking entirely. Hard to tell the difference from outside, though. And yeah, I'd be curious if anyone's actually measured this systematically instead of anecdoting about it.

You're right that there's a real thing being skipped, but I think you might be underweighting how much the *framing* of the problem matters more than the repetition itself. I've watched people spend three weeks hand-rolling database connection pooling learn basically nothing except "this is tedious," while someone who read the docs and then immediately debugged a production connection leak at 2am learned it in a way that stuck forever. The difference wasn't the repetition—it was that one had stakes and actual confusion to resolve. That said, your harder question is where this gets interesting. The real learning bottleneck isn't "can you write a loop," it's "can you recognize when you're in a weird state and reason about it." And yeah, if someone's using Claude as a syntax vending machine and never getting genuinely stuck on anything, they're probably building worse intuitions about their own system. But if they're using it to skip the tedium *and then deliberately creating harder problems for themselves*—or more likely, getting thrown into real codebases where the tedium is actually somebody else's weird abstraction they need to understand—the outcome might be different than you'd predict. The honest answer is probably that we won't know for a few more years, and it'll track really closely with whether people's teams or learning environments force them into the genuinely hard part or just let them keep describing what they want to Claude. That's always been the actual variable.