Vibe Coding Isn't the Problem. Calling It Engineering Is.
Vibe coding can help you build software faster.
The problem starts when “it works” becomes the definition of engineering.
There is a lot of debate around vibe coding.
Some developers think it is the future.
Others think it is destroying software engineering.
I think both sides are missing the real problem.
Vibe coding isn't inherently bad.
Using AI to generate code, prototype an idea, explore an unfamiliar API, or get from zero to something working can be incredibly useful.
The dangerous part is something else:
Confusing generated software with engineered software.
Those are not the same thing.
What Is Vibe Coding?
At its simplest:
Idea
↓
Prompt AI
↓
Generate code
↓
Run it
↓
"It works!"
↓
Ship it
This can be surprisingly effective.
You describe what you want.
An AI generates an implementation.
You run it.
It works.
You move on.
For a weekend project?
Great.
For a prototype?
Often great.
For testing an idea?
Fantastic.
But now imagine applying the exact same workflow to:
- authentication
- payments
- medical software
- financial systems
- distributed infrastructure
- security-sensitive applications
- systems expected to run for years
The standard changes completely.
Working ≠ Engineered
This is the distinction that gets lost.
A program that works for the happy path is not automatically good software.
Consider:
def login(username, password):
if username == "admin" and password == "1234":
return True
return False
It works.
You can log in.
The feature is technically functional.
But would you call this production authentication?
Obviously not.
Engineering asks questions that "does it work?" doesn't answer.
Does it work?
↓
Is it correct?
↓
Is it secure?
↓
Is it maintainable?
↓
Is it observable?
↓
Does it fail safely?
↓
Can someone else understand it?
↓
Can we change it six months from now?
That's engineering.
AI Is Extremely Good at Producing Code
And that's exactly why this conversation matters.
Modern coding models can generate surprisingly large amounts of software.
They can:
- create components
- write APIs
- generate tests
- refactor code
- explain unfamiliar code
- create database queries
- scaffold projects
- fix obvious bugs
- connect services
- generate documentation
The productivity gain is real.
But there is an important asymmetry:
Generating code is becoming cheap. Understanding code is still expensive.
That's the part people underestimate.
The Real Bottleneck Is Understanding
Imagine an AI generates 15,000 lines of code for your project.
You didn't manually write those lines.
But now you own them.
You need to understand:
Architecture
│
├── Data flow
├── Dependencies
├── Security assumptions
├── Failure modes
├── Performance
├── State management
└── Deployment
The code may have been generated in minutes.
Understanding it may take days.
That's why AI doesn't eliminate engineering.
It can actually increase the amount of software you need to reason about.
The "It Works" Trap
One of the easiest mistakes in AI-assisted development is this:
Prompt
↓
Code
↓
Run
↓
Works
↓
Ship
But professional engineering looks more like:
Problem
↓
Requirements
↓
Constraints
↓
Design
↓
Implementation
↓
Tests
↓
Review
↓
Observability
↓
Security
↓
Deployment
↓
Maintenance
Notice something?
Coding is only one part of the process.
Vibe Coding Is Great at the Beginning
There is a reason people love it.
The feedback loop is ridiculously fast.
You can go from:
"I have an idea"
to:
"I have a working prototype"
in an afternoon.
That's powerful.
For example:
Day 0
Idea
│
▼
AI
│
▼
Prototype
│
▼
Demo
│
▼
Feedback
Without AI, this might have taken considerably longer.
That's not a problem.
That's leverage.
The mistake is assuming the prototype has automatically become a production system.
Prototype ≠ Product
This is perhaps the most important distinction.
A prototype optimizes for:
Speed of learning.
Production software optimizes for:
Reliability over time.
Those goals are different.
Prototype
Speed
████████████████████
Reliability
███████
Production
Speed
███████████
Reliability
████████████████████
A prototype asks:
"Can this work?"
Engineering asks:
"Can this continue working when reality happens?"
Reality includes:
- unexpected users
- malicious input
- network failures
- corrupted data
- traffic spikes
- dependency failures
- partial deployments
- changing requirements
- future developers
The AI Doesn't Own the Consequences
This is another uncomfortable truth.
When an AI generates bad code, the AI isn't on call at 3 AM.
You are.
When the database gets corrupted:
you own it.
When a security vulnerability is discovered:
you own it.
When the deployment breaks production:
you own it.
When a future developer asks:
"Why the hell does this work like this?"
Guess who's responsible?
The engineer.
Engineering Is About Managing Uncertainty
This is why software engineering is more than programming.
Programming is largely about telling a computer what to do.
Engineering is about making decisions under constraints.
ENGINEERING
│
┌────────┼────────┐
▼ ▼ ▼
Correctness Security Reliability
│ │ │
└────────┼────────┘
▼
Maintainability
│
▼
Longevity
You are constantly balancing:
- cost
- complexity
- performance
- security
- reliability
- developer experience
- deadlines
- business requirements
AI can help with those decisions.
But someone still has to make them.
The Best Developers Will Probably Vibe Code
Ironically, I don't think the future is:
"Real engineers don't use AI."
Quite the opposite.
The strongest developers will probably use AI aggressively.
But they won't surrender the engineering process to it.
They'll use AI for:
Exploration
Scaffolding
Boilerplate
Refactoring
Testing
Research
Documentation
Debugging
And they'll keep humans in the loop for:
Architecture
Tradeoffs
Security
Requirements
System boundaries
Risk
Correctness
Ownership
That is a much more powerful model.
Think of AI as a Very Fast Junior Engineer
A useful mental model is:
AI is a ridiculously fast junior engineer who has read an absurd amount of code but can confidently make mistakes.
That means you don't ask:
"Can AI write this?"
You ask:
"How should I use AI here?"
For example:
Good use
"Generate three approaches for this API and explain the tradeoffs."
Better use
"Implement option two and write tests for the edge cases."
Engineering use
"Implement option two, identify security risks, explain assumptions, and give me a test strategy."
The difference isn't the model.
It's the human using it.
The New Skill Isn't Prompting
Prompting matters.
But I think a more important skill is emerging:
Judgment.
When AI produces code, can you tell whether it is:
- correct?
- overcomplicated?
- insecure?
- inefficient?
- unnecessary?
- inconsistent with the rest of the system?
That requires fundamentals.
You still need to understand:
Data structures
Algorithms
Networking
Databases
Operating systems
Security
Distributed systems
Architecture
Testing
AI changes how you use those fundamentals.
It doesn't make them irrelevant.
From "Code Writer" to "System Designer"
There is a bigger shift happening.
Historically:
Engineer
↓
Write code
Increasingly:
Engineer
↓
Understand problem
↓
Design system
↓
Use AI to implement
↓
Verify
↓
Operate
↓
Improve
The value moves upward.
You don't necessarily become less important because AI writes more code.
You become responsible for more of the system around the code.
The Architecture Problem
This is where AI-generated applications can become especially dangerous.
You can ask AI to build:
Frontend
↓
API
↓
Database
And it will happily produce something.
But real systems quickly become:
┌─────────────┐
│ Clients │
└──────┬──────┘
│
▼
┌─────────────┐
│ API Gateway │
└──────┬──────┘
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Auth Service A Service B
│ │ │
▼ ▼ ▼
Database Queue Cache
│
▼
Workers
│
▼
Storage
At that point, generating code is only a small part of the job.
The difficult questions become:
- Where should state live?
- What happens when the queue fails?
- What happens when a request is retried?
- How do services authenticate?
- Which operations are idempotent?
- Where are transactions required?
- How do you observe failures?
- What happens during partial outages?
No amount of "make me a full-stack app" changes those questions.
Documentation Becomes More Important
There's another interesting consequence.
When AI makes code generation faster, understanding the system becomes harder.
That makes good documentation more valuable, not less.
And not just README files.
Teams need:
- architecture diagrams
- dependency maps
- data-flow diagrams
- API documentation
- decisions
- assumptions
- operational runbooks
A visual representation can sometimes explain what hundreds of lines of code cannot.
For example:
Request
│
▼
Gateway
│
├──── Auth ──────► User DB
│
▼
Order Service
│
├────► PostgreSQL
│
└────► Queue
│
▼
Worker
│
▼
Notifications
The more software we generate, the more important it becomes to understand how the pieces fit together.
So, Should We Stop Vibe Coding?
No.
We should stop pretending it is the entire engineering process.
Vibe code.
Prototype.
Experiment.
Generate.
Throw things away.
Use AI to move ridiculously fast.
But when something matters?
Slow down.
Understand it.
Test it.
Review it.
Document it.
Design it.
Own it.
The New Rule
I would describe the distinction like this:
Vibe Coding
"Make it work."
Engineering
"Make it work,
make it understandable,
make it safe,
make it maintainable,
and make sure we know why."
Neither approach is inherently wrong.
They're optimized for different things.
The problem happens when we use the first definition while claiming we're doing the second.
AI Didn't Kill Engineering
It exposed what engineering actually is.
If your definition of engineering was:
"I personally typed every line."
Then AI absolutely threatens your definition.
But if engineering means:
understanding a problem, making sound technical decisions, managing complexity, validating assumptions, and building systems that survive reality
then AI doesn't eliminate engineering.
It makes those skills more valuable.
Because when anyone can generate 10,000 lines of code...
the scarce resource isn't code anymore.
It's judgment.
Final Thought
The future probably won't belong to developers who refuse to use AI.
And it probably won't belong to people who blindly let AI build everything either.
It will belong to people who can do both:
Move incredibly fast when speed matters.
and
Think incredibly deeply when correctness matters.
That's the difference between generating software and engineering software.
Vibe coding isn't the problem.
Calling the vibe the engineering is.
Top comments (0)