Vibe coding, and the bill that arrives later
Building by feel (prompt, look, accept, repeat) is the fastest software has ever been to write. The cost is real, deferred, and avoidable.
Vibe coding is building by feel: describe what you want, glance at the result, accept it if the screen looks right, repeat. You are steering on outcomes rather than reading the code.
It is not a joke and it is not lazy. For a large class of work it is the correct strategy, and treating it as beneath serious engineers is a way of missing what has actually changed.
What it is genuinely good for
- Exploration. When you do not yet know what you are building, building five versions badly beats specifying one carefully.
- Throwaway work. Prototypes, demos, internal one-offs, spikes. Debt on something you delete is never repaid.
- Unfamiliar territory. Getting something working in a stack you have never used, to find out whether the approach is viable at all.
- Interfaces. Screens are self-evidently right or wrong. Looking at the result is a legitimate check.
When the bill arrives
The bill is not a crash. It arrives as a specific, recognisable moment.
Something is broken in production, and you are reading your own codebase for the first time.
That is the entire cost, and everything else is a consequence of it. You have a system you own, that works, that you cannot navigate, so diagnosis means learning the code under time pressure, in the least forgiving circumstances available.
The secondary costs follow from the same root:
| Moment | What it costs |
|---|---|
| First production incident | Learning the codebase during an outage instead of before one |
| First security question | Nobody can answer "where is user data handled?" without a search |
| First hire | Onboarding with no architecture to explain, so they read files and guess, like the model did |
| First audit or customer security review | Questions phrased in terms of the system's structure, which nobody has written down |
Why "just read the code later" does not work
It sounds like a fair plan, and it fails for a practical reason: reading code tells you what it does, never what it was for.
You can read a function and understand its behaviour exactly. What you cannot recover by reading is whether the duplicated validator is a deliberate distinction or an accident, whether the retry loop is load-bearing, whether that direct database call was a considered exception or a shortcut nobody noticed.
That information existed only in the moment the code was generated, and vibe coding is defined by not capturing it then. This is the same mechanism behind why AI-generated apps fall apart: you are now in the position the model was in.
Keeping the speed, losing the hangover
The fix is not to stop vibe coding. It is to capture structure while you go, at a cost low enough that it does not slow you down.
Draw before you prompt
Five minutes of boxes and arrows before a feature. Not a formal document, just the parts and what talks to what. This is the artefact that survives, and it is the one nobody makes.
Version control from minute one
Not for the history so much as for the diff. Being able to see exactly what a change touched is the cheapest comprehension tool that exists.
Name your boundaries out loud
Decide the two or three rules you actually care about (what must never call what) and enforce them mechanically. Two enforced rules beat twenty written down.
Draw a line around the risky parts
Auth, payments, anything touching personal data. Those get read by a human, whatever you do elsewhere. This is the highest-value hour you will spend.
That first step is what Graphlit is built around. You draw the architecture, it becomes a typed graph, and the code is generated against it, so the structure exists as a by-product of building rather than as documentation you were supposed to write afterwards and did not.
No prompt. No template. No prose.
The point is not discipline for its own sake. It is that when the incident comes, and it does, you are reading a map instead of reading forty files.
Common questions
Is vibe coding suitable for production applications?
For getting to production, often yes. For staying there, it depends entirely on whether anyone can navigate the result under pressure. The deciding factor is not code quality but comprehension: whether someone can answer "where does this happen?" during an incident.
What is the main risk of vibe coding?
Owning a working system nobody understands. It is not usually experienced as bad code; it is experienced as an outage where diagnosis means reading your own codebase for the first time, at the worst possible moment.
How can I vibe code more safely?
Sketch the structure before prompting, keep everything in version control, mechanically enforce two or three boundaries you actually care about, and have a human read anything touching authentication, payments or personal data.
Draw it. Then keep it true.
Graphlit turns an architecture drawing into a typed graph, builds against it, and proves the code still matches. Free to start.