It is 2:14 AM. Production is degraded. You are hunting for the edge of the fire. There is no edge.
Forty minutes have passed. The code compiles. The tests are green. The deployment was flawless. But the system is failing under load, and you are staring at a file trying to find where the payment logic ends and the user logic begins. You cannot find it. Everything is touching everything. The auth module reaches into the billing service. The billing service is mutating concerns it should never have touched.
There are no boundaries. No interfaces. No quiet spaces where one system hands off to another and walks away. Just a wall of syntax, perfectly indented, completely entangled.
The codebase is confident. The codebase is everywhere. You are drowning in it.
Good engineering is not the speed of the typing. It is knowing which battles to lose first.
Before you build the feature, you sketch the failure mode. You write the interface before the implementation, and you leave it deliberately loose — not because you don't know what it should do, but because you know the requirements will pivot, the load will spike, or the database will lock. You decouple the boundary so the system fails predictably when it does. The payment service drops dead. The auth service keeps running. The fire stops at the seam because you built the seam before the fire.
This is designed loss. You plan a small, controlled failure so the larger system can survive real pressure. You leave things unfinished on purpose, because that early loss is how you download enough information to build the thing that actually lasts.
And you stay loose because you do not actually know how users will interact with your solution. Humans arrive at your interface with contexts you never modeled. They find the path you did not design for and pull on it until something breaks. The system that cannot flex will fracture. A seam is not a metric of clean code. It is a planned retreat point — from your own assumptions as much as anything else.
Go on social media and watch amateurs fight.
No jab. No feint. No reading the opponent. Just two people throwing the hardest punch they can, as fast as they can, from the first bell. It looks like aggression. It looks like confidence. By the second round both fighters are gassing out, arms dropping, eating shots they would have slipped if they hadn't already spent everything.
The amateur does not throw a punch to gather information. They throw a punch to end it. Every swing is a haymaker. Every haymaker is a vote against the future — against round three, against the pivot, against the moment the fight changes and you need something left in reserve.
The LLM fights like an amateur. Not because it is stupid. Because it has no stamina to conserve. There is no round three for the model. There is only the ticket, and the response, and the need to fill every void with syntax before the context window closes. It cannot throw a jab. It cannot leave the interface deliberately underspecified. It cannot resist closing the seam. Incompleteness feels, to the model, like failure. So it finishes. Every time. Instantly. With total confidence.
That is not a bug. It is the nature of the tool.
Dave Farley studied 150 developers and found that AI makes them around 55% faster. The data is real.
But we are misreading what got faster.
It is 55% faster at finishing. The machine crystallizes the entire feature on contact — tokens arranged the way code looks, the same way a photograph captures light arranged in the shape of a face without understanding the skull beneath it. No rebar. No load-bearing logic. In a low-saturation solution, molecules move freely. You can separate things, alter them, work them. Vibe coding is supersaturated. Everything binds to everything else the moment you hit enter. There is no seam left open for the pivot. No failure mode designed in advance. No room left for the user you forgot to model.
Farley didn't prove that AI is good at engineering. He proved that AI is good at winning the first battle. The work that needed to stay loose? The planned retreat point? The architectural boundary? That work was skipped 55% faster.
It is still 2:14 AM. You are still hunting for the edge of the fire.
The architecture was never designed. It was merely outputted. The machine threw the haymaker, the PR was approved, and the sprint velocity chart pointed up and to the right. Leadership got the high. The engineer got the dark.
In a few hours there is a standup. You do not know what you are going to say, because you still do not know what you are facing. The soup is everywhere. Somewhere inside it, something is burning.
Somewhere, six months ago, a prompt won.
And now, in the dark, you are losing.
[1] We Studied 150 Developers Using AI (Here's What's Really Happening) — Dave Farley: https://www.youtube.com/watch?v=b9EbCb5A408
Top comments (0)