Linus Torvalds on vibe coding, and the guardrails that make it actually safe
Linus says vibe coding is fine for learning and a horrible idea for maintenance. That is the part every article about him covers. The part nobody covers: what a vibe coding stack looks like when those maintenance concerns are translated into concrete, readable rules that the agent loads before your first prompt. On mk0r that file is 2,354 lines long, sits at src/core/vm-claude-md.ts, and you can read it yourself.
What Linus actually said
In interviews through late 2025 and early 2026 Linus Torvalds landed on a consistent position: vibe coding is fine as a way for people who would not otherwise get a computer to do something to get a computer to do something. He called it a "great way" into computing. In the same breath he called it a "horrible, horrible idea from a maintenance standpoint" and said you will not see it in the Linux kernel. He framed AI as another tool, comparable to the compiler, which freed humans from writing assembly and increased productivity without making programmers obsolete.
The coverage stops there. Every article paraphrases the same three ideas and reaches the same unexamined conclusion: be careful. None of them walk through what a vibe coding stack looks like when someone actually sat down and wrote rules that honor his concerns.
The mapping nobody else writes down
Linus's concerns break down into a small number of specific fears. Each one has a matching rule in the mk0r agent rulebook. The table below is the point of this page.
| Feature | What Linus warns about | What the rulebook says |
|---|---|---|
| Touching infrastructure the author did not review | AI rewrites load-bearing code without understanding what it protects | Lines 314-317: do not modify /opt/*.js, /opt/startup.sh, Chromium, Xvfb, x11vnc, the proxy, or HMR config |
| No proof the change works | Agent ships code because it compiled, not because it ran | Lines 278-283: navigate to localhost:5173, snapshot DOM, check console, do not report done until the browser shows the expected result |
| Silent regressions in configuration | Secret or env gets quietly corrupted; failures look like 'the API is flaky' | Lines 292-310: trim trailing \n on every env value; named failure mode with a fix, not a vibe |
| Scope creep into other people's code | Agent starts 'fixing' code it was not asked to fix | Line 317: do not write files outside /app unless the user explicitly asks |
| No artifact to review | Maintenance is a 'black box' the next human cannot read | Rulebook is 2,354 lines in a file anyone can read; 15 named exports, including 6 skills |
| Forgetting prior decisions | Next turn repeats a mistake because context is lost | Built-in memory system with typed entries (user, project, feedback, reference); agent must write on correction and read at turn start |
The four "do not" rules, verbatim
This is the part of the rulebook that does the most work. It is seven lines of markdown, buried at line 312 of a 2,354-line file. The agent reads it on boot, before you send your first message. You can open the repo and check.
Why each rule exists
A "do not" rule without a reason gets ignored the first time it inconveniences the agent. Here is what each rule is protecting and what breaks when it is missing.
No /opt edits
/opt holds startup scripts that bring up Xvfb, x11vnc, the HMR proxy, and Chromium. One bad edit bricks the VM for that session and every future session that reuses the snapshot.
No Chromium kills
The browser is how the agent verifies its own work. Killing it to 'clear state' leaves the agent blind and unable to satisfy rule five in the Browser Testing block: do not report done until the browser shows the result.
No HMR tweaks
Vite HMR runs over wss at clientPort 443 because the sandbox sits behind a proxy. Change it and the preview iframe silently disconnects. The user sees 'nothing is happening' and the agent sees 'everything is fine.'
No writes outside /app
The agent owns /app. Everything else belongs to the VM. This is the fast-surface, slow-surface split, scaled down. The rule makes blast radius small enough that a bad session can be thrown away without breaking the machine.
The "verify in the browser" rule
The kernel community has a phrase for this: "code works, not code compiles." The mk0r rulebook applies the same standard at web app scale. After any UI change the agent has to open the preview, snapshot the DOM, read the console, and confirm the user sees the expected result. If the browser shows a blank page, the work is not done, no matter what the type checker says.
The regression that taught us about env vars
One of the most painful kinds of regression Linus warns about is the silent one. The code passes review, the tests pass, and production breaks in a way no log can explain. The rulebook names one specific version of this failure, with an example, because it has been paid for at least once in production.
How the rulebook reaches the agent before your first prompt
What "fine for learning" actually looks like
The other half of Linus's statement is that vibe coding is a great way to learn. The rulebook is structured to make that real, not marketing. A beginner opens mk0r, types a prompt, and the agent responds under a contract that a senior engineer wrote. The output will not use Inter, will not paint purple gradients on white, will not leave Lorem Ipsum, will not fabricate statistics, and will verify itself in the browser before claiming it is done. The beginner inherits those defaults without having to know they exist.
Defaults the beginner inherits for free
- Never default to Inter, Roboto, Arial, or system fonts
- No exclamation points. Ever
- Remove filler words: very, really, just, actually, basically, simply
- Three colors maximum: black, white, and one dominant accent
- Honest over sensational: never fabricate statistics or testimonials
- Check /app/.env before asking the user for credentials
- Trim trailing \n from every env value before using it
- Do not report done until the browser shows the expected result
What the rulebook is, in numbers
Every number below comes from src/core/vm-claude-md.ts in the public repo. You can count them yourself.
How the contract runs, turn by turn
The rulebook is not static. Each turn activates a specific subset of it. Here is how a single prompt like "build a waitlist site with email capture" flows through the file.
One prompt, one pass through the contract
You land on mk0r.com with no account
The landing page fires POST /api/vm/prewarm on mount. A booted E2B sandbox is already warm by the time you finish reading the hero.
The agent reads the rulebook before it reads you
globalClaudeMd is written to /root/.claude/CLAUDE.md. projectClaudeMd is written to /app/CLAUDE.md. Six skill files land under /root/.claude/skills/. All of it is in context before your first token arrives.
The guardrails fence the VM
Lines 312-317 tell the agent what it cannot modify. /opt is off limits. Chromium is off limits. HMR config is off limits. Anything outside /app needs your permission.
The backend-services skill wires the waitlist
The agent checks /app/.env, finds DATABASE_URL, RESEND_API_KEY, and RESEND_AUDIENCE_ID already provisioned, and writes code that uses them on turn one. No signup forms for Resend, no 'go paste a key here.'
The agent verifies in the browser
Once the waitlist is wired, the agent opens localhost:5173 via Playwright, snapshots the DOM, reads the console, and confirms the form renders and submits. Only then does it report completion.
Memory persists the corrections
If you say 'make the button green, not teal,' the agent writes a feedback memory immediately. The next turn reads it. The mistake does not repeat.
What this is not
Nothing on this page is a claim that vibe coding is ready to ship kernel code. Linus is right that it is not. The point is narrower: between "AI writes whatever it wants in your repo" and "AI writes nothing, ever, in any production system," there is a middle ground, and that middle ground lives or dies on the quality of the rulebook the agent runs under. mk0r's bet is that this file is worth more than any individual model upgrade. A better model with a worse contract still leaks outside /app, still reports done without opening the browser, still ships env values with a trailing newline.
A worse model with a better contract does not.
Want to read the rulebook with us?
Book 20 minutes and we will open src/core/vm-claude-md.ts together, walk the guardrails, and show what each rule changes in the output.
Book a call →Frequently asked questions
What does Linus Torvalds actually say about vibe coding?
He has said he is 'fairly positive' about vibe coding as a way for beginners to get computers to do something they could not otherwise, but that it is 'a horrible, horrible idea from a maintenance standpoint' for production code like the Linux kernel. He has also said AI is just another tool, like a compiler, and it does not make programmers obsolete. The quotes come from interviews and panels covered in late 2025 and early 2026.
Why is the maintenance angle the real concern?
Code you do not understand is code you cannot fix. A vibe coded hobby project that breaks can be deleted. A vibe coded change inside a 30 million line kernel, or a payments flow, or a regulated system, leaves behind behavior no human reviewed. If a later commit regresses it, no one knows the old behavior was load bearing. Linus's position is that vibe coding does not yet leave the right artifacts to keep code maintainable at that scale.
How does mk0r translate Linus's concerns into the product?
The agent ships with a rulebook at src/core/vm-claude-md.ts that is 2,354 lines long. It is written into /root/.claude/CLAUDE.md and /app/CLAUDE.md inside the sandbox before the agent reads the user's first prompt. Four 'do not' rules at lines 312 to 317 lock down the parts of the VM the agent is not allowed to modify: /opt/*.js, /opt/startup.sh, Chromium, Xvfb, x11vnc, the proxy, Vite's HMR config, and anything outside /app unless the user explicitly asks.
What verification does the agent do before reporting 'done'?
Lines 273 to 283 require the agent to open http://localhost:5173 in the VM's Chromium, take a Playwright snapshot of the DOM, check browser_console_messages for runtime errors, and refuse to report completion until the browser actually shows the expected result. 'It compiled' is not an acceptable finish state. The rulebook forces the agent to behave like the kernel's 'show me the working output' standard, scaled down to one app.
What about silent regressions in environment variables?
Lines 292 to 310 name a specific failure mode: AI models often leave a trailing newline on secrets and API keys. That newline causes silent 401s, failed webhook signatures, and broken integrations that look like 'the API is down.' The rulebook instructs the agent to trim every value before writing to .env and before using it in API calls. A single trailing newline shipped to a Stripe webhook secret is how production payments go silent for 337 events, and the rule exists because that has happened.
Does the agent get to touch the whole VM, the way Linus fears?
No. The VM is partitioned. The agent owns /app. It does not own /opt (infrastructure), it does not own the browser processes, it does not own the HMR proxy, and it cannot write files outside /app without explicit user permission. This is the small version of the Linux kernel principle of keeping the fast-moving surface separated from the slow-moving surface. The fast surface is your code. The slow surface is the VM.
Is the rulebook public?
Yes. The file lives at src/core/vm-claude-md.ts in the mk0r repo. You can read the globalClaudeMd export (identity, memory, guardrails), the projectClaudeMd export (Vite + Tailwind + pre-provisioned services), and the six named skill exports (frontend-design, copywriting, algorithmic-art, backend-services, website-builder, seo-page). Nothing in the agent's behavior is hidden behind a 'secret sauce' paywall.
Is vibe coding on mk0r suitable for the kinds of codebases Linus works on?
No, and mk0r does not claim it is. Linus is talking about core operating system code that has to remain stable across decades. mk0r is a sandbox for describing and building web apps. The translation of his principles is narrower: keep the VM infrastructure off limits, verify in the browser before reporting, and never regress env vars silently. Inside those constraints vibe coding can ship a real waitlist site with a real Postgres database on turn one. It will not ship a scheduler for the Linux kernel.
What is the shortest way to see the difference?
Open mk0r.com with no account, describe the app you want, watch the preview in the sandbox. Every output was produced by an agent that had already read the rulebook. The 'do not' rules are doing work you cannot see. You can read the exact file at src/core/vm-claude-md.ts to verify which rules applied.
Open a session. No account. The agent loading your first prompt has already read 0 lines of rules.
Start building on mk0r