How to Vibe Coding: the part every guide skips
Vibe coding is not just "accept the diff." If the model cannot open the app and look at it, you are the feedback loop, and the vibe is gone. Here is what the loop actually has to contain, and how mk0r wires it for you.
The definition most guides give you
Andrej Karpathy coined vibe coding in early 2025 to describe a mode where you talk to an LLM, accept what it produces, and only look closely when something breaks. The top search results all repeat that definition and then list tools. Describe, accept, ship.
That description is accurate, but it is missing the loop. Describe and accept works if, and only if, the thing you accepted actually runs. Otherwise you are back to reading code line by line to check the model, which is the exact activity vibe coding was supposed to replace.
The real loop: the model needs eyes
A vibe coding session works when this cycle runs end to end without you in the middle:
- You describe what you want.
- The agent edits files.
- A dev server picks up the edits.
- The agent opens a real browser and loads the app.
- The agent reads the DOM and console, spots problems, fixes them.
- Only then does it tell you it is done.
Steps 4 and 5 are the ones most tutorials skip. Without them, "done" means "the code compiled," which is not the same as "the app works." A component that is never imported, a Tailwind class that collapses a flex container, a route that never mounts, all of these compile and all of them break the vibe.
How mk0r wires it (the anchor)
When you prompt mk0r, a Freestyle VM starts with four processes behind a single proxy on port 3000:
The agent that receives your prompt gets Playwright MCP as a tool. Its system prompt, hard-coded at src/app/api/chat/route.ts line 8, spells out the exact loop:
Step 4 is the difference. The agent literally calls browser_navigate on the Playwright MCP server, takes a snapshot of the DOM, reads the console, and iterates until the page looks right. You can watch it happen in the screencast while it works.
Try the loop without setting it up
No account, no install. Describe an app and watch the agent build and test it.
Start Vibe Coding →If you want to wire this yourself
The same loop works locally if you are willing to assemble the parts. You need:
- A dev server with hot reload. Vite on 5173 is the obvious pick; Next dev also works.
- Playwright MCP, running as an MCP server the agent can call. Install
@playwright/mcpand expose it over SSE or stdio. - An agent runtime that supports MCP tool use. Claude Code, the Claude Agent SDK, and the Agent Client Protocol all qualify.
- A system prompt that tells the agent to open the app and fix what it sees before reporting. This is the most overlooked piece. Without an explicit instruction, agents default to writing code and stopping.
The mk0r system prompt is a reasonable starting point. Copy the workflow block, adapt the port numbers, and drop it into your own agent config.
When to stop vibing
Vibe coding is a speed mode. It works well for greenfield UI, small tools, and throwaway apps where the cost of a bug is low and the model can recover by looking at the result. It starts to fray when the app has invariants the browser cannot check: data integrity, authorization, payment flow, migrations.
At that point, read the code. The nice thing about vibe coding on a real Vite + React + TypeScript project is that there is real code to read. You are not locked into a DSL or a visual runtime; you can pull the project down and keep going by hand the moment the vibe stops being enough.
Frequently asked questions
What is vibe coding, in one sentence?
Vibe coding is describing what you want in plain English and letting an LLM write the code, accepting the output by feel rather than reading every line. The phrase comes from Andrej Karpathy in early 2025. The part most guides skip: the vibe only holds if the model can run and see the app too, otherwise you end up accepting broken code that looks right in a diff.
Why does a visual feedback loop matter for vibe coding?
Text only tells the model what it wrote, not what actually renders. A TypeScript file can compile cleanly and still produce a blank page because an import was missed, a route was wrong, or a Tailwind class collapsed the layout. If the agent cannot open the app in a real browser and check, you become the eyes, which defeats the point of vibe coding.
How does mk0r give the model eyes?
Every mk0r VM runs Playwright MCP on port 3001 behind the VM's proxy. The agent has Playwright as a tool and the system prompt tells it to open Chromium, navigate to http://localhost:5173, check the page, and fix any errors it sees before reporting done. You can read the exact instructions in src/app/api/chat/route.ts starting at line 8.
Do I need to install anything or sign up to try vibe coding on mk0r?
No. mk0r has no account, no install, and no credit card. You open the site, describe an app, and a VM with Vite, React, TypeScript, Tailwind v4, and Playwright MCP boots from a pre-warmed snapshot. The agent starts writing code while the preview streams back.
What is actually inside the VM when the agent builds?
Four processes behind one proxy on port 3000. Vite dev server on 5173 (the preview), Playwright MCP on 3001 (the browser the agent uses to test), an ACP bridge on 3002 (runs the Claude agent subprocess), and the proxy itself. The Vite server is already running when the agent arrives, and Tailwind v4 is pre-configured, so the agent only has to edit files under /app/src.
Why does the mk0r system prompt insist on editing /app/src/App.tsx?
Because components that are not imported from App.tsx never appear on screen, and vibe coding fails silently when the model creates a beautiful component that no route ever renders. The prompt makes it a rule: if you create src/components/Foo.tsx, open App.tsx and render Foo in it. Rule 3 in the system prompt at src/app/api/chat/route.ts:18.
When does vibe coding stop working and what do you do then?
When the prompt gets longer than a screen, when there are real invariants to preserve, or when the app depends on specific data shapes from a backend. At that point, stop and read the code. Vibe coding is a speed mode for greenfield and UI work, not a substitute for architecture. The mk0r VM hands you a plain Vite + React project you can pull down and edit by hand the moment you need to.
Describe an app. Watch the agent build it, open it in Chromium, and fix what it sees. No signup.
Start Vibe Coding