Vibe coding
Vibe coding meansforgetting the code exists.I teach the opposite.
Andrej Karpathy coined the term on 2 February 2025 and he meant it literally: accept every diff, paste the errors back, never read what you shipped. That is a fast way to get a prototype and a slow way to get a product. What I teach runs under the same banner and inverts the method: you write the specification, the model executes it. This page is the entire argument, ungated.
- Term coined by Andrej Karpathy · 2 Feb 2025
- Six products shipped
- No production code written by me
- Islamabad, Pakistan
The term
What it actually means, and where I part company with it.
Andrej Karpathy posted the term on X on 2 February 2025. His words: "There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists." In the original description that is a method rather than a joke. You accept the diffs without reading them, you paste errors straight back into the model, and you let the codebase grow however it grows.
It is worth saying plainly that this works, for a certain job. A weekend prototype, a throwaway internal tool, a thing you are building only to find out whether it is worth building: the speed is real and the sloppiness costs you nothing, because you are going to delete it.
It stops working the moment somebody else depends on the output. What produces code you throw away is the absence of a specification, not the presence of AI. A model that cannot ask you a clarifying question will fill every gap in your brief with a guess, it will do it confidently, and you will not find out which guesses were wrong until the demo.
So what I teach is deliberately the opposite of the coined definition, and I would rather say that than quietly redefine somebody else's term. You write the brief first (constraints, edge cases, the file it goes in, what "done" means, what must not be touched) and the model executes it literally. Same tools. Same models. The whole difference sits upstream of the first prompt.
The distinction is the value, which is why the page leads with it. Take the term at its original meaning and you will conclude the tools are for engineers and go back to waiting on somebody else's queue. That is precisely what I concluded, for months.
Why the first attempt fails
Four failure modes. Most people hit at least three.
None of these is a model problem, which is why a better model does not fix them. They are one problem wearing four coats: the specification was incomplete, and nothing forced you to notice until the work was already done.
Failure 01
The search-engine reflex
You type one line, the way you would type a query, and expect something to fill the gap between the sentence and the software. It is not a search engine. It is closer to an extremely fast, completely literal contractor with no memory of yesterday and no ability to ask you a question. One line of instruction buys one line of thinking.
- What it looks like: output that runs, looks roughly right, and is wrong in a way that takes longer to unpick than to rewrite.
- What to do instead: write the brief you would hand a contractor who cannot phone you back.
Failure 02
No definition of done
"Add a login page" has no end state, so the work has no end. You get something. You ask for a change. You get something else. Three hours later you cannot tell whether you are closer than you were, because there is nothing to be closer to.
- What it looks like: a loop of small corrections that never converges, and a growing suspicion that the tool is the problem.
- What to do instead: write the acceptance conditions before the work starts, in terms somebody who was not in the conversation could check.
Failure 03
No fence around what must not be touched
Nobody says which files are off limits, so it refactors something that was working, renames a thing three other files depend on, and helpfully improves code you shipped last month. The damage is rarely in the file you were looking at, which is why it takes a day to find.
- What it looks like: the new feature works and two unrelated things quietly broke.
- What to do instead: name the target and name the boundary. Only this file. Do not change the schema. Do not touch auth.
Failure 04
No context carried between sessions
Every session starts from nothing. You re-explain the stack, the conventions, the decisions you already made and the reasons for them. Badly, because you are doing it from memory at speed. The model then makes a different choice from the one it made on Tuesday, and both are defensible.
- What it looks like: the same argument with the same tool twice a week, with drifting conventions as the residue.
- What to do instead: keep the standing context in a file the agent reads every time: stack, conventions, decisions, what is off limits. A CLAUDE.md, in practice.
The turn
The anatomy of a brief that works.
Five parts. In real use this is one to two screens of writing and about ten minutes, roughly what the four failure modes above cost you before lunch.
01
The target
Name the file, the route, the component. Where the change goes is a decision, and if you do not make it, something else will. This is also the sentence that stops a model quietly reorganising your project to suit one feature.
02
The constraints
The stack, the versions, the conventions, the patterns already in the codebase. "Match the file next to it" is a constraint. So is "no new dependencies". Constraints are how you get output that reads like the rest of your code rather than like a tutorial.
03
The edge cases
Empty state, error state, offline, slow network, the field somebody leaves blank, the submit button pressed twice. This is the part operators are already good at and do not realise transfers: it is the same list you have written for human teams a hundred times.
04
The definition of done
What must be true when this is finished, written so somebody outside the conversation could verify it. If you cannot write it, you are not ready to start, and that is useful to discover ten minutes before it becomes expensive rather than three hours after.
05
What must not be touched
The files, the schema, the public interfaces, the things already in production. The most valuable line in most briefs and the one nearly everybody omits, because until it has cost you an afternoon it does not occur to you that it needs saying.
This is not a template you fill in and stop thinking. It is a checklist for the thinking you were going to have to do anyway, moved to the point where doing it is cheap. The brief is the work. The code is the output of the work.
If you have ever run a team you have written this document before, for people, many times over. The only new thing is that the reader is literal, never tired, and will not quietly fill your gaps and resent you for it later.
Worked example
The same task, thin and properly specified.
Illustrative rather than a transcript: the point is the shape and the length, not the particular feature. Read the two side by side and it becomes obvious which one produces work you keep.
Before · the thin prompt
One line
Illustrative example
"Add a waitlist form to my site so people can sign up." That is the whole prompt. Everything below is left for the model to decide, and it will decide.
- Where it goes: unspecified.
- What counts as a valid address: unspecified.
- What happens on a duplicate: unspecified.
- Where the entry is stored: unspecified, which is how you end up with a form that saves into the browser and an owner who cannot read a single signup.
- What it must not change: unspecified.
After · the brief
Twelve lines
Illustrative example
Same feature, same model, same afternoon. The extra ten minutes is entirely upstream, and there is now nothing left worth guessing.
- Target: one new form component, rendered on the home page only.
- Constraints: match the markup and classes of the form next to it. No new dependencies. No client-side framework.
- Behaviour: one email field and an explicit consent checkbox, unticked by default. Submit writes to the existing signups table.
- Edge cases: invalid address, duplicate address, empty submit, double submit, network failure, JavaScript disabled.
- Done when: a valid address creates exactly one row, a duplicate returns the success state without a second row, every error state has visible text, and the whole form can be completed by keyboard alone.
- Do not touch: the database schema, the auth flow, the shared layout, anything under the legal pages.
The limits
What this does not replace.
The honest version, because the dishonest version is most of what this market currently sells.
Still yours, still required
- Technical judgement. You still have to know when an answer is wrong, and no brief gives you that. You can ship a real product without writing production code; I have done it six times. You cannot ship one with no technical judgement at all, and anyone selling you that is selling you something.
- Review. Accepting diffs unread is the original definition of the term, and it is also the fastest way to accumulate work nobody can maintain. Read the change. If you cannot read it yet, that is the next thing to learn, not the thing to skip.
- Security and privacy decisions. Auth, permissions, secrets, personal data, payments. A model will cheerfully write something that runs and leaks. These need a person who is accountable, and once real users are involved that person should be qualified.
- Engineers, on anything with scale, uptime or money attached. This makes a small team faster and a solo operator viable. It does not turn a one-person project into an infrastructure team, and pretending otherwise is how you get an outage nobody on the payroll can fix.
- Knowing what to build. Specification skill is not product sense. The tools make it cheap to build the wrong thing very quickly, which for most people is the larger risk of the two.
If that reads as a reason not to start, read it again: it is a list of where a human stays in the loop, not a list of prerequisites. Every product below was shipped by somebody who is still not technical, with a human sitting in exactly those five places.
Proof
Six products, none of them written by me.
The argument is worth nothing without this section, so it carries the least spin on the page. Stacks, statuses and links are on the work page.
- Products shipped
- 6
- Years running a company I could not build
- 4
- People trained on these tools
- 15+
- Lines of production code written by me
- 0
LittleOS
In development · open source
A zero-cost AI operating system: 50+ agents, workflow automation, content generation, voice control, installable as a PWA. A 45-table database, 20 design documents and 58 architectural decisions, all specified before any of it was built.
Liquid Finance
Live
Personal-finance PWA with AI receipt scanning, multi-currency budgets and full offline capability. The one I use every week, which is the only honest test of a finance app.
Safar
Live
E-visa eligibility checker for Pakistani, Bangladeshi and Nigerian passport holders travelling to the UAE, Turkey and Indonesia. Live requirements, cached for 48 hours so the answer is current without being expensive.
ThumbSnap AI
Live · private
Generative design SaaS for thumbnails. A job that took two hours of designer time now takes thirty seconds, the clearest example here of what changes when specification is the only bottleneck left.
Autonomous Article Writer
Running
A publishing pipeline shipping 15+ articles a day from 20+ sources at zero operational cost, with image generation and HTML formatting, into Notion and WordPress via GitHub Actions.
Triisum Eco-Ambassadors
Live
Sustainability web app: points for eco-actions, streaks, levels, team challenges and partner rewards. Built for a hackathon, still running.
The objections
Four things people say about this, answered.
Is this just prompt engineering with a new name?
I am not technical. Does this actually work for someone like me?
Will a better model make the brief unnecessary?
My engineers say vibe coding produces code nobody can maintain.
Next
The free course is this whole system, on a real project.
Claude Code for Founders is free and hosted here. It walks the specification system end to end: the brief structure above, the context file that survives between sessions, and the four failure modes named so you catch them before they cost you an afternoon. If it does not change how you work in the first hour, stop there and do not buy anything else.
P.S. The next time you get bad output, do not rewrite the prompt. Write the brief you would have handed a contractor who cannot ask you questions: the file, the constraints, the edge cases, what done means, what must not be touched. The difference is obvious inside an hour, and you do not have to buy anything to see it.