We Ran 11 Coding Agents on One Repo and Lost 3 Days: the Role That Fixes It

The three days were not spent on anything interesting. We had eleven coding agents working through a backlog of small, independent changes on one repository, and we lost most of a working week to agents overwriting each other, to a checkout that took four minutes and was performed eleven times, and to the disk filling up with eleven near-identical copies of the same codebase. Not one of those failures was a model failure. Every one was an infrastructure failure, and on Wednesday a project shipped a 1.0 that treats it as such.

What shipped, precisely

LayerFS 1.0.0 was published at 11:21 UTC on 21 October 2026, described by its authors as the first official release after the 0.1.x developer previews. It is MIT licensed, written in Rust, and the model is stated in one sentence in the release notes: each agent mounts a complete, writable workspace over shared committed history, does its work, commits what it changed, and goes away.

The mechanics that matter for anyone who has hit the problem above:

• A fork is metadata, not a copy. Eleven agents do not mean eleven checkouts of the base. This is the line that removes both the four-minute checkout and the disk pressure.
• Commits are deduplicated checkpoints. Each agent commits only what changed, and identical bytes are stored once. The published deduplication test puts 157 snapshots of a real project at 100.1 MB against 1,994.6 MB for Btrfs with zstd.
• Conflicts are refused, not guessed. Merges work by identity, files with equal bytes are never a conflict, and mode and mtime merge separately so a chmod survives an edit. An actual same-file clash fails rather than silently resolving, which is the correct behaviour when the writer is an agent.
• Sandboxes are numbered and self-closing. A workspace mounts into an existing sandbox, a new one starts once the running ones each hold 16 workspaces, and each closes itself after two idle minutes.
• There is a platform constraint. Store calls now run in your process, which requires Linux with the store on ext4, xfs or btrfs. Elsewhere those calls fail as unsupported, with macOS available through the DeepSeek Harness route.

The benchmark numbers, read honestly

The release publishes results, and they deserve both attention and scepticism. The notes state that each suite ran once, on a named commit, through the JavaScript SDK. One run means no variance, and a project publishing its own benchmarks also chooses the comparison. So here is how I would weight them.

The pattern is that the correctness claims are stronger than the speed claims, which is unusual and mildly reassuring. A project optimising for a launch narrative leads with throughput. Leading with conformance against kernel overlayfs and with data-integrity suites is the behaviour of people who expect to be audited. It is also a useful lens for the hiring question below, because reading a benchmark table this way is precisely the skill you are trying to recruit.

The role Singapore teams have not hired

When our eleven-agent week went badly, the instinct in the room was to hire another AI engineer. That would have been the wrong hire, and it took me an embarrassingly long time to see why. Nobody on the team was short of model knowledge. What we lacked was somebody who owned the environment agents execute in: how a workspace is created and destroyed, where the disk comes from, what happens when two writers touch one file, and what the blast radius is when an agent does something stupid at two in the morning.

That is a platform engineer with container, filesystem and isolation experience. The adjacency to work your team already understands is close, which is good news for sourcing: it is the same instinct that makes somebody good at build infrastructure and multi-tenant isolation. Our method for hiring Kubernetes platform engineers in Singapore is the nearest existing playbook, and the signals overlap by about two thirds.

The one interview question that separates candidates

Ask this: Eleven agents need to work on one repository at the same time. Design it. What breaks first?

Strong candidates go almost immediately to isolation and to the write path. They ask whether the agents touch overlapping files, what the conflict policy should be, whether the base is read-only, and how much disk eleven copies would cost before deciding not to make eleven copies. The best ones ask what happens to a workspace when an agent crashes halfway through, because that is the question that separates people who have run this from people who have read about it.

Weaker candidates reach for orchestration first, describing a queue and a scheduler without addressing what each worker writes to. A queue is the easy half. Several will also propose giving each agent its own virtual machine, which works and is why the question is useful: ask them to cost it at eleven agents and then at fifty, and see whether they notice the problem themselves.

What to do this week, in order

Adoption is not urgent. The release is days old, reception in the community has been mixed with a fair amount of pointing at prior art in overlay filesystems, and the durability caveat means it has a specific place rather than a general one. The staffing question is the part that does not wait. In order:

1. Count your parallel agents honestly. Not the licences, the number that execute against a shared repository in the same hour. If that number is one, you do not have this problem and should stop reading. If it is above five, you have it already whether or not anyone has named it.
2. Find out who owns the execution environment today. In most teams the honest answer is a senior engineer doing it informally alongside their real job. That is the gap, and it is cheaper to name it now than after the next lost week.
3. Measure the waste before you buy anything. Checkout time multiplied by agent runs per week, plus disk, plus the hours lost to collisions. Ours came to roughly three days in a week, which is what made the case. Our guide to engineering productivity metrics covers how to capture this without inventing a new dashboard.
4. Trial on throwaway work first. Run the integrity suites yourself rather than trusting a single-run table, and point the agents at a repository you could lose.
5. Only then decide between a hire and a project. Sometimes the answer is a week of platform work by the team you have. Our notes on building an AI-first engineering team cover how this role sits alongside the rest, and if you are also assessing agent-related skills in interviews, evaluating agent debugging ability is the complementary screen.

Frequently asked questions

What did LayerFS 1.0.0 actually ship on 21 October 2026?

It was published at 11:21 UTC as the first official release after the 0.1.x developer previews: an MIT-licensed filesystem in Rust from Ephemeral-AI-Lab. Each agent mounts a complete, writable workspace over shared committed history, commits what it changed as deduplicated checkpoints, and goes away. The 1.0 moved store calls into the calling process, replaced the older sandbox create and mount API with a workspace API over numbered sandboxes, and improved merges so identical bytes are never a conflict and a mode change survives an edit. The headline property is that forking a workspace is metadata rather than a copy.

Are the published benchmark numbers trustworthy?

They are the project’s own, each suite ran once, on a named commit, through the JavaScript SDK. One run gives no variance and a vendor chooses its comparison, so treat the speed figures as directional. The correctness results are the interesting part: zero unexpected failures on pjdfstest against kernel overlayfs, and 14 of 14 integrity passes with 3,755 of 3,755 entries identical after commit and remount. Those are falsifiable and easy to re-run, which is exactly what you should do in a trial.

Does LayerFS run on macOS, and does that matter for hiring?

Partly, and yes. Store calls running directly in your process require Linux with the store on ext4, xfs or btrfs and fail as unsupported elsewhere; the repository lists macOS via the DeepSeek Harness route. For a Singapore team that means the familiar split between Linux production and Apple laptops, and somebody has to own the gap. A tool whose capabilities differ by host filesystem is an infrastructure component, and infrastructure components need an owner rather than a volunteer.

Should we adopt this now or wait?

Wait on adoption, act on staffing. The release is days old, and the repository warns the store runs in a disposable profile with no crash or power-loss durability, so it must not hold the only copy of data you cannot rebuild. Community reaction has been mixed, with plenty of prior-art comparisons. But if you run coding agents in parallel against one repository today, you already have the problem, and you will solve it with this, a competitor, or something in-house. Who owns agent execution environments is the decision that cannot wait.

Sources: LayerFS v1.0.0 release notes and the LayerFS documentation. All benchmark figures quoted are the project’s own published results. Figures for our own eleven-agent week are from our internal delivery record of October 2026.