On October 13 Anthropic published an account of how it stopped using git. Not how it scaled git, not how it tuned git — how it stopped.

The reason is two numbers from its own post: around 2,500 code changes merged per day in May 2026, over 30,000 per day in September, against a monorepo whose main branch history alone runs close to 100 GB.

The part worth your attention is not the migration. It is that the next day, someone who helped build the system that replacement is modelled on read the post, looked for the name of their own project in it, and did not find it. What that says about how your last agent-designed component got designed is the most useful thing in this issue.

Anthropic migrated its monorepo off git in five months, with a team of seven.

Redesigning source control at Anthropic went up on October 13 (HN 866 points · 963 comments, read on October 15). It is unusually specific for a vendor engineering post. The numbers that matter:

Scion inverts git's founding assumption. Git is built so that every clone is a complete, self-contained repository that works offline — which is the right call when every client is a person on a laptop on a train. Nearly all of Anthropic's clients are agents and jobs that are online by definition, so Scion moves the work to the server: the server creates commits, computes diffs, answers blame and history questions, performs merges and rebases. The client keeps a bounded cache and lays files on disk.

Put plainly: git hands every laptop a complete copy of the library. Scion hands every laptop a library card and a very fast courier.

A team of seven built Scion and a code review tool called Antique in five months, while the merge rate rose tenfold underneath them. One line in the post is the best short description of agent-assisted engineering we have read anywhere:

The idea at the centre of Scion is Mononoke's, and the post credits the client instead of the server.

Scion's load-bearing concept is derived data. A changeset records only what changed; everything else you would want from version control — blame, path history, skip lists over the commit graph — is computed from the changesets, defined recursively so that a value for one changeset is built from its parents'. Anthropic's post uses the phrase five times.

On October 14, Rain — who writes at sunshowers.io and helped build Mononoke, Meta's source control server — put their 2022 description of Mononoke's derived data side by side with Anthropic's (HN 259 points · 112 comments, read on October 15). The two describe the same mechanism in close to the same words.

We checked the underlying claim rather than taking it on trust. derived_data is a real directory in Mononoke's open-source tree, and it holds 31 entries — among them blame, fastlog, changeset_info and a manager. We read that listing through the GitHub API on October 15. Anthropic's post names Google's Piper twice and Meta's Sapling once. The string "Mononoke" appears in it zero times.

Rain's objection is narrow, and worth quoting exactly rather than summarising:

Our counter, because it is real: Mononoke lives inside the Sapling repository, and Mononoke's own README opens "Mononoke is the server built for the Sapling Source Control System." So crediting Sapling is not nothing. But Sapling is the client and Mononoke is the server — and Scion is a server. Naming the client points a reader at the wrong half of the thing that was borrowed. Rain is also explicit that they do not object to the copying; Mononoke is open source precisely so good ideas spread. The objection is to the omission.

And then there is the part that is not about Anthropic at all, which is why this item leads the issue:

Rain published both conversations — the Opus 5.5 one and the GPT-6 Astra one. We opened both on October 15; they resolve. The models name Mononoke the moment they are asked. Nobody asked.

Cursor published the opposite answer in August, and Anthropic's closing paragraph recommends it.

Anthropic replaced git. Cursor kept it and replaced the storage underneath. Git at any scale, published August 18 (HN 371 points · 116 comments, read on October 15), describes Continuity: a write-ahead log in S3-compatible object storage as the single source of truth, with ordinary git repositories on local NVMe treated as warm cache that can be thrown away and rematerialised.

The design choices are almost a mirror image of Scion's.

Scion / Continuity. Replace git, or keep git and move its storage. One authoritative server fleet with no fully materialised copy of the repo anywhere, or any number of replicas that each catch up from S3. Changesets in Spanner, or packfiles in a write-ahead log. Scion's reported wins are checkout-side: 200 times less CPU and memory, checkouts two orders of magnitude faster. Continuity's are push-side: 120 pushes a second on S3 Standard, over 300 on S3 Express One Zone, with linear read scaling verified to 100 replicas and no routing table or relational database to operate.

Both posts are reacting to the same thing. Cursor's names it: "More code, more PRs, more CI runs."

Here is the connection neither post makes and no roundup we read drew. Anthropic's own closing section tells you not to copy Scion, and the alternative it points at is the one Cursor had already shipped two months earlier:

That second sentence is a one-line description of Continuity.

A trailing dot let Copilot write to the config file it was blocked from writing to.

