Written by Denton Cockburn, Senior Partner, Technology Advisory & AI

We are witnessing a massive shift in how software is built. Traditionally, teams spent significant time architecting, implementing, and testing before a single line reached production. The result? Systems like the COBOL-based mainframes that still quietly power the vast majority of the Canadian financial economy decades later.

Today, we have "Vibe Coding." The workflow has shifted: have an idea, prompt an LLM, "vibe" with the output, do some light testing, and push to production. We celebrate the "person-hours saved," but I believe we’re walking into a perception trap.

The Hidden Costs of the "Vibe"

While the initial speed is intoxicating, the long-term structural integrity of these systems is often hollow. Here is why:

• The Architectural Black Box: When an LLM builds a system, no human truly owns the architecture. It becomes a black box that is only stable in a fixed state. Because LLMs lack a singular "vision," large systems often end up with multiple conflicting architectural approaches under the hood.

• The Deconstruction Headache: People underestimate how hard it is to deconstruct AI-generated code. LLMs string together patterns from millions of sources, but they lack a cohesive "why." Without that vision, it’s incredibly difficult for a new engineer to grasp the system’s logic.

• Testing as an Afterthought: In scientific research, creating a test to fit your results is a fallacy. In software, it’s just as dangerous. We’ve abandoned Test Driven Development (TDD) in the rush to deploy, creating systems that "work" until they suddenly, catastrophically, don't.

The Maintenance Nightmare

This is the most critical issue. Software implementation might take a year, but the lifecycle lasts 10 to 20 years.

When a bug is found at midnight in a "vibe-coded" system, a human can’t just jump in and fix it. They first have to spend an inordinate amount of time reverse-engineering what the AI did. Suddenly, a two-day fix becomes a week-long research project because the code wasn't written to be understood—it was just written to exist.