Blog Posts
On Vibe Forks
LLM code generation enthusiasts are pushing the boundaries of what’s feasible with vibe coding. What started as ghost-text line completion moved to function generation, then to file completion, and now we’re all pushing for whole-project generation. These advances have made a new phenomenon possible: vibe forking. I define a vibe fork as a reimplementation or forked extension of an existing project using vibe coding.
It’s a deliberately broad definition. At one end it covers the startups and incumbents forking VS Code to compete for the coveted AI-IDE crown. At the other, it covers solo developers prompting their way to glory, recreating existing software from scratch in a clean-room environment. However, for the purpose of this post, I will focus on the latter.
It is worth taking a moment to consider how impressive this is before we add it to the pile of bazillion other amazing things that AI can do. A hundred thousand lines, three architectures, a booting kernel, a 99% pass rate on the GCC torture suite, and it even compiles DOOM. This is not a toy. Neither is it a drop-in replacement of the C compilers for production-ready use cases. This is somewhere in the uncanny valley. The dizzying pace of the advancement of LLM code generation capabilities and the whiplash among developers in terms of their changing role in this new reality forms a fertile ground for wildly varying and imaginative extrapolation of the future: some utopian, some dystopian.
When anyone with a decent token budget can vibe code a clean-room implementation of the software that folks put years of their life into, it is only natural for builders and maintainers to worry.1 The strongest version of the worry is real, and I’ll grant it up front: if the cost of reimplementation collapses toward zero, then any project whose only moat was its source code is genuinely exposed. But I feel, while the source code is a necessary condition for a project’s success, it is not a sufficient one. The sucess of software is a function of many factors. Here is my thinking on why I am not yet concerned about vibe forks.
In scarcity, features matter; in abundance, curation matters. Today developers are empowered to prompt their way to glory. And when anyone can prompt a C compiler or a PTY implementation or a toy OS to existence, the artifact stops being the scarce thing. Judgment about the artifact becomes scarce: which of the thousand generated compilers is correct, is maintained, is safe to depend on? Answering that is itself labor, and it doesn’t fall out of a model. Rather it accrues as reputation, over time.
The app stores are a great lens to look at this. Cloning cost there is already near zero and the barrier to listing is low, so the stores are flooded with clones. A hundred habit trackers, a thousand flashlight apps. The clones exist. They just don’t seem to go the distance. What drives the winner in a category from the mountain of clones is never the feature list. It’s the discovery (the editorial featuring, the reviews, the ranking, the brand, the trust) that separates genuinely useful apps from the pile of clones.
Trust and real deployment are the moat, and feature parity is not enough to get past. A drop-in replacement carries a real, hard-to-quantify switching cost. If it ain’t broke, you don’t fix it. You certainly don’t swap a battle-tested dependency for a freshly minted clone that does the same thing. People do switch, but only when the new thing is not equivalent but better by a wide margin. Look at the AI-IDE forks: nobody abandoned VS Code because someone shipped a pixel-identical copy; they moved for Cursor and Windsurf because the AI integration was a genuine step-change. Parity doesn’t move anyone. Slope does.
And the very property that makes vibe forking possible works against it here. A widely deployed software has been pulled into the training data and into context windows many times over; the model is good at it precisely because the world has already hit its corner cases and written them down. Zero history of a freshly minted vibe-fork may result in varying mileage of LLM-based coding depending on how far the APIs have deviated from the original project. The LLM is, in a real sense, better at maintaining the incumbent than at sustaining its replacement. The same way Carlini’s compiler leaned on GCC to get over the line.
Support is a long-tailed, deeply human task. Agentic greenfield projects can go swimmingly, but brownfield work is where real perseverance is tested. Every project carries essential and accidental complexity, and much of software engineering is the slow work of reducing the accidental part over time. If your program uses only a narrow slice of C, a custom compiler clone may look attractive. The harder question is whether you are willing to maintain that personalized artifact for the full life of the system. Anyone can prompt a prototype in an afternoon. Sustaining it through years of issue triage is still unproven and very debatable.
Finally, if everyone is going to set tokens ablaze, a little organization about where we burn them goes a long way. There is little glory in n people pushing their models to the same solution and comparing who got the answer fastest. There is real progress in n people solving n distinct problems in service of one larger goal. These are two extremes and reality sits somewhere in between, but the incentives mostly push away from the wasteful end: economic pressure and plain human pride rarely permit a thousand identical forks to all survive. Ask how many vibe-forks of C compilers are currently out there and how many of them you have actually used.
Footnotes
-
Some of these are reminiscent of the “recent” licensing wars: the fights that went mainstream when hyperscalers operationalized OSS as cloud services and developers fought back with more restrictive licenses. The outcome of that bloody, tooth-and-nail battle is still debatable. For instance, RedMonk’s analysis found no meaningful change in financial outcomes from the relicensing. And here is the thing worth remembering before we panic about vibe forks: copyleft was, at bottom, a copyright defense; it governed linking and distribution. The clean-room vibe fork reproduces behavior without copying expression, and walks straight around that defense. That is the genuinely new and unsettling property. But the licensing wars already taught us something deflating: even the defenders who had the copyright weapon and used it saw the revenue needle barely move. The wall everyone is now afraid of losing turns out, on inspection, to have been fairly short all along. ↩