The Asbestos Bakery

Every fifteen years, a new generation of Architecture Astronauts descends from the heavens to announce that the degrading, manual labor of actually typing out logic is finally over. In the 1990s, they promised us salvation via 1990s CASE tools and Rational Rose. Some guy in an expensive suit would show up at your office, plug his laptop into a projector, and enthusiastically insist that if you just drew a bunch of neat little UML diagrams on a whiteboard, the computer would magically write the entire enterprise system for you. (Attention, Gen Z thought-leaders: yes, we actually had electricity and keyboards in the nineties, I promise. No need to email me about it.)

Today, the exact same consultant class has returned with a shiny new buzzword—"vibe coding"—and the pitch remains completely unchanged. You just casually prompt the machine, swirl your iced macchiato, and watch in smug satisfaction while a Large Language Model frantically vomits out a scrillion lines of untested boilerplate on your behalf. The underlying fantasy assumes typing syntax is the hard part of software engineering, implying that automating the keyboard will usher in a post-scarcity utopia of instant applications.

Look at the breathless mainstream coverage surrounding the Paint.NET 5.2 alpha release. The software's lead developer heavily utilized AI tools to assist in the construction of a major update, and the headline number floating around the ecosystem is that this update involves something on the order of 180,000 lines of new code cranked out in a terrifyingly short window of time. To the Twitter thought-leaders and the efficiency-obsessed management tier, this is absolute, unassailable proof of the singularity. Dang, 180,000 lines of code generated practically overnight! Traditional programmers who sit around thinking about abstractions and reading log files are totally obsolete, right?

Wrong.

If you look at the panicked reaction of actual, battle-scarred developers in the intense debate on Hacker News, you will see absolutely zero awe. You will only see the cold, sweaty terror of people who have spent three consecutive days trying to track down a single, invisible race condition inside a vendor-supplied DLL. Experienced engineers understand a fundamental truth about human cognition: safely reviewing 180,000 lines of machine-generated, statistically probable slop is physically impossible for a human brain. It is like being asked to manually count the salt granules in a bathtub full of clam chowder.

When a human being writes a piece of code, there is an underlying intent. A human programmer, even a hopelessly incompetent one, leaves breadcrumbs of logic. An LLM doesn't have intent. It hallucinates a giant, intricate web of syntactically valid functions in three seconds, but a human developer still has to read it, hold the resulting state machine in their fragile meat-memory, and figure out why the user's graphics driver is suddenly causing an unhandled exception when they click the eyedropper tool.

Which brings us to a catastrophic misunderstanding of basic microeconomics. Why, exactly, is having more code suddenly considered a victory?

There is a persistent, industry-wide delusion that source code is an asset, like cash in the bank or gold bullion stacked up in a vault. Every sensible economics textbook will tell you that code is actually purely, strictly inventory. Every single line of code you commit is a toxic liability that you have to store, read, maintain, compile, debug, port to next year's idiotic operating system, and ultimately pay for with human suffering. If you can solve a business problem with ten lines of code, you are a hero. If it takes you ten thousand lines to solve the exact same problem, you have saddled your company with a massive, depreciating pile of inventory.

Let us step away from the IDE for a second and imagine a commercial bakery. A bakery makes money by selling baked, delicious loaves of bread to hungry customers. The bread is the asset. Now, to make that bread, you need giant vats of flour, huge drums of yeast, and massive, sticky lumps of dough sitting in the back room. The dough is inventory. If the bakery manager crashes through the storefront doors driving a forklift loaded with four hundred tons of unbaked dough just to show off his newfound productivity, you do not give him a bonus. You fire him, because all that dough is going to rot, attract pests, and bankrupt the business before it ever makes it into the oven.

But the vibe coding phenomenon introduces a deeply sinister twist to the dough problem. The AI goes far beyond pumping out excess inventory by actively weaving massive, inscrutable structural complexity into the very walls of your application. Bragging that you had an AI generate 180,000 lines of unread code for your app is exactly like bragging that you sprayed 180,000 pounds of raw asbestos into the walls of a bakery.

Sure, the walls might go up insanely fast. The building might even stay nice and warm for the first week. You can pat yourself on the back for being a hyper-productive architect. But you haven't actually baked more bread. You have just hyper-scaled your technical debt to fatal levels.

Because eventually, there will be a leak in the plumbing. Eventually, a customer will request a new feature, or a third-party API will deprecate an endpoint, and some poor, exhausted duct-tape programmer is going to have to take a sledgehammer and open up that wall. When they do, they are going to drown in a toxic cloud of 180,000 pounds of raw asbestos. The maintenance cost doesn't just scale linearly; it scales geometrically with the sheer volume of undocumented, machine-hallucinated complexity you pumped into the foundation. The builder gets the dopamine hit of immediate construction, while the maintenance programmer gets mesothelioma.

This is not a new lesson. When prominent thinkers like Martin Fowler correctly pointed out that using UML as blueprint ultimately collapsed under its own weight, they were observing the exact same economic reality. The crushing, decades-long maintenance burden of dealing with massive volumes of auto-generated code heavily outweighs the initial thrill of watching it instantly appear on your monitor.

We keep optimizing for raw typing speed, completely ignoring that the absolute limit on software engineering is human reading comprehension. If you force more keystrokes into the pipeline without upgrading the human brain's ability to actually read and understand the output, you are just crashing the car into a brick wall at a higher velocity. When you use an LLM to blindly dump code into your repository, you are using a machine to hyper-scale the exact thing you want less of. You are automating the generation of liabilities.

If you are 'vibe coding' by letting an LLM hallucinate a hundred thousand lines of unread boilerplate into your codebase, you need to unplug your router immediately. I am completely serious. Delete the generated garbage, sit down at your desk, and type out something you actually understand. The bakery depends on it.