The graveyard of vibe-coded projects: why they never ship

The AI wrote the code, the demo ran, the repo went public. Then nothing. Here is where vibe-coded projects actually die, with numbers you can check, and a one-week plan to carry one of yours to real people.

Published August 11, 2026 · By Dmitry Tolstoi · 9 min read

GitHub gained about 121 million new repositories in a single year, by GitHub's own count. Walk through the fresh ones and you keep passing the same grave: a clever weekend app, a README full of screenshots, four stars, a last commit from three months ago. Someone described a product to an AI, watched a working demo appear, published the repo, and stopped.

I run a content operation alone, with AI doing most of the production, so none of this is an anti-AI speech. Building really did get cheap. That is exactly why the graveyard grows. The hard part moved, and most builders are still fighting the old one, the one that no longer needs them.

Below I walk the rows one by one: what kills a project at each stage, the numbers behind each cause of death, and what the few that ship do differently.

The warning was in the original tweet

In short: the man who named vibe coding fenced it to throwaway weekend projects in the same post, and the graveyard is what lies past the fence.

Andrej Karpathy coined the term vibe coding in February 2025: a way of building where you "fully give in to the vibes" and "forget that the code even exists". You accept every change without reading it, paste error messages back until they stop, and let the code grow, in his words, "beyond my usual comprehension". The same post carries the fence: "It's not too bad for throwaway weekend projects."

The fence got trampled within weeks. People took a technique named for toys and pointed it at products with users, payments and private data. Karpathy himself, releasing his next serious project that October, said it was basically entirely hand-written, because coding agents were "net unhelpful" for the job. The inventor kept to his own fence. The graveyard is what grew on the far side of it.

Why do vibe-coded projects fail?

In short: they die in the gap between demo and product, and that gap has three walls: the unfinished last third, distribution, and focus.

Both sides of the loud argument are right, about different phases. The vendors are right about the demo phase: a quarter of Y Combinator's Winter 2025 batch had codebases that were about 95 percent AI-generated, and those companies exist. The sceptics are right about the product phase. In Stack Overflow's 2025 survey, just over 72 percent of the developers surveyed said vibe coding is no part of their professional work.

A vibe-coded project dies in the space between those two phases. The demo is real, the product never arrives. The distance between them splits into three walls: the last third of the build, which the AI does badly; the distribution work, which nobody automated; and the discipline of staying with one idea, which got harder as starting got cheaper.

The last third of the build is the actual product

In short: AI hands you the easy seventy percent in a weekend; the remaining thirty percent is the part users actually pay for.

Addy Osmani calls it the 70 percent problem: AI produces most of a solution astonishingly fast, and the rest, the edge cases and the production plumbing, stays as hard as it ever was. A demo shows the path where everything goes right. A product is mostly the other paths: the email field that gets an emoji, the payment clicked twice, the connection that drops mid-save.

The tooling will not tell you that you have crossed into that territory. In Stack Overflow's 2025 survey, 66 percent of developers named "almost right, but not quite" answers as their top frustration, and 45 percent said debugging AI-generated code takes more time. A controlled study by METR found experienced developers were 19 percent slower with AI on real tasks while believing they were 20 percent faster. The gap between feeling done and being done is exactly where demos go to die. I wrote about the visible half of this in the piece on why $1 AI websites look generated: a template has one appearance, a product has six.

The codebase outgrows the person who prompted it

In short: a few thousand lines nobody has read turn every new feature into two new bugs, and the only fix left is another prompt.

Karpathy's line about code growing beyond comprehension is funny in a toy and terminal in a product. Once nobody on the team, which is you, can read the codebase, every change is a gamble. You ask the model for a fix, it rewrites something it half-remembers, two other screens break, and the only tool you have left is asking again.

The pattern shows up at population scale. GitClear analysed 211 million changed lines of code and found that 2024 was the first year on record where copy-pasted code exceeded refactored code: duplicated blocks piling up faster than anyone cleans them out. Mo Bitar, a developer who spent two years all-in on this workflow, described opening his own vibe-coded codebase plainly: "It was pure, unadulterated slop. I was bewildered." He went back to writing by hand.

What breaks when you ship it anyway?

In short: unreviewed code takes API keys, paywalls and user data public, and the internet finds the gaps within days.

