INQUIRING LINE

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

This explores whether a student's coding background changes how they actually behave inside vibe coding tools — and the corpus suggests the gap shows up as how deeply they engage with the code, not just how fast they ship.


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.


Sources 4 notes

Does vibe coding actually keep humans in the loop?

Vibe coding sits between first-generation prompt-per-function completion and fully autonomous agentic coding, but novice users often behave like passive agent users—minimal code engagement, surface-level testing, restart strategies—defeating the tool's design assumption of active human steering.

Where do vibe coding students actually spend their debugging time?

Across 19 students, 63.6% of interactions involved testing the prototype while only 7.4% touched code directly. Of code interactions, 90% were reading rather than editing, suggesting students remain distant from implementation details.

How do AI tools trick users into overestimating their own skills?

Attribution ambiguity, fluency illusion, cognitive outsourcing, and pipeline opacity combine to systematically misattribute AI outputs as user competence. The effect is multiplicative—each mechanism amplifies the others.

Does AI assistance actually harm the way developers learn?

A randomized trial of developers learning new libraries showed AI use degraded conceptual understanding and debugging ability. Six interaction patterns emerged: three low-engagement patterns produced quiz scores of 24-39%, while three high-engagement patterns with active comprehension steps achieved 65-86%, suggesting the mechanism matters more than tool presence.

Research prompt for your LLMexpand ↓

Copy into ChatGPT or Claude to take this line of inquiry further — it asks the model to find newer work and re-test which earlier constraints still hold.

You are a learning scientist auditing claims about how prior coding experience shapes student behavior in AI-assisted coding tools. The question remains open: does experience truly shift *engagement mode* (surface vs. implementation debugging), or have newer vibe coding interfaces, better scaffolding, or training protocols since mid-2025 begun to flatten that gap?

What a curated library found — and when (dated claims, not current truth):
Findings span 2023–2026 and cluster around three constraints:
• Novice users of vibe coding tools default to prototype-level debugging (testing the app) rather than code-level debugging (understanding implementation); 90% of code interactions are reading-only, not editing (~2025).
• Competence misattribution (attribution ambiguity, fluency illusion, cognitive outsourcing, pipeline opacity) makes novices feel skilled when they've only learned to operate the tool, not code (~2026).
• AI assistance degrades conceptual understanding and debugging ability under low-engagement patterns (24–39% quiz performance) but reaches 65–86% under high-engagement patterns with active comprehension steps (~2026).
• The experience gap is *not* intrinsic to the tool but to interaction mode: prior experience equips students with deliberate-practice habits that turn passivity into active collaboration (~2025).

Anchor papers (verify; mind their dates):
• arXiv:2507.22614 — Exploring Student-AI Interactions in Vibe Coding (2025-07)
• arXiv:2604.14807 — The LLM Fallacy: Misattribution in AI-Assisted Cognitive Workflows (2026-04)
• arXiv:2601.20245 — How AI Impacts Skill Formation (2026-01)
• arXiv:2508.20722 — rStar2-Agent: Agentic Reasoning Technical Report (2025-08)

Your task:
(1) RE-TEST EACH CONSTRAINT. For every pattern above (surface-level debugging, misattribution, low-engagement collapse, mode-dependent learning), judge whether newer scaffolding, interface affordances (e.g., forced code-review steps, inline explanations, debugging hints), or training protocols have since pulled novices into high-engagement mode by default. Separately, ask whether agentic reasoning systems (rStar2-Agent onward) have made the prototype–implementation boundary less salient. Plainly state which constraints still hold and which appear softened.
(2) Surface the strongest work from the last ~6 months that either *contradicts* the claim that engagement mode is learnable/designable, or shows vibe coding tools that successfully *bridge* the novice–expert gap via interface alone.
(3) Propose 2 research questions that assume the regime *has* moved: (a) If vibe coding tools now routinely pull novices into high-engagement patterns, what *new* mode of misattribution emerges? (b) Does agentic code reasoning (not human-mediated vibe coding) render the prior-experience gap irrelevant, or simply relocate it?

Cite arXiv IDs; flag anything you cannot ground in a real paper.

Next inquiring lines