AI: The New Steam Engine Trap

In my last post, we looked at why history keeps face-palming every time we get a new toy. From telegraphs to steam engines, we’ve spent 150 years assuming that swapping one component for a faster one would magically fix the economy.

It never did. And right now, the software industry is about to step on the same rake. Again.

The Collective Amnesia of “Vibe Coding”

Something weird is happening. Since everyone discovered LLMs and started talking about “vibe coding,” the entire software industry has developed a sudden, violent case of amnesia. We’ve spent the last 25 years learning that software engineering is not just typing characters into a screen. And yet, here we are, acting like it’s 1985 again.

Speaking of the 80s, there’s an urban legend from the IBM/Microsoft era about a developer whose performance was measured by Lines of Code (LOC). Tasked with writing a function to print a byte as a string of zeros and ones, he didn’t use a simple sprintf. Instead, he dropped a monstrous switch statement with 256 individual cases.

Instead of three lines, he delivered over 500. On paper? A massive “productivity” win. Technically? You could even defend it—it was $O(1)$ performance, no buffer parsing, no overhead. But in reality? It was a maintenance suicide note. What if he fat-fingered case 163? Who’s checking that?

This is where the saying comes from: Measuring software progress by lines of code is like measuring aircraft progress by weight.

Goodhart’s Law: When the Metric Kills the Mission

This isn’t just a clever one-liner to throw around at stand-ups; it’s a direct bridge to the psychological trap we’re setting for ourselves right now—a phenomenon known as Goodhart’s Law: “When a measure becomes a target, it ceases to be a good measure.”

Because AI can generate 500 lines of code in three seconds, we’ve decided that “writing code” is the only metric that matters. But software engineering is a much bigger, uglier beast. Before you even touch your IDE, you have to identify the problem and design a solution. You have to navigate load requirements, budgets, legacy constraints, and—most importantly—the “right” trade-offs.

And once the “happy coding” is done? That’s when the real work begins. You have unit tests, integration tests, static analysis, security scans, and vulnerability checks. You have the joy of manual and automated exploration to make sure your “perfect” code doesn’t set the server on fire.

The Great Shift: From Typing to Validating

Two or three years ago, the act of coding was the “dominant operation.” It took up most of our time. Now? Code “does itself.” Write a spec in a .md file, point a couple of agents at it, and watch the scroll bar move.

But this doesn’t eliminate the design phase. More importantly, it violently shifts the weight from coding to validation.

Validation hasn’t been eliminated; it’s become the bottleneck. It is now harder, more critical, and more exhausting than ever. Researchers are already calling the psychological fallout “AI Brain Fry.” Trying to verify 1,000 lines of AI-generated code that “looks” right but might have a hallucinated security flaw in case 163 is a cognitive nightmare.

The “One Big Motor” Mistake

And yet, how are we estimating tasks? Still by how long we think they’ll take to “code.” We subconsciously assume that if AI cuts the coding time in half, the design and validation phases will magically shrink along with it.

This is exactly what the factory owners did 100 years ago. They thought replacing a central steam engine with one giant electric motor would create a “hockey stick” productivity curve. It didn’t. They were still using the same old belts, the same old pulleys, and the same old messy floor plan.

Right now, we are greenlighting every half-baked idea because “it’ll only take the AI two days to build.” We are flooding our repositories with “weight” and calling it “progress.”

The Verdict

GenAI, state machines, and agentic workflows are going to change our jobs forever. I’m not denying that. But it’s not happening at the breakneck speed the current hype cycle suggests.

Real productivity benefits won’t come from AI writing code faster. They will only come when we perform a total system reboot of how we design and validate software. We need new metrics, new workflows, and a completely different approach to risk.

We’ve bought the new electric engines. Now, we need to stop pretending the old belts and pulleys are going to hold up.

But hey, at least the “vibe” is good, right?