Have you ever finished building something and realized you can’t explain how it works?

I got uncomfortably close to that back when I was learning React during my transition out of accounting into a full-stack bootcamp. Except back then, I didn’t have AI to blame.

The wall I hit wasn’t state management or JSX syntax but setup.

What packages do I install?

Where do these files actually go?

Why does my directory structure look nothing like the one in the tutorial?

I’d follow a course, build along, and everything made sense in the moment. The instructor’s project ran, and my understanding felt solid.

Then I’d sit down to build something, as I usually do for every THT post, and the whole thing would fall apart 🤦‍♀️

I’d hit a wall on structure, take a break, come back, hit it again.

The tutorial made the setup look easy because someone else had already made every decision for me. Alone, I had to make them myself, and I didn’t yet know which decisions mattered.

The lack of an easy shortcut was the only reason I closed that gap. I had to grapple with the confusion until it resolved on its own.

Now, there’s a shortcut. AI can hand you the initialized project before confusion ever has a chance to teach you anything. That unglamorous, invisible kind of friction I fought through is what AI strips by default, for developers and for anyone building anything.

So the question isn’t whether AI can finish the project faster, but whether you walk away able to explain how it works.

This post dives into what happens to comprehension debt, debugging instinct, and motivation when the struggle disappears before it can teach you anything, and how to use AI without giving up the parts you still need to learn yourself.

How AI Removes the Struggle That Used to Teach You Something

By removing the entire on-ramp, AI no longer just answers your questions.

Scaffolding, boilerplate, and your “what do I even install first” question vanish in a single prompt, and this doesn’t just happen in code.

• Marketers can generate a twelve-month content calendar in seconds.
• Junior designers can skip grid theory and go straight to a finished layout.
• PMs can turn a rough idea into a full PRD before finishing their coffee.

I’m not going to argue that all of that friction mattered, because the reality is some of it never did.

However, it does raise a real tension of friction that was skipped.

Was it friction of the kind that was wasting your time, or the kind that was quietly teaching you something?

What sucks is that you usually can’t tell in the moment. You can only tell later when you either understand the thing, or you don’t.

I think about this most clearly through my own experience learning to code, back before AI could hand me any of it.

What Learning React Taught Me About AI-Assisted Coding

The lesson from that early React period isn’t to say that struggle is good while ease is bad.

Honestly, if I could’ve handed off that setup tax (the endless package installs, the directory-structure guessing), I probably would have 💁‍♀️

That particular friction wasn’t teaching me React. It was teaching me how to follow someone else’s conventions well enough to reproduce them, which isn’t nothing, but it’s also not the actual skill I needed.

But if you never once have to reason through why a file structure is organized the way it is, you inherit a project you can’t extend later.

You can run it, but you can’t reshape it.

Someone still has to understand the shape of the thing well enough to change it in six months. If that’s never been you, even once, you’re borrowing understanding you don’t actually have.

So this one’s mixed, and it doesn’t resolve cleanly. While the setup tax wasn’t some pure teaching tool, handing over all of it isn’t free either.

Yes, it was mostly annoying, but sometimes it taught us how to think.

Note: The tutorial version always felt easy because the instructor had already made every structural decision. My solo version was harder because I was doing, for the first time, the invisible work the tutorial had already finished for me.

Related: Are AI Coding Tools Making Developers Worse at Coding?

What Is Comprehension Debt in AI-Assisted Coding?

I came across a study where researchers ran a randomized controlled trial with 52 professional developers learning an unfamiliar async Python library from scratch. Half had AI assistance. Half didn’t.

The AI group finished in roughly the same amount of time as the group working alone (no real speed advantage).

But on the comprehension quiz afterward, the AI group scored 50% compared with 67% for the control group, a 17-point gap on code they’d written themselves minutes earlier.

The gap wasn’t uniform across everyone who used AI, though 👀

• Developers who used it to delegate (essentially asking it to write the code) scored below 40%.
• Developers who used it to ask why something worked scored above 65%, matching the group that had no AI access at all.

Same tool yet very different outcome because the tool isn’t the deciding factor. What the person does with the tool is what matters.

Addy Osmani gave this pattern a name in March 2026: comprehension debt. It describes the growing gap between how much code exists in a system and how much of it anyone actually understands.

Making code cheap to generate doesn’t make understanding cheap to skip!

