Why vibe coding needs software engineering before we let the agents loose.
Don's loop gets the post-build part right.
With coding agents, though, I think a lot of the damage can happen before we ever get there.
In Vibe Was Never the Problem: The Missing Half of Vibe Coding, Don Johnson argues that intuition isn't what goes wrong in vibe coding. Stopping at intuition is.
His fix is a loop:
Vibe → Build → Break → Understand → Stabilize → Perfect
I agree with nearly all of it, especially the Break → Understand → Stabilize middle. That is exactly the part many AI-assisted projects skip.
My addition is about sequence.
Don's loop eventually produces a spec. It appears during Stabilize, alongside tests, types, contracts, and other things that turn an experiment into something trustworthy.
I think some version of that spec needs to exist before the build too, not only after it.
My version would be:
Vibe → Spec → Break the Design → Build → Break the Build → Understand → Stabilize → Perfect
The difference looks small.
I think it matters a lot.
Why sequence matters more now
Don makes a good case for exploration before full understanding.
A sculptor doesn't completely specify the statue before touching the clay. A musician doesn't prove a bassline before playing it.
For exploration, I agree.
But clay is cheap to reshape.
And clay doesn't install twelve dependencies while you are getting coffee.
A coding agent can.
One Build step today can produce twenty files, new packages, infrastructure configuration, a database migration, authentication logic, retries, background jobs, and, occasionally, an abstraction that apparently needed its own abstraction.
When understanding comes after all of that, we are no longer simply reviewing generated code.
We are reverse-engineering our own system.
A lightweight spec up front changes the division of labor.
Instead of:
AI designs → AI builds → human discovers what happened
we get:
Human defines intent and boundaries → AI builds → human verifies
Without that step, we can now create architectural debt faster than we have ever created code.
You can test a bad architecture very well
This is where I think Don's Break step is necessary, but not sufficient.
Breaking an implementation asks:
Does this thing fail?
A design review asks a different question:
Should we have built it this way at all?
I learned this lesson earlier in my career while leading testing for a cardiovascular device.
We had a test environment that could tell us whether the device behaved correctly under the conditions we had defined.
The problem was that one of those conditions was wrong.
We were using water where the real operating environment involved blood, which behaves differently.
We could have continued testing.
We could have generated more test cases.
We could have produced more data.
And we would have become increasingly confident in a model of the system that did not adequately represent the real environment.
The important question had to come before the test:
Does this test environment actually represent the system we are designing for?
That experience stayed with me because it showed how easily a team can validate an implementation while missing an assumption at the system level.
Sometimes the thing you need to break first is not the code.
It is the model of the problem.
The same issue becomes even more important with AI systems.
Imagine an application handling sensitive enterprise documents.
You can fuzz the retrieval endpoints, run adversarial prompts, test latency, and achieve excellent coverage.
None of that fixes an architecture where sensitive documents should never have crossed a particular service boundary in the first place.
It doesn't fix authorization being copied into a second store when it should have been checked against the authoritative source.
And it doesn't fix giving an agent a tool permission it never needed.
Sometimes the bug isn't in the code.
It's in the architecture.
Break twice
So I would break the system twice.
First: Break the design
Do it before implementation becomes expensive.
Attack the assumptions.
Ask:
- What if this assumption is wrong?
- What happens at 10x scale?
- What happens when the downstream service is unavailable?
- What if the user is malicious?
- What if the model is confidently wrong?
- Where are the trust boundaries?
- What should the model decide?
- What should stay deterministic?
- What requires human review?
- What are we optimizing for?
- What are we giving up?
This is the cheap Break.
Nothing exists yet.
A bad answer might cost a whiteboard edit instead of a rewrite.
Then: Break the build
This is Don's step, and I would keep it.
Test it.
Fuzz it.
Inject failures.
Attack it.
Load-test it.
Test the security boundaries.
Give it malformed inputs.
Give it adversarial inputs.
And, of course, give it the user who pastes an emoji into the ZIP code field.
The two Break stages answer different questions:
Break the Design: Is this the right system?
Break the Build: Did we implement that system correctly?
We need both.
Where exploration ends
None of this means you cannot build before the spec.
A throwaway spike can absolutely come first.
Build three versions in an afternoon if that is how you discover the shape of the problem.
That is one of the most exciting things coding agents give us.
AI makes architectural experimentation dramatically cheaper.
But at some point the spike stops being an experiment and starts becoming something another person may have to trust, operate, or maintain.
That is where I want the spec.
The spec marks the transition from:
"Let's see if this works."
to:
"We may actually ship this."
Without defined users, boundaries, requirements, and success criteria, five prototypes are still just five opinions.
The spec is one page, not 47
There is an obvious danger in what I am proposing.
If every vibe needs a six-week architecture review, three governance committees, twelve Jira epics, and a 47-page design document before anyone can touch the keyboard, then congratulations:
We have solved vibe coding by making sure nobody codes.
That is not the proposal.
For many AI projects, the high-level spec can fit on one or two pages:
- Problem and users
- Requirements and non-goals
- Major components and boundaries
- Data flow: what comes in, where it goes, and what gets stored
- Key assumptions
- Failure modes
- Permissions: what the agent or application can access
- Success criteria
Then review it.
But review it for disagreement, not ceremony.
A good design review is not ten people saying, "Looks good to me."
It is one person asking the uncomfortable question that makes everyone stare at the architecture diagram for thirty seconds.
Those thirty seconds can save three months.
The spec also gives us something the build loop cannot provide by itself.
There are two fundamentally different questions in software engineering:
Did we build it right?
and
Did we build the right thing?
AI is becoming extraordinarily good at accelerating the first one.
Generate.
Test.
Fix.
Repeat.
But an AI agent can execute the wrong requirement with impressive efficiency.
A beautifully engineered solution to the wrong problem is still the wrong solution.
The spec gives us something to evaluate the implementation against.
When code is cheap, judgment becomes scarce
This may be the bigger shift behind vibe coding.
When implementation was expensive, much of engineering naturally centered around:
Can we build this?
AI changes the economics of that question.
Increasingly, the harder questions move somewhere else:
Should we build this?
What should the system boundary be?
What should the model decide?
What should remain deterministic?
Where does a human need to stay in the loop?
Where do we need a hard control instead of a prompt?
What happens outside the happy path?
Those are engineering questions.
They are product questions.
And increasingly, they are governance questions.
They are also questions a coding agent will happily answer on your behalf if you do not answer them first.
That is the part that concerns me.
Not that AI can write code.
That it can quietly make architectural decisions while appearing to simply write code.
Vibe and engineering were never opposites
This is where I strongly agree with Don.
Vibe coding versus software engineering is a false choice.
Vibe opens the loop.
Engineering determines whether what comes out of that loop deserves to ship.
I would only extend the argument one step further:
Engineering shouldn't wait for the vibe to finish. It should surround it.
Before the prototype becomes a system, write down what you think you are building and try to prove the design wrong.
Then build it.
And try to prove the implementation wrong again.
AI didn't make software engineering less important.
It made it possible to build the wrong thing much faster.
And perhaps that is the other missing half of vibe coding.
Not less vibe.
More engineering around the vibe.
Over to you: Has a coding agent ever built you something that passed every test but still had the wrong boundary, assumption, or architecture? What would have caught it earlier?
