The vibe coder problem

A vibe coder is someone who prompts an AI, accepts the output, ships it, and cannot debug it when it breaks.

In 2025 the term was a meme. By 2026 it is a category of founder problem we get hired to clean up. The pattern is consistent enough that we can predict the diff before we open the repo.

This post is not about whether AI is good at writing code. It is. This post is about what happens when an AI writes the code and there is no developer in the loop to read it, refactor it, throw out the half that does not fit, and add the test that was never asked for.

The shape of the codebase we are called to fix

We have done three "fix the vibe-coded codebase" engagements this quarter. The shape is so consistent that it has become a checklist.

• No domain model. Each feature was prompted in isolation. The user object has one shape in onboarding, another in billing, a third in the admin panel. On staging this is invisible. In production it shows up as the same customer appearing as three customers in three reports.
• No tests, or worse, tests that all pass. Tests generated alongside the code they are supposed to verify. Each test asserts that the code does what the code does. They run green and prove nothing. The first real bug ships through them untouched.
• No deletion. Old code never got removed when new code got added. The codebase is a museum of every direction the founder ever tried. Three auth strategies, two payment integrations, a half-built referral programme abandoned in week six. Every new feature has to pretend the others do not exist.
• One person who "kind of" understands it. Usually the founder. Sometimes a contractor who is now ghosting. The person who shipped the code does not have a mental model of the whole, they have a mental model of the prompts that produced it, which is not the same thing.

Why typing was never the development work

Typing the code was never the development work. It was the visible part, the part that took hours and looked like work. The actual job was always the part that did not photograph well: deciding what to build, how it composes, what to leave out, what to throw away, which 5% of the surface area will hold up under load, where the seams between subsystems should sit, and what to do when two requirements quietly contradict.

When typing was slow, those decisions happened in the gaps between typing. A senior developer would write a function, pause, realise it did not compose with the rest of the system, delete it, and start over. That deletion was the development work. The typing was the byproduct.

In 2026 the typing is fast and the deletion never happens. The AI does not pause. It does not realise. It does not throw out its own output unless you tell it to. If the developer in the loop is also not pausing, not realising, and not throwing out the output, then nobody is.

What we do differently

We are not anti-AI. Every senior developer on the team uses Claude Code, Cursor, or both, every day. The output of a senior developer in 2026 is two to three times what it was in 2024. That multiplier is the entire reason our pricing works. The difference is what happens in the 30 seconds between the AI's suggestion and the merge button.

• Read the diff. Every line. The cost of reading a generated diff is a fraction of the cost of debugging it in production three weeks later.
• Throw out the parts that do not fit. Most AI output is locally correct and globally inconsistent. The senior's job is to enforce the global model.
• Add the test the AI did not think to write. Particularly the test that proves the negative, the request that should fail.
• Delete what is now redundant. The AI almost never deletes. The developer does.
• Read the logs after deploy. Catch the regression before the customer does.

When vibe coding is fine

To be clear about where this stops being a problem: if you are shipping a side project, vibe coding is great. Beautiful, even. The constraint that makes the vibe path expensive is future maintenance by another human. If the future maintainer is nobody, ship away.

If the future maintainer is the rest of your company for the next five years, hire someone who is going to read the diff.

What to do if you are already here

If this post describes your codebase, you have three options.

• Live with it. Plenty of companies have. The tax shows up as slower feature velocity, more support load, and a higher chance that the next senior hire quits in week two.
• Rewrite incrementally. Identify the two or three subsystems that carry the most production load. Refactor those first. Leave the rest for later. This is what we usually recommend.
• Rewrite end-to-end. Only sensible if you are also pivoting the product. Otherwise it is six months of not shipping new things, and most companies cannot afford that.