On Vibe Forks

Blog Posts<br>On Vibe Forks<br>2026-06-29

People Management in the Age of AI<br>2026-05-14

Coding on a Phone: What I Learned Building Software on Mobile in the Last Three Weeks<br>2026-01-14

Autopilot, Copilot, and Software Developers<br>2025-10-12

Degrees are merely proof of the money you've spent on a course...<br>2025-06-25

The AI Remote Has Arrived: Let Go of the Knob<br>2025-05-27

Developer Tooling in the age of LLM<br>2024-07-03

Developer Agents & The Future of Software Development<br>2024-03-09

Team Values<br>2021-08-16

J.A.R.V.I.S. for Developers<br>2018-03-09

Screens, Windows, Distractions, Focus, and Work"<br>2017-04-15

'Mini-Servers' for 'Micro-Services'<br>2017-03-31

A few Billion Lines of code Later: Using Static Analysis to Find Bugs in the Real World<br>2016-04-18

API Mapping using Text Mining<br>2015-10-10

Tricorder: Building a Program Analysis Ecosystem<br>2015-09-30

When, How, and Why Developers (Do Not) Test in Their IDEs<br>2015-09-23

Hello World!<br>2015-09-21

On Vibe Forks<br>2026-06-29

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.

As an example of the latter, Nicholas Carlini at Anthropic set sixteen Claude agents loose on a shared repo to build a C compiler from scratch: over nearly 2,000 Claude Code sessions and $20,000 in API costs, the agent team produced a 100,000-line compiler that can build Linux 6.9 on x86, ARM, and RISC-V.

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...