The vibe coding beginner trap is grooming the prompt

Tutorials show one long prompt and a finished app. Beginners imitate that with a 200-word brief, hit enter, judge the first output, and conclude the tool is broken. The product code says something else. The rulebook the agent loads before turn 1 is already 2,845 lines, and 8 templates fire on 1-word triggers. A 3-word prompt plus follow-ups beats a polished paragraph almost every time.

Matthew Diakonov, Written with AI

Published May 21, 20269 min read

Direct answer · verified 2026-05-21

The beginner trap is grooming the prompt.New vibe coders treat the first prompt as the deliverable because tutorials demo it that way. On mk0r the agent's rulebook (2,845 lines at src/core/vm-claude-md.ts, loaded before turn 1) makes the prompt step 1 of roughly seven; the agent then picks a template if your phrasing triggers one, checks pre-provisioned services in /app/.env, edits files, verifies in a browser, and commits the turn. The polished prompt overrides almost none of that and buries the trigger words that would have helped.

What the trap looks like in the wild

A beginner opens an AI app builder, picks a tutorial-shaped project (“a recipe-sharing app with users, profiles, comments, and a feed”), and writes a paragraph. They include requirements they think a real app would have: authentication, a database, dark mode, mobile responsiveness, three color schemes, a hero section with a CTA, a footer with social links, accessible forms, loading skeletons, error states, an empty state. They press enter. They wait.

The model generates something. The page renders. Some bits look good. The header is centered, the colors are fine, the layout holds. Other bits look generic in a way the beginner cannot quite name. The hero font is Inter. The CTA is a purple-to-blue gradient. Every section is a rounded card in a uniform grid. The empty state says “Nothing to see here yet.” The beginner concludes: vibe coding produces AI slop. The tool is broken. Or they are bad at prompting.

Neither is true. What happened is that the polished prompt replaced the trigger words the template system was waiting for (“recipe-sharing app” has no template; “flashcards for braised pork techniques” would have fired one) and the list of generic requirements pulled the agent down a generic path. The rules in the rulebook that ban Inter, ban purple gradients, and ban uniform card grids were still in effect, but the agent took the user's repeated emphasis on “professional” structure as an override.

What the agent already does on autopilot

Before you write a word, the agent has loaded seven habits. Each is verifiable in the public repo. The trap is writing prompt content that duplicates or overrides any of them.

1
Read the rulebook
Loads 2,845 lines of CLAUDE.md (Tailwind v4, mobile-first, three colors max, no Inter, no purple gradients, no icon libraries unless asked).
2
Ask if unclear
Workflow step 1 is literally 'Understand what the user wants (ask if unclear).' The agent is allowed to interview you.
3
Check templates
Scans your prompt for trigger words and applies one of 8 pre-baked templates if it matches. Generating from scratch is slower and worse.
4
Read /app/.env
PostHog, Neon, Resend, GitHub are already provisioned in the sandbox. The agent uses those keys instead of asking you for new ones.
5
Edit and HMR
Writes files in /app/src/, the dev server hot-reloads. Components must be imported in src/App.tsx or they never render.
6
Verify in browser
Navigates to http://localhost:5173 via Playwright, takes a DOM snapshot, checks the console for errors before reporting completion.
7
Commit the turn
git add -A and git commit inside the VM after every successful turn. /undo walks back to the previous SHA; iteration has a real safety net.

Source: src/core/vm-claude-md.ts (rulebook, 2,845 lines) and src/app/api/chat/route.ts (turn limit, error handling).

The 8 templates the “polished prompt” kills

Eight templates ship pre-baked at /opt/mk0r-templates/ in the sandbox. Each has a small set of trigger words. When the agent sees one in the prompt, the rulebook's line 1167 takes over: “If a template matches, you MUST use it.” The template gives you a complete Vite + React + Tailwind scaffold with the right sections for that app type. Generating from scratch, by the rulebook's own words, is “slower, less consistent, and produces worse output.”