Though AI can generate source code, it can’t generate the shared understanding that often is part of a collective that’s a team.

Tip 😬
That gap between “this makes sense while I’m following along” and “wait, why doesn’t this work when I try it alone” from my React days? That’s comprehension debt before it had a name. Feeling like you understand something and actually retaining that understanding aren’t the same thing.

Explore: Why AI Code Review Is Now Secretly Killing Developers

Why AI Can’t Replace the Debugging Skills You Build Yourself

When something breaks in one of my projects, my first move isn’t AI. It’s DevTools.

Console errors first, then the Network tab, then tracing backward from wherever the failure showed up to wherever it actually started.

Most of the time the what is obvious anyway: syntax error, failed request, stack trace pointing right at the line.

What I’m actually chasing is the why, and that instinct came from those multi-day stalls early on, where I had no choice but to sit with a broken thing until I understood it.

That’s uncomfortable. It’s also where I learned how to stop staring at a problem and start asking better questions about it.

AI does show up in my workflow, just later than most people assume. Once I’ve already traced a problem to its source, I’ll bring AI in as a sounding board. I lay down the problem, where I traced it, and what I think might be happening.

Then ask if I’m right 🤓

That’s a fundamentally different question from “fix this for me.” I don’t copy-paste the console error or issue (or, worse, select the lines, no prompt) and ask to fix it.

My approach keeps the reasoning mine even when the answer has help behind it.

One developer who mentors juniors at a startup described a pattern where engineers sail through technical interviews only to freeze on a ten-line bug during their first week.

Now, the problem isn’t smarts. They’re more than capable of solving it, but they never built the habit of forming a hypothesis and checking it against evidence. They’d only ever asked AI to fix things for them.

Debugging, in his words, is one of the things that still separates people.

Note 👀
You can prompt your way to a first draft. You can’t prompt your way through an inconsistent trace and a lying log file at three in the morning. What’s missing isn’t intelligence, but the repetition of forming a hypothesis and, sometimes, being wrong.

Related: I Easily Find Bugs In AI Code Every Single Time

Why Copy-Pasting AI Answers Creates a Learning Gap

Someone consults AI and pastes the response verbatim into a doc, Slack/Team’s thread, or PR comment. Usually with some version of “this is what AI said” attached. Often with no further processing or indication that they actually read it.

I’ve watched this happen across devs and non-devs alike.

As you can tell, I’m not a big fan of it 😒

When I see that, it rubs me the wrong way because it usually means one of three things:

1. They didn’t read the response closely.
2. They read it but didn’t fully understand it.
3. Or, worst case, they understood and didn’t care enough to translate before handing it off to someone else to sort out.

I can’t always tell which it is, but all three share the same missing step: Nobody translated the answer into something they could claim as their own.

It’s the difference between forwarding an email and actually replying to one.

I have zero issue with consulting AI, constantly, for research, a second opinion, sanity checks. The issue isn’t asking for help.

Asking for help and owning an answer are two different activities. That translation step, even when rough, is where understanding either happens or quietly doesn’t.

Tip 💯
If you’re going to share what AI told you, read it first. Put it in your own words before you pass it along. Sure, getting to that solution may have required help—that’s fine. But the rewording itself is useful because it’s proof you sat with the answer long enough for some of it to stick.

AI Automation vs. AI Augmentation: Which One Actually Helps You Learn?

We don’t need to preserve every friction point, since some of it is plain dead weight and automating it is a gain.

I certainly don’t want to go back to manually wrestling with package configuration just because struggling somehow makes me a better developer. That’s not the lesson.

The problem starts when you can’t tell the difference between friction that was wasting your time and friction that was teaching you something.

The part that complicates things is that augmentation only works if you keep choosing the harder thing on a day when nobody’s watching, and nothing’s forcing you to.

That’s a lot to ask of anyone 💁‍♀️

Which is why automation is the natural default. Augmentation takes longer, and almost nothing about how people currently work rewards taking longer.

Deadlines don’t care that you stopped to understand something. Managers aren’t too crazy about a task taking an extra 20 minutes because you made yourself explain the reasoning first.

And if you’re learning on your own, nobody is standing behind you telling you to slow down and understand the thing before you ask AI to finish it. You have to make that call yourself while knowing the fast answer is sitting right there.

Related: The Hidden AI Skill Gap Nobody’s Talking About

