Comprehension Debt: What AI Coding Costs You Later

There's a version of the AI coding conversation that goes like this: either you're a true believer shipping apps at the speed of thought, or you're a grumpy traditionalist insisting that real programmers write every line themselves. It's a stupid binary, and most working developers know it. What's rarer is someone willing to sit in the middle and actually map the terrain.

That's what Matt Stauffer did at Laracon US 2026—and the framework he laid out is more useful than most of what passes for AI discourse right now.

Stauffer—Laravel author, CEO of Titan, one of the longer-running Laravel consultancies—spent three months building Voxicon, a Minecraft-style 3D recreation of the Laracon venue, in Three.js. A framework he did not know. He built it anyway, with significant AI assistance, over hundreds of hours of prompting, architecting, debugging, and reworking. The result worked. The process taught him something he thought was worth a conference talk.

The core concept is comprehension debt—the gap between what your application can do and what you actually understand about how it does it. Like financial debt, it's not inherently evil. It's a tool. But like financial debt, ignoring the interest payments tends to end badly.

"Debt is a tool," Stauffer said, "but you have to understand the potential ramifications of using that tool, and I think we're all ignoring it."

The ignoring part is the interesting bit. It's not laziness, exactly. It's something more structural.

The friction we lost

Here's a thing that's easy to forget about learning to code before AI: it was slow in ways that turned out to be useful. You hit view-source. You read the docs. You broke things. You googled error messages at 11pm. All of that grinding, frustrating iteration was—quietly, invisibly—building comprehension. The path from problem to solution had enough friction that the solution stuck.

AI mostly removes that friction. Which feels like pure gain until it isn't.

Stauffer cites an Anthropic study (conducted across hundreds of thousands of coding sessions) finding that AI compounds the expertise you already bring to it. Two developers, same agent, same task—the expert gets dramatically better results. That's not a knock on AI; it's a knock on the assumption that AI is a great equalizer. It's more like a multiplier, and the multiplier scales with what you already know.

The downstream implication is uncomfortable: if AI is doing the friction-work, and friction is how expertise builds, then heavy AI reliance at the wrong stage might be quietly hollowing out the next generation of expertise. Stauffer doesn't dwell on this—he's careful to frame it as a concern rather than a conclusion—but it's the subtext of his whole talk.

A separate Anthropic study he references put numbers to a narrower version of this. Developers given an unfamiliar Python library were randomly assigned AI assistants or not. Follow-up comprehension test: the AI group scored 50%, the non-AI group scored 67%. The sharpest gap was in their ability to debug the code afterward. They could build with it. They couldn't fix it.

Four guidelines for staying solvent

Stauffer's practical framework is built around the idea that you can use AI to build beyond your current abilities without permanently surrendering comprehension—if you're intentional about it.

Reach from solid ground. Don't parachute into a completely alien ecosystem. Stauffer built Three.js—a JavaScript framework he didn't know—on top of Laravel, Laravel Cloud, Reverb, and other technologies he knew extremely well. One unfamiliar piece, surrounded by familiar infrastructure. The unknown is learnable when you can triangulate it against things you already understand. When everything is unknown, you don't even know where to start.

Don't stack your unknowns. This is where Stauffer admits his own project went sideways early. Three.js led to modern React (which he hadn't used in years), which led to Drei and Fiber (React-specific libraries), which led to Rapier for physics. Suddenly he had five unfamiliar systems running simultaneously. When he couldn't understand a piece of code, he couldn't even identify which unknown was tripping him. Was it Three.js? React hooks? Drei? He couldn't tell, and that confusion made intentional learning nearly impossible.

Google's Addy Osmani draws a distinction Stauffer found useful here: cognitive offloading versus cognitive surrender. Offloading means delegating a task while maintaining ownership and understanding—a senior developer reviewing a junior's code, for instance. Surrender means accepting whatever the tool outputs as your final answer, with no mental model of what it actually does or why. The path from offloading to surrender is, Stauffer argues, shorter than we think, especially when you're juggling five unfamiliar systems at once.

Use AI to build comprehension, not just code. This one is the most counterintuitive and possibly the most important. Stauffer distinguishes between using AI to generate code and using AI as a learning partner. The Anthropic study showed that developers who asked AI conceptual questions—why does this work this way? what should I understand about this library?—outperformed those who just asked for fixes and features.

The practical suggestion: ask AI to build you a curriculum. "Here's what I know. Look at this codebase. What concepts am I missing? Walk me through what to learn, in what order." Or set it up proactively: ask the AI to maintain a running markdown document of things to learn as you build, then pause periodically to work through it.

"This promise that you're going to learn as you go," Stauffer said, "is completely bull unless you have an intentional system you can use to figure out how to learn as you go."

Own your failure path. This is the one that bit Stauffer hardest. After months of building Voxicon, he deployed it and a tester immediately broke it: place a stair block, dig it, try to place something else—nothing happens. He asked the AI to fix it. The AI tried and failed. Tried again, failed again. Neither of them understood the bug because neither of them fully understood how block storage worked in the system they'd built together.

"Something's broken and nobody in the room knows how to fix it is not a good moment."

The stair blocks were stored slightly differently from regular blocks. Neither Stauffer nor the model had internalized that. The implication isn't that AI is unreliable—it's that AI can't save you from comprehension debt you've accumulated in the system you built with it. When both you and the model are working from incomplete understanding, you're not debugging. You're rolling dice.

What this looks like at scale

After the talk, someone asked Stauffer how he handles this at Titan. His answer was characteristically unsentimental: everyone at the company needs to be an AI expert, and then they get to use their own judgment about how and when to apply it. He's not tracking token usage or mandating daily AI touchpoints—that way lies resentment and theater. But he's also not ignoring AI as a capability. The middle path is expertise-building followed by judgment.

His consultancy is now seeing clients arrive with AI-generated applications—reasonably polished UX, coherent workflows, working front ends—that aren't stable enough for production. Rather than viewing these as failed projects, Titan treats them as prototypes: the client has used AI to define and visualize their application, and now professionals take it from there. The people who built those prototypes couldn't have afforded a UX firm. Lovable and $700 in credits got them to a starting point that would otherwise not have existed.

That's actually a decent articulation of what the AI-enables-new-builders story looks like when it's working well—not code-to-production by someone who has no business pushing to production, but prototype-to-handoff where the expertise enters at the right moment.

Stauffer closed Voxicon's chapter with a note that carries past the conference room: by the time the project shipped, his understanding had caught up. The software got there first, but he followed. That's the hopeful version of comprehension debt—not a permanent deficit, but a temporary one you actively work to close.

The question is whether most developers building with AI right now are working to close it, or just rolling the tab forward and hoping it never comes due.

By Marcus Chen-Ramirez, Senior Technology Correspondent