The vibe coding practice
Building software by describing intent in natural language and reacting to what comes back, rather than typing every line.
What the loop looks like
Vibe coding is development driven mostly by natural language: you describe a behaviour, a model writes the code, you run it, and you react to the result. The loop is short and the first draft is disposable until something proves it works.
> make the signup form reject disposable email domains and show an inline error
(edits validation.ts and SignupForm.tsx, adds a test)
> npm test
FAIL validation.test.ts: expected "blocked", received "ok"
> the check runs before the domain is lowercased - fix the order
(reorders the pipeline, re-runs, one test still failing)
> the error text needs an aria-live region so screen readers announce it
(wraps the message, all tests pass)- Describe behaviour rather than implementation, unless the implementation is the point.
- Run it immediately. A failing test or a screenshot is better feedback than another paragraph.
- Iterate in small steps so a wrong turn is cheap to undo.
- Keep version control in the loop - it is the only reliable undo you have.
Where the leverage is
| Situation | Fits the approach | Why |
|---|---|---|
| Greenfield prototype | Yes | Nothing to break, and speed dominates |
| Internal tool for a handful of people | Yes | Low blast radius plus fast feedback |
| Learning an unfamiliar library | Yes | A cheap way to discover the shape of an API |
| Payment or authentication logic | No | Correctness is not negotiable and defects are expensive |
| Untested legacy codebase | Carefully | You cannot tell a fix from a regression |
💡
The technique is not new - it is a faster feedback loop. What changed is that the cost of a first draft collapsed, so judgement and verification moved to the centre of the job.
FAQ
Do I still need to read the code?
If it ships, yes. Reading the diff is the moment you take responsibility for it, and skipping that step is how a prototype becomes an incident.
Is it only for prototypes?
No, but the bar rises with the stakes. Production code needs tests, review and an owner, whoever or whatever typed it.
Related
When it works and when it fails Keeping quality with tests and review
Last refreshed 2026-09-18.