How does prior coding experience change the way students use vibe coding tools?

This explores whether prior coding experience changes how students *use* vibe coding tools, and the most useful finding in the corpus is that the difference is less about output and more about where attention goes. Vibe coding is designed to sit in a middle zone — more hands-on than a fully autonomous agent, but still steered by a human who reviews and corrects. The catch is that novices often don't behave that way. They drift toward agent-style passivity: minimal engagement with the code, surface-level testing, and a 'just restart and re-prompt' strategy when something breaks, which quietly defeats the tool's core assumption that a human is actively in the loop Does vibe coding actually keep humans in the loop?.

You can see this concretely in where students spend their time. Across one cohort, almost two-thirds of interactions were testing the prototype while only about 7% touched code at all — and of those code interactions, 90% were *reading* rather than editing Where do vibe coding students actually spend their debugging time?. In other words, less-experienced users debug at the level of 'does the app do the thing?' rather than 'why does this function do the thing?' Prior coding experience is essentially what lets someone drop down to the implementation level when the prototype-level fix stops working. Without it, the floor of the tool becomes the ceiling.

The more unsettling adjacent finding is that this gap is partly hidden from the student themselves. AI-mediated work produces a kind of competence misattribution: attribution ambiguity (who actually wrote this?), a fluency illusion (smooth output feels like mastery), cognitive outsourcing, and pipeline opacity all combine — and they amplify each other — so the output gets read as the user's own skill How do AI tools trick users into overestimating their own skills?. A novice using a vibe coding tool can ship something impressive and conclude they've learned to code, when what they've learned is to operate the tool.

The encouraging counterweight is that the *tool* isn't destiny — the *mode of engagement* is. A randomized trial of developers learning new libraries found AI assistance degraded conceptual understanding and debugging ability under low-engagement patterns (quiz scores of 24–39%), but the same tools under high-engagement patterns with active comprehension steps reached 65–86% Does AI assistance actually harm the way developers learn?. That maps cleanly onto the experience gap: experienced students already have the habits (read the code, predict behavior, isolate the bug) that turn a vibe coding session into deliberate practice, while novices default to the passive patterns that flatten learning.

The thing worth carrying away: prior experience doesn't just make students faster with these tools — it changes which *layer* of the problem they can even see. The novice is locked at the prototype surface and feels competent there; the experienced coder treats the same tool as a fast collaborator they can overrule at the code level. The open design question the corpus hints at is whether vibe coding tools can be built to pull novices down into that engaged mode on purpose, rather than letting them coast in agent-style passivity.