The incident always looks the same. A feature shipped three weeks ago. It worked. Tests were green. Then something adjacent breaks — a currency conversion, a permission check, a retry loop that silently swallows failures — and when someone finally opens the file, nobody on the team recognises the code. Not because it is bad code. Because nobody actually wrote it. It was generated, skimmed, approved, and merged.
This is the part of the vibe coding story that does not make it into the demos. I run engineering across a portfolio of enterprise products, and I have watched the same pattern repeat in a dozen codebases over the last eighteen months: the velocity gain is real, it is large, and it is being paid for later — with interest — unless somebody puts structural guardrails in place first.
So let me be precise about my position, because it gets misrepresented in both directions. I am not anti-vibe-coding. At Lasting Dynamics our teams use AI assistants every single day and I would not go back. Every engineer we hire goes through LD Academy, where coding with AI agents is part of the curriculum from day one. But there is a difference between using AI to write code and letting AI decide your architecture, and most enterprise teams have not yet drawn that line anywhere.
Michele's Take
The question is not whether your team should vibe code. They already are — with or without your policy. The only real question is whether the code they produce this way can reach production without passing through a gate that a human owns. If the answer is yes, you do not have an AI strategy. You have an unpriced liability.
What Vibe Coding Actually Means in an Enterprise Context
Vibe coding is the practice of building software by describing intent in natural language and accepting the code an AI model produces, with limited or no line-by-line review. The term was coined for solo builders shipping prototypes at speed, and in that context it is genuinely wonderful. The problem is that the practice migrated into enterprise codebases without the definition migrating with it.
In an enterprise setting, vibe coding is better understood as a shift in where engineering judgement is applied. It has not disappeared — it has moved. It used to live in the act of writing. Now it has to live in the act of specifying, constraining, and verifying. Teams that made that transition consciously are shipping faster with fewer defects. Teams that did not simply removed judgement from the pipeline and called it productivity.
Three distinct behaviours get lumped under the same label, and treating them identically is where most governance failures begin:
- Assisted authoring — a developer knows what they want, uses AI to type it faster, and reads every line. Low risk. This is just a better keyboard.
- Delegated implementation — a developer specifies behaviour, AI produces a whole module, the developer reviews the interface and spot-checks the internals. Medium risk. Manageable with the right gates.
- Unsupervised generation — a prompt produces working code, tests pass, it merges. Nobody has a mental model of the internals. This is where the real cost accumulates, and it is the only one of the three that genuinely deserves alarm.
Almost every policy I have reviewed either bans all three or permits all three. Both are wrong answers, and both are symptoms of the same mistake: treating vibe coding as a tooling question rather than a risk-tiering question.
The Productivity Number Everyone Quotes — and the One Nobody Does
The number in every deck is GitHub's controlled experiment with 95 developers: about 55% faster task completion with an AI assistant. It is a real result and I have no quarrel with it. My quarrel is that it measures a single dimension — time to first working implementation — and enterprise software is not judged on that dimension.
Here is the fuller picture, drawn from what I actually observe when a team adopts AI assistants without changing anything else about how they work:
| Dimension | Direction | What actually happens |
|---|---|---|
| Time to first working code | Strongly better | The 55% figure holds up. This part is not controversial. |
| Volume of code produced | Sharply up | More code, larger diffs, more surface area per pull request. |
| Code review quality | Down | Reviewers face 3–4x larger diffs with the same time budget. Approval becomes skimming. |
| Architectural consistency | Down | Each generation solves its problem locally. Patterns diverge silently across modules. |
| Defect escape rate | Up | Bugs that pass tests but violate unstated invariants — the expensive category. |
| Time to understand code later | Sharply up | Nobody has a mental model. Debugging starts from zero every time. |
Read that table as a whole and the pattern is unmistakable. Vibe coding does not eliminate engineering work — it relocates it downstream, from authoring into reviewing, debugging and maintaining. If your organisation has not correspondingly strengthened review, debugging and maintenance capacity, you have not made a productivity gain. You have made a loan.
The Metric That Exposes This
Stop tracking velocity and start tracking mean time to comprehension: when an unfamiliar engineer opens a production file, how long until they can safely change it? It is the single metric that catches vibe-coding debt, because it is the only one that gets worse as generated volume goes up. If it is trending the wrong way while your story points trend up, you have your answer.
The Four Ways Vibe Coding Breaks Enterprise Codebases
These are not hypotheticals. Each of the four is something I have been called in to diagnose, and none of them announce themselves early — which is precisely what makes them expensive.
1. Architectural drift
An AI model optimises for the prompt in front of it, not for the seventeen conventions your codebase has accumulated. Ask for a caching layer and you get a good caching layer — one that ignores the abstraction three other modules already use. Repeat forty times and you no longer have an architecture. You have a collection of locally reasonable decisions that nobody can hold in their head simultaneously. This failure mode is slow, silent, and by the time it is visible it costs a rewrite.
2. Security holes that read as clean code
Generated code is stylistically excellent, which is exactly the problem — it does not look suspicious. The recurring offenders I see are authorisation checks that verify authentication but never permission, input validation on shape but not on range, error handlers that leak internals into responses, and dependency choices made on training-data popularity rather than maintenance status. A reviewer skimming for smells finds none, because there is no smell. This is why security by design stops being optional the moment you adopt AI assistance at scale.
3. Tests that validate the implementation, not the requirement
This is the most under-discussed failure mode and, in my experience, the most dangerous. When the same model writes both the code and its tests, the tests describe what the code does — not what the business needs it to do. Coverage looks superb. The suite is green. And it is structurally incapable of catching the class of bug that matters most, because the misunderstanding is present identically in both artefacts. Green tests written by the author of the bug prove nothing.
4. The knowledge vacuum
Traditionally, writing a module was also how an engineer came to understand it — the struggle was the learning. Remove the struggle and you keep the artefact but lose the understanding. Six months later the person who shipped it cannot explain it, and the organisation's real capability is far lower than its commit history implies. This one compounds worst of all, because it degrades the very capacity you need to fix the other three.
The Guardrail Architecture: Six Layers That Actually Work
This is what I implement when a team wants to keep AI-assisted speed without accepting the downstream cost. It is deliberately boring, it is not expensive, and the order matters — each layer assumes the one above it is already in place.
- Codify your conventions as machine-readable context. Your architectural decisions, naming rules, approved libraries and forbidden patterns belong in a file the AI reads on every request. Undocumented conventions are, from a model's point of view, conventions that do not exist. This single step removes most architectural drift for a day of work.
- Separate the author of the code from the author of the tests. If AI generates the implementation, a human writes the acceptance criteria first — or a different model writes tests from the requirement, never from the code. Break the correlation and tests regain the ability to fail meaningfully.
- Gate on blast radius, not on volume. Diff size is a terrible risk proxy. What the code can reach — money, personal data, auth, external contracts, migrations — is a good one. The next section covers this properly, because it does more work than the other five layers combined.
- Make AI code review mandatory and adversarial. Run a second model over every diff with the explicit instruction to find security flaws, missing edge cases and convention violations — not to summarise. Cheap, fast, and it catches a meaningful share of what a skimming human misses. It supplements human review; it never replaces it.
- Set a floor on human comprehension, and enforce it in the ritual. The rule we use: an engineer may not approve a diff they could not defend in a design review. Not a slogan — an actual question asked in stand-up. It is the only control that directly addresses the knowledge vacuum.
- Instrument the invariants, because tests will not. Assert your business rules in production: balances reconcile, totals are non-negative, every privileged action has an audit record. AI-generated code fails on unstated assumptions, and runtime assertions are the only layer that catches assumptions nobody thought to write down.
Start With Layers 1 and 3
If you implement nothing else this quarter, do the machine-readable convention file and the blast-radius tiering. Together they are roughly two days of work and they address the two failure modes — architectural drift and unreviewed access to critical paths — that cause the incidents you will actually be paged for.
Blast Radius Is the Only Rule That Really Matters
Most AI coding policies I read are written as blanket permissions — AI is allowed, or it is not, or it is allowed “with review.” All three are useless, because they treat a marketing page and a payment ledger as the same object. The workable approach is to tier your codebase by what the code can damage, and set the gate per tier.
| Tier | What lives there | Vibe coding policy |
|---|---|---|
| Green | Internal tools, prototypes, admin views, scripts, tests for non-critical paths, docs | Unrestricted. Ship it. Do not add process here — this is where the speed is won. |
| Yellow | Product features, UI, non-critical APIs, integrations without financial or personal data | Generation allowed, human review required with the comprehension floor enforced. |
| Red | Auth and permissions, payments and ledgers, personal or health data, migrations, external contracts, audit logging | AI may draft and propose. A named human owns, rewrites and signs off line by line. No exceptions and no time pressure applied to this gate. |
In practice, the honest tiering of a typical enterprise codebase lands somewhere near 70% green, 25% yellow, 5% red. That is the whole insight: you can vibe code the overwhelming majority of your system with no ceremony at all, precisely because you have made the 5% genuinely non-negotiable. Blanket policies fail because they either strangle the 70% or expose the 5%. Tiering is what lets you stop choosing.
“The teams getting the most out of AI assistance are not the ones with the loosest rules or the strictest. They are the ones who know exactly which 5% of their codebase a human must still own.”
— Michele Cimmino · CEO & Founder, Lasting Dynamics
What This Looks Like on a Real Team
Some operational detail, because frameworks are easy to nod along to and hard to actually run. Across our teams at Lasting Dynamics, the tiering lives in the repository itself — path-based rules in CI, so a pull request touching a red-tier directory automatically requires the named owner and cannot be merged by anyone else. The policy is not a document people are supposed to remember. It is a pipeline that refuses.
The convention file is treated as production code: reviewed, versioned, and updated the moment an architectural decision changes. When drift shows up in review, the fix is usually not a lecture to the engineer — it is a missing line in that file. That reframing matters more than it sounds, because it turns a discipline problem into a documentation problem, and documentation problems are tractable.
And the comprehension floor is enforced socially, not technically. In design review we pick a recently merged file at random and ask its approver to walk through it. Nobody is punished for failing — but the incentive corrects almost immediately, and after two weeks the skimming approvals stopped. It is the cheapest control on the list and it does the most for long-term capability. This is the same argument I make about owning your systems rather than renting them: the value is in the understanding you accumulate, not just the artefact you end up with.
If you want the broader picture of how AI is reshaping delivery economics rather than just code review, I wrote a founder-facing version of that argument in my no-hype guide to AI in software development. This article is the enterprise governance counterpart — same technology, different question.
The 30-Day Rollout
You do not need a transformation programme. You need four weeks and someone with the authority to say no.
- Week 1 — Tier the codebase. Get your senior engineers in a room and classify every top-level directory green, yellow or red. Argue about the boundaries; the argument is the valuable part. Commit the result to the repository.
- Week 2 — Write the convention file. Architectural decisions, approved dependencies, forbidden patterns, naming, error handling. Wire it into whatever AI tooling your team uses so it is loaded automatically rather than remembered.
- Week 3 — Wire the gates. Path-based CI rules for red-tier ownership, an adversarial AI review step on every pull request, and runtime assertions on your three most important business invariants.
- Week 4 — Install the ritual and the baseline. Start the random walk-through in design review, and measure mean time to comprehension now so you have a number to compare against in a quarter.
The Part Nobody Wants to Hear
Vibe coding is not a phase and it is not going to be regulated out of existence internally. Your engineers are using it right now, the productivity gain is real, and any policy built on prohibition will simply be routed around — quietly, by good people, under deadline pressure. That is not a discipline failure. It is what happens when a policy makes people slower at their actual job.
But the enterprises that will still be able to change their software in three years are not the ones that generated the most code. They are the ones that stayed able to understand it. Comprehension is the scarce resource now — not typing speed, not commit volume, not story points. Everything in this playbook is ultimately in service of protecting it.
The good news is that none of this is expensive or slow. Six layers, four weeks, and one uncomfortable conversation about which 5% of your system a human still has to own. The organisations that have that conversation now will be shipping just as fast in two years. The ones that postpone it will spend those two years explaining incidents in code nobody wrote.
Michele's Take
If you take one thing from this: the goal is not to slow AI down. It is to make speed survivable. Guardrails are not the tax you pay for using AI — they are the reason you get to keep using it aggressively without a quarterly incident review. Tier your codebase, protect the 5%, and let your team fly through the rest.