What vibe coding actually is

In February 2025, Andrej Karpathy — one of the founding team at OpenAI — posted a description of a new way of working with code. He called it vibe coding: you describe what you want, the AI writes it, you barely read it, and you keep going. "I'm not even reading the code," he wrote. "I just see things, say things, run things, and it mostly works."

Within weeks, it had a name, a community, and thousands of people building things they never could have built before. Solo founders shipped MVPs in a weekend. Non-technical operators automated entire workflows. People who had never written a line of code were running live products.

This is genuinely remarkable. It has unlocked a real wave of building. And it has also produced a very specific and increasingly common problem.

"It mostly works" is a very different thing from "it works, and you know why."

What goes wrong — and when

Vibe-coded projects fail in a pattern. The early phase is fast and euphoric. Features appear quickly. The AI rarely says no. Progress feels continuous.

Then something shifts. It's usually one of these:

The code works but nobody knows why The app is live, but no one on the team — including the person who built it — can explain what a given file does or why it was structured that way. Small changes cause unexpected failures elsewhere.
AI-generated AI debt Every new feature was added by prompting the AI, which had no memory of previous prompts. The codebase is full of near-duplicate logic, conflicting patterns, and dead code that nothing references but everyone is afraid to delete.
You've hit a wall the AI can't help with The AI can no longer suggest a fix without breaking something else. Its context window doesn't span the full system. It gives confident, plausible answers that make things worse.
Security holes you didn't know were there AI code generation is optimistic. It rarely adds input validation, rate limiting, or authentication checks unless explicitly prompted. If nobody prompted for them, they probably aren't there.
Something broke in production and you can't diagnose it No error logging. No structured tests. No way to tell what changed or when. The fix could be one line or a complete rewrite — and right now you have no idea which.

These aren't failures of ambition or effort. They're structural. Vibe coding optimises for speed of creation, not durability. The tool you used to build it was never designed to produce maintainable software — and that's fine, until it isn't.

Why asking the AI to fix it usually doesn't work

The instinct is to go back to the same AI tool that built the thing and ask it to fix the problem. Sometimes this works. More often, it makes things worse in ways that take a while to notice.

The AI has no genuine understanding of your system. It reasons about the fragment of code in its context window. When it suggests a fix, it's pattern-matching against similar-looking code it was trained on — not tracing actual execution through your specific architecture.

This produces confident, plausible-looking code that addresses the symptom and misses the cause. You apply it. The immediate error goes away. Three weeks later, something else breaks, downstream, for a reason that traces back to the fix.

There's also a compounding problem. Each AI-assisted patch adds another layer of context the next AI session doesn't have. Over time, the codebase becomes progressively harder for the AI to reason about — and progressively harder for a human to audit, because the AI-generated parts are often structured to look reasonable at a glance while being structurally incoherent underneath.

The codebase becomes progressively harder for the AI to reason about — and harder for a human to audit, because the AI-generated parts look reasonable at a glance while being structurally incoherent underneath.

What the rescue actually looks like

When we come into a vibe-coded project, we're not there to judge how it was built. We've built things the same way. The goal is to understand what exists, stabilise it, and give you back a codebase you can work with.

The first thing we do is read the code — actually read it, end to end. This isn't something AI-assisted coding encourages, so it often hasn't been done since the project started. We map the data flow, identify where the real logic lives versus where it's been duplicated, and look for the structural issues that are causing the problems you're experiencing.

From there, the approach depends on what we find. Sometimes it's a focused stabilisation: add the tests that should have been there, fill the security gaps, document the parts no one understands, and establish a baseline everyone can build from. Sometimes the right move is a targeted rewrite of the parts that are causing the most friction, keeping the things that work. Occasionally, the code is actually fine — the problem is configuration or deployment — and the fix is quick.

We'll always tell you which one it is before we do anything.

Who this is for

If any of these describe your situation, we're the right call:

We've worked with founders, operators, and non-technical teams who built real, working things with AI tools and then needed someone to come in and make them solid. The project being AI-generated doesn't embarrass us and shouldn't embarrass you. It just means the starting point is different.