How to do it well

What is written here are practices repeated in three or more papers, plus points that came up separately in studies of artists. Sources are given, so you can read the originals in References to see why. The order is "before → during → how to look → for artwork → before putting it out".

Before

1. Decide which model you will work in. If it is a throwaway prototype, you do not need to look at the result. If it is a work you will keep, use the loop of reading, running and checking [7]. The conclusion across the literature is that vibe coding is strong for prototypes and exploration and weak for production and safety [4].
2. Think without AI first. The idea comes from you and the implementation from the AI. This order leaves the most creative moments and the most original ideas [25]. Designers also recommended brainstorming alone first [19].
3. Break it down. In an experiment with 22 artists, the group that split the work into subtasks reflected 1.5 times as much, and the group that asked for everything at once scaled back its ambition [22]. A practitioner's analogy: ask for "a glass of water" and the AI does not know whether the glass is glass or brick, so ask in order (the water first, then the amount, the cup, the shape) [19]. People in YouTube sessions who restarted a whole project also gave the reason that they had asked for too much at once [15].
4. Keep a rules file and a plan. The experienced users observed wrote the language, framework and style in .cursorrules/CLAUDE.md, and made a sketch and a short plan first, so that the model would hallucinate less [2]. Practitioners report that rules files really are followed [12].

During

5. One thing at a time. Generate in small steps and roll back to the previous step if it fails. Changing a lot at once leads to hallucination or to parts of the request being forgotten [19]. Lock the scope in each prompt: "step 1 only", "no Stripe yet, just the design with dummy data" [2].
6. Give context. Name files and functions directly, paste error messages as they are, give screenshots and reference images, and give documentation URLs [2][8][19]. Half the participants in a visualization study switched to hand sketches, annotated screenshots or Figma when words were not enough [29]. To point at an exact spot, find the element's id in the browser developer tools and put it in the prompt. Participants found that naming a specific DOM element always gave better results [29].
7. Short and action-oriented. Instructions that worked averaged 18 words, for example: remove the tail, have it sit on its hind legs, make both front paws visible [17]. A vague "make it cooler" returns only generic suggestions [8].
8. Do not be afraid to throw a session away. When a conversation starts to lose its mind, open a new one [12]. The experienced users observed opened a fresh composer window for each new step and closed tabs to clear the context [2].
9. Checkpoints. A commit is a save point [8]. One piece of advice from the streamer study: do not fear git reset --hard, roll back and roll the dice again [13]. Not knowing how to return to a Cursor checkpoint was an actual observed problem [2]. For artists who managed versions by duplicating files and taking screenshots [21], a one-line commit is an upgrade of that habit.
10. Make small fixes by hand. If the fix is shorter than the prompt, do it yourself [2]. As one participant put it, the AI takes 30 seconds to change one line and they take 10 [29]. Artists used prompts for big leaps and sliders and code for the last 10% [21][23].

How to look: this is the real review

11. Run it every iteration and look with your own eyes. Software is done when "the tests pass", but in visual work only a person can judge whether it looks right, and the model cannot judge aesthetics [29][17]. So running it on every turn is your acceptance test [7].
12. Do not believe "it's done". Put several requirements in one prompt and the AI does some of them and writes in the summary that it did all of them [29]. In one case the agent reported "78% success" and, when pressed, admitted that 97 of 135 had failed [11]. Read phrases like "PRODUCTION READY" as a warning sign.
13. Check that earlier constraints still hold. Satisfying the latest prompt while breaking the constraints of an earlier one is a repeatedly observed failure [29]. Polishing a feature breaks something that used to work [13].
14. At least read what changed. Practitioners name two tools for vibe coding well: reading the code line by line and testing what the code does [12]. If you cannot read it, ask for an explanation ("explain this code", "is this based on fact?") [13]. Pointing out why it works, even in one line, is what separates this from a workshop where people only follow steps.
15. Press beyond the happy path. Of the tests done by 19 students, 91.7% were on the normal path and 2.2% on edge cases [15]. Try strange input, empty input, double clicks.
16. Be suspicious of AI-written tests and self-review. The AI may have written the tests just to pass [13], and you cannot outsource verification to the model that generated the code [12]. Still, the single line "review your changes" reduced the reintroduction of security flaws from 40% to 18% [30]. That means it is better than nothing, and it does not mean it can replace you.
17. Do not just paste the error back in. One streamer sent 31 prompts in a row over an hour containing nothing but error messages [13]. Asking again with no new information is "rolling the dice", and for people who had never looked at the code, 40% of their prompts were like that. Before sending again, add one thing that is different: a screenshot, what you expected versus what happened, which line.

For artwork

18. Ask for alternatives: three of them. Anchoring on the first result was observed in both artists and students [24][14]. Remedies: three concepts before committing [14], running the same prompt in two tools and choosing [13], several mood boards before any code [28]. This is Compton's "mutant shopping" [38].
19. Ask for the reasoning and a reflection question as well. "Give me the reason for this change, and one question for me to think about." This alone turned artists' parameter tweaking into causal reasoning and raised originality ratings [23]. While you are learning, having the AI give questions and conceptual guidance instead of answers prevents copy-pasting [26][27].
20. Make meaningful handles. "Bloom", not z-scale [38]. Ask for the "magic constants" in generated code to be pulled out as sliders, and it becomes a tool that fits how artists actually work (constant tuning) [21].
21. Choose sounds with your ears. An LLM does not know what its code will sound like [31]. Make several candidates and listen, have Max patches generated through MaxPy, and if you want stranger results, say "use loops and random()" [32].
22. Give a small vocabulary. Naming libraries that map 1:1 to natural-language concepts, such as ml5, p5.sound and Tone.js, raises pass rates a lot [34]. The more common the stack, the better the AI helps [12], and for languages without training data the accuracy drops sharply [32].
23. Put in your own material. The remedy for homogenization is feeding in references: your palette, your images, your sounds, your sentences [28]. One artist wished the tool would learn from them instead of from the whole world [21].
24. Keep a record of prompts. The recommendation to keep prompts, assumptions and model versions for work you will archive comes up repeatedly [4][5]. Designers suggested treating the AI like a co-author: record your prompts and note where the AI stepped in [19]. You will need this to talk about "what you chose" at the December critique.

Before putting it out

25. Put "ready for production" in the prompt, and when it is finished, ask it to "review your changes". These two lines were the most effective single interventions (recurrence 40%→13% and 40%→18%) [30]. In contrast, an "expert prompt" crammed with technical detail made things worse (56%).
26. Scan for TODOs, "temporary", "for demo" and hardcoding. In deployed apps, a // TODO comment for password validation shipped as is, and "for demo" base64 "encryption" was left in place [30].
27. Keys go in .env; check .gitignore. This is exactly the step agents hand over to the user and quietly skip [30]. Practitioners report passwords stored in plain text [12].
28. The standard changes the moment others can see it. The nature of the activity changes the moment you move from a page for yourself to a page for others [39]. Practitioners' self-discipline: vibe for weekend projects and localhost, and not when passwords, data or other people's time are at stake [12].