When to use vibe coding vs autocomplete: scaffold cost, not AI capability.

It is not 'which AI is smarter.' It is 'does the project exist yet.' Autocomplete (Copilot tab, Cursor tab, Supermaven) is a per-keystroke prediction inside a file that is open in your editor. It needs a project on disk, an editor pointed at it, and a cursor sitting at a position. Vibe coding (mk0r, Lovable, v0, Bolt) builds the whole app from a sentence, scaffold and all, with no editor in the loop. If you already have the project open, autocomplete is the cheaper move. If the project does not exist and you would have to npm init, install Tailwind, configure a router, then start typing, vibe coding skips that whole tax.

Autocomplete: you write 'function calculateStreak(' and the editor proposes the next 8 lines, you press tab, you read what came back, you fix the off-by-one. The unit of work is a token sequence. The unit of attention is a function. Vibe coding: you type 'a habit tracker app with a 7-day streak counter and a dark mode toggle' into a chat box, an agent writes the files, runs the build, opens the preview in a browser. The unit of work is a working app. The unit of attention is whether the rendered UI does the thing you described. The two never compete on the same line of code because they do not operate at the same level of the work.

Five honest cases. First, you are inside an established codebase and the next thing to write is a small, local extension (a new field, a similar function, a typed wrapper). Second, you have strong opinions about how the code should be shaped and you want the AI to type faster than you, not pick the architecture. Third, you are debugging, the project has to keep running between keystrokes, and a chat that rewrites the whole file is the wrong granularity. Fourth, you are working under tight cost or latency constraints (autocomplete tokens are far cheaper per useful suggestion than a full agent loop). Fifth, the work is so short that the cost of opening a chat surface, waiting for a plan, and reading the diff is more than the cost of typing the lines yourself.

Four cases that map well. First, you have an idea and no scaffold yet. The alternative to vibe coding is sitting at a blank shell typing npm create, choosing a router, picking Tailwind v3 or v4, copying eslint config, and only then asking AI for help with the actual feature. Vibe coding skips that. Second, the artifact is intentionally throwaway: a demo for a meeting tomorrow, a Friday-night side project, a thing you want to send a friend. Third, you are non-technical and there is no editor on your machine to autocomplete inside of in the first place. Fourth, you are iterating on UI and want to react to what you see rendered, not what reads well in the diff. UI is one of the things vibe coding handles surprisingly well because the verification is visual, not structural.

It is right but underspecified. The honest workflow is: vibe code the first 80 percent (the scaffold, the routes, the look-and-feel, the boring boilerplate that has no information content), then move to an editor with autocomplete for the part that has actual decisions in it (the auth flow, the payment math, the migration). The mistake is thinking vibe coding and autocomplete are interchangeable for any given task. They are not. They are the right tools at different moments of the same project. The decision tree is mostly about where you are in the project's life: pre-scaffold, post-scaffold, deep in business logic.

mk0r is the worked example of the 'no editor in the loop' end of the spectrum. It does not ship autocomplete. There is no IDE in the product. The only system prompt the model gets, at src/core/e2b.ts line 148, reads 'You are an expert app builder inside an E2B sandbox with a Vite + React + TypeScript + Tailwind CSS v4 project at /app.' The only input surface is a chat box. The only verification is the rendered preview in a phone-shaped panel. mk0r exists to answer the 'project does not exist yet, the alternative is fifteen minutes of setup' question. It deliberately does not try to be Cursor.

Yes, and most serious workflows do. The handoff point is when you stop reacting to the rendered preview and start caring about what is in the diff. Vibe coding is great until you want to grep, refactor across files, name a private helper, or argue with a linter rule. At that point you want a real editor with a cursor and tab completion. mk0r's roadmap takes this seriously: a published mk0r app is HTML/CSS/JS you can pull into any editor, and the 'open in your editor' affordance is more honest than pretending you should keep iterating in the chat forever.

Yes. Autocomplete is bad at scaffolding. Drop it into an empty directory and ask it to start a Vite + React + Tailwind app and it will offer a single line at a time, depending on what you are typing. It cannot write seven files in dependency order, run npm install, start a dev server, and verify the page rendered. That is an agent loop, which is what every vibe coding tool ships under the hood. The asymmetry is real: the vibe layer can do everything autocomplete does (slowly, expensively) but autocomplete cannot do what the vibe layer does at all.

Also yes. Vibe coding is bad at small surgical edits inside a large existing codebase. The agent has to load the project context, decide what to touch, write a plan, edit, verify. For changing a return type on one function in one file, that is enormous overhead. Autocomplete handles that in two keystrokes. Vibe coding is also bad at decisions where you have a strong opinion the model does not share. The chat surface is high-leverage for novel scaffolds and low-leverage when you want to drive the architecture yourself.

Half right. The 'serious vs prototype' axis is about output discipline (tests, code review, type safety), not about which tool you used to type the code. You can vibe code with discipline by reading every diff, asking the agent for tests, and rejecting turns that fail. You can autocomplete a prototype with no review at all. The framing collapses two different things. The cleaner version: autocomplete is for editing existing code, vibe coding is for creating new artifacts. Both can produce serious or sloppy output. The discipline is in how you treat the result, not in which surface produced it.