After 26+ years in software development, I have seen several big shifts.
Waterfall to Agile.
Monoliths to Microservices.
Manual deployments to CI/CD.
Now we are witnessing another shift: vibe coding — describing what you want in plain English and letting AI generate the code.
In many ways, English is becoming a programming language.
But here is the reality.
Just because someone can describe software in English does not mean they can build production systems.
After all, everyone can write sentences — but not everyone can write a novel.
The Hype vs the Reality
The excitement around vibe coding is understandable.
You describe a feature…
And seconds later, working code appears.
It feels magical.
But anyone who has actually shipped production software knows something important:
Writing code was never the hardest part.
The real challenge was always making the system:
reliable
maintainable
secure
scalable
operable in the real world
Generating code is easy.
Running software successfully for years is the hard part.
The Missing Layer: Non-Functional Requirements
Every serious application is built on two types of requirements.
Functional requirements
What the system should do.
Examples:
Build a login page
Create an API to fetch orders
Generate reports
These are explicit.
They are easy to describe.
AI is already very good at generating this type of code.
Non-functional requirements
How the system should behave.
This is where engineering experience becomes critical.
You are constantly making trade-offs:
Will this code still be maintainable six months later?
How configurable is the system across environments?
What happens if a deployment fails at midnight?
Can we roll back safely?
What is the total cost of ownership over three years?
Which architecture allows the system to scale?
Which technology stack actually fits the team?
These decisions rarely appear in prompts.
They live in the engineer’s judgment.
And AI will not ask these questions unless you already know to ask them.
The Car vs the Airplane Problem
Assuming that someone who cannot drive a car can easily fly a plane — simply because the plane is more powerful — would be a dangerous assumption.
The same logic applies to vibe coding.
AI is an incredibly powerful tool.
But power without understanding increases risk.
The engineers who benefit the most from AI are the ones who have already:
designed systems
debugged production failures at 2 AM
maintained legacy systems
refactored fragile architectures
lived through painful deployments
They know:
what to ask for
what to review carefully
when generated code looks right but is fundamentally wrong
The Abhimanyu Trap
The Mahabharata gives us a surprisingly accurate metaphor.
Abhimanyu knew how to enter the Chakravyuh — the complex battle formation.
But he did not know how to exit it.
Vibe coding can create the same situation.
You can rapidly generate:
screens
APIs
database schemas
integrations
Progress feels fast.
But when the real-world problems appear — performance issues, scaling limits, security gaps, deployment failures — you suddenly realize something:
Getting into the system was easy.
Getting out of the complexity is not.
Without architectural experience, debugging skill, and system thinking, you are stuck inside the Chakravyuh.
The Bottom Line
Vibe coding is a remarkable capability.
But it amplifies expertise — it does not replace it.
For experienced engineers, it can easily make you 5–10x more productive.
But if someone skips the engineering fundamentals and jumps straight to:
“Just tell AI what to build.”
They may ship quickly.
But they will pay the price later — in maintenance, reliability, and technical debt.
And that price is often far higher than writing the original code.
Yes — English is becoming a programming language.
But software engineering is still software engineering.
💬 I am curious about others’ experiences.
Are you finding vibe coding to be a superpower, or are you already seeing the early traps?
First published on LinkedIn.