In March 2025 a non-technical founder known as Leo spent a week telling X how cheap it had become to run a SaaS built with Cursor, an AI coding editor. Days later he posted: "guys, i'm under attack." Strangers had maxed out his API keys, walked past his paywall, and written junk into his database. The keys had shipped inside the app's public code, where anyone could read them, and the paywall was checked on the user's machine.

The write-ups of Leo's "under attack" week were unkind, but the pattern is ordinary: Veracode ran 80 coding tasks across more than a hundred models and found that 45 percent of the AI-written solutions introduced security vulnerabilities.

Simon Willison, one of the calmest voices on this subject, keeps a simple rule for true vibe coding: keep the stakes low, and think about how much harm the code could cause if it has bugs. A product that stores strangers' data or takes their money is never low stakes. Ship it unread and you are hosting a bug bounty with no prize pool.

Distribution is the biggest wing of the graveyard

In short: most dead projects had working code and died unseen, because nobody built the path from stranger to user.

CB Insights keeps post-mortems of 431 venture-backed companies that shut down since 2023: 70 percent ran out of money, 43 percent named poor product-market fit. Broken code barely registers as a cause of death. Scale that down to solo projects and the picture is starker, because a solo builder has no runway to burn through: the repo simply goes quiet.

I measured a version of this on my own accounts. Two posts on the same profile, view counts orders of magnitude apart, and neither moved the product an inch, because neither gave a single viewer a road from the post to the thing I sell. Stars on a repo are views. A product needs a path, and building the path from content to product is its own system, work the AI did not do for you. A product nobody can find does not exist.

The twentieth repo, or abandonment dressed as progress

In short: when a new project costs one evening, leaving the current one costs nothing, and that maths fills graveyards faster than any bug.

Indie Hackers threads about dead products reach the same verdict again and again: projects die because their builders walked away far too early, usually toward a fresher idea. Vibe coding made that exit cheaper than it has ever been. When repo number seven costs one evening, finishing repo number six feels like a chore you are allowed to skip.

I will not pretend to watch this from a distance. My own drafts folder holds features finished to the last key that never met a user, and the only honest word for them is inventory. AI automated the start. Nobody automated the months after, and those months are where the money is.

What the projects that ship do differently

In short: survivors keep a review step, cut scope to one path a stranger can finish, and treat distribution as part of the build.

Google says more than a quarter of its new code is AI-generated, and the sentence continues: "then reviewed and accepted by engineers." That second clause is the entire difference between AI-assisted engineering and the graveyard. Simon Willison draws the same line from the other side: if you reviewed it, tested it and can explain how it works, "that's not vibe coding, it's software development."

For a solo builder the survivors' playbook is short. Read what ships, or pay for one review from someone who can, at least for anything touching money or data. Cut scope until one stranger can complete one path without you in the room. Pick one project and archive the rest, because archived is honest.

And build the path to users alongside the product, with the same seriousness. I keep a whole playbook on being the verification gate for AI output, and its core carries over unchanged: generation got cheap, judgment did not.

A one-week plan to carry one project to real people

In short: pick one repo, walk it as a stranger, finish the boring parts of a single path, lock the secrets, then show it to ten people.

This is the plan I would run on any half-dead repo worth saving. It fits in a week of evenings.

1. Day one, choose. Pick the one project with a real pain behind it and archive every other repo. The graveyard shrinks the moment you stop pretending you will come back.
2. Day two, walk it as a stranger. One path, from landing to result, on a phone, logged out. Write down every place it breaks or confuses. That list is your real backlog.
3. Days three and four, finish the boring third. Real error messages, empty states, the login and payment flow if you have one. For anything touching money or data, read the changes or have them reviewed. This is where the 70 percent problem lives, so expect it to be slow.
4. Day five, lock the doors. Keys out of the public code, paywall checked on your server, backups turned on, experiments in a separate environment. One evening of hygiene against Leo's week under attack.
5. Day six, build one path in. Pick the single channel where your users already spend time and publish something useful there that ends at your product. A naked link in a bio does not count.
6. Day seven, ten strangers. Put the thing in front of ten real people and watch them use it. Fix what actually broke, ignore what you merely fear, and post again.

Where this comes from

I run a content operation as one person with AI on operations: a live product site, a guides section, a channel, all shipped and maintained solo. I also keep my own graveyard of finished features nobody ever used, which is why this piece has no sneer in it. Every number above is public and linked where it appears, and where the example is mine, I say so.