Beads changed how I think about agentic workflows. The concept is genuinely revolutionary - persistent memory for coding agents that survives context compaction, dependency graphs, task tracking that actually works across sessions.

But the internet is calling it a “virus.” And honestly? I agree with them.

This isn’t a hit piece though. Steve Yegge didn’t deceive anyone. He was brutally upfront about the constraints. I just want to talk about what happens when good ideas meet messy execution, and the question I still can’t answer: when do you walk away?

What Beads Gets Right

The idea is revolutionary. Before Beads, I was losing context constantly. Agent sessions would compact, forget what they were doing, and I’d have to re-explain everything. Beads solved that. It gave agents persistent memory, dependency tracking, a way to pick up where they left off.

Steve’s honesty about it is refreshing. From his Gas Town post:

“I’ve never seen the code, and I never care to… I’ve never looked at Beads either, and it’s 225k lines of Go code that tens of thousands of people are using every day. I just created it in October. If that makes you uncomfortable, get out now.”

That’s vibe coding taken to its logical extreme. And you know what? It shipped. It delivered real value to real people. There’s a whole generation of developers so worried about the next refactor that they miss the point of actually delivering something. Steve delivered.

We need more people willing to be upfront about constraints when building software. It’s refreshing to see someone say “this is how I built it, take it or leave it” instead of pretending everything is production-ready when it isn’t.

The Internet’s Verdict

But the critics aren’t wrong either.

Greg Wedow put it bluntly: “easily the most frustrating piece of software I’ve used in years. Buggy, slow, slopmaxxed to hell.”

And later: “I’ve been using beads since October and every release made it worse. Finally got time to rip it out of my projects over the holidays and all my workflows run so much smoother now.”

Armin Ronacher had a similar experience: “I tried beads and it’s the most invasive shit I have trialed yet. It might be great, but somehow every one of my projects starts having beads in them and I can’t figure out why. Frustrating.”

And then there’s banteg’s detailed breakdown - the “Infection Report”:

Stage 1: Initial Infection. bd init and suddenly you have a .beads/ directory with SQLite, JSONL files, metadata. A beads-hooks/ directory committed to your repo. And your git config’s core.hooksPath is now owned by Beads.

Stage 2: The Daemon Awakens. A background daemon auto-starts. You didn’t ask for it. It’s just there. Watching. Running health checks every 60 seconds. Auto-restart on version mismatch.

Stage 3: Git Hooks Take Over. Pre-commit runs bd sync --flush-only on every commit. Post-checkout auto-imports after branch switches. Pre-push blocks your push if JSON is uncommitted - with an interactive prompt that breaks CI.

Stage 4: The Sync Branch. A hidden beads-sync branch with worktrees that conflict with the daemon.

Stage 5: 29 Migrations. The SQLite schema has been refactored 29 times.

Stage 6: AI Compaction. Calls Claude API to summarize old issues. Requires ANTHROPIC_API_KEY. Irreversibly deletes original content.

“470,000 lines of Go vs mkdir .tickets && vim”

That’s where “the virus” label came from. Harsh. But I get it.

My Story

I hit the config overwrite issue firsthand.

Running bd setup claude tried to overwrite my ~/.claude/settings.json. The tool wanted to inject its configuration into my Claude setup, which sounds reasonable until you realize it was going to blow away my existing config.

Nix saved me. My config files are read-only symlinks pointing to the Nix store. The tool didn’t botch my configuration only because it couldn’t. If I’d been running a normal setup, my Claude config would’ve been toast.

I tried to contribute fixes instead of just complaining. Steve merged them promptly. He’s receptive, not defensive. That matters.

But after looking at the codebase… the debt is deep. The amount of effort it would take me to fix everything that annoys me might exceed rolling my own.

I agree with the critics. But I don’t want to miss the value being generated here.

When Do You Walk Away?

I’d much rather contribute to something than roll my own.

The critical mass principle: if more people use a piece of software, there’s a greater likelihood of it succeeding and sticking. More people benefit. You contribute, others contribute, the ecosystem wins.

Rolling your own puts you on an island. Now you have to maintain it, maybe promote it, and it might feel like you’re throwing shade at the original project - which clearly isn’t the intent. Steve was upfront from day one.

But there’s a threshold where fixing upstream costs more than starting fresh.

Greg hit that threshold. Inspired by Joe Armstrong’s “Minimal Viable Programs”, he built ticket - a single bash script that does git-backed issue tracking. Markdown files with YAML frontmatter in .tickets/. No SQLite to sync. No background daemon. It even has a migrate-beads command.

I have no idea if he’s trying to win or what he wants out of this. Doesn’t matter. He hit a breaking point and built his own thing. That’s a valid answer to the question.

When you hit that threshold, it’s always the same questions: is the architecture sound or fundamentally broken? Is the maintainer receptive? (Steve is.) How much time would fixing take versus starting fresh? Can you live with the parts you can’t fix?

Old-world questions. They assume code is precious - worth understanding, worth fixing, worth investing in.

A vibe-coded world offers a simpler answer: if it’s annoying, regenerate it. If you can’t regenerate it, walk away.

I don’t think that’s right. Architecture matters. Understanding what you’re running matters. But the tools I use full-time today didn’t exist two years ago. How sure can I really be?

Treating code as disposable? I could. Whether I should is the part I’m still working out.

That uncertainty is exactly what got me thinking about all this.

What Remains

Steve deserves credit for shipping and being honest about constraints. The haters aren’t wrong, but neither is he.

Trying to solve a problem in a minimum viable way - even if that way is messy - is valuable. Sometimes you need someone to point the way, even if they can’t take you all the way there.

Extract the learnings, even from software you don’t like. Beads taught me something important about agent workflows. That’s worth something.