The curve every team is now watching
Week one: a small team ships more in a week than they used to ship in a month. Demos in Slack. Product moves on features that had been backlog for a year. The AI tools are a genuine unlock.
Week four: velocity is still high. Maybe higher. The team is shipping features faster than they can write release notes for them.
Week eight: the shape of the codebase is starting to feel odd. There are three different patterns for doing the same thing in different parts of the system. Nobody quite remembers why. Tests are thin. The AI helpfully generated assertions that are mostly "make sure the function runs without throwing."
Week twelve: someone asks to add a feature that touches five parts of the system. The AI tries. The AI fails. A human engineer tries. The human engineer finds that adding the feature breaks a different feature. Fixing that one breaks a third. The team spends more time untangling than shipping.
This is the wall. Multiple teams have now publicly described some version of it. Salesforce Ben predicts 2026 is the year of AI-induced technical debt. InfoWorld calls vibe coding the new gateway to technical debt. Autonoma and others have started calling the month three inflection "the spaghetti point."
It is not a moral failure. It is a predictable consequence of shipping faster than you architect, and it has a shape worth understanding.
Why month three
Three things compound at roughly the same time.
The surface area gets big. In the first weeks, the codebase is small enough that any engineer can hold it in their head. Inconsistencies are obvious. By week twelve, the codebase is two or three times the size. Inconsistencies are subtle, distributed, and hard to see without walking the whole tree.
The test debt catches up. AI-generated code tends to ship with AI-generated tests that are structurally correct but behaviorally shallow. They check that code runs. They do not check that it is right. In week one the tests catch nothing but nothing is broken. In week twelve something is subtly broken in production and the tests did not catch it.
The architectural decisions accumulate. Every shortcut gets taken for good reasons at the time. Inline a config. Duplicate a helper. Stuff a feature flag inside a service that should not know about it. By week twelve the shortcuts form a constellation. Reversing them requires touching everything. Nobody has time to touch everything.
The specific shape varies. The timing is consistent. Teams that ship fast with AI tools and no governance layer hit some version of the wall around three months.
What the wall looks like in production
Some concrete symptoms, in rough order of appearance.
Duplicate implementations of the same concept. Three different date formatters. Two different session handlers. Four different ways to log an event. Each implemented correctly in isolation. None knowing about the others.
Tests that cover syntax, not behavior. Assertions that the function was called with the right arguments, but not that it did the right thing with them. Tests that pass even when the business logic is subtly wrong.
The performance cliff. An endpoint that was fast in testing is slow in production. An import pipeline that worked for sample data OOMs on real data. Each individual component is fine. The composition is not.
The refactor that nobody owns. Someone on the team knows the system needs a big structural cleanup. Nobody has time. Nobody is assigned to it. The debt grows.
The hire that does not ramp. A new engineer joins. They spend their first month confused. The code base looks like five different engineers wrote it in different styles, because in effect it was written by one model in five different moods.
None of these individually is a crisis. Together they are the wall.
The governance layer that prevents it
The fix is not slowing down. Teams that hit the wall do not benefit from pretending vibe coding is a mistake. The productivity gains are real. The fix is adding a thin governance layer that preserves the velocity while preventing the accumulation.
A governance layer that works in practice:
Architecture review on every significant change
A lightweight review, not a heavyweight process. An engineer with context on the whole system spends 15 minutes on every PR that touches a shared concern (auth, data model, shared services). They are not looking for bugs. They are looking for the third implementation of something that already exists twice.
This is not hard to set up. It is hard to stick with when the team is shipping fast. Commit to it anyway.
Tests that check behavior, not syntax
An AI-generated test suite is a starting point, not a destination. For every feature, at least one test that exercises the end-to-end behavior with a realistic input and asserts on a realistic outcome. The AI can write these, but only if you ask specifically. "Write a test" produces shallow tests. "Write a test that verifies the user's refund is issued and their balance is updated" produces useful ones.
The forcing function: PR review that catches shallow tests. Over time the team internalizes it.
Style guides and architectural patterns the AI can read
Modern AI coding tools can be given a style guide, pattern documentation, and architectural constraints. They follow them, if you provide them.
The work is writing the documentation, not enforcing it manually. A well-structured CLAUDE.md, CURSOR.md, or equivalent that encodes how your codebase is supposed to be organized, what patterns to prefer, and what to avoid. Update it as the codebase evolves. Every AI-assisted code generation session reads it and respects it.
This is the single highest-leverage investment most teams are not making. The payoff compounds.
Evals on what matters
For AI-generated code in production, evals are not optional. A nightly or per-deploy run that exercises the important workflows end to end with realistic data. Not unit tests. Integration tests that catch the performance cliff, the subtle behavior regression, the edge case that used to work and now does not.
When the eval fails, you know within hours rather than in a customer report in six weeks.
Periodic architectural refactoring
Scheduled. On the roadmap. A week every quarter dedicated to paying down the duplicate implementations, consolidating patterns, updating the style guide with new conventions the team has settled on. Treated as a first-class engineering deliverable, not an optional cleanup sprint that never happens.
The refactoring itself is a great use of AI tools. The model can find the duplicates, propose unifications, and do the migration. A human reviews the diff. Fast, cheap, effective.
Sane PR size
A PR that touches 40 files and adds 2000 lines is not reviewable. It does not matter whether a human or an AI wrote it. Break it up. One feature per PR. Tests included. The AI can help structure the work; it cannot replace the discipline of keeping changes small.
The teams getting this right
They tend to share a shape.
They treat their AI tools as collaborators that need guardrails, not as magic. They invest in the docs the AI reads. They keep PRs small. They review architectural decisions explicitly. They maintain an eval suite for production-critical behavior. They schedule cleanup.
They are not slower. They ship fast and they keep shipping fast in month six, month twelve, month twenty-four. The curve does not flatten into a wall.
The teams that hit the wall are the teams that skipped the governance layer because it felt slow in week one. It was not slow. It was the difference between a codebase that compounds into an asset and one that compounds into a liability.
The broader point
Vibe coding is not going away. The productivity gains are too real, and the tools keep getting better. Teams that try to forbid it will lose engineers to teams that do not.
But the naïve version, where you let the model generate whatever and ship whatever it generates, is a short-term play that cashes out around month three. Enterprises that want the velocity without the cliff are the ones adding the thin layer of process, evals, docs, and review that makes AI-generated code into something that can be owned and extended.
If you are at month one or month two and this sounds like your team, the cost of adding the governance layer now is a fraction of the cost of untangling the spaghetti later. If you are already at month three and hitting the wall, the move is not to blame the tools. The move is to pay down the debt deliberately, install the governance layer, and resume shipping.
The AI is not the problem. The missing scaffolding is.
Kai Token leads AI engineering at Fraktional. Works on the governance scaffolding that lets teams ship fast with AI tools and keep shipping fast past month three. Believes the boring parts of engineering are what make the exciting parts possible.
