Sonith Manakkat"Vibe coding" is the name people give to building software by describing what you want to an AI and accepting what it writes, without reading the code closely. It is exciting, useful and often misunderstood. This article is balanced on purpose: what it is, where it works well, where it breaks, and a middle path I actually use. Everything factual is sourced at the end (last checked 2026-10-21). My own opinions are labelled.
Where the term comes from
The kitchen analogy
- Describe the dishYou say what you want in plain words
- The AI cooksIt writes and runs the code
- You tasteYou try the result in the app
- You ask for changesUntil it feels right
The spectrum
- Pure vibeAccept everything, never read it. A throwaway prototype or a toy for one evening
- Personal toolVibe plus a quick look. A tool only you use, with nothing sensitive in it
- Internal appAI-assisted engineering: tests and review. A small tool your team relies on
- ProductionAI-assisted engineering plus staged release. Real users, real data
- Safety-criticalHand-built, formally reviewed. Anything where harm is possible
What it is genuinely good at
- Fast first versionsA rough working prototype can appear quickly
- A lower barrier to startYou can begin without knowing a language
- Exploring ideasTry three designs before committing to one
- LearningReading what the AI wrote, and asking why, teaches a lot
The honest limits
No syntax barrier, so anyone can build anything
True for starting. Not for owning the result: you still need to understand behaviour, debugging, data, security and how to ship it
Whole applications in minutes
A prototype can be quick. Something safe, maintainable and ready for real users takes the same careful steps as before
If it runs, it works
Code can run and still be wrong in edge cases, insecure, or unmaintainable
- Hidden bugsLooks right on the happy path, fails on odd input
- Insecure defaultsMissing checks on who may see or change what
- Leaked secretsPasswords or keys pasted into code or chats
- Dependencies and licencesPackages added without anyone checking them
- CostLong sessions and large changes use more tokens than expected
- Tangled codeEach fix piles on, and later changes get harder
- You to The AI Describe what you want and give it a way to check the result.
- The AI to You (reply) It looks right and may miss an edge case.
- You to A check Tests, a script or a screenshot, not just a glance.
- A check to You (reply) The check shows a failure that reading would have missed.
- You to The AI Paste the failing output so the AI can work from it.
- The AI to You (reply) A revised version.
- You to A check The check passes, so now you can trust it a little more.
Takeaway. If you cannot verify it, do not ship it.
A safety checklist for vibe coding
- Back up and use gitA clean place to return to
- Take small stepsOne change at a time
- Ask for testsAnd run them
- Read the diffEven a quick skim catches surprises
- Never paste secretsKeep keys out of prompts and code
- A person reviews sign-in, payments and data codeAlways
- Release to a few people firstThen widen
The gate between prototype and production
A prototype can be
- Rough and fast
- Unreviewed
- Used by you or a friendly few
Production must be
- Tested, including odd inputs
- Read and reviewed by a person
- Free of secrets, with data handled on purpose
- Released in stages, with a way back
- Prototype to Tested Tests include odd inputs, and they are run.
- Tested to Reviewed A person reads the diff and checks secrets and data handling.
- Reviewed to Small group Release to a few people first.
- Small group to In production If it holds up, release to everyone.
- Tested to Problem An edge case breaks, so it is not ready.
- Small group to Problem The small group hits a bug or a surprise.
- Problem to Prototype Go back to prototype, fix it and test again.
Takeaway. A prototype becomes production only by passing checks, never by lasting a long time.
An example from my own work
- BriefOne job, a few acceptance checks
- AI draftsSmall steps
- Automated checksTests and random-input stress
- Real deviceTried by hand
- Review and releaseA person decides
Who it is for
- Non-developers prototypingGreat for showing an idea. Get help before real users arrive
- Developers speeding upFine when you keep reviewing and testing
- TeamsAgree rules first: tests, review, secrets, release
Should I vibe code this?
- Is it only for me, or throwaway?Then go ahead and enjoy it
- Will other people depend on it?Add tests, review and a staged release
- Does it touch money, health, privacy or safety?Involve experienced people and keep a human in charge
- Unsure?Start as a prototype, then decide
Expert viewVibe coding, agentic coding, and spec-driven development
These words overlap. In my own usage, vibe coding is about attitude: accept the output without reading it. Agentic coding is about tooling: an AI that can read files, run commands and iterate on its own, which Claude Code's documentation calls an agentic coding environment. Spec-driven work writes the requirements first. The best-practice guide describes a version of this: for larger features, have Claude interview you and write a spec to a file, then start a fresh session to implement it. You can be agentic and careful, or agentic and careless.
Expert viewContext, instructions and checks
Claude Code's documentation says most best practices come from one constraint: the context window fills quickly and performance degrades as it fills. Practical consequences it lists: keep a short CLAUDE.md of standing rules, clear context between unrelated tasks, and after two failed corrections start fresh with a better prompt. See CLAUDE.md and memory and Context explained. Write tests first or give the AI an executable check, so it can run it, read the result and iterate.
Expert viewReviewing large AI changes
Split big changes into small ones so each diff can be read. The documentation suggests a fresh session as reviewer, since it is not biased toward code it just wrote, and warns that a reviewer asked to find gaps will usually report some, so tell it to flag only issues that affect correctness or the stated requirements. Read the tests as well as the green result; an agent can make a failing test pass by weakening it. See Part B of the delivery playbook for gates and release.
Expert viewSecurity, cost and team policy
Scan for secrets before every commit, check dependencies you did not choose, validate inputs, and keep authorisation checks reviewed by a person. Watch token use on long sessions; see Tokens explained. Licence and legal questions depend on your country and your employer, so check your own rules rather than assuming. For teams I would write a short policy: what may be vibe coded, what needs review, and who signs off a release. Use Claude Code and AI agents for permissions and safe habits.
Speed is only an advantage when someone checks the destination.
Frequently asked questions
Is vibe coding bad?
No. It is a good fit for prototypes and personal tools. The risk comes from treating a prototype as production.
Do I still need to learn to code?
You can start without, but understanding behaviour, data and security is what lets you own the result.
Is AI-assisted engineering just slower vibe coding?
It is a different goal: keep much of the speed, and add the checks that make the result trustworthy.
Where do I begin safely?
Build something small for yourself, use git, ask for tests, and read the diff.