Vibe coding has a learning side effect. The condition is whether the tool lets you watch.

The wrong question, and the better one

The wrong question is whether vibe coding teaches you to code. That collapses two different categories into one and the answer comes back ambiguous because it depends on the tool, the user, and the session length. Useless.

The better question is mechanical: through what channel could a non-technical user, while not actively studying, absorb technical information? There are two candidates. The final artifact (a running app) is one channel; it is almost empty, because a running app does not declare its own file structure or framework. The agent's working process is the other channel; it is dense, because every Edit tool call broadcasts a file path, every Bash call broadcasts a command, every Write call broadcasts a code shape.

A tool either pipes that second channel to you or it does not. That single design choice decides whether the learning side effect exists for users of that tool.

What scrolls past you while mk0r builds

The block below is a compressed sample of the events a user actually sees in the mk0r chat panel during a single "build me a habit tracker" session. Each line maps to a real ACP event type the chat route forwards from the agent running inside the VM. No content here is invented: these are the event shapes emitted by src/app/api/chat/route.ts (search for agent_message_chunk and tool_use).

Read that block again, slowly. A non-technical user did nothing to study and yet now has a passing acquaintance with: where React components live (src/components/), what an env file is, that types declare the shape of data, that a dev server runs on a localhost port, that React complains about missing keys in lists, and that fixing a console warning is a normal turn in the build loop. None of that was taught. All of it was overheard.

Tools that do not stream this channel rob the user of the same ambient learning. You can build a habit tracker on a platform that shows only the rendered preview and come out of the session knowing nothing about file structure or env vars because nothing in the preview talked about them.

The half of Linus that is usually skipped

The Torvalds quote is everywhere, but the part that gets repeated is "horrible for maintenance." The first half ("a fine tool to learn things") is usually written off as a polite concession. It is not. It is a specific technical claim. Linus is saying that if you are reading what the agent does and reasoning about it, you are learning. The reading is the channel. Hiding the diff breaks the channel.

This means "does vibe coding teach you to code" has the same answer as "does this tool render the diff in front of me." If the answer to the second question is no, the answer to the first is also no.

The rulebook is a second curriculum

The agent does not freelance. Before your first prompt it loads a 2,438-line file at src/core/vm-claude-md.ts in the mk0r repo (github.com/m13v/appmaker). Six skills (frontend-design, copywriting, backend-services, algorithmic-art, website-builder, seo-page) and two CLAUDE.md files (one global, one per project) get copied into the sandbox.

Every rule the agent obeys in your session is a small lesson visible by inference. Extract components at ~100 lines, trim every env value before writing, prefer const, do not write outside /app, errors handled at boundaries not internally. When the agent does these things and the result works, the rule attaches itself to a memory of a thing you built. That is how style guides actually stick: with a concrete reference, not with a list.

What the side effect does not give you

Two honest limits. The first is depth. Watching the agent create a useState hook is not the same as being able to reason about why state is wrong in a different component three days later. Exposure trains pattern recognition; it does not train problem solving. You will be able to point at a file and say what kind of code lives in it long before you can write that code unaided.

The second is the adversarial layer. The rulebook handles named foot-guns (Inter font, purple gradients, trailing newlines in env vars). It does not handle the unnamed ones, and a real product has unnamed ones: production-grade auth that survives a competent attacker, multi-user real-time state with conflict resolution, payments compliance, native iOS review. A vibe coding session, even a careful one, gets you a convincing first draft of those and then leaves you to do the engineering. The side effect will not teach you what the engineering even looks like; it stops at the layer the rulebook reaches.

How to get more out of the side effect (if you want to)

If the goal is just to ship a weekend prototype, you do not need to do anything; the stream will scroll past whether you study it or not. If the goal is to convert exposure into actual technical literacy, three small habits stretch the yield:

1. When the agent says "Edit src/App.tsx," actually click on that file in a separate tab and read it after the edit lands. It is the cheapest review pass that exists.
2. When a tool call surfaces a word you do not know (HMR, env var, fetch, Vite, JSX), pause and ask the agent for a one-paragraph explanation in the same session. Cost: 10 seconds. Benefit: the term sticks to a moment you remember.
3. Read the rulebook once. Not all 2,438 lines; just open src/core/vm-claude-md.ts on GitHub and skim the section headers. You will recognise patterns you already saw the agent obey.

The honest summary

Vibe coding has a learning side effect, and it is the channel most of the debate misses. The side effect is bounded: it tops out at the layer a rulebook can describe, and it does not turn an exposure into a skill on its own. But for someone who has never written code, an hour spent watching an agent build their own idea moves the needle further than an hour spent reading a tutorial that was not about their idea. Pick a tool that streams the diff. Watch what scrolls past.