Beads (bd) vs Cursor 2.0

“The primitive here is clean: a dependency-aware DAG of tasks, stored as versioned JSONL inside your repo, with hash-based IDs that make merge collisions structurally impossible rather than a discipline problem. The DX bet — put the complexity in the data model, not the CLI — is exactly the right call, and `bd claim` for atomic task assignment is the kind of thing you only design if you've actually run two agents into each other and watched them both pull the same file. The weekend alternative here is a markdown TODO in a git repo, and it collapses the moment you have two agents or a branch switch; Beads earns its existence specifically because the naive solution fails in a documented and predictable way.”

“The primitive here is a persistent, headless coding agent that operates on your repo as a subprocess while your main editor session stays hot — that's meaningfully different from tab-completion or inline chat, and it's the right DX bet. Background tasks offload the complexity to a task queue you can inspect, which means you're not blocked waiting for a 40-file refactor to finish. The diff review interface is where this earns it: if the agent's output is a black box you approve or reject wholesale, you're just rubber-stamping; but if the diff surface lets you selectively accept hunks with the same granularity as a git patch, Cursor has done the hard design work that most agent tools skip entirely.”

“Direct competitor is Linear or GitHub Issues used as agent context via MCP — and the reason Beads wins that comparison is that those tools were designed for humans and bolt agent support on top, while Beads is designed for the case where the agent *is* the primary user and humans are secondary readers. The scenario where Beads breaks is a solo developer running a single-agent workflow on a small project, where the overhead of a Dolt-backed graph is pure ceremony for a problem that a flat task list already solves. What kills it in 12 months: Anthropic or the Claude Code team ships a native persistent task graph in the agent runtime itself, making Beads infrastructure that got absorbed — but that's a win condition for users, not a failure condition for the idea.”

“The direct competitor is GitHub Copilot Workspace, which ships from Microsoft with a distribution moat Cursor cannot match — but Cursor is iterating noticeably faster and the product is genuinely better to use today. The scenario where this breaks is a real monorepo with 800k lines, inconsistent naming conventions, and no test coverage: background agents confidently produce green CI on a branch that silently broke behavior because they optimized for the tests that existed, not the ones that should. What kills this in 12 months isn't a competitor — it's that OpenAI or Anthropic ships a coding agent native to their own IDE-adjacent surface and Cursor's model-agnostic positioning becomes a liability instead of a strength.”

“The thesis here is falsifiable: within 3 years, multi-agent software development becomes the default mode, and the binding constraint on parallelism shifts from compute to coordination — specifically, agents colliding on tasks, losing context at session boundaries, and producing incoherent work when they can't see each other's progress. Beads bets on this and solves exactly the coordination layer, not the intelligence layer, which is the right abstraction boundary to defend. The second-order effect that matters: if Beads or something like it becomes standard infrastructure, it shifts the locus of software project state from human-readable GitHub Issues into a machine-first graph format, which subtly transfers project legibility from PMs and engineers to the agents themselves — and that's a much larger change than the tool's README suggests.”

“The thesis Cursor is betting on: within 3 years, the primary unit of developer work shifts from writing code to reviewing and directing agent-generated code, making the diff interface more strategically important than the autocomplete surface. That's a falsifiable claim and the background agent feature is the first serious implementation of it in a shipping editor. The second-order effect is subtler — if background agents normalize async coding workflows, the concept of a 'blocked developer' disappears, which restructures how engineering teams size their sprints and parallelize work. Cursor is on-time to the agentic coding trend, not early, but they're building the right layer: the review and direction surface, not just the generation surface.”

“The job-to-be-done is unambiguous: give AI coding agents persistent, collision-safe, dependency-aware task memory that survives the boundaries a scratchpad cannot. That's one job, stated without an 'and,' and Beads does not wander from it. The completeness test is where it earns real points — embedded mode means a solo developer can `brew install bd` and have a working agent memory layer without running a server, while server mode handles the multi-agent case without requiring a different mental model; you don't have to keep the old solution around for any part of the workflow. The one gap: onboarding assumes you already know what a Dolt-backed JSONL task graph is and why you want one, which means developers who haven't already felt the pain of agent context loss will bounce before they reach the moment of value.”

“The job-to-be-done is clear and singular: let me keep coding while the agent handles the parallel task I just described — no context switching, no waiting. Onboarding to the background agent feature is where I'd probe hardest; if the first-time experience requires the user to configure a task queue or understand agent primitives before seeing a result, that's a product gap dressed up as a power-user feature. The opinion baked into this product — that review-driven workflows are better than approve-or-reject workflows — is the right one, and the diff interface signals the team actually thought through the editing loop rather than shipping generation and calling it done.”