A study of 8.1 million pull requests, summarized by Autonoma in its 90-day reckoning writeup, found that technical debt rises 30 to 41 percent after a team adopts AI coding tools. Salesforce Ben is calling 2026 "the year of technical debt". A new service category, "vibe-code cleanup," went from zero shops to dozens in under a year.

That last part is the part founders should pay attention to. The market for fixing AI-generated code is now real, priced, and visible, and the agencies building it are not the agencies who once cleaned up after offshore-dev contracts. They look more like us.

Here is what is happening and, more usefully, what cleanup actually looks like when a vibe-coded app lands on our desk.

The shape of the problem

Jesse Skinner wrote a piece this week called Cleaning up after AI rockstar developers that hits the pattern exactly. The "rockstar developer" archetype, the one who joined the team years ago, rewrote everything in a paradigm only they understood, then left the next engineer to inherit a tangle, has had a quiet upgrade. The new rockstar is a chat window. It writes ten thousand lines an hour. It does not remember what it did yesterday. It is unfailingly confident about code it will never have to maintain.

The damage is not the AI's fault any more than a power tool is at fault when used without a guard. It is just that the speed of generation now outpaces the speed of review by an order of magnitude, and the bottleneck moves downstream. The Autonoma research traces a predictable 90-day arc: velocity feels great in week one, the second sprint adds duplicated logic, and by month three engineers are afraid to touch the file that does billing. An arxiv paper from late 2025 documents the same curve in academic language. Flow, then debt, then a guideline-shaped scramble.

The reason there is now a service category is that small founders cannot wait three months for the curve to flatten. They have customers. The prototype that demoed beautifully needs to survive payroll. So they Google "vibe code cleanup" and find a list of agencies who do exactly that.

What we look for in the first hour

When a project lands at Pixelworx with the words "we built most of this with an AI tool and now it's behaving weirdly in production," we do not start with the bug they reported. We start with three checks that almost always change the scope of the engagement.

The first is environment reproducibility. Can a new developer get the app running locally on a clean machine without surprises. Not a single magic command, just a documented sequence that works the first time, every time. Vibe-coded apps tend to fail this badly. Dependencies got installed inside a chat session and never made it into a manifest. Environment variables exist only in the founder's .env. We have walked into projects where no one alive can get the staging build to start.

The second is what we call the "explain this function" pass. We pick a handful of files at random — the auth middleware, a queue handler, the model that gets edited most — and ask whoever shipped them to walk us through the code. If we hear "the AI wrote it, but it works" more than twice, the engagement is no longer a bug fix. It is a prototype-to-production project, which means a different scope, a different timeline, and a different conversation.

The third is the test suite. Not whether one exists. Whether it tells the truth. Vibe-coded test suites have a particular smell: lots of green checkmarks, very little assertion. Functions that mock the database they are supposed to be testing. End-to-end tests that never actually hit the endpoint. We call these "trust-debt tests," and they are worse than no tests at all, because they make a team confident in code that should worry them.

The cleanup playbook, in the order it has to happen

Cleanup is sequencing more than it is technique. The order matters because each step buys leverage for the next.

We start with an honest map. Before refactoring a line, we read every route, every event listener, every queued job. We write down what the system is supposed to do, in plain sentences, and where each behavior actually lives. Half the cleanup work is just discovering that two features quietly call the same broken helper.

We then write the tests the AI did not. Not full coverage. We pick the five flows that, if they break, the business stops. Login. Payment. The single workflow customers pay for. We write integration tests that hit real services, not mocks. We have written elsewhere about the case for AI in expert hands, and the same logic applies here in reverse. Cleanup without a safety net is just a slower way to break things.

Only then do we refactor. Always from the leaves inward. The helpers no one depends on first, then the modules that depend only on cleaned helpers, then the core. Every change runs against the new tests before it ships. The pattern is unglamorous and slow. It is also why a Pixelworx cleanup tends to come out the other side as a codebase the founder's next hire can read in a week.

The last step is the one most cleanup shops skip. We hand back a written architecture note, three or four pages of plain English, that explains how the system is shaped now, what is intentionally simple, and where the next decision will need to be made. The point is to break the cycle. The whole reason the rockstar problem exists, in both its human and AI versions, is that the next person inherits the artifact without the reasoning.

Where the line really is

There is a healthy version of vibe coding. Used well, AI is a fast and capable collaborator for prototyping, for one-off scripts, for the first cut of a UI. We have written about how AI has reshaped the math of building a software team, and that whole piece sits on the assumption that AI in the loop is good news for the right teams. The line we draw is the same line every careful shop is drawing. AI can help you build the version that proves the idea. It cannot, on its own, build the version that customers depend on.

Founders who treat that line as the moment to call in real engineering tend to ship faster and spend less than founders who keep prompting until production starts paging them at 3am. The cleanup market in 2026 is, in a sense, an expensive education in that distinction. The cheaper move is to not need it.

If you are looking at a prototype and wondering whether it is closer to demo-fragile or production-ready, that is the conversation we are happy to have on our contact page. The answer is usually less dramatic than founders expect, and the path from one to the other is almost always shorter than the rewrite voice in your head is whispering.