Vibe Coding Is Not Production Engineering

I do not know why it did not occur to me sooner, but the iceberg picture is basically the perfect metaphor for vibe-coded apps.

Above the water you see the fancy UI. A slick demo. A few screens stitched together. Maybe some error logs in the editor you are “vibing” in. It looks like a product because, visually, it sort of is one.

Below the water is everything that makes it survive contact with real users.

Authentication. Permissions. Data modelling. Deployment. Backups. Monitoring. Rate limits. Security. Logging. Rollbacks. Load handling. Data deletion prevention. Audit trails. Recovery. Billing. Support. Edge cases. The things that are boring right up until the moment they become the only things anyone cares about.

Demos are not production

I like AI coding tools. I use them constantly. They are getting better at a ridiculous pace, and they have already changed how quickly a technical person can move from idea to working prototype.

That is brilliant.

But a prototype is not a production system. A demo is not an operating business. A UI is not an application just because the buttons mostly do things when you click them in the right order.

Most vibe-coded apps are probably fine for a small number of users. If you have 20 or 30 people using something, maybe even 50 if you are close to them and can handle issues manually, you can get away with a lot. You can fix data by hand. You can apologise in a message. You can redeploy on a hunch. You can be the human glue holding the whole thing together.

That stops working once usage grows.

The hidden stack becomes the product

At 50+ users, and especially once money, customer data, business processes or reputation are involved, the hidden stack starts to matter more than the shiny bit.

What happens when something breaks?

Can you roll back safely?

Do you know what changed?

Can users access only what they should?

Can someone delete data they should not be able to delete?

Can you recover from a failed migration?

Can you explain what happened if a customer asks?

This is where software engineering shows up. Not as a job title. As a set of responsibilities.

The frustrating part is that the iceberg underneath the app is rarely visible in the early excitement. Nobody shares a viral post saying “look at my sensible permission model and tested rollback plan”. Which is a shame, because frankly some of us would enjoy that more than another animated landing page.

AI makes building faster. It does not remove responsibility.

The lesson is not that people should stop using AI to build software. The opposite. More people should build things. More ideas should make it out of notebooks and into working form. AI tools are making that possible, and that is genuinely exciting.

But speed changes the risk profile.

When building becomes easier, more people reach the point where production problems appear. That means the need for good engineering does not go away. It moves closer to the surface.

The future is not “everyone vibes and engineering disappears”. It is more likely that the baseline for what can be built quickly goes up, and the value of knowing how to make it robust goes up with it.

Vibe coding gets you above the waterline.

Production engineering is what stops the whole thing sinking.

Draft adapted from Brad’s LinkedIn post from 2026-06-24. Source: LinkedIn post.