The Confident Soup

Source: Dev.to

It is 2:14 AM. Production is degraded. You are hunting for the edge of the fire, but there is no edge. Forty minutes have passed. The code compiles, the tests are green, the deployment was flawless, yet the system is failing under load. You stare at a file trying to find where the payment logic ends and the user logic begins, but everything is touching everything. The auth module reaches into the billing service, and the billing service mutates 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 perfectly indented, completely entangled syntax. The codebase is confident. The codebase is everywhere. You are drowning in it.

Good Engineering

Good engineering is not the speed of typing. It is knowing which battles to lose first. Before you build a feature, you sketch the failure mode. You write the interface before the implementation, deliberately keeping it loose—not because you don’t know what it should do, but because you anticipate pivots, load spikes, or database locks. By decoupling the boundary, the system fails predictably when it does: the payment service drops dead, the auth service keeps running, and the fire stops at the seam because you built the seam before the fire.

Designing for Failure

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 gather enough information to build something that actually lasts. You stay loose because you do not know how users will interact with your solution. Humans arrive at your interface with contexts you never modeled; they find paths you didn’t design for and pull on them until something breaks. A 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.

Amateur vs. Strategic Fighting

Go on social media and watch amateurs fight. No jab. No feint. No reading the opponent. Two people throw 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 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, but because it has no stamina to conserve. There is no round three for the model; there is only the ticket, the response, and the need to fill every void with syntax before the context window closes. It cannot throw a jab, cannot deliberately underspecify an interface, cannot resist closing the seam. Incompleteness feels, to the model, like failure, so it finishes—instantly, with total confidence. That is not a bug; it is the nature of the tool.

AI’s Impact on Engineering

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—was skipped 55 % faster.

Conclusion

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 stand‑up. 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.

Reference

We Studied 150 Developers Using AI (Here’s What’s Really Happening) — Dave Farley