The triggers are short. They are exactly the words a beginner would replace when “making the prompt sound more professional.” If you have one of these app types, the shortest correct prompt is the one that contains the trigger verbatim.

Triggers that fire a template

restaurant, cafe, izakaya, bistro, bar, menu, reservation — fires the restaurant template
padel, tennis, squash, racquet, pickleball, sport club — fires the padel-club template
our wedding, save the date, RSVP, getting married — fires the wedding template
yoga, pilates, barre, vinyasa, meditation studio — fires the yoga-studio template
florist, flower shop, floral design, weekly bouquet — fires the florist template
real estate listing, property listing, for sale, MLS — fires the real-estate template
dashboard, admin panel, internal tool, QC, sample/run tracker — fires the lab-dashboard template
flashcards, spaced repetition, Anki/Quizlet, study app + a subject — fires the flashcards template

Source: src/core/vm-claude-md.ts, lines 1156-1167.

The numbers that should reset your expectations

0lines of rulebook loaded before turn 1

0templates that auto-apply on trigger words

0anonymous turns before sign-in gate

0old turn cap, raised because it was too tight

2 → 6

“Two turns was way too tight — users were getting blocked before they finished their first prompt cycle.”

src/app/api/chat/route.ts, line 21 (code comment above ANON_TURN_LIMIT = 6)

What to do instead

Treat the first prompt as the cheapest possible seed for a five-minute conversation. Three things to do, in order.

1
Name the app type in 1-2 common words.
“Restaurant site.” “Padel club site.” “Flashcards for the EU capitals.” If a template matches, you have already done the most valuable work the prompt can do.
2
Add the one specific thing the agent cannot infer.
The name. The city. The subject. “Restaurant site for Tonkatsu Maisen in Tokyo.” Not the color palette, not the font, not the section list. The agent has rules for those. It does not know who you are building this for.
3
Iterate in small, named diffs.
“Make the hero darker.” “Add a contact section with a map.” “Use Playfair Display for the headings.” Each one is cheaper than the alternative (rewriting the prompt) and is undoable for free. /undo and /revert exist as real chat-API routes; /regenerate does not.

The counter-case: when grooming the prompt actually helps

Long, detailed prompts are not always wrong. They work when the project does not match any template and you already know what you want. A bespoke internal tool, a personal portfolio with an unusual structure, a generative art piece, a custom dashboard for a real estate brokerage that does not match the single- property listing template — these benefit from a tight, specific brief because the agent cannot lean on a category.

The test is honest: if you can name your app type in two common words, the short prompt wins. If you cannot, write the brief. Most beginner projects fall into the first bucket; most production projects fall into the second. The trap is treating beginner projects like production projects.

“Keep this loose enough that a curious visitor can play with the product for a real session before hitting the gate. Two turns was way too tight — users were getting blocked before they finished their first prompt cycle.”

appmaker

src/app/api/chat/route.ts, comment above the anonymous turn limit constant

One more trap, briefly: speculative features

Beginners ask for authentication, payments, multi-user state, and real-time collaboration on the first prompt because they assume “real apps have those.” The rulebook explicitly forbids speculative abstractions and feature flags. The result of asking for four systems on turn 1 is four half-built systems and a fragile prototype. Pre-provisioned services in /app/.env cover analytics, email, database, and source control already, so most prototypes do not need a credential conversation at all. Add features when a real user behavior demands them, not when you can imagine demanding them.

Stuck on the prompt? Skip it.

Open mk0r, type three words, press enter. If you want a walkthrough first, book a 15-minute call.

Frequently asked questions

What is the biggest beginner trap in vibe coding?

Grooming the prompt. New vibe coders polish a 200-word brief because every tutorial models the prompt as if it were the work. On a tool like mk0r the agent has already loaded 2,845 lines of rules before you press enter, and 8 templates auto-apply on 1-2 word trigger phrases. A 3-word prompt with the right trigger word produces a better first draft than a polished paragraph, because the paragraph drowns the trigger and forces the general path.

Why is the long prompt a trap if the model accepts long prompts?

