On October 13, Anthropic published an engineering post about Scion, an internal system that replaced git for their monorepo. The numbers justify the project on their own: merges grew from about 2,500 per day in May to over 30,000 per day by September, almost all of it model-written code, and “source control became our biggest development bottleneck.” Serving that load through ordinary git semantics would have meant hundreds of petabytes of transfer per day against a 25 GB monorepo. So they moved everything server-side. Commits, merges, rebases, and history queries happen on the server; no machine anywhere holds a full copy of the repository; a commit costs in proportion to the size of the change rather than the size of the repo. They also gave up something the industry treats as load-bearing: there is no global lock on the merge queue anymore, and correctness shifted to post-merge and pre-deploy testing.
That is a real shift worth reading about. Agent-scale development did not just strain the tools we all use, it broke one, and the replacement quietly relocates where correctness gets checked. But that is not why we are writing about Scion this week.
Three days in October
The day after the post went up, an engineer who goes by Rain published a side-by-side reading of it. Rain helped build Mononoke, the source control server Meta developed in Rust and open-sourced. The comparison showed Scion’s design tracking Mononoke’s closely, down to the concept the post presented in some detail: derived data, indexed structures computed recursively from changesets so that operations like blame and diff stay fast without touching the core data model. Anthropic’s original post credited the “hard-won lessons” of Meta’s Sapling. It did not mention Mononoke, the server those lessons actually live in.
Two days later, Anthropic responded on Hacker News and updated the post. It now reads: “Source control for huge monorepos has prior art, notably Google’s Piper and Meta’s Sapling,” and says of Mononoke that it “pioneered many of the techniques we use in Scion, in particular the Bonsai data model.” An editor’s note records the change. Rain acknowledged the added attribution as sufficient.
A two-day correction loop, publicly resolved. What makes it worth a post is one detail in Rain’s write-up that would be easy to skim past.
The detail
Before publishing, Rain asked both Claude and a GPT model about prior art for a design like Scion’s. Both immediately pointed at Mononoke.
Hold that up against how Scion was built. The post is explicit that Claude wrote most of the system, with a small team of engineers steering. The same model family that helped design and build Scion could name, on request, the public project its central ideas resemble. The lineage was retrievable the entire time, at the cost of one prompt, from the tool already in the room. Nobody made asking part of the process.
We do not know what happened inside Anthropic’s writing and review loop, and we are not interested in assigning motives; the correction was fast and the updated post is better. The failure mode, though, generalizes well beyond one company, because it is a failure mode of every team that designs systems with a model in the loop. That includes us.
What a model-proposed design is
When a model proposes an architecture, the proposal is best understood as a read from the commons. Models index heavily on existing designs; Mononoke is open source, documented, and in every recent training set. The stronger and more production-shaped a proposed design looks, the more likely it rhymes with something that already survived production somewhere. And from inside the conversation, “the model invented this” and “the model retrieved and adapted this” are indistinguishable. The output arrives with the same fluency either way, in your house style, with no citation trail, because weights do not carry one.
That last part is the trap. We have written before about checking the provenance of sources before a claim lands in an article, and about walking citation chains backwards. Those checks exist because text arrives dressed in credibility it may not have earned. A model-proposed design has the same property: it arrives dressed as an invention. The difference is that for designs, the provenance check has an unusually convenient oracle. The model that produced the design can usually name its relatives. Rain demonstrated exactly that, with two different vendors’ models, in minutes.
Lineage is not just credit
It would be easy to file this under etiquette. Credit matters, and Rain’s broader point stands: giving credit to those who came before has never been easier, which makes omitting it read worse. But for working engineers, lineage carries something more practical than courtesy.
A named ancestor imports its history. Mononoke has years of production operation behind it, with the failure modes, scaling decisions, and documented trade-offs that implies. The updated Scion post, by naming the Bonsai data model, now tells a reader exactly where to go to understand the idea’s track record and where Scion diverges. The original post could not transfer any of that, because a write-up that does not name its ancestors cannot inherit their lessons. Reviewers lose the baseline question that makes design review cheap: the prior system handled this problem some way, did we diverge deliberately or in ignorance?
The practice we are adopting
The check is one prompt, so we are making it a standard one. When a model hands us an architecture, the follow-up question is: what existing systems is this closest to, and where does it differ? The answer is a lead, not a citation. Models misattribute, so whatever they name gets verified against the named project’s own documentation before it goes in the design doc. But as a discovery step it is absurdly cheap, and the Scion episode shows it works even when the design’s authors skipped it.
Then the lineage goes in the document. Not as a legal disclaimer, as an engineering section: here is the prior art, here is what we took, here is where and why we diverged. Our design docs and our public write-ups both get it, because the two failure costs are so lopsided. Before publication, the check costs a prompt and a paragraph. After publication, it costs a public correction loop on someone else’s timeline, and the correction is the part everyone remembers.
Agent-scale development is going to keep producing systems like Scion, built fast, mostly model-written, genuinely impressive. Every one of them will have ancestors. The models know who they are. The only question is whether we ask before someone else does.