A story about AI, software engineering, and the difference between shipping code and shipping production systems.
A few days ago, a post from a Vietnamese CEO sent shockwaves through the local tech community.
His claim was bold.
"I pay around $20/month for Claude. It replaced developers for our internal software."
He argued that small and medium businesses no longer needed software developers, expensive SaaS subscriptions, or months of development.
Instead, they could simply describe what they wanted in natural language, and AI would build it.
The post spread rapidly across social media.
Thousands of people agreed.
Some celebrated it as the future of software development.
Others saw it as the beginning of the end for software engineers.
Everyone seemed to have an opinion.
Then, a few days later, something interesting happened.
A handful of engineers managed to find the application behind the viral post.
Out of curiosity, they did what engineers naturally do.
They opened the website.
They pressed F12.
They opened DevTools.
At first, nobody was trying to prove anyone wrong. They simply wanted to understand how it had been built.
Then the first screenshot appeared.
"Wait... why is this exposed in the frontend?"
A few minutes later, another one.
"This credential shouldn't be here."
Then another.
"Is the admin page actually protected?"
More engineers joined in.
Some inspected the JavaScript bundle.
Others monitored the network requests.
Some traced the API calls.
Within hours, screenshots, code snippets, and technical analyses started spreading across engineering groups in Vietnam.
One finding became five.
Five became twenty.
The conversation was no longer about whether AI could generate code.
It had evolved into a much more interesting question.
What's the difference between software that works and software that's ready for production?
First Impression
To be fair, the application looked surprisingly good.
The UI was clean.
Authentication existed.
Users could log in.
Data could be created and updated.
If someone had shown me only the demo video, I probably would've said:
"Wow. AI is getting incredibly good."
And honestly, I still believe that.
Because what happened next wasn't evidence that AI is bad.
It was evidence that software engineering is much bigger than writing code.
The First Five Minutes
The first thing experienced engineers inspect usually isn't the UI.
It's what the browser already knows.
Within minutes, several issues became obvious.
Sensitive configuration values were exposed directly in the frontend.
Credentials that should never live inside client-side code were accessible.
Administrative functionality wasn't actually protected by authorization.
In one case, it was simply hidden from users using CSS.
The browser wasn't supposed to display it.
But nothing stopped someone from navigating there directly.
Some API endpoints trusted the frontend far more than they should.
Several security checks that normally belong on the server appeared to be missing.
In several places, the application assumed users would behave honestly.
Software rarely gets attacked by honest users.
The most interesting part?
None of these findings required sophisticated hacking techniques.
Just a browser.
A few minutes.
And DevTools.
None of These Were AI Bugs
This is where I think many discussions go wrong.
People immediately say:
"See? AI writes terrible code."
I don't think that's true.
Claude didn't randomly decide to expose secrets.
It didn't intentionally replace authorization with CSS.
It didn't wake up one morning and think:
"Today I'm going to ignore security best practices."
It simply optimized for the task it was given.
If the prompt was:
"Build me an admin dashboard."
Then it built an admin dashboard.
Not a secure production system.
Those are two very different requests.
AI did exactly what it was asked to do.
The real problem wasn't AI.
The real problem was assuming that generating code is the same as engineering software.
It isn't.
The Demo Was Successful. The Engineering Wasn't Finished.
This is something our industry has struggled to explain for years.
Many people think software engineering is writing code.
It isn't.
Writing code is only one small part of the job.
Real engineering happens in the invisible layers.
The things users never notice.
Things like:
- Authentication
- Authorization
- Secret management
- Rate limiting
- Audit logging
- Monitoring
- Backup strategies
- Disaster recovery
- Database migrations
- Infrastructure
- Threat modeling
- Performance under load
- Compliance
- Security reviews
None of these appear in a product demo.
None of these make a startup launch video look cooler.
Yet these are the things that determine whether software survives in production.
AI Has Changed the Cost Curve
This is actually the exciting part.
Five years ago, building an MVP required a team.
Today?
One founder with AI can build something surprisingly impressive over a weekend.
That's incredible.
And honestly, I love it.
More people can validate ideas.
More startups can experiment.
More businesses can automate repetitive work.
AI has dramatically lowered the cost of creating software.
That is unquestionably a good thing.
But lowering the cost of creating software doesn't eliminate the need for engineering.
It simply changes where engineering creates value.
The Job Was Never Just Writing Code
This is probably the biggest misconception I see online.
People assume developers are paid to type.
They're not.
We're paid to reduce uncertainty.
We're paid to reduce risk.
Anyone can generate code.
Experience helps answer questions like:
- What happens if someone bypasses the frontend?
- Can users access another customer's data?
- What if this service goes offline?
- How do we rotate secrets without downtime?
- Will this architecture still work with one million users?
- How do we recover after a failed deployment?
- What telemetry do we need when production breaks at 2 AM?
These questions rarely appear in prompts.
But they appear every single day in production.
Vibe Coding Isn't the Enemy
In fact, I use AI every day.
- Claude
- GPT
- Gemini
- Cursor
- GitHub Copilot
They've made me dramatically faster.
AI writes boilerplate.
AI explains unfamiliar code.
AI generates tests.
AI reviews pull requests.
AI helps me prototype ideas in hours instead of days.
It's one of the best productivity tools I've ever used.
But I don't confuse acceleration with expertise.
Giving a Formula 1 car to someone who just got a driver's license doesn't create a Formula 1 driver.
It creates a faster beginner.
AI works the same way.
What Actually Happened Here?
Ironically, this story wasn't about a CEO.
It wasn't about Claude.
It wasn't even about security vulnerabilities.
It exposed something much deeper.
For years, many people—including our own industry—mistakenly equated software engineering with writing code.
AI shattered that illusion.
Writing code is becoming cheaper every month.
Engineering judgment isn't.
If anything, AI has made it even more valuable.
Because now anyone can generate thousands of lines of code.
The difficult part is knowing whether those thousands of lines should ever reach production.
My Take
I don't think AI is replacing software engineers.
I think AI is replacing the part of software engineering that we mistakenly believed was the job.
Typing code.
The real work has always been:
- Understanding systems.
- Managing complexity.
- Designing for failure.
- Protecting users.
- Making good engineering decisions.
Ironically, AI is making those skills more valuable than ever.
Because when anyone can generate code...
The hardest part is no longer writing software.
It's knowing whether that software deserves to be deployed.
Final Thoughts
The viral post wasn't wrong about one thing.
AI has fundamentally changed software development.
It has lowered barriers.
It has empowered founders.
It has made individual developers dramatically more productive.
That's worth celebrating.
But the engineering community's response reminded us of something equally important.
There's a huge difference between software that impresses in a demo and software that survives in production.
One proves an idea.
The other earns trust.
And trust has always been the hardest thing to engineer.
Perhaps the biggest lesson from this story isn't that AI will or won't replace developers.
It's that AI has finally forced us to answer a question our industry has been avoiding for years:
What do software engineers actually do?
And maybe, for the first time, we now have a better answer than simply saying:
"We write code."
What do you think?
Has AI changed what it means to be a software engineer?
Or has it simply revealed what software engineering has always been about?
Top comments (5)
This is great. The gap between "it works on my machine" and "it survives in production" is exactly what I've been writing about in my 36 Stratagems series — just from a security/ops angle instead of AI. That F12 moment is chef's kiss. For a small team with no dedicated infra person, where do you personally draw the line between vibe coding and proper engineering?
Thanks! I actually came across your 36 Stratagems series while writing this article and borrowed some of the production mindset ideas from it. Really enjoyed the security/ops perspective.
I don't think there's a hard line between vibe coding and proper engineering. It really depends on the scope of the project.
For an MVP, the first question I ask isn't "Should I use AWS or GCP, etc...?" It's "What am I actually building?" Is it an internal tool for 5 people? A side project? Or a SaaS product that I hope will eventually serve thousands of users?
For small teams, moving fast is usually the right decision. I'd rather use Vercel, Supabase, Railway, Clerk, Stripe, etc. than spend weeks setting up cloud infrastructure. Time-to-market matters much more than having a perfect architecture on day one.
As for when I stop relying purely on vibe coding, I usually look at two things:
When I can no longer write good prompts because I don't fully understand the problem anymore.
For example, if I'm asking Claude to "make authentication more secure" without understanding OAuth flows, token management, authorization models, or why something is insecure in the first place, then I'm probably outside my expertise. At that point, I either need to learn the domain or ask someone who understands it better.
When the product starts proving itself.
If it's a SaaS product and people are actually using it, paying for it, and generating revenue, that's usually my signal to start investing more seriously in engineering. Real users change everything—security, observability, backups, scalability, and reliability suddenly become business problems rather than technical nice-to-haves.
I guess my view is that vibe coding isn't something you stop doing. You simply grow out of relying on it alone as your product and responsibilities grow.
That prompt litmus test — I don't think I've seen it framed that way before. Really good way to put it. I've definitely been down that auth rabbit hole myself. 😅 Was there a specific moment or project where you realized "alright, vibe coding alone isn't cutting it anymore"?
Haha, I actually learned this while building an AI-powered marketing scoring system.
Vibe coding felt like magic at first. With a good spec and pattern files, AI got me to ~90% incredibly fast. But the closer I got to production-ready quality, the worse the ROI became. Small architectural decisions, edge cases, and domain-specific logic often took more time to explain to AI than implementing them myself.
My takeaway is that AI can get you to 90-95% insanely fast, but getting from 95% to 100% can sometimes cost more than building it yourself if you don't deeply understand the problem you're solving.
The 90-95% vs 95-100% framing is spot on. That last stretch is where the actual engineering lives. Feels like the ceiling isn't AI — it's how well you understand the problem yourself.