Vibe coding vs agentic engineering is not a choice. They are the same loop.
Every other writeup on this topic frames it as two methodologies you pick between. The honest reality is the chat is the vibe and the tool loop is the agent, and you cannot ship a working app with only one. mk0r is the worked example: the box you type into is a vibe surface, and the line that handles your prompt imports the Agent Client Protocol.
Direct answer, verified 2026-04-30
Vibe coding is the consumer surface: you describe an app in plain language, you accept what comes back, you do not read the code. Agentic engineering is the execution layer underneath: an agent plans, edits files, runs commands, opens a browser, validates, then iterates.
They are not competing methodologies. They are the chat side and the tool side of one loop. Any tool that ships actual running software has both, even when only one is visible. The arXiv paper Vibe Coding vs. Agentic Coding (2505.19443) gives the canonical academic framing; the diagrams show the same agent loop sitting under both labels.
On mk0r the proof is one line of code. Open src/app/api/chat/route.ts line 1: it imports @zed-industries/agent-client-protocol. That endpoint is what every "vibe" prompt hits. There is no non-agentic path.
The frame the existing playbooks repeat
If you read the top results on this topic, they all converge on the same shape. Vibe coding is "intuitive, conversational, low review." Agentic engineering is "planning, tool use, validation, oversight." You are then told to pick between them based on whether your output is throwaway or production. Most pages add a paragraph about how vibe coding fails at scale and you should graduate to agentic engineering for real work.
Two things are wrong with that frame. First, it talks about the two terms as if they are at the same level of the system. They are not. Vibe coding describes a feel, the experience of writing software by description. Agentic engineering describes a substrate, the kind of execution loop the model is running. A feel and a substrate are not alternatives.
Second, the frame implies that "non-agentic" vibe coding is a real thing you could buy. It is not. A chat that takes your sentence and prints code at you is a code generator, not an app. To get an app, something has to write files, run a build, open a browser, and confirm the page rendered. Those are tool calls. The agent loop runs whether the user notices or not.
Both columns at once: same prompt, two views
Here is one mk0r turn shown the way the user sees it on the left, and the way the agent runs it on the right. They are the same prompt. They happen at the same time.
One prompt, two layers
// What you type in the box on mk0r.com
"build me a habit tracker
with a 7-day streak counter
and a dark mode toggle"
// You hit enter.
// You watch the preview pane.
// You did not write a single line of code.What sits under the chat box on mk0r
mk0r's chat is one POST per prompt to /api/chat. That endpoint hands the prompt to an Agent Client Protocol bridge running inside an E2B sandbox, which has the model wired to four real services. The diagram below is what every prompt actually touches.
The vibe surface and the engine, in one session
See src/core/e2b.ts line 148 for the system prompt that names this whole stack, and line 153 (buildMcpServersConfig()) for how Playwright MCP gets bolted to Chromium.
One turn, ten round-trips
People imagine a "vibe" prompt as a single round-trip: text in, code out. It is not. Here is the round-trip count for one mk0r prompt that builds a small app, end to end. Most of these are invisible to you.
POST /api/chat: 'a habit tracker app' (one prompt)
What each layer is actually doing
The two columns below are not opposites. They are what is happening at the same moment, on the same prompt, in the same product.
Vibe surface
- You type one sentence
- You watch a preview render
- You react to what you see
- You do not read the code
- You do not run a build
- You do not open a debugger
Agentic engine
- Plan named tasks for the turn
- Issue write_file tool calls through ACP
- Run npm/git/shell via the ACP /exec endpoint
- Drive Chromium through Playwright MCP
- Take DOM snapshots and screenshots
- Commit a SHA per turn for replay
The five steps of the agent loop, on every turn
Every prompt on mk0r runs through these five phases. None of them are optional. The chat surface hides the bookkeeping; it does not skip it.
Plan
The agent receives your one sentence, reads its 2,354-line rulebook (src/core/vm-claude-md.ts), and decides what files to write, in what order, and what to verify before reporting done. None of this is in the chat output.
Edit
It issues write_file tool calls through the ACP bridge running on port 3002. New files land at /app/src/*. The Vite dev server on port 5173 picks up the change via HMR.
Run
Shell commands like 'npm install' or 'npx vite' go through the same bridge as exec calls. Stderr and stdout stream back as session/update notifications, which the UI converts into the gray rolling log you see in the chat.
Verify in a real browser
Playwright MCP on port 3001 is wired to a Chromium running with remote debugging on port 9222 (see buildMcpServersConfig() in src/core/e2b.ts line 153). The agent opens the URL, takes a snapshot of the DOM, and screenshots the rendered page. Same loopback, same cookies, same running app.
Iterate or commit
If something is wrong the agent issues another write_file. If the turn looks done, commitTurn() in src/core/vm.ts writes a git commit named for the turn. Every prompt becomes a SHA you can revert to. The 'vibe' you experienced was a sequence of named, replayable engineering steps.
The honest version of the disciplined-agents argument
The strongest reading of the existing "vibe vs agentic" pages is not really about architecture; it is about discipline. The fear is that the chat surface lets people skip code review, skip tests, skip planning, then ship something only the model has read. That fear is fair. It is also independent of whether tool calls are running.
The discipline lives in the rulebook the agent reads, not in whether the user sees the rulebook. mk0r's system prompt at src/core/e2b.ts:148 tells the agent it has a Vite + React + Tailwind project at /app and a Playwright MCP for browser testing, and points it at the project's CLAUDE.md files. The CLAUDE.md the agent loads inside the VM is generated by src/core/vm-claude-md.ts, which is 2,354 lines of named coding standards, environment guardrails, and verify-before-report rules. None of those lines are visible to the chatting user. All of them apply to the chatting user's output.
That is the trade. You, the user, get to vibe. The agent, on your behalf, has to engineer.
Where the framing actually matters
You should not pick "vibe coding" vs "agentic engineering" for a project. There is nothing to pick. What you should choose is how much of the engineering is exposed to you and how much of the rulebook the agent has to obey.
For a hobby app, a quick demo, a Friday-night side project: a hidden agent loop with a strong rulebook is the right product. You vibe. The agent quietly verifies in a browser, commits a SHA, and you can revert. mk0r is built for this case.
For a regulated payment flow, a kernel module, anything that has to be maintained by another human in two years: surface the agent loop, demand a planning step, demand named tests, do not accept a green light without reading the diff. That is also "agentic engineering," just with the dial turned the other way. It does not stop being an agent loop because it is more disciplined.
One-file tour, if you want to verify this
- src/app/api/chat/route.ts line 1: imports
@zed-industries/agent-client-protocol. The chat endpoint that handles every "vibe" prompt is an ACP bridge. - src/core/e2b.ts line 148: the default system prompt names the Vite project, the dev server, the Playwright MCP, and the CLAUDE.md files. There is no "just chat" mode that bypasses the agent stack.
- src/core/e2b.ts line 153,
buildMcpServersConfig(): the Playwright MCP server config, pointing at Chromium on--cdp-endpoint http://127.0.0.1:9222. - src/core/vm-claude-md.ts : 2,354 lines of agent rules, generated into a CLAUDE.md the model reads on every turn. The discipline part of agentic engineering, encoded.
- src/core/vm.ts exports
commitTurn,undoTurn,redoTurn,jumpToSha. Every "vibe" prompt is a SHA. You can revert.
Try the surface. The engine is already running.
Open mk0rWant the agent loop walked through live?
Book 20 minutes with the team. We'll start a session in front of you and open the ACP bridge logs, the file writes, and the Playwright screenshots side by side while you 'vibe.'
Frequently asked questions
What is the actual difference between vibe coding and agentic engineering?
Vibe coding is the consumer surface. You describe what you want in natural language and accept what comes back without reading the code. Agentic engineering is the execution layer underneath. An agent plans, edits files, runs commands, opens a browser, validates, then iterates. Karpathy's term names what it feels like to use the chat. The Anthropic, Cursor, and Zed crowd's term names what is actually executing while you chat. They are not opposed; they are two sides of the same loop. The arXiv paper at arxiv.org/abs/2505.19443 is the most-cited write-up that frames them as separate, but its diagrams show the same agent loop sitting under both.
If they are the same loop, why does every article say to choose one?
Because the term 'vibe coding' got loaded with a workflow (no code review, no tests, no design, ship the demo) that agentic engineering people want to disown. So the conversation got framed as 'undisciplined vibing' versus 'disciplined agents.' The discipline argument is real. The architectural argument is not. You cannot have one without the other in any tool that produces a working app, because the chat surface alone cannot run a build or open a browser. Something agentic has to be doing the work even when you call the experience 'vibing.'
Where in mk0r can I see this for myself?
Open src/app/api/chat/route.ts. The first import on line 1 is `import type { SessionNotification, PromptResponse } from '@zed-industries/agent-client-protocol'`. The whole chat endpoint is an Agent Client Protocol bridge. There is no separate 'vibe path' that bypasses it. Every prompt you type into the box on mk0r.com goes through an agent loop. The visible chat is the surface; the ACP bridge plus Playwright MCP plus the file system is the engine.
What does the agent actually have access to during a 'vibe' prompt on mk0r?
Inside the E2B sandbox, the agent has: a Vite + React + TypeScript + Tailwind v4 project at /app, a Playwright MCP server on port 3001 wired to a real Chromium with remote debugging on port 9222, the ACP bridge on port 3002 for file edits and shell commands, and a Vite dev server on port 5173 with HMR. The default system prompt at src/core/e2b.ts line 148 names all of those. Tool selection lives at line 153 in buildMcpServersConfig(). The agent is using the same surface area a human engineer would use: edit files, run commands, look at the running app in a browser.
So is mk0r vibe coding or agentic engineering?
Both, and that is the point of the page. The user-facing description on mk0r.com is the vibe form: 'describe what you want, watch it build.' What runs underneath is agentic, with named tool calls, browser screenshots, and a 2,354-line agent rulebook in src/core/vm-claude-md.ts. We do not ask the user to pick a side because we do not think there are two sides to pick.
Where does Karpathy's original 'vibe coding' tweet fit?
Karpathy's February 2025 framing was about a feel: forgetting that the code is even code, just talking and trusting the output. That is a phenomenology of using the chat. It does not say anything about whether tools are running underneath. In practice the early demos that fit Karpathy's description were already issuing tool calls (file writes, terminal runs) inside Cursor or Claude Code; the 'vibe' was just the part the user noticed. The two terms describe the same loop from inside (vibe) and outside (agentic).
When does the disciplined-agents argument actually matter?
When the artifact has to be maintained by a human or another agent later. Vibe coding fails when no one read the code, no test pinned the behavior, and the next change regresses something nobody knew was load bearing. Agentic engineering as a discipline (planning step, named tasks, browser verification, commit per turn, system prompt with rules) is a way to keep the chat surface intact while making the underlying loop produce maintainable output. mk0r leans into the discipline part: every turn writes a git commit (commitTurn() in src/core/vm.ts), the agent has 2,354 lines of guardrails to read (src/core/vm-claude-md.ts), and the Playwright MCP exists so the agent can verify in a real browser before reporting done.
What if I want pure vibe coding without anything agentic?
You will not find that in any tool that ships running software. A pure 'vibe' surface that did not edit files, did not run tests, and did not open a browser would just be a chat that prints code at you. To get an app you can open, you need the file write, the npm install, the dev server, and the rendered DOM. Those are tool calls. They are the agentic part. If a tool advertises 'no agents, just vibing,' it is doing them and not telling you.
Is this just an mk0r marketing argument?
It is an mk0r page so the framing is ours, but the architectural point is checkable in any tool that ships working code. Look at Cursor's tool calls. Look at Claude Code's MCP servers. Look at v0's deploy step. Every one of them has an agentic execution layer under whatever surface they show you. The disagreement is purely about which surface to put on top, and how many guardrails to put in between.