Vibe coding
Why it matters
It collapses the cost of building an internal tool, a prototype or a small product to roughly the cost of thinking clearly about what is needed. A job that once waited weeks for a contractor can exist by the end of the afternoon.
The catch is that an app nobody understands becomes a liability the moment it breaks. The tool is best treated like a fast junior colleague: capable, quick and eager, but in need of a clear brief, a review and tests. Trusting it blindly is how people end up with software that looks finished and quietly loses data.
How to apply it
- Write a short spec first, even three sentences, so there is something to check the result against.
- Describe the data and the states, not only how it should look. "An invoice can be draft, sent or paid" is more useful than "make it clean".
- Read the changes, at least the parts that handle money, logins or anything sent to a customer.
- Ask a second pass to look for flaws and risks, not to reassure.
- Keep a real database and proper sign-in underneath, not something disposable.
- Keep the project in version control so any bad change can be undone.
What it is
Vibe coding is a way of making software where the human states the goal and an AI coding tool writes the code. The term was popularised by the AI researcher Andrej Karpathy in early 2025, describing a style where you mostly talk to the tool and accept what it produces. A person who has never written code can now describe "a dashboard of open deals by stage" and get a working version the same day.
Common mistakes
- Accepting code nobody has read. An app that works on the demo data can still lose records or expose them to the wrong person.
- Starting without a brief. With no spec, there is nothing to check the result against and every screen looks fine.
- Building on a disposable setup. A prototype with no proper database or sign-in gets used for real work and then cannot be fixed.
- Letting it grow unreviewed. Each quick addition adds code no one understands, until a small change breaks three things.
- Putting real customer data in too early. Test with made-up data until the access rules have been checked.
