Speed without friction

As anyone with even the slightest interest in software engineering can tell you, the last couple of years have borne witness to a monumental shift in the way digital products are created. The bottleneck that engineering had represented for decades has been smashed to smithereens. Those who can't tell a terminal from a command line, or a function from a syntax have started deploying to production without ever writing a single line of code.

"Vibe coding" is the term that's stuck. So much so that it was named Collins Dictionary Word of the Year 2025. Iteration is now measured in minutes rather than sprints and the fear barrier around code, long one of the most effective gatekeeping mechanisms in product organisations, has dropped away almost entirely. 

Tools like Cursor, Replit, and Vercel's AI copilots have made conversational development highly effective and genuinely pleasurable. They’ve allowed designers to prototype interactions directly, to test ideas before organisational friction kills them, and to throw something in front of users the same day the concept emerged. 

However, it’s the capabilities granted to founders that represent the most radical example of this shift. The classic early-stage dilemma, “do we validate the idea or hire the engineers to build it?”, is collapsing. Those without any technical background are now shipping working prototypes before their first investor meeting, testing pricing pages with real checkout flows, and iterating on core product loops without a single line of code written by hand. The minimum viable team is getting smaller. In some cases, it's a team of one with a very good prompt.

It’s fair to say that the power dynamics in product development are shifting in ways that will take years to fully play out. However, so may the consequences of this new way.

The debt that doesn't show

The problem isn't that AI-generated code is always bad. In fact, much of it is genuinely impressive. The problem is far subtler: AI is very good at generating convincing interfaces and local solutions, all the while silently degrading global system coherence.

Every individual component might look clean. Every feature might work in isolation. But across a codebase built through successive rounds of vibe coding, patterns emerge that no engineer would introduce deliberately: duplicated logic, unclear abstractions, dependency sprawl, inconsistent state management and security oversights that only surface at scale.

The most dangerous version of this is that it stays invisible for a long time. Vibe-coded products can reach users, generate revenue, and attract investment whilst containing major structural problems that are yet to be triggered. The architecture debt compounds quietly with every new feature. Not linearly, but exponentially. The tenth feature isn't ten times riskier than the first. It may be a hundred times riskier, because it interacts with everything that came before.

THE BLUEPRINT PROBLEM

Imagine constructing a large building by continuously adding attractive rooms, one locally logical, but with no master blueprint.

Every addition solves the problem directly in front of it. Need more space? Knock down a wall. Need another connection? Run another wire. Each decision makes sense in isolation, and every new section looks impressive when viewed on its own. But as the building grows, inconsistencies begin to emerge.

Corridors become convoluted, different wiring conventions are used throughout causing flickering lights and even power-outs, pipes are routed wherever space is available, and nobody fully understands how the pieces fit together. Maintenance becomes slower, more expensive and even hazardous because the structure was never designed as a coherent whole

Every room is a success. The building is a failure.

The illusion of competence

Vibe coding creates a combination that is, in its own way, treacherous: high output, high confidence, and often shallow understanding of what has actually been built.

A product can look polished, deploy successfully, and gain real users but contain critical architectural problems that will only reveal themselves later. Maintainability collapse, onboarding difficulty, or undiagnosable regression chaos are issues far too common to those who initially felt they’d managed to crack the code (pun very much intended) of cheap and effortless digital product construction. 

Learning to code has always involved encountering resistance - errors that don't resolve quickly and abstractions that don't click until you've fought with them are as familiar to any veteran software engineer as switching on a laptop. That friction, frustrating as it is, produces understanding. Vibe coding can bypass all of it. You get the output without the comprehension. The product works until it doesn't, and when it doesn't, you don't know why.

Speed paired with discipline

The answer isn't to slow vibe coding down. The democratisation of building is genuinely valuable, and the tools aren't going anywhere. The answer is to pair the speed it grants with discipline. It’s to treat AI-assisted development as a starting point that still requires architectural thinking, code review, shared standards, and a refactoring culture.

Engineering doesn't disappear in this future, but rather transforms. The repetitive implementation work AI handles well was never the most valuable part anyway. What becomes more important is what AI is genuinely poor at: governance thinking, identifying where a locally correct solution creates globally incoherent systems, and knowing when coherence is starting to break.

The question shifts from "can you write code?" to "can you design systems that survive complexity?", and that second question is harder, more important, and still entirely human.