I’ve seen the same story shared online about what’s called the “vibe coding backlash”. During the first several months of integrating AI, there’s noticeable progress. Then, somewhere around the 6- to 12-month mark, a distinct slowdown happens that nobody can fully explain.

But because it can’t be explained doesn’t mean there’s no explanation.

As time went by, the codebase grew in structure and complexity. However, nobody has a mental map of that codebase anymore since, instead of building it (as in experiencing the struggle of that process), they prompted it into existence.

Note 😬
This isn’t only a developer problem. The same mechanism plays out for a marketer who generates a content calendar without ever reasoning through their audience, then can’t explain why a post underperformed. A designer who skips past grid logic and can’t articulate why a layout broke on mobile. A copywriter who hands in AI-generated work they’ve barely read, let alone understood. Different disciplines yet the same problem of speed now, comprehension debt later.

What Fei-Fei Li Says About AI, Learning, and Motivation

While watching the Huberman Lab episode with Dr. Fei-Fei Li this past weekend, I came across the idea that for someone learning, AI’s sharpest risk might be motivation loss, not just skill loss.

Ask anyone, and one of the top answers I’m fairly certain you’re going to get about the biggest danger AI poses to education would be cheating.

It’s reasonable. It makes sense. It’s what I would answer.

But Fei Fei argued that the biggest danger is the erosion of students’ motivation and agency to learn on their own, taken away by tools.

That’s a whole different claim from you’ll forget how to debug. It’s saying that the desire to push through difficulty in the first place is what’s at stake. And honestly, I agree. I think that’s the scarier version.

Li doesn’t argue for banning the tools (she’s like me 🥲). She points to her own experience struggling with organic chemistry as a premed student, where TA hours were limited and questions went unanswered. With an AI tutor available around the clock, she would’ve asked far more questions because she already had the motivation. She just needed guidance.

The distinction here is between a learner who’s engaged but stuck and one who’s outsourcing the thinking. Though the two might look the same from the outside, they’re not even close to the same thing.

Tip 👇
That tracing habit (the hypothesis, the “am I right?” check I bring to AI only after I’ve already done the work) exists because I stayed engaged through the stuck part often enough that staying engaged became the default. It has to get built the slow way, at least once.

How to Use AI Without Outsourcing the Thinking

Did you understand, or did you just get an answer? That’s really the question underneath all of this.

All that we touched on from the setup tax, comprehension research, debugging instinct, copy-paste habit, vibe coding pattern, and even Li’s agency framing are all different angles looking at the gap between learning and getting past it.

Sometimes getting past it is exactly what you need.

Sometimes you’re on a deadline, and you don’t have another hour to spend understanding a piece of boilerplate you’ll probably never touch again.

And sometimes you’re learning, so that extra hour is the entire point.

I let AI handle scaffolding for new projects, but it’s never a blank-slate prompt. If I’m spinning up a React project with Vite, instead of asking for generic boilerplate, I’ve already:

1. outlined a specific directory structure
2. drafted workflow files for the project
3. defined actual parameters for what the project needs to do

The automation happens downstream of my own reasoning, not instead of it.

I do use AI, and I don’t do everything manually. At the same time, I don’t hand over the part that I still need to learn.

Granted, it’s not always easy. Under time pressure, I don’t always go back and re-prompt for a full breakdown of something AI provided. Sometimes “good enough” understanding of the what, the why, and the how is the actual ceiling I hit that day. It’s a situational tradeoff.

Yet, during slow weeks, that ceiling is higher, and I challenge almost everything AI hands me. Not to play devil’s advocate but to actually learn.

It’s a Wrap

I asked at the start whether you’ve ever finished building something and realized you couldn’t fully explain how it worked. After writing all of this, my answer is yes, more than I’d like.

What’s different now is I’m a little quicker to notice it, and a little less willing to call “it works” the same thing as “I understand it.”

When I sit down to build something from scratch, the parts I struggle through are usually the parts I can explain later.

The struggle itself isn’t the valuable part. It’s the understanding that came out of it.

So, the next time you reach for AI because you’ve hit a wall, maybe pause for 30 seconds first.

Ask yourself what you’re actually stuck on. If you can name the problem, you’ve already done part of the work.

And if you still need AI after that? Heck ya, use it.

Just make sure you come back and ask yourself if you understand why it works 😉

Stay curious, bye.