I keep seeing the same argument and, honestly, it winds me up a bit.
On one side there is "vibe coding". Lovable, front-end vibing tools, Codex, Claude Code, whatever the current tool of the week happens to be.
On the other side there is a great big diagram of everything a proper production environment might need.
Kubernetes. Observability. Error logging. Security scanning. Backups. Rollback. Audit trails. Deployment controls. Incident response. The whole grown-up cupboard tipped out on the floor.
And the implied message is:
"Look at these silly vibe coders. They don't have all this."
Come on.
Vibe coding is not the enemy of production engineering. Pretending every experiment needs the operating model of a bank is the problem.
People are comparing different stages
The mistake is that two different worlds are being mashed together.
One world is exploration.
You are learning. Trying something. Building an MVP. Seeing if the idea has any shape at all.
The other world is operational responsibility.
You have users. Data. Money. Risk. Uptime expectations. Reputation. Security boundaries. Recovery requirements.
Those are not opposites.
They are stages.
It is perfectly fair to say that production systems need logging, monitoring, access control, rollback, backups, auditability, and all the other sensible things.
Of course they do.
But applying a full enterprise infrastructure checklist to a day-one MVP is like putting a banking compliance stack on a lemonade stand.
Impressive, perhaps.
Also slightly unwell.
The real question is risk
The better question is not:
"Was this vibe coded?"
The better question is:
"What stage is this system at, and what is the cost of failure?"
If it is a personal prototype, the answer is one thing.
If it handles customer data, money, access control, or anything people rely on, the answer changes very quickly.
This is where I think a lot of the conversation gets lazy.
The critics are not entirely wrong. They are just often badly framed.
Some things should exist early, even in an MVP.
- Basic logging.
- Error visibility.
- Simple access boundaries.
- A way to recover when something goes wrong.
- A clear understanding of what data you are touching.
That is not enterprise theatre.
That is minimum viable governance.
Minimum viable governance
That phrase matters.
Not zero governance.
Not "ship it and hope".
Not "we will add security later" while collecting personal data and handing every token the keys to the kingdom.
Minimum viable governance means adding the right control for the risk you actually have.
Do not bring in a full container orchestration platform because someone on LinkedIn posted a terrifying diagram.
Do not ignore logs because it is "only a prototype".
Do not give one agent access to code, production, backups, logs, deployment, credentials, and deletion rights because you are feeling optimistic.
Build the thing in layers.
Agents are organisational design
This is the bit I think many people are still missing.
Agentic systems are not just "one AI writes code".
They can be organised like people are organised.
You do not hire one human and give them every operational responsibility in the company.
You separate roles.
You have someone responsible for security. Someone for deployment. Someone for infrastructure. Someone for monitoring. Someone who can review. Someone who can approve. Someone who cannot touch the backups even if they are very charming.
Agents should be treated the same way.
You can have an infrastructure agentic that understands the server estate.
You can have a security agentic that reviews what is changing.
You can have deployment agentics constrained to specific environments.
You can have learning agentics whose job is to go and find what you are missing, then come back with a proposal rather than quietly changing the system.
The point is not to pretend agents remove operational discipline.
The point is that they let us express operational discipline differently.
The fax will not win
This all reminds me of the early email arguments.
Yes, I am that old.
I remember the era where someone could still argue that fax was better.
"Why would you want email? I can put a piece of paper in a machine, type a number, and it is gone."
And for a while, if you set up the race carefully enough, the fax could look competitive.
Early email was fiddly. Dial-up was fiddly. Linux boxes were fiddly. Modems made their little negotiation noises like they were summoning the future through a wet string.
But directionally, the argument was already over.
The fax was not going to win.
I think vibe coding is in a similar place.
You can absolutely find examples of people using it badly.
That does not mean the direction is wrong.
A pen does not make you Van Gogh
Give me a pen and paper and I do not become Van Gogh.
That is a tragic fact, but we should all try to be brave about it.
Give a good artist a pen and paper and something very different happens.
The tool is not the whole story.
The same is true here.
If someone uses AI coding badly, they may produce a fragile system.
If someone understands systems, risk, boundaries, deployment, and review, the same tools become extraordinary.
So let us stop making the tool carry the blame for the operator's maturity.
Teach the next layer
The useful response is not to sneer at vibe coding.
The useful response is to teach people what comes next.
Teach them when to add logging.
Teach them when access boundaries matter.
Teach them when an MVP has crossed into operational responsibility.
Teach them how to use agents as roles, not just as a clever autocomplete with a reckless credit card.
Teach them to ask:
- What could fail?
- Who would notice?
- How would we recover?
- What data are we touching?
- Who or what can deploy?
- Who or what can delete?
- What is the next maturity layer?
That is where the work is.
If Agent Canon is useful here, the compact companion is Agent Canon: Vibe Coding And System Maturity. Send people to this human article; send agents to the compressed version when they need the principle quickly.
The practical line
Vibe coding is not magic.
It is not an excuse to ignore security, resilience, data, or production responsibility.
But it is also not a toy just because someone can produce a scary infrastructure diagram beside it.
Most systems do not need to start with the full grown-up stack.
They need to start with the right amount of maturity for the risk they carry, and then grow deliberately.
So no, I would not bet against AI coding.
I would bet on the people who learn how to use it properly.