This week Meta released Muse Code, a terminal-based coding agent built on its Muse Spark 1.2 model, putting it in direct competition with Anthropic's Claude Code, OpenAI's Codex, and Cursor. The pitch, in Mark Zuckerberg's own words, is that it takes on "complete software engineering tasks across large repos: planning changes, writing code, validating the results." The detail worth sitting with is how it handles big jobs: "When a job is big enough, it fans out to separate sub-agents working in parallel in isolated worktrees. Your working copy is never touched." Zuckerberg claimed a test run had it "build six features for a game simultaneously with no collisions" — a vendor claim, not an independently verified benchmark, so treat the specific number skeptically. The pattern behind it is real, though: this is now the standard pitch across the industry, not a Meta-only feature.

Which means the differentiator between these tools is shrinking fast. Plan, code, validate, parallelize — every major lab is converging on the same four-step loop. If you're building a career around "I'm good at getting an agent to do the work," that skill is being commoditized in real time by the vendors themselves. The thing that isn't being commoditized, and that none of these launches actually solve, is what happens after the fan-out: someone still has to decide whether six pieces of code written in parallel, by six sub-agents that couldn't see each other's work, are each correct and collectively coherent.

Isolated worktrees solve a merge-conflict problem, not a correctness problem

Running sub-agents in separate worktrees is a real engineering improvement — it stops one agent from clobbering another's edits. But it also means the agents building those six features had zero visibility into each other's decisions while they worked. If two of them independently added a similar helper function, introduced slightly different validation logic for the same input, or made incompatible assumptions about a shared data shape, isolation doesn't catch that — it defers the collision from "merge conflict" to "integration bug that ships." That's a structurally different failure mode than the one these tools were designed to prevent, and it's the one a human now has to catch.

This is worth being precise about, because it's easy to conflate "the agent validated its own output" with "the output is validated." An agent checking that its code compiles and passes the tests it wrote is not the same as a reviewer asking whether six parallel changes are consistent with each other and with the rest of the codebase. Those are different jobs, and only one of them is what these harnesses are actually selling.

The skill that's actually getting scarce

If you work in or around software — engineer, PM, QA, technical support, even a non-engineer now shipping small tools with these agents — the practical implication is that "reviewing multi-file, multi-agent output for consistency" is turning into its own discipline, distinct from writing code and distinct from prompting an agent well. A few concrete pieces of it:

  • Trust calibration. Knowing, before you read a line, which kind of change needs a careful pass (anything touching shared state, an API contract, or something more than one sub-agent might have also touched) versus which kind is safe to skim.
  • Cross-diff reading. When a task fans out into parallel work, the review unit isn't one diff — it's the set of diffs together. That means deliberately checking for duplicated logic, diverging behavior on the same input, and inconsistent naming or assumptions across the pieces, not just reading each file in isolation.
  • Spec-writing for an unsupervised executor. The upstream fix for collision risk is a task description precise enough that parallel agents don't need to coordinate because their boundaries were drawn correctly in the first place. Writing that kind of spec is closer to a systems-design skill than a prompting skill.

None of this is new in the abstract — code review and interface design have always mattered. What's new is the volume and the blind spot: when one person can trigger six parallel workstreams in an afternoon, the amount of cross-cutting review needed scales with that, but the tooling to make cross-cutting review easy hasn't caught up to the tooling that makes parallel generation easy.

What to actually do about it this month

If your team is piloting one of these harnesses — Muse Code, Claude Code, Codex, or a competitor — a few low-cost moves are worth making now, before habits calcify:

  • When you review agent-generated work, explicitly ask "did anything else in this task touch the same file, function, or shared type?" before approving — most review checklists don't prompt for this because they were written for single-author diffs.
  • If your team doesn't have a written spec format for handing tasks to an agent, volunteer to draft one. The person who owns "how we brief the agent" ends up with outsized influence over how much review debt the team accumulates later.
  • Stay conversant in more than one of these harnesses rather than betting your fluency on whichever one your current employer picked. They behave differently enough — in worktree handling, in how aggressively they parallelize, in what they surface for review — that switching cold later costs real time.

The headline from this launch cycle will be about which lab's agent is fastest or cheapest. The more durable career signal is quieter: the companies shipping these tools are all explicitly optimizing for more code, generated faster, in parallel. They are not, so far, shipping a correspondingly better way to check that code for consistency. That gap is where the next round of hiring demand is going to show up, and it will show up as a review and systems-thinking skill, not a prompting skill.