What is a vibe coding session, really?
Every article on the first page of Google tells you vibe coding is "describe what you want and let AI write the code." That is the surface. The thing that makes a session actually work is not the prompt, it is the streaming agent protocol behind it.
The definition nobody finishes
Andrej Karpathy coined "vibe coding" in February 2025 to describe a workflow where you stop writing syntax and start describing intent. The AI does the typing. Most articles stop there, list a few tools, and call it done.
The part they skip is why it feels different from asking a chatbot for code. When you paste a prompt into ChatGPT, you get a response. When you open a vibe coding session, you get a live feed of everything the AI is doing: files being edited in the sidebar, the dev server restarting, a browser tab refreshing, console errors appearing and disappearing. You are not requesting an artifact. You are watching an agent work.
That feed is not decorative. It is the protocol. Without it, vibe coding collapses back into copy-paste.
Three pieces every real vibe coding session needs
Anyone can slap "AI coder" on a chat UI. A session only earns the name when these three things are true at the same time.
A bidirectional agent protocol
The AI has to stream structured events back to the UI, not just text. File edits, shell commands, browser screenshots, tool results — each one typed, not stringified into a paragraph.
A live runtime the agent can act inside
File system, shell, dev server, and a real browser. If the AI cannot run what it writes, it cannot catch its own mistakes.
A UI that surfaces the event stream
You need to see what the agent is touching so you can stop it, revert it, or guide it. Hidden agents feel like lag.
The protocol mk0r actually speaks
mk0r does not invent its own wire format. It speaks the Agent Client Protocol (ACP), the open spec published by the Zed editor team as the npm package @zed-industries/agent-client-protocol. Version 0.4.5 is pinned in package.json, and the chat route imports the two types that matter most: SessionNotification for every incremental event, and PromptResponse for the final turn result.
That import is the anchor of every vibe coding session on mk0r. When you hit enter on a prompt, the server opens a fetch stream to an ACP bridge inside the VM. The agent emits SessionNotification updates as it works. The frontend reads them off the stream and renders the matching UI: a tool call card, a file-edit chip, a browser screenshot, a text chunk. Close the stream, and the illusion ends.
What one turn actually looks like on the wire
Below is the real shape of one turn. Your browser talks to mk0r, mk0r talks to the ACP bridge inside the pre-warmed E2B VM, and the agent inside the VM streams events back.
One vibe coding turn, end to end
Notice that nothing about the protocol says "return a markdown blob of code." Every event is typed. Every tool call is a discrete object. That is why mk0r can show a file-edit chip, a browser preview, and a diff all at once instead of one long chat bubble. The wire format is richer than text.
Where vibe coding lives: the runtime
A protocol needs a place to run. For mk0r that place is a pre-baked E2B sandbox. The template name and id are hard-coded in src/core/e2b.ts, and the file comment at the top is unusually candid about what that buys you.
Three constants here do all the heavy lifting. E2B_TEMPLATE_ID points to a snapshot with Node, Vite, Playwright, Chromium, and the ACP bridge already installed, which is why cold boot lands near 2.5 seconds instead of two minutes. POOL_MAX_AGE_MS keeps a warmed sandbox alive for up to 45 minutes, so the /api/vm/prewarm endpoint can top the pool up without constantly churning. VM_POOL_TARGET_SIZE sets how many stay hot at once.
The home page hits /api/vm/prewarm the instant it mounts. By the time you finish typing your first prompt, the sandbox you are about to get is usually already booted, with git initialized, the dev server running on port 5173, and the ACP bridge waiting for your session.
What the UI actually does with the event stream
The agent sends events. The UI has to decide what to do with each one. This is where the "vibe" part happens. Every event type fans out into a different piece of visual feedback, so the session feels alive instead of like a loading bar.
How one prompt fans out into the interface
Vibe coding vs. "AI writes code for me"
Both use an LLM. Only one is a session. Here is what differs once you look past the chat window.
| Feature | Chatbot code assistant | Vibe coding on mk0r |
|---|---|---|
| Interaction model | Request, response, copy, paste | Streaming agent protocol (ACP) |
| Runtime | None, you run the code yourself | Real VM with Vite, Chromium, Playwright |
| Self-verification | You test, then paste errors back in | Agent opens a browser and checks its own output |
| Version control | You save files, you remember what you changed | Every turn is a git commit, one-click revert |
| Boot time to first token | Instant chat, but zero working environment | ~2.5s from a pre-warmed sandbox pool |
| Account required | Usually yes | No, just a session key in localStorage |
What you actually do in a session
The protocol disappears as soon as you use it. You type something, you watch it build, you point at what is wrong, you move on. It feels less like programming and more like directing. That is the vibe.
The reason it feels that way is that you are not waiting on the AI, you are watching it work. Each event that lands is a piece of evidence that the system is doing what you asked, or a clue about where it went off the rails so you can steer it back.
Open a vibe coding session
Type a description, watch the protocol open, no account required.
Start a session →The short answer, with the part that matters
A vibe coding session is a natural-language conversation with an AI agent that writes and runs code for you inside a live environment, surfacing every step as a typed event on a streaming protocol. On mk0r, that protocol is the Zed editor's open Agent Client Protocol at version v0 (the 0.4.x line), running against a pre-baked E2B sandbox that boots in about 0s from a pool that stays warm for up to 0 min.
Strip any of those pieces out and it stops being vibe coding and becomes copy-paste. Keep them in place and the session feels like thinking out loud, which is the whole point.
Want the tour instead of the spec?
Book a call and we will open a live session, walk through the ACP stream event by event, and show how your use case fits the agent loop.
Frequently asked questions
What is a vibe coding session in plain terms?
A vibe coding session is a conversation where you describe an app in natural language and an AI agent writes and runs the code for you. Andrej Karpathy named the style in early 2025. What makes it a session (rather than just a prompt) is that the AI can act across many steps, edit files, run commands, test its own output, and report back every action as a typed event you can watch live.
How is vibe coding different from using ChatGPT to write code?
ChatGPT returns a block of text. You copy it into a file, try to run it, and if it fails you paste the error back. In a vibe coding session the agent is already inside a running environment. It writes the file, runs the dev server, opens the browser, reads the page, catches the error, and fixes it. You do not mediate the loop, you watch it.
What protocol does mk0r use to run a vibe coding session?
mk0r uses the Agent Client Protocol (ACP), the open spec the Zed editor publishes as @zed-industries/agent-client-protocol. The chat route in src/app/api/chat/route.ts imports SessionNotification and PromptResponse from that package and forwards every agent event (file edits, tool calls, browser observations, text chunks) to the UI as it happens.
What infrastructure has to exist for vibe coding to work at all?
Three pieces: a bidirectional agent protocol so the AI can stream actions back to you, a real runtime where the AI can actually execute those actions (file system, shell, browser), and a UI that surfaces the event stream so you can interrupt. mk0r runs a pre-baked E2B sandbox (template id 2yi5lxazr1abcs2ew6h8) that boots in about 2.5 seconds, with a Vite dev server, Playwright browser, and an ACP bridge all ready to go.
Why does it feel instant on mk0r and slow on other tools?
mk0r keeps a pool of pre-warmed VMs in Firestore. The pool target is configurable via VM_POOL_TARGET_SIZE, entries live up to 45 minutes, and the home page pings /api/vm/prewarm on load so a sandbox is already booting before you click anything. When you send your first prompt, the ACP session is usually claimed from the pool instead of cold-started.
Do I need an account to start a vibe coding session on mk0r?
No. mk0r stores a session key in localStorage as mk0r_session_key. There is no signup wall. You open the site, type a prompt, and the session opens against a warm sandbox. The session key persists across visits so your project history follows you without ever entering an email.
Can I see the code the AI wrote and keep it?
Yes. Every session is a real git repo inside the VM. Every turn becomes a commit. You can view history, revert to any turn, and the output is standard Vite plus React plus TypeScript so you can export it and run it anywhere.
Is vibe coding safe if I do not know how to code?
Safer than copy-pasting from a chat window, because the agent is the one running the code in an isolated VM and checking the output. You are the reviewer, not the integrator. Still, read the preview carefully, watch the version history, and do not paste secrets into a public session.
Ready to open a session? No signup, just a prompt.
Start Vibe Coding