Vibe coding vs SE-focused generative coding

"Vibe coding bad, engineering good" is the wrong frame. Both are tools. Vibe coding optimizes for learning speed. SE-focused generative coding optimizes for code you can operate for years. The mistake isn't using either one. It's using the wrong one for the stakes, or not noticing when the stakes change.

What actually differs

Dimension	Vibe coding	SE-focused
Goal	Find out if an idea works	Ship something you'll maintain
Unit of work	"Build feature XYZ"	"Add logout button. Clear session, redirect /login"
Who holds the design	The model, implicitly	You, explicitly: plan, constraints, finish line
Reading the code	Optional. Judge by behavior	Required. Judge by the diff
Errors	Paste the stack trace, retry	"Fix TypeError in auth.ts:42", with a failing test first
Done means	It runs and looks right	Reviewed, tested, secure, observable
Cost curve	Cheap at first, compounding later	Higher upfront, flat later
Main risk	Code nobody understands reaches production	Process slows down work that didn't need it

The real difference is ownership of the design. In vibe coding the model makes hundreds of small architectural choices you never see. That's fine when the code dies next week. It's a liability when someone will be paged for it.

It's a spectrum, not a switch

Mode	Looks like	Right for
Pure vibe	Describe the outcome, accept what runs	Throwaway spikes, demos, learning a new API
Guided vibe	Vibe, but in a sandbox with a real data model and one test for the core path	Prototypes you'll show users, hackathons
Assisted	You design, the agent implements small tasks, and you read every diff	Most internal tools, early-stage product work
SE-focused	Plan, constraints, TDD, security review, owner approval	Production services, anything customer-facing
High-assurance	SE-focused plus domain expert review, threat model, staged rollout	Auth, payments, health data, infrastructure

Most work belongs in the middle. Teams get in trouble at the edges: pure vibe on something that becomes production, or high-assurance ceremony on a script that runs once.

Choosing the mode

Pick by the stakes, not by habit or by which approach feels more rigorous:

Question	Vibe is fine if...	Move toward SE-focused if...
How long will it live?	Days to weeks	Months or more
Who uses it?	You and your team	Customers or other teams
What data does it touch?	Fake or public	Real user, financial, or health data
Can you undo it?	Delete and redo	Migrations, public APIs, sent emails
Who gets paged?	Nobody	Someone on call
How many people change it?	One	Several, over time

One answer in the right-hand column is enough to move a step to the right on the spectrum.

Where each one fails

Vibe coding fails quietly:

Security holes nobody looked for (auth checks, injection, exposed keys)
An implicit architecture that fights the rest of the codebase
Duplicated logic and dependencies nobody chose
A prototype that "just needs a few fixes" and becomes production by accident

SE-focused coding fails loudly, but it fails too:

Design docs and reviews for code that should have been a 20-minute spike
Weeks of polish on an idea users would have rejected in a day
Engineers who can't prototype anymore because every change needs ceremony
Rigor that feels productive but answers the wrong question

The staff skill is noticing which failure you're heading toward.

Graduating a prototype

When a vibe-coded prototype proves the idea, don't patch it into production. Decide deliberately:

Keep the learning, question the code. The prototype answered "is this worth building?" It rarely answers "how should this be built?"
Write down what the prototype decided implicitly: data model, API shape, dependencies, auth
Rebuild or harden. Small and clean: harden it with tests, review, and a security pass. Large or tangled: rebuild from the plan, using the prototype as the spec
Name an owner before it goes live

"Read the prototype in prototypes/checkout/. List every implicit decision it makes:
data model, external calls, auth, error handling, dependencies. Mark which ones are
safe to keep and which need a real design."

Team policy

Name the sandboxes where vibe coding is encouraged: prototypes/, spike branches, demo environments with fake data
Block the accidental path: prototype code can't be deployed to production environments or merged to main without the hardening checklist
Don't ban it. Teams that forbid vibe coding just do it without saying so, and lose the chance to review it
Teach both directions: show juniors a vibe prompt next to a precise one on a real PR, and show seniors when their process is too heavy for the task