Andreas Horn recently shared something that caught my attention: "The Vibe Coding Lie." He followed it with the line many of us have heard lately: "I built an app in 3 hours." And then the reality check: "Sure. You built a demo. It will take you at least 3 weeks to make it production-ready. And 3 months to clean up the mess."

That framing nails the moment we are in. AI tools make building software feel effortless, and in many ways they are. But as Andreas Horn pointed out, vibe coding is fun until you have to ship something real. The gap between a slick prototype and a dependable product is where teams win or lose.

In this post, I want to expand on Andreas Horn's argument and make it practical: what exactly is missing when we "build an app in 3 hours," why LLMs tend to amplify those gaps, and how to keep the speed benefits without creating a long-term operational headache.

The seduction of the 3-hour app

A modern stack can make almost anything look real fast: a polished UI, a hosted backend, a database, authentication, and a deploy button. With LLMs, you can generate components, endpoints, schemas, and boilerplate in minutes. Andreas Horn described the effect well: "Anyone who can write a prompt can spin up something that looks like a product."

I have felt that rush too. The first working version lands quickly, stakeholders get excited, and it seems like software has finally become as easy as describing what you want.

But the hard part was never typing code quickly. The hard part is building to last.

"You would not build a house without a foundation. Yet that is exactly what vibe coding encourages."

A demo is optimized for responsiveness and surface area. Production is optimized for correctness, resilience, security, and operability over time.

What breaks when you skip the fundamentals

Andreas Horn listed the missing pieces that cause products to "break the moment you skip the fundamentals":

Infrastructure design
Security boundaries
Deployment strategy
Error handling
Logging for diagnosis
Monitoring for failure detection
Alerts when things break at 2 a.m.

Let me translate that into the most common failure modes I see when prototype code gets promoted to production.

Infrastructure design: the invisible architecture

A demo might run on a single managed service with default settings. A production system needs explicit decisions: networking, isolation, scaling, data durability, backups, and cost controls. If you do not design these, the system will still run, until it runs into limits you did not know you had.

Practical tell: if your app depends on "whatever the platform does by default," you do not have an infrastructure design. You have a hope.

Security boundaries: who can do what, and from where

LLM-generated code often "works" while quietly violating least privilege. Tokens end up in client-side code. APIs accept broader permissions than necessary. Admin endpoints lack authorization checks. CORS is set to allow everything. Secrets get committed or copied into environment variables without lifecycle controls.

Production-ready means:

Clear trust boundaries (browser vs backend vs internal services)
Strong authentication and authorization (not just login)
Secure secret management and rotation
Threat modeling for the core flows you support

Deployment strategy: repeatability beats heroics

A demo can be deployed manually. Production needs a repeatable pipeline: build, test, scan, deploy, and rollback. You want small, frequent releases, not risky big pushes.

If deployment relies on one person remembering a sequence of steps, you do not have a deployment strategy. You have a single point of failure.

Error handling: the difference between a crash and a service

Prototype code often assumes the happy path. In production, everything fails eventually: upstream APIs time out, users send malformed input, databases hit contention, and background jobs retry.

You need:

Explicit error contracts (what do clients receive?)
Retries with backoff (where appropriate)
Idempotency for operations that can be repeated
Timeouts everywhere

Logging and monitoring: software you cannot observe is software you cannot operate

Andreas Horn called out logging, monitoring, and alerts because they are the difference between "we have an issue" and "we know exactly what happened and how to fix it." The vibe coding trap is thinking you can add observability later. You can, but by then you are debugging blind in production.

At minimum, you want:

Structured logs with request IDs and user correlation
Metrics tied to user outcomes (latency, error rate, throughput)
Tracing for multi-service flows
Alerting tied to SLOs, not random thresholds

Why LLMs amplify the problem

Andreas Horn made an important point that is easy to miss: "AI optimizes for plausibility. Not for simplicity and also not for long-term correctness." That is the core of the vibe coding lie.

LLMs are excellent at producing code that looks like code that should work. They are far less reliable at producing systems that remain understandable after six months, survive load spikes, or meet compliance and security requirements.

In practice, unconstrained AI output often creates:

Abstraction layers nobody can explain
Blurred component boundaries
"Best practices" added before there is a problem to solve

That last one is sneaky. The model will happily add patterns that appear professional (layers, factories, complex configuration, premature microservices) even when a simpler design would be easier to test and operate.

The result matches Andreas Horn's warning: more code, lower quality, slower teams over time.

Vibe coding vs engineer-guided AI

I like the distinction Andreas Horn implied: vibe coding optimizes for speed as the primary metric. Engineer-guided AI treats software as long-lived infrastructure that must be operated, understood, and evolved.

This is not an anti-AI argument. Andreas Horn explicitly said AI-assisted development is powerful and that timelines can compress from weeks to days. I agree. The question is who is steering.

"AI does not reduce the need for engineering judgment. It increases it."

The engineer's role shifts from writing every line to constraining, reviewing, and shaping what gets produced.

A practical playbook: keep the speed, avoid the mess

If you want to ship fast without inheriting a fragile system, here is a lightweight way to operationalize Andreas Horn's message.

1) Define "production-ready" up front

Before you generate more code, write down non-functional requirements:

Availability target (even a simple 99.9%)
Data retention and backup needs
Security requirements (PII? compliance?)
Performance expectations
Support expectations (who is on call?)

This prevents the demo from silently becoming the production plan.

2) Force simplicity with constraints

When using an LLM, add constraints that push toward maintainability:

"Prefer fewer components over more"
"No new abstraction unless it removes duplication in 2+ places"
"Keep boundaries explicit: UI, API, data layer"
"Write tests for critical flows"

AI is an accelerator. Constraints decide what you accelerate.

3) Build the foundation as you build the feature

Do not postpone the basics. Add them as part of the same pull request:

CI pipeline
Linting and formatting
Secret management
Basic observability (logs, metrics)
Error handling standards

Even a minimal foundation compounds over time.

4) Treat architecture decisions as first-class

Capture key decisions with short ADRs (architecture decision records). This is one of the best antidotes to AI-generated complexity because it forces humans to explain "why this design" in plain language.

5) Review for operability, not just correctness

In code review, ask:

"How do we know this is failing?"
"How do we debug it?"
"How do we roll it back?"
"What happens under load?"

This is where a demo becomes a service.

The honest takeaway

When someone says, "I built an app in 3 hours," Andreas Horn is right to respond: you probably built something impressive, but you did not build something durable yet.

Vibe coding is not the enemy. Unmanaged vibe coding is. If you want the upside of AI-assisted development, pair it with engineering fundamentals: clear boundaries, secure defaults, repeatable deployments, and real observability.

Ship the demo quickly. Then do the work that makes it safe to keep shipping.

This blog post expands on a viral LinkedIn post by Andreas Horn, Head of AIOps @ IBM || Speaker | Lecturer | Advisor. View the original LinkedIn post →