If Part 1 was the dream of playing Emperor —pointing at a map and declaring “Build me a wall!”—then Part 2 is the soggy Monday morning when you realize the wall was built over a swamp, the stones are actually painted cardboard, and the architect has moved to a non-extradition country.
The history of enterprise IT is littered with the wreckage of “Silver Bullet” solutions that promised to automate away the messy human element. Today, as we swoon over AI “Vibe Coding,” we are walking a path already paved with the expensive tears of CEOs from the 80s and 90s
The Siren Song of the 80/20 Trap
Every “effortless” tool follows a predictable, almost comedic trajectory. For the first 80% of a project—the standard screens, the basic database entries, the “Hello World” of business logic—the tool is a miracle. It’s like a pre-fab Roman villa: looks great, goes up in a weekend, and impresses the neighbors.
The “Iceberg of Complexity.”
But then comes the “Hard 20%”—the idiosyncratic, logic-heavy edge cases that define a real business. This is where the abstraction “leaks.” Suddenly, the villa needs a secret dungeon that also functions as a geothermal spa, and the pre-fab kit has no instructions for that. Developers are forced to use “conceptual duct tape,” injecting custom code into the tool’s guts, eventually making the high-level tool more difficult to manage than the raw code it was supposed to replace.
As a Program Architect from Salesforce, I’ve walked into the ivory towers of dozens of global enterprises, and the scene is always a recurring nightmare. The business leaders point at the map and demand a “standard sales process” that everyone can follow. Then, reality hits. Regional logic differs. Commissions are arcane puzzles. A “simple” lead requires data from a legacy mainframe that hasn’t seen the light of day since 1996.
The Hall of Fame (of Failure)
When “Great Hope” meets the 80/20 rule at high speed, the result is usually a billion-dollar crater. Has the industry paid for this oversight before?
The “Tower of Babel” Modernized
| Project | The Initiative | The “Silver Bullet” | The Result |
| Westpac CS90 (1990s) | Build a revolutionary core banking system. | Extreme CASE tool generation and academic modeling. | $150M write-off. 90% of the “finished” code didn’t actually exist. |
| Bank of America MasterNet (1988) | Automate trust accounting. | High-level design abstractions meant to replace traditional processing. | $80M loss. Abandoned after years of failure; trust division outsourced to a rival. |
| FAA Advanced Automation System (1982-94) | Modernize US air traffic control. | Complex software abstractions and automated code generation. | $2.6B wasted. The models couldn’t handle real-time performance requirements. |
| Allied Irish Bank (AIB) (2000s) | Core banking implementation. | “Out-of-the-box” Oracle standardized models. | €84M settlement. Only 3,000 out of 5 million customers were ever migrated. |
The “Black Box” Nightmare
The most insidious byproduct of these failures is the Black Box. When a tool generates code, it isn’t writing for humans; it’s writing for the machine. It produces a labyrinth of optimized, unreadable procedural logic.
The “Digital Ouroboros.”
As long as the “visual model” works, everyone is happy. But the moment the business needs to change—or the “magic” tool goes obsolete—the link between the model and the code is severed. You are left with a massive, monolithic system that no living human understands. Modernizing these systems isn’t software engineering; it’s digital archaeology, trying to figure out what the “Mad Hatter” was thinking thirty years ago.
I’ve sat in mahogany conference rooms and watched the “no-code” fantasy get dismantled, rule by rule. I’ve heard the refrain, “We just need one little Apex trigger here. Just a tiny LWC there to make this screen work. This logic is idiosyncratic; the business demands it.” And despite all architectural advice about Cognitive Technical Debt and the inevitable “Black Box Nightmare,” the implementation partners, hungry for billable hours, nod eagerly. Yes, we absolutely need this custom code.
The low-code platform’s picturesque pasture is soon overgrown. Fast-forward eighteen months and millions of dollars, and the supposed “standard system” is a digital jungle, strangled by a monumental glacier of bespoke code that no one truly understands. A platform designed for speed becomes a monolithic fortress that defies change, guarded by a maze of ancient Apex, and leaving the organization with the exact Leaky Abstractions and unmaintainable legacy code they were promised they would escape.
Parallel to the Present: AI and “Cognitive Debt”
The current craze for “Vibe Coding”—where we describe the feeling of an app to an AI—is the ultimate 80/20 trap. LLMs are incredible at synthesizing that first 80%. But when the AI generates a complex routine that you don’t fundamentally understand, you are taking out a high-interest loan of Cognitive Technical Debt.
If that AI-generated code breaks in production at 3 AM, “vibes” won’t fix it. You’ll be stuck in the “Dory Problem.” The “Dory Problem” occurs when developers rely on AI to generate code, but the AI lacks a persistent, institutional understanding of the system’s history and overarching architectural intent
This results in the accumulation of “cognitive technical debt,” where developers fail to fundamentally understand the systems they are building and are forced to blindly apply iterative patches without grasping the root causes of production failures
The Lesson: Abstraction is a powerful tool for creation, but it is a terrible substitute for comprehension.
Coming Up Next…
We’ve seen the wreckage. We’ve smelled the smoke. Is the era of instructions truly over? Join me for Part 3: The Death of the “Perfect Prompt” and the Rise of “Vibe Coding,” where we explore how to actually navigate this new era without becoming another cautionary tale in a bank’s annual report.
