Define vibe coding by reading the file the agent loads first
The dictionary definition is easy. Vibe coding is describing an app in natural language and letting an AI write and run the code. That is the concept. The operational definition is a 2,354-line file. The agent reads it before you type. Everything the session does or refuses to do is in there.
The two-sentence definition, and why it is not enough
Vibe coding is a workflow where you describe an app in natural language and an AI agent writes and runs the code for you. Andrej Karpathy coined it in February 2025 to name a shift from writing syntax to describing intent.
That is accurate. It is also the part every Google result stops at. The definition leaves out the thing that actually decides what a session looks like: the written contract the agent reads before your first prompt. Two tools can share an LLM and still produce wildly different sessions, because the rules they load first are different. If you want to define vibe coding in a specific product, read that file.
The file you can actually read
On mk0r, the rulebook is a single TypeScript module at src/core/vm-claude-md.ts. It is 2,354 lines long, exports 15 constants, and is copied into the sandbox at boot so the agent sees it before anything else. This is not a secret config or a marketing asset. It is the source of truth, it lives in the repo, and it is the closest thing mk0r has to a dictionary entry for vibe coding.
That header comment is not documentation. It is the invoice: the three file paths it lists get populated inside the VM the moment the template boots, so by the time your first message arrives, the agent is already holding the entire contract in context.
What the file becomes inside the sandbox
If you open a shell inside the VM mid-session, the rulebook shows up as real files on disk. This is how Claude Code discovers instructions and skills: by scanning its home directory and the project directory. Vibe coding on mk0r inherits that convention.
The six skills that get loaded with you
A skill in Claude Code is a markdown file with frontmatter. The frontmatter describes when the skill applies. The body is the prompt the agent loads when that skill is activated. Vibe coding on mk0r is not "one big prompt." It is six specialised prompts that turn on when the request calls for them.
frontend-design
Picks typography, color, layout. Forbids Inter, Roboto, Arial, system fonts, and purple gradients on white. Demands a committed aesthetic direction before coding.
copywriting
Enforces clarity over cleverness. Banishes exclamation points, marketing buzzwords, and hedge words. Writes CTAs like 'Save changes,' not 'Submit.'
backend-services
Wires pre-provisioned PostHog, Neon, Resend, and GitHub into the app. The agent checks /app/.env before asking you for keys.
algorithmic-art
Switches to p5.js via CDN. Uses flow fields, particle systems, recursive subdivision. Seeds randomness so runs are reproducible.
website-builder
Ships a multi-page site: homepage, pricing, about, blog. Opinionated page structure, not a blank canvas.
seo-page
Builds content pages with JSON-LD, breadcrumbs, FAQ schema, and a comparison table. 11 required sections, in order.
The definition is opinionated, and it shows
Most definitions of vibe coding are neutral. The contract on mk0r is not. It has opinions that the agent will act on without being asked. Below is a direct quote from the frontend-design skill. It is the part that keeps every output from looking like the same "AI landing page."
These are not suggestions in a blog post. They are rules inside the system prompt. The agent will pick a non-generic font, avoid purple-on-white, and refuse to leave Lorem Ipsum in the output. If you asked ChatGPT the same question cold, it would happily ship Inter and a purple gradient. The "vibe" in vibe coding is the behavior that falls out of rules like these.
Rules you can quote straight from the file
- Never default to Inter, Roboto, Arial, or system fonts
- No exclamation points. Ever. They weaken copy
- Remove filler words: very, really, just, actually, basically, simply
- No marketing buzzwords: streamline, optimize, innovative, seamless
- Three colors maximum: black, white, and one dominant accent
- Do not modify /opt/*.js or /opt/startup.sh (VM infrastructure)
- Do not write files outside /app unless the user explicitly asks
- Always trim env var values to strip trailing newlines
Pre-provisioned services are part of the definition too
A big reason vibe coding feels fast on mk0r is that the agent does not start from zero. The project CLAUDE.md includes a table of services that are already wired up. The agent is told to check /app/.env before asking for credentials. This is why a waitlist site can collect real emails on turn one instead of waiting for you to sign up for Resend.
How one file fans out into a full session
The rulebook does not sit in memory as a blob. Each piece hits a specific part of the runtime. The diagram below is how one file turns into a working agent.
vm-claude-md.ts at runtime
Memory is written into the definition, not tacked on
Most "AI coder" products treat memory as an add-on feature. On mk0r, it is the second section of the global rulebook, right after the role description. The agent is told to save a memory the instant the user corrects it, names a preference, mentions what the app is for, or rejects a direction. That is not behavior the LLM invents. It is behavior the file demands.
The memory loop the contract prescribes
The user sends a prompt
It can be the first message or the tenth. The agent reads the rulebook first, then the user's text.
The agent decides whether to save
The rulebook lists the triggers: a name, a skill level, a color preference, a rejection. Any match fires a write.
A memory is written with a type
user, project, feedback, or reference. Typed memory is searchable. 'Do not use blue' is feedback; 'targeting restaurant owners' is project.
Next turn reads the memory back
The rulebook also instructs the agent to read memories at the start of each turn, because the conversation may be long and early details get compressed.
Open a session against the real contract
No signup. The agent you talk to loads this file before it reads your first message.
Start building →SERP definition vs. operational definition
Both definitions are correct. One of them tells you what vibe coding is called. The other tells you what actually happens when you use it.
| Feature | SERP definition (most articles) | Operational definition (mk0r) |
|---|---|---|
| Length | A sentence or two | 2,354 lines of written rules |
| Typography rule | Not mentioned | Never Inter, Roboto, Arial, or system fonts |
| Copy rule | Not mentioned | No exclamation points. Ever |
| Services the agent can use | Not mentioned | PostHog, Neon, Resend, GitHub (names and env vars) |
| Memory behavior | Vague reference to 'the AI remembers' | Triggers, types, when to read, when to write |
| Guardrails | Not mentioned | Cannot touch /opt/*, Chromium, HMR, files outside /app |
| Where you can read it | A tweet from February 2025 | src/core/vm-claude-md.ts in the public repo |
The short answer, with the part that matters
Vibe coding is a natural-language workflow for building software with an AI agent. The concept is a tweet. The definition of a specific vibe coding tool is the contract the agent runs under. On mk0r that contract is 0 lines of written rules, 0 named skills, and 0 pre-provisioned services, all living in one file you can open and read.
Strip the file out and the sessions stop producing coherent output. Keep it in place and "describe the app and it appears" actually works, because the agent has already been told how to behave before you ask.
Want the walkthrough instead of the file?
Book a 20 minute call and we will open a session, read the rulebook together, and show how each section of the file shapes the output for your use case.
Frequently asked questions
What is the shortest honest definition of vibe coding?
Vibe coding is a workflow where a human describes an app in natural language and an AI agent writes and runs the code, inside an environment the agent can act on. Andrej Karpathy coined the term in February 2025. The short definition is accurate but incomplete: it leaves out the rulebook the agent operates under, which is where most of the actual behavior comes from.
Why is the 'rulebook' the real definition?
Two agents with the same LLM but different system prompts produce very different sessions. Ask one for a landing page and it picks Inter and purple gradients. Ask another, under mk0r's prompt, and it will refuse Inter by rule ('Never default to Inter, Roboto, Arial, or system fonts') and pick an accent that is not purple. The behavior lives in the written rules, not in the model.
Where is mk0r's rulebook stored?
In a single TypeScript file at src/core/vm-claude-md.ts. It is 2,354 lines long and exports 15 constants. globalClaudeMd is written to /root/.claude/CLAUDE.md in the sandbox, projectClaudeMd goes to /app/CLAUDE.md, and six named skill exports become SKILL.md files under /root/.claude/skills/. The agent reads all of these before your first prompt arrives.
What are the six skills the agent loads?
frontend-design, copywriting, algorithmic-art, backend-services, website-builder, and seo-page. Each is a markdown file with frontmatter that tells Claude Code when to use it. A request for 'a waitlist site with a Postgres backend and email capture' activates website-builder, copywriting, and backend-services in one session.
Which pre-provisioned services does vibe coding on mk0r get out of the box?
The project CLAUDE.md advertises four: PostHog for analytics (VITE_POSTHOG_KEY, VITE_POSTHOG_HOST, VITE_POSTHOG_APP_ID), Neon for Postgres (DATABASE_URL, NEON_HOST, NEON_DB_NAME), Resend for transactional email (RESEND_API_KEY, RESEND_AUDIENCE_ID), and a dedicated GitHub repo (GITHUB_REPO, GITHUB_REPO_URL). The agent checks /app/.env before asking the user for keys, so it can wire a working backend on the first turn.
Can the agent write to any file in the VM?
No. The rulebook includes explicit VM guardrails: do not modify /opt/*.js or /opt/startup.sh, do not kill Chromium, Xvfb, x11vnc, or the proxy, do not change Vite's HMR config, and do not write outside /app unless the user asks. These are part of the definition too. Vibe coding without guardrails is just 'let the AI do anything,' which is why it fails.
What specific writing rules are baked in?
The copywriting skill enforces: no exclamation points ever, no filler words like 'very' or 'really' or 'just', no buzzwords like 'streamline' or 'seamless', and specificity over vagueness ('Cut weekly reporting from 4 hours to 15 minutes' beats 'Save time on your workflow'). If the agent writes copy on mk0r, it writes to these rules by default.
Do I need to read the rulebook to use it?
No. The rulebook exists so you do not have to think about it. You open mk0r, describe what you want, and the contract runs silently in the background. Reading it only matters if you want to understand why the output looks the way it does, or if you are comparing vibe coding tools and want to know what is actually different between them.
Read the definition, then put it to work. No signup required.
Start a vibe coding session