When Not to Vibe Code
The situations where typing it yourself is faster, safer, or the only responsible option.
A course that only argues for its subject is marketing. Here is the honest accounting: the situations where reaching for an AI makes things slower, worse, or irresponsible — and how to recognise them before you are already in one.
When the point is that you learn it
The clearest case. If you are working through an exercise to understand recursion, having it written for you removes the entire value of the exercise. You will recognise the solution, feel that you understood it, and be unable to reproduce it a week later.
Recognition is not the same as comprehension, and AI output produces recognition very efficiently. When learning is the goal, struggle is not an obstacle to it — it is the mechanism.
When you cannot verify the answer
This is the deepest one. AI output is only as safe as your ability to tell whether it is right. In a domain you know, a wrong answer looks wrong. In a domain you do not, a wrong answer looks like an answer.
- 1Cryptography
Code that is subtly wrong runs perfectly and protects nothing.
- 2Concurrency
A race condition passes every test you write and fails in production at 3am.
- 3Numerical and financial code
Rounding and precision errors are invisible until they are audited.
- 4Anything safety-related
Medical, legal, structural. The cost of being confidently wrong is not measured in developer time.
The rule: if you could not tell a correct answer from a plausible one, you are not reviewing — you are hoping.
When getting it wrong is expensive to undo
Some mistakes cost you a debugging session. A smaller category costs data, money, or someone else's afternoon, and which category you are in has nothing to do with how confident the model sounded while producing it. Running a migration against a real database, deleting a table, emailing everyone on a list, deploying straight to production with no rollback path — these carry consequences no code review catches after the fact, because by the time you are reviewing it, it already ran.
The signal to watch for is not complexity, it is reversibility. A wrong shade of blue costs one more prompt. A wrong DELETE statement against production costs however long recovery takes — assuming recovery is possible at all.
- 1Run it somewhere fake first
A staging database, a dry-run flag, a --no-execute mode. Insist on one before anything touches production data.
- 2Read the exact statement, not a description of it
“This removes inactive users” is a summary. The WHERE clause is the truth.
- 3Keep a human in the loop for anything with no undo
A confirmation step costs ten seconds and exists specifically for this category.
When it is faster to type it
Describing a three-line change precisely takes longer than making it. Writing the prompt, waiting, reading the diff, and correcting the parts it over-reached on is real overhead — and for small, well-understood edits it exceeds the work.
Renaming a variable across one file, swapping a hard-coded colour, fixing a typo in a label — a decent typist clears these in under thirty seconds. Writing the sentence that describes it, waiting for a reply, and reading the diff to confirm nothing else moved easily takes three or four times as long.
Watch for the tell: if you are on your third prompt for something you could have typed in a minute, you are not being efficient, you are avoiding starting.
When the code is not yours to share
Prompts leave your machine. Depending on your tool and plan, they may be retained, reviewed, or used for training. Before pasting, check whether you are allowed to:
- 1Employer policy
Many organisations restrict which tools may touch their source.
- 2Client confidentiality
Contract terms often cover disclosure to third-party services.
- 3Personal data
Real customer records in a prompt can be a regulatory problem regardless of intent.
- 4Licence terms
Some code cannot be redistributed, and a prompt is a form of transmission.
When the loop has stopped converging
A specific in-the-moment signal, worth naming because it is easy to miss while it is happening: each fix creates the next problem, and you have stopped moving toward working software.
After the second failure, close the conversation. Read the code yourself. Write a minimal reproduction. Frequently you find the actual cause in five minutes — and it was something the model could never have seen.
The principle underneath all of these
Every case here is the same rule wearing different clothes: AI is an accelerator, and accelerating is only good when you know where you are going.
When you can judge the output, it makes you dramatically faster. When you cannot, it makes you faster at producing something you cannot evaluate — which is not the same thing, and is occasionally much worse than being slow.
Key takeaways
- When learning is the point, the struggle is the mechanism. Write it first, then ask for a critique.
- If you could not tell a correct answer from a plausible one, you are hoping, not reviewing.
- Reversibility matters more than difficulty. Run anything with no undo somewhere fake first.
- For a three-line change, typing it is often faster than describing it.
- Check what you are allowed to send before you paste. Prompts leave your machine.
- When each fix creates the next problem, stop and read the code yourself.
- Accelerating is only useful when you know where you are going.
Before you move on
Quick check
Answer these to unlock the next chapter: 3 of 4 to pass. You can retake it anytime.
Make a free account to read on
Every chapter is free — an account lets your course progress follow you from your laptop to your phone. No payment, no trial.