Forecast
The 80/20 problem with AI coding assistants
Last year I watched a junior spend three days debugging a race condition in a background job queue. Claude had written the initial code in ten minutes. The junior had never actually *built* a queue before, so when things went wrong under load, he had no mental model to fall back on.
I think the honest answer is that AI has mostly just moved the goalpost. Writing boilerplate and gluing together libraries is genuinely faster now. But understanding *why* something doesn't work, or designing around constraints you haven't hit yet — that part is still as hard as ever. Maybe harder, because now you can't even use "I had to read the source code to figure this out" as the forcing function.
The weird part is that it might actually flatten the learning curve in a bad way. Used to be you'd struggle through your first CRUD app and come out knowing something about databases. Now you can ship five CRUD apps and still not understand what a transaction is, because you just asked Claude to handle "the data part." I'm not sure that's progress. We had a contractor last year who could generate features but genuinely couldn't reason about load testing or deprecation strategies — and those aren't even the hard things.
So yeah, the first 80% is faster. But I'm skeptical that the last 20% has gotten any easier. If anything, you need more discipline now to actually learn the parts that used to force you to learn.
2 comments
Log in to comment.
This reminds me of something I watched happen repeatedly in the prison education program. We'd get someone into a GED class who'd memorized test-taking strategies without building foundational numeracy, and they'd pass the exam. Then they'd get out and try to manage a budget or understand an apartment lease and hit a wall they couldn't pattern-match their way around. The test wasn't actually measuring what we claimed it measured.
What you're describing isn't really about AI making learning harder—it's about the difference between *performing competence* and *building a model*. The contractor you mentioned could perform; he could produce artifacts that looked correct. But he had no internal representation of how systems degrade under load, so every new situation required external guidance. That's brittle in ways that matter.
The forcing function thing you mentioned is the actual mechanism. When you *had* to read source code to fix the race condition, you were forced to develop an intuition about concurrency. The struggle wasn't a bug in the system, it was the system working. Now you can skip that step and end up in a position where you can follow instructions but can't generalize. The discipline you're describing—actually choosing to go deeper when you could move forward—is something almost no incentive structure rewards. You shipped the feature on time. That's what gets measured.
This maps onto something I've been watching in ed tech for years: tools that remove friction from the easy part without teaching the hard part tend to create a new kind of problem later. The forcing function matters.
In classrooms, we saw this with calculators, but also—and this is closer to your point—with learning management systems that let teachers post assignments without actually structuring them. The tool made the surface-level task easier, but it didn't teach the underlying design skill. Students who'd never had to sit with a poorly-worded problem, or a teacher who'd never had to confront the fact that their instructions were ambiguous, just... didn't develop that feedback loop.
What strikes me about your race condition story is that it's not really about *access* to the solution. He could've Googled his way to the same code. The difference is that a Google path forced some resistance—you have to articulate what's going wrong first, read someone else's explanation of the failure mode, build a hypothesis. With Claude doing the whole thing front-loaded, there's no forcing function to build the mental model. You're right that it might actually be *worse* for learning than the old constraint was.
The honest version of "AI makes you more productive" is probably "AI makes you more productive *if you already know what you're doing*." For people still building foundational understanding, it's murkier. Maybe the discipline part you mention—deliberately choosing to read the implementation, to stress-test, to learn the constraint before you hit it in production—becomes the actual skill that matters now. That's just not guaranteed to happen.