Vibe coding 是原型方法，不是交付流程

“Vibe coding” is useful when it describes low-cost exploration through natural language. It becomes misleading when a fast visible draft is treated as evidence that a feature is ready to own.

Natural-language development can help with scaffolding, unfamiliar APIs, UI variants, test ideas, and the first workable shape of a solution. The draft still has to survive users, bad data, cost constraints, security review, and maintenance.

The gap between “it runs” and “we can own it” has not disappeared. Agents just made the first half faster.

The demo is not the discipline

Most vibe-coding demos optimize for visible progress. A prompt becomes a screen. A screen becomes a feature. A feature gets tweaked in natural language. That is genuinely fun, and fun matters more than jaded engineers admit.

But production software is mostly invisible constraints: auth states, cache invalidation, failed payments, idempotency, accessibility, observability, rollback, dependency drift, partial migrations, and slow tests that catch the one thing a demo never touches.

The agent can help with all of that, but only if the workflow asks for it. Otherwise, it will optimize for the artifact you reward: the visible change.

Those two paths rarely get equal attention:

The visible path — short, and every step feels like progress:

Request → Fast draft → Visible behavior → Ship

The hidden path — the constraints that decide whether you can actually own it:

• Auth states and permission edges
• Cache invalidation
• Failed payments and idempotency
• Accessibility and observability
• Dependency drift and partial migrations
• Rollback plans, logs, types, and tests

The contrast is the point. The visible path reaches “ship” in four happy steps, while the hidden path never really ends and stays invisible until something breaks in front of a user. Nothing forces that second path to matter unless the workflow does.

When does vibe coding work well?

The strongest use is reducing the cost of trying ideas. Ask for three constrained layout variants, a minimal SDK example to verify against primary docs, or candidate tests for repetitive branches. Treat the output as options to review, not a decision already made.

An agent can also propose names or boundaries when a team is stuck, provided everyone treats the output as a menu rather than a decision.

That is exploration with a receipt, and it keeps review honest.

The key is to frame the work as provisional. “Create a draft implementation” is a different instruction from “finish this feature.” Drafts invite review. Finished-sounding requests invite trust.

For example:

Draft a small implementation of workspace invite expiration.
Start by reading how invites already work, and leave the database schema alone.
Cover the cases that actually bite us: expired, accepted, and missing invites.
Stop at the first working version and tell me the tradeoffs you made along the way.

That prompt still feels natural, but it contains engineering boundaries. The agent knows the shape of useful work. The reviewer knows what to expect.

When does vibe coding get expensive?

Vibe coding gets expensive when it generates surface area faster than the team can understand it. Every helper, dependency, abstraction, and test fixture becomes something the team owns. If the agent writes code in a style nobody recognizes, the merge may be quick and the maintenance bill may arrive later.

A visible smell is overproduction: a flexible configuration system before there are two configurations, a generic abstraction around one call site, or a new dependency for a capability the repository already has. None of those choices is automatically wrong, but each expands the surface the team must own.

Counter that with a review checklist simple enough to repeat:

## Agent-generated diff review

- Does the change follow nearby patterns?
- Did it add a dependency or abstraction? Why?
- Are public contracts unchanged unless requested?
- Are failure states tested?
- Can the summary explain the behavior without hand-waving?

This is not anti-agent. It is pro-ownership.

Traditional rigor still matters

The phrase “traditional engineering rigor” can sound like gatekeeping, so let me be specific. I mean the practices that turn a patch into a reliable change: small diffs, clear contracts, tests that prove the important behavior, type boundaries, observability, code review, and rollback plans.

Agents can accelerate those practices. They can write the first draft of tests. They can inspect a diff for missing edge cases. They can compare an implementation against the design doc that describes it. They can generate a migration checklist. But the team has to ask for rigor as an output.

One test-first pattern is:

Before editing implementation code:
1. Inspect the existing tests for this feature.
2. Propose the smallest set of failing tests for the requested behavior.
3. Add only those tests.
4. Run them and confirm they fail for the expected reason.
5. Implement until they pass.

That sequence slows the agent down in the right place. It reduces the chance of a broad, self-justifying patch. It also creates a reviewable story: this behavior was missing, these tests expressed it, this implementation made them pass.

The human role changes, not vanishes

The lazy critique is that vibe coding means developers stop thinking. The lazy hype is that developers can stop thinking. Both miss the point. The thinking moves.

Instead of spending all our attention on syntax and boilerplate, we spend more of it on problem framing, constraints, decomposition, review, and system design. That is not less engineering. It is engineering with a different bottleneck.

The danger is that natural language feels complete when it is only expressive. A feature can be described clearly while omitting the one invariant that matters. The agent will not know the omission is important unless the repo map, tests, docs, or task make it visible.

A sane vibe-coding workflow

A reviewable version looks like this:

1. Explore with natural language and keep the output disposable.
2. Convert the promising path into a bounded task.
3. Ask the agent to inspect existing patterns before editing.
4. Force tests, types, or runtime checks into the loop.
5. Review the diff as if a fast junior engineer wrote it.
6. Keep what fits the codebase and throw away the rest.

That last step matters. Deleting agent-generated code is not a failure. It is part of the workflow. The agent lowered the cost of exploration, and the engineer still decides what deserves to live in the system.

What they do not tell you

The honest version is more interesting than the hype version. Vibe coding can make you faster. It can also make you sloppier at a speed that feels productive. The difference is not the model. The difference is the workflow around it.

Natural language is a powerful interface. It is not a substitute for architecture, tests, domain judgment, or taste. When those things are present, agents feel like leverage. When they are absent, agents feel like a very persuasive source of future cleanup work.

So yes, use the vibe. Enjoy the speed. Just make it pass through the same gates as every other change you plan to own.