Three reasons. First, the longer the prompt, the more model attention drifts from the front of it by the time the back is processed — same drift problem long context windows always have. Second, the rules you are writing into the prompt are almost always already in the rulebook the agent loaded; you are duplicating it. Third, the agent's workflow step 1 is 'ask if unclear,' so vagueness in the prompt was meant to be resolved by a clarifying question, not by you pre-empting the question with three paragraphs.

What is the right shape for a beginner's first prompt?

Short, with a trigger word if your project matches one of the 8 templates. Examples that work: 'restaurant site for Tonkatsu Maisen in Tokyo,' 'flashcards for medieval German verbs,' 'padel-club site for Padel Lisboa,' 'dashboard to track QC samples by run id.' Each is 5-8 words, names the app type with a trigger word, and leaves the styling and structure to the rulebook and the template. Follow-ups handle the rest: 'make it darker,' 'add a contact section,' 'change the headline.'

Where is the 'rulebook' you keep mentioning and how do I read it?

It is a TypeScript module at src/core/vm-claude-md.ts in the appmaker repo. The file is 2,845 lines (run wc -l on it). It exports constants that become /root/.claude/CLAUDE.md (global config), /app/CLAUDE.md (project config), and six SKILL.md files (frontend-design, copywriting, backend-services, algorithmic-art, website-builder, seo-page). The agent loads all of it before the first prompt.

Why are 8 templates relevant to a beginner trap?

Because the template system is a 'must use' rule. The rulebook says 'If a template matches, you MUST use it,' and the templates are restaurant, padel-club, wedding, yoga-studio, florist, real-estate, lab-dashboard, flashcards. The triggers are short common words. A beginner who replaces 'restaurant' with 'a marketing website for a small dining establishment specialising in Japanese cuisine' has just killed the trigger and forced the agent to generate from scratch. Generating from scratch is, by the rulebook's own admission, slower and produces worse output.

How many turns does a first session actually take?

More than two. The anonymous turn cap on mk0r is ANON_TURN_LIMIT = 6 (src/app/api/chat/route.ts:23). The comment above the constant reads 'Two turns was way too tight, users were getting blocked before they finished their first prompt cycle.' That number came from telemetry on real first sessions: one prompt to seed, two or three to refine, one for a misstep, one to retry. The trap is grading the first output as if it were the deliverable when the product itself is tuned for six turns.

Should beginners try to write good code prompts, or just ship?

Ship. The fastest path to your first working app is 3 words plus iteration. Reading the rulebook is useful once you understand the loop, not before. Beginners who try to 'learn the right way to prompt' before building usually never build, because there is no right way to prompt, only a feedback loop. The product was tuned around that loop: the chat API ships /undo, /redo, /revert, /history and no /regenerate. The shape of the surface area tells you the shape of the work.

What about the 'I should add auth and a database from the start' trap?

That is a different trap and it is real. The global rulebook explicitly forbids speculative abstractions and feature flags. Beginners ask for auth, payments, multi-user state on the first prompt because they assume 'real apps have those.' The result is a fragile prototype with four half-built systems. Add features when you actually need them, not when you can imagine needing them. mk0r's pre-provisioned /app/.env covers analytics, email, database, and source control so you do not need to ask for them on turn 1.

When does a long, detailed prompt actually help?

When you already know exactly what you want and the project does not match a template. Detailed prompts are tighter iterations done in your head before sending. They work for one-of-a-kind apps where the agent cannot infer structure from a category (a custom internal tool, a personal portfolio with an unusual layout, a creative generative art piece). They hurt for everything that matches a template, because the template path is faster than the from-scratch path and the long prompt buries the trigger.

Does mk0r need an account to try the loop?

No. There is no signup, no payment, no email capture before you build. A session key is stored in localStorage and the agent runs against a pre-warmed E2B sandbox. You get up to 6 anonymous turns before you have to sign in, which is enough to seed, iterate twice, undo a misstep, and retry. Free model is Claude Haiku; paid plans add the larger models for harder problems.