The programmers who learned their craft before the AI era have a specific frustration with vibe coding. It is not the tools. It is watching people ship code with no understanding behind it: authentication written without grasping what it is protecting against, database queries with no awareness of what happens at scale, error handling that assumes nothing ever fails in production. The code runs. It passes the demo. The vulnerabilities and the architectural debt are invisible to the person who built it, because spotting them requires the knowledge they used AI to avoid needing.
Vibe coding is the clearest current example of a pattern that will repeat across every domain where AI gets deployed at production scale. AI lowers the floor for producing something that resembles a professional output. It does not lower the expertise required to know whether that output is actually right.
The Gap Between Producing and Understanding
AI makes the gap between producing and understanding visible in ways that are uncomfortable to acknowledge. A developer using AI to write code can produce working software without understanding why it works, what its failure modes are, or what an attacker would do with it. That gap was always present in software development. AI dramatically accelerates the rate at which people who do not understand what they are building can produce things that look finished.
The gap is not unique to programming. It appears in any domain where AI lowers the production cost of outputs that require expertise to evaluate. An analyst using AI to generate financial models can produce outputs that look rigorous without understanding the assumptions embedded in them. A clinician using AI diagnostic tools can receive recommendations without the knowledge to assess whether the patient in front of them fits the model’s training distribution. A lawyer using AI to draft contracts can produce documents that look complete without knowing which clauses matter in the specific jurisdiction and context.
In each case, the AI produces the output. Domain knowledge is required to evaluate whether the output is right, what its limits are, and where it will fail. Without that knowledge, the AI does not remove risk. It transfers it invisibly.
This is precisely why the EU AI Act requires meaningful human oversight of AI in high-risk domains: not as a bureaucratic formality, but as a recognition that a human who cannot evaluate an AI recommendation cannot provide real oversight of it. The regulation institutionalises what good practitioners already know.
Treat AI Like a Brilliant Junior Who Moves Fast
The mental model that works best in practice comes from pair programming. Imagine working with a junior developer who is extraordinarily capable, learns instantly, writes at a speed no senior engineer can match, and can hold an enormous amount of context in mind simultaneously. The catch: they have no judgment about when to stop, no instinct for the edge case that will cause a production incident at 2am, and no feel for when the technically correct solution is the organisationally wrong one. Left to run without experienced oversight, they will produce impressive-looking output with expensive hidden problems.
That is AI. Fast, capable, genuinely useful, and in need of knowledgeable oversight to channel its output in the right direction.
The pair programming model is instructive because it is explicit about the roles. The senior developer is not there to do what the junior cannot do. They are there to provide judgment, to ask the right questions, to catch what speed and enthusiasm miss, and to ensure the output actually solves the right problem. The junior’s speed is an asset. The senior’s knowledge is what makes that speed safe to use.
This model applies directly outside programming. The financial analyst reviewing AI-generated models needs enough expertise to ask the right questions about assumptions and edge cases. The clinician working with AI diagnostic tools needs enough clinical knowledge to recognise when the patient in front of them does not fit the pattern the model was trained on. The lawyer reviewing AI-drafted contracts needs enough domain experience to spot the clause that looks standard but is not in this context.
The domain expert is not validating AI out of caution or compliance instinct. They are performing the judgment function that AI genuinely cannot perform: deciding whether the output is right for this situation, for these constraints, with these stakes.
The Foundation Every Enterprise AI Program Needs
The productivity case for AI is real. The speed gains are real. The ability to do significantly more with existing expertise is real. None of that contradicts the need for domain knowledge. It depends on it.
The enterprise AI programmes that deliver on their business cases are not the ones that use AI to reduce their reliance on domain expertise. They are the ones that use AI to give their domain experts significantly greater leverage, while keeping those experts close enough to the outputs to catch what the AI gets wrong.
Building AI capability without investing in the domain expertise to oversee it is the equivalent of hiring the fast junior and removing all the seniors. Output increases. Quality control disappears. The mistakes accumulate until they become visible, at which point they are expensive.
Domain expertise is not a legacy requirement that AI is gradually making redundant. It is the foundation that determines whether AI produces value or produces risk at scale. Getting this right is one of the core fundamentals of enterprise AI implementation, and it is the one most often underestimated at programme inception.
