Vibe coding, and the first week that does not end in a mess
Vibe coding is building by describing what you want and accepting what the model writes without reading all of it. It works when the cost of being wrong is low and the feedback is immediate — prototypes, scripts, throwaway tools. It stops working when the code outlives the session, because the thing you skipped is the thing that later has to be understood.
Vibe coding is building by describing what you want and accepting what the model writes without reading all of it. The term is Andrej Karpathy’s, and the distinguishing feature is not that AI wrote the code — that is now ordinary — but that nobody reviewed it line by line.
That is a trade, not a mistake. Whether it is a good trade depends entirely on one question: how long does this code have to live?
Where does vibe coding actually work?
Prototypes you intend to delete. The cost of being wrong is that you throw it away, which you were going to do anyway.
Scripts and one-off tools. A thing that reshapes a CSV, seeds a database, scrapes a page once. If it produces the right output you are done; nobody is going to maintain it.
Learning the shape of something unfamiliar. Getting a working example of a library you have never used is faster this way than reading the docs first, and you can read the docs after with a concrete thing in front of you.
Anything where the feedback is immediate and total. If it works, it works, and you find out in ten seconds.
The common thread is that being wrong is cheap and obvious. That is the condition. Not the size of the project, not the language, not whether it is “real” — just whether a mistake shows up immediately and costs little.
When does it stop working?
The moment the code outlives the session that produced it.
This is not a moral point. It is arithmetic: you bought speed by skipping understanding, and the bill arrives when somebody has to change code that nobody understood when it was written. If nobody ever changes it, the bill never arrives and you got the speed for free. That is a real outcome and it happens a lot.
What makes it go wrong is not knowing which case you are in. Most bad experiences start as a prototype that quietly became load-bearing while nobody was deciding anything.
How do I tell which case I am in?
Three questions, and they are about the situation rather than the code:
| Ask | Vibe coding is fine when | It stops being fine when |
|---|---|---|
| How fast do I find out I am wrong? | Seconds. You run it and see | Weeks, via a customer |
| What does being wrong cost? | You delete it and start again | Money, data, or somebody’s trust |
| Who else depends on this? | Nobody | Anyone who is not you |
All three pointing the same way is the case this was made for. All three pointing the other way and you are not vibe coding, you are gambling with extra steps.
The useful part is that this is decided per piece of work, not per project. The same afternoon can hold a throwaway script you never read and a permissions change you read twice. Treating a whole repository as one setting is what produces both of the common mistakes — reading everything on a prototype, and reading nothing on the part that bites.
What should I never vibe code?
A short list, and the reason is the same for every item on it:
- Authentication and permissions. Wrong here does not throw an error. It quietly lets the wrong person in, and you find out from somebody else.
- Money. Prices, charges, refunds, currency. Off-by-one in a loop is a bug; off-by-one in cents is a chargeback and an email you do not want to write.
- Anything that deletes. Cascading deletes especially. The test for this category is whether an undo exists.
- Database migrations. They run once, against real data, and the failure is discovered after the data is already gone.
- Anything handling other people’s personal data. Being wrong here has a regulator attached.
Notice what is not the criterion: difficulty. Some of these are easy code. The property they share is that being wrong does not announce itself — which is exactly the assumption vibe coding runs on.
This is not “write it yourself”. It is “read this one”. Have the model write it, then actually read what it wrote, and ask it to explain the parts you cannot follow. The reading is the whole cost, and on these five it is worth paying.
The first week
Keep sessions short, and end each one on something that works. This is the single highest-leverage habit and it is not about the AI at all. A long session accumulates decisions nobody wrote down, and when something is finally wrong there is no point to go back to. Short sessions with a working commit at the end give you somewhere to return to.
Read the expensive parts. Not all of it — that would defeat the purpose. Read anything touching money, authentication, data deletion, or code another person also works on. Skim the rest. The skill being built here is triage, and it is a real skill: knowing where being wrong is expensive is most of what senior engineers know.
Say what it must not do. Most people describe what they want and stop. The instruction that saves the most time is the one that rules things out — do not touch the auth module, do not add dependencies, do not change the database schema. Models are agreeable and will happily do a helpful thing you did not want.
Run it before you believe it. Generated code that looks right and does not run is the most common single failure, and the cheapest to catch.
Notice when the prototype stopped being a prototype. There is usually one specific moment: somebody else opens it, or it goes in front of a user, or you deploy it. That is the moment the trade changes, and the honest response is to go back and read it properly.
What a good session looks like, start to finish
Concretely, because “keep sessions short” is advice you can agree with and still not act on:
- Start from a commit. Not a tidy repository — a committed one. This is the save point, and it takes ten seconds.
- Say the goal and the boundary in the same message. What you want, and what is off limits. The second half is the one people skip.
- Let it work without interrupting. Steering mid-flight produces a change that is half one plan and half another, which is harder to read than either.
- Read the diff, not the codebase. How many files, which files, anything deleted you did not ask to delete.
- Run it. Before you believe any of it.
- Commit, or throw the whole session away. Both are fine outcomes. The one that is not fine is carrying a half-working state into the next session.
Roughly an hour is where this lands for most people, and the number matters less than the shape: the session is the unit you can throw away. Once a session has been going long enough that discarding it is unthinkable, you have lost the property that made the whole approach safe — and that happens gradually, which is why it is worth watching for.
The questions people actually ask
“Am I still a real developer if I do this?”
The question underneath is whether you are building a skill or avoiding one. You are building one — triage, specification, knowing where risk lives — and it is not the same skill as writing the syntax yourself. Both are real. Neither is complete on its own.
“How do I stop it inventing libraries that do not exist?”
Run the code. Hallucinated imports fail immediately, which makes this the least dangerous class of error. Worry more about the ones that run.
“It rewrote something I did not ask it to touch.”
Very common, and the ordinary fix is to say what is off limits before you start. On a repository other people work on, this stops being a nuisance and becomes the actual problem — which is its own post.
“Should I commit code I have not read?”
On something disposable, yes. On something shared, you are handing your colleagues a diff you cannot answer questions about, and that is a social problem before it is a technical one.
“Is this how professional teams work now?”
Partly, and honestly the answer is still moving. What is clearly true is that the constraint has shifted from how fast can this be written to how confidently can it be changed later, and the teams doing well are the ones treating that as the thing to design around.
Where this is going, and what we do about it
Everything above works for one person on their own machine. The interesting failures start when the repository is shared — when generated code is locally reasonable and globally wrong because the model could not see a convention that lives in somebody’s head.
That is the problem CommitCycle works on: each agent gets a grant bound to one task and one branch that expires on its own, the paths that would hurt carry an owner, and every task closes with a record of what it declared versus what it touched.
Being straight about where that is: the plugin installs the enforcement today, and the commitcycle package on npm installs the CLI — the process without the wall. The hosted board is invitation-only while this is small. And none of it is what you need in your first week of vibe coding — in your first week you need short sessions and a habit of reading the expensive parts.
The week after, when you have decided the thing is going to exist beyond Friday, the question changes from habits to setup: what to have in place before the first prompt, and why each piece is there.