The dangerous version of vibe coding
A lot of people are learning the wrong lesson from vibe coding.
They see someone build an app in a weekend with Cursor, Claude Code, Codex, Lovable, or Windsurf, and they assume the hard part of software is gone.
It is not gone.
It moved.
Before AI coding tools, the painful part was writing the code. You had to search the error, read Stack Overflow, understand the answer, paste the snippet, rename the variables, break something else, and slowly build a mental model of how the system worked.
That workflow was slow, but it was also useful. You learned by touching failure directly.
Now AI removes a lot of that friction. Copilot fills in the blank file. ChatGPT explains the error. Cursor edits across files. Claude Code and Codex can take a task, inspect the repo, write the code, run commands, and come back with a diff.
That is a real shift.
But it creates a new problem: the code can look finished before the engineer understands it.
The first 70% feels like the whole product
AI is extremely good at the first part of building software.
It can create:
- scaffolding
- boilerplate
- CRUD pages
- auth screens
- landing pages
- basic APIs
- simple tests
- plausible refactors
- documentation
This is the part that demos well. It is also the part that convinces beginners they are further along than they really are.
The app opens. The form submits. The dashboard loads. The button works. The AI says the tests pass.
So it feels done.
But production software does not fail in the happy path. It fails in the edges.
The last 30% is where engineering starts
The hard part is usually not generating code.
The hard part is knowing what the generated code forgot.
Things like:
- permissions
- data integrity
- rate limits
- bad user states
- retries
- migrations
- security
- latency
- observability
- rollback paths
- maintainability
AI will happily build the shortest path to “it works.”
That does not mean it built the safest path, the simplest path, or the path your codebase can survive six months from now.
This is why experienced developers get more leverage from vibe coding.
They can look at the diff and feel when something is wrong.
They know when a test is fake.
They know when the agent created an abstraction just to solve one local problem.
They know when a database rule is missing.
They know when a UI works only because nobody has tried the second account, the expired session, the duplicate request, or the failed payment.
The agent writes.
The engineer judges.
The dangerous version of vibe coding
The dangerous version is letting the agent expand scope faster than your understanding.
You ask for one bug fix.
It rewrites the component.
You ask for one UI change.
It introduces a new state system.
You ask for one helper.
It creates five abstractions, updates twelve files, and tells you everything is cleaner now.
Maybe it is.
Maybe it is not.
If you cannot tell the difference, you are not moving faster. You are taking on debt with a nicer interface.
This is where vibe-coded products start to rot.
Because the human stopped supervising.
The better version is boring
The best AI coding workflows are much less magical than people think.
They look like this:
- give the agent a small task
- provide the relevant files
- ask for a plan first
- keep scope tight
- review the diff
- run the tests
- reject messy changes
- commit in small steps
- repeat
That is not as exciting as “I built a SaaS in one prompt.”
But it is how you get speed without losing control.
Good vibe coding is closer to managing a junior engineer than talking to a genie.
You do not just ask for the outcome.
You define the task, set constraints, inspect the work, and decide whether it is acceptable.
The junior developer problem
The problem is that the tasks AI automates first are the same tasks juniors used to learn from.
Small bugs.
Basic features.
Boilerplate.
Docs.
Test stubs.
Simple refactors.
Those tasks were never the final goal. They were the reps.
They taught you how codebases are shaped. They taught you what breaks. They taught you how to read other people’s code. They taught you how a “simple change” becomes a production issue.
If juniors skip all of that and go straight to agent-driven development, they may ship more in the short term.
But they risk becoming dependent before they become competent.
The new skill is supervision
The important skill is not prompt engineering in the cheap sense.
It is agent supervision.
Can you explain the task clearly?
Can you give the right context?
Can you keep the agent from touching unrelated files?
Can you spot fake progress?
Can you design a real test?
Can you reject a bad diff?
Can you turn messy generated code into a clean PR?
That is where the leverage is.
The future is not “engineers stop coding.”
The future is that coding becomes only one part of engineering.
More of the job shifts into specification, review, testing, architecture, and judgment.
