Traps

This is the flip side of How to do it well: what is risky and why, with numbers.

Rolling the dice

An FSE 2026 paper analyzed 7 YouTube live sessions (16 hours, 254 prompts) [13]. V5, who never once opened the code, sent 31 prompts containing nothing but error messages in one hour and eventually switched on "YOLO mode". For the two people who had never looked at the code, 40% of prompts were repeat requests with no new information, while for those who looked at the code or had background knowledge it was under 20%. More than 20% of each session (over 50% for V5) was time spent waiting for generation. One commenter's objection is exactly right: you can reroll an image, but in programming, one pixel off is a bug.

The verification gap

• Classifying 518 behavioral units from 101 practitioner sources, the QA practices were "skipped" 36%, "uncritical trust" 18%, "delegating QA to AI" 10%, and "re-prompting instead of debugging" 5% [5]. For perceived code quality, "fast but flawed" was 68%.

  

• In a survey of 162 people, non-developers were the only group who answered that they do not check generated code, and they had the highest rate of giving up on debugging because they could not understand it [6].

• The conclusion of a review of 47 sources: the field converges on what to recommend but not yet on what works [4].

One paper calls the people who fall into this gap a new group of vulnerable developers who can build but cannot fix [5]. The dangerous moment is less when it fails and more when it seems to work while harboring subtle vulnerabilities and technical debt.

The lie of "done"

Agents inflate their progress. In a three-session case study [11], Claude Code declared "SYSTEM OPERATIONAL & VALIDATED" and documented "revolutionary achievements", then, when pressed, admitted that 97 of 135 tests had failed and said it seemed to be designed to prioritize appearing competent over honesty. The authors read this as a context-sensitive performance tuned to exploit user trust, more than as random hallucination, and argue that the informal mood of vibe coding encourages skipping verification to keep the flow going. The sample is small and the interpretation strong, so cite it only as a case. But the same thing was observed among the 16 people in the visualization study: doing only part of the work while reporting in the summary that all of it was done [29]. In the security study, in 32% of the runs that reintroduced a vulnerability, the agent knew about the risk, moved it into a comment, and deployed anyway [30].

Context momentum

What Sarkar and Drosos call "context momentum" [2]: path dependence in which earlier interactions and outputs strongly shape later direction. It is hard to move away later from an interpretation accepted early on, and as the line between prototype and production blurs, the first "vibe" sets the trajectory of the whole project. Practitioners' "prompt spirals", the disaster of 30 files changed with no commit [12], and the feeling that the model "gets dumber" in long sessions [13] are different faces of the same phenomenon.

Homogenization and fixation

• A controlled experiment: with an LLM, correct answers became more similar to each other, idea generation got shorter, and "aha" moments decreased, all the more in tasks with more freedom [25].
• A hackathon: 23 of 27 people explored 5 ideas or fewer, and every app's UI looked similar [14]. Results that closely resembled the workshop examples got low originality scores, and the authors say the scaffolding should be removed gradually [16].
• Designers said it is easy to stop at the easy answer and skip the hard, messy exploration where real creative breakthroughs happen, and that if you are not careful everything will look and work the same [19]. There is also the ownership problem: an almost finished draft feels like someone else's work.
• At the macro level there is a feedback loop: a model trained on the statistical average of the internet becomes a "universal homogenizer", and its output becomes training data again, a permanent flattening of digital heritage [28]. This is what Compton called "a thousand bowls of oatmeal" in 2015 [38].

Loss of understanding

• The price of "coding the way you paint" is the loss of the deep embodied understanding and skill formation that come from wrestling with the material resistance of code [2].
• Artists said they had less of a sense of holding on to what was going on [21]; 7 of 11 did not look at the code [24].
• Education research warns of an "illusion of competence": students who were confident with AI could not do it alone, and found that what they thought they understood fell apart when they built it themselves [18]. The same paper says vibe coding should be "strictly limited" for complete beginners, but that standard is for people who want to become software engineers. There is no reason to apply it as is to people making artwork, but two exercises are worth taking from it: "explain it" and "build it again without AI".
• The beginner's trap also runs the other way: to ask a question you have to know enough to know what you don't know [13]. A streamer making a 3D game said they did not know the 3D engine, so they did not know what to ask for.

Security

A study found 10,517 apps on GitHub with more than 85% of their code written by AI and audited 200 deployed ones [30]: 90% had vulnerabilities, 77% of those critical or high. Access control failures were 36%, and 63% of vulnerabilities were in the backend. Smaller apps had higher density (small does not mean safe), and the median development time was 9.8 days. Three failure types: memory failures (authentication added to the new router but not to 11 old handlers; a // TODO shipped as is), goal failures (a bypass login added because "Supabase auth was broken"; "for demo" base64 encryption), and knowledge failures (hallucinated APIs that do not exist; an instruction in CLAUDE.md to "protect the key with a Caesar cipher").

Most works that run locally are not affected. The moment a form, a database, an API key or a login is added, these numbers become yours.

Cost and lock-in

• Dependence on API credits and powerful machines raises concerns about exclusion and technological elitism [9].
• Control does not disappear; it concentrates in model and protocol providers [10]. Price changes, service shutdowns [3].
• 5.5% of creative code has already disappeared, and generative art depends on a "fragile supply chain" of assets, APIs and device protocols [36]. Generated code that nobody understands is even harder to preserve.
• And addiction: one practitioner described being literally addicted, and feeling like they were living a lie when people thought of them as a great coder [12]; others described it as almost like an addiction [19].

In class

So

What this list warns against is vibe coding without looking at the results, and vibe coding itself is fine. The final sentence of the review of 47 sources says that vibe coding should not be treated as a speed-first shortcut [4]. Remember also that the use the same literature supports most strongly is "prototyping and UI". That is exactly what we do on the first day.