Vibe Coding Is Not Engineering

Menu

Vibe coding produces code. Engineering produces systems.<br>The gap between those two things is where production failures live.

This is not an argument against AI. It is an argument for engineering.

A model can generate a login system in seconds. It will not ask if emails<br>must be unique. That single missing requirement can collapse the system.<br>LLMs cannot see the category of questions that keep software safe.

What vibe coding gives you

Vibe coding gives you code. It gives you output. It gives you momentum.

What it does not give you is coherence.

Before any code exists, engineers make the decisions that keep systems safe.

Topic<br>Description

Problem framing<br>Define the problem, the user, the constraints, and the intended outcome.

Requirements engineering<br>Elicit behaviours, invariants, edge cases, and acceptance criteria.

System modelling<br>State models, data flows, sequence diagrams, causal reasoning.

Architectural design<br>Boundaries, responsibilities, interfaces, failure modes, trade‑offs.

Non‑functional requirement definition<br>Performance, reliability, security, compliance, operability, cost.

Risk identification<br>Unknowns, dependencies, failure points, mitigations.

Interface and contract design<br>Define APIs, schemas, and behavioural guarantees.

Planning and sequencing<br>Break work into coherent, deliverable units.

What engineering actually is

When engineers write code, they are not just typing. They are:

resolving ambiguity

defining boundaries

modelling behaviour

deciding how the system behaves under stress

Most of this happens before a single line of code exists. This is the work that<br>keeps systems coherent.

The engineering work vibe coding skips

These parts of the engineering discipline are skipped by LLMs.

Area<br>What engineers decide<br>What LLMs generate

Invariants<br>What must always be true<br>Code that assumes everything is fine

Identity & Uniqueness<br>What makes an entity "the same thing"<br>Code that treats everything as interchangeable

Constraints<br>What the system must never allow<br>Code that violates boundaries without noticing

Failure Modes<br>How the system behaves under stress<br>Code that only works in the happy path

Coupling & Sequencing<br>What depends on what, and in which order<br>Code that ignores ordering entirely

State & Transitions<br>How state changes and what triggers it<br>Code that mutates state without rules

Interfaces & Contracts<br>What each part promises to the rest<br>Code that exposes whatever the model invented

Boundaries<br>What the system does not do<br>Code that expands until it breaks

Error Handling<br>How the system recovers<br>Code that collapses on the first unexpected input

These are not abstractions. They are the decisions LLMs never ask about.

This is why systems fail even when the generated code looks correct.

A system is more than its text

This matters because a system relies on:

invariants that must always be true

constraints that cannot be violated

coupling and sequencing rules that shape business logic and user behaviour

None of these exist in the model's internal world.

Why AI‑generated code stalls and creates fragility

AI‑generated code stalls because the engineering decisions were never made.

When such decisions are missing:

features collide and break each other

system state becomes unpredictable

deployments become fragile and slow

error messages lose meaning

simple features become hard to add

Confidence collapses long before the system does. These decisions always<br>reappear later under pressure.

The system is not the code you generate. It is the environment the code runs<br>within.

A demo is easy; a product is not

Given a simple prompt:

write python to "Add user accounts to a website so people can log in."

The model generated a small, working Flask and SQLite example. That is<br>acceptable for a demo but it did not ask about these five requirements:

Should emails be unique

Should accounts be verified

Should users reset passwords

Should roles exist

What is the security model?

The consequences of unasked questions

If emails are not unique, two people can sign up with the same email address.<br>If they are logged in at the same time, user login identity is ambiguous. The<br>system cannot tell the difference between them.

When a user logs in with a repeated email address, the check of that user’s<br>registration from the database will always contain multiple values. Any code<br>built to check for a registered user will now have to safely handle the<br>possibility of multiple results.

The lack of unique‑email consideration means that if a user with a repeated<br>email resets their password, the vibe‑coded implementation will reset the<br>password for all users who share the same email. This is not survivable in<br>production. And if one user deletes their account, multiple accounts will be<br>deleted.

No production system can tolerate this.

The misconception behind vibe coding

Vibe coding assumes the AI is "intelligent" in the way an engineer...