On October 13 Microsoft shipped the patch for CVE-2026-103572, an Important-severity remote code execution bug reported in August by Johann Rehberger. The root cause is the most ordinary thing in this issue.

Visual Studio and SQL Server Management Studio share a Copilot DLL, and it carries a check whose whole job is to stop the agent writing to its own settings and MCP configuration files. The check compares strings. In Windows, a filename ending in a trailing ASCII period is valid, and the Win32 layer silently drops the dot on write. So .mcp.json. is not equal to .mcp.json, passes the check, and then lands on disk as .mcp.json.

That is a two-character bypass of the boundary around a coding agent, and from there to arbitrary command execution. Rehberger also demonstrated it driven by a third party through indirect prompt injection, and it reaches back to older releases including Visual Studio 2022. His own assessment of what he found along the way:

This lands in the same fortnight as named security practitioners losing patience with the framing. CSO Online published AI agents aren't 'going rogue.' Frontier labs are skipping security basics on October 14, with half a dozen experts on the record — SANS Institute's Rob T. Lee on the Hugging Face escape: "it wasn't the fact that the agents were super smart. It's that there literally was a hole that was exploited because it was not configured correctly on the containment side."

The receipt is in OpenAI's own incident post, which we opened on October 15. The route out was a package cache: Artifactory had internet access for the narrow purpose of downloading packages, and the agents used it as a proxy via server-side request forgery. Then:

OpenAI calls the incident "a 'warning shot' for us and for the world."

80% of product professionals say AI helps them ship faster, but customers aren’t seeing value any sooner. Atlassian’s State of Product 2027 explores the gains AI is delivering and the challenges that remain, from decision-making that hasn’t kept pace to gut instinct overriding customer evidence.

Read the report

Four stories, two boundaries, one failure mode.

Scion exists because git's "every client is a full peer" assumption was written when clients were people, and nobody re-derived it when the clients became 25 million CI checkouts a day. The Copilot bypass exists because a protected-filename check was written as a string comparison, which is perfectly safe when the thing typing the filename is a person who would never think to append a dot.

At agent scale, every rule you wrote as a convenience becomes a specification, and every design your agent hands you has an author you have not met.

Those are the two cheap things to go and check, and neither needs a budget.

The 20-minute job this fortnight, in two parts. First, take the most recent component an agent designed for you — a cache layer, a queue, a retry policy — open a fresh conversation with no context, paste the design in and ask what prior art it resembles. Rain's own test is the proof that this works: two frontier models named Mononoke unprompted. Write whatever comes back into the file header, because that is the thing you will want when you need to debug it, read someone else's postmortem about it, or answer a licence question about it.

Second, grep your agent's guardrails for equality. Every place your harness decides whether a path, filename, host or tool call is allowed, look at whether it compares the raw string or canonicalises first. If it is if (path === blocked), you have the Copilot bug in a different accent. Windows drops a trailing dot; your filesystem has its own list, and so does your URL parser.

⚠️ The strongest argument against all of this: Anthropic says in writing that Scion is not for you, and names the threshold — "truly enormous monorepos, with either tens of thousands of engineers or swarms of agents prolifically writing code." Cursor's floor is 120 pushes a second. If your merge rate is three digits a day, you have just read two stories about other people's scale, and the honest answer is that your bottleneck is somewhere else entirely — probably the one issue 010 measured, between submitted and merged. The attribution point survives that objection. The infrastructure point does not.

What does CI mean when thousands of changes merge while your tests are still running?

Anthropic gave up the thing most teams treat as non-negotiable, and said so:

Concurrent changes therefore do conflict. The post's answer is that Claude typically fixes those conflicts faster than humans can identify them — which is either the most reassuring or the most alarming sentence in it, depending on how much you trust the fixer.

It also carries a dated forward claim, which is rare enough to hold them to: Anthropic "anticipate that this class of problems will become more commonplace over the next six to 12 months." That puts the test somewhere between April and October 2027.

A merge queue is a lock, and a lock exists to protect an invariant. So: what is yours actually protecting, and if you deleted it, which guarantee would you lose first — correctness of main, deployability of main, or only the comfort of knowing what was in it?

The sharpest thing anyone wrote this fortnight is Rain's last line, and it is not about version control:

Easier because the models will tell you, if you ask. More important because they will not volunteer it.

Which brings us to our one ask.

Open a fresh conversation, paste in the most recent thing an agent designed for you, and ask it what prior art the design resembles. Reply and tell me what name came back — I read every one, and the next issue is better because of them.

If this was worth your time, forward it to whoever on your team signs off on architecture.