Vibe coding
Building by describing what you want and accepting what comes back without reading it closely. Genuinely fine for a prototype. The failure mode is shipping it, then discovering nobody — human or model — knows why the code does what it does.
The term came from the observation that you can now build something that works without reading it, which is true and useful. A weekend project, a throwaway script, a demo you will delete: read nothing, ship it, enjoy yourself.
It stops being free the moment someone else depends on the result. The cost is not bugs — bugs surface. The cost is that no explanation exists. Six weeks later a change breaks something and the only account of why the code was shaped that way is a chat session nobody kept.
The fix is not to stop using agents, which would be daft. It is to make the reasoning durable while the generating is cheap: write down what you asked for and why before the model builds it, and anchor the result to the lines that carry the decision. That is the whole argument for spec-driven development, and it is why the two ideas are usually discussed as opposites when they are really a sequence — vibe your way to understanding, then write it down before it matters.
- Spec-driven development
Building software where the specification is the durable artefact and the code is downstream of it. The document is precise enough that a competent engineer — or agent — could implement from it and land somewhere you would recognise.
- Context engineering
Deciding what an agent should be able to see. Increasingly the real skill: a model with the approved spec, the review notes and the relevant code will beat a better model working from a paragraph.
- Prompt-to-PR
The pattern where a request goes to an agent and comes back as a pull request. Fast, and it skips the two questions that matter: was this the right thing to build, and did anyone agree to it?