Perhaps I'm dense but I don't see how any of that answers the question "why even have source control?"

I think the answer is that they don't, indeed, need source control but just a way to let their agents resolve editing conflicts. It's basically yet another message board.

> 100GB uncompressed git history on main, 25GB

I might be completely out of context, but why is it only 4x compression? Do they commit a lot of binaries? I just don't understand why would code compress so badly.

I have no special information, but it could just be Amdahl's Law. If one guy (or bot) checked in 5GB of binaries before you thought to enable git-lfs, then that's not a 100/25 ratio, it's a 95/20 ratio. And if it was 10GB, that's a 90/15 ratio, and so on. IIUC, the old un-LFS'ed binaries remain in the history unless you actively `git lfs migrate` and rewrite your whole history, which they might not want (or care enough) to do.

Creating an entirely new version control system and switching to that is supposed to be less disruptive than rewriting history?

> Many parts of the Git distributed version control are the results of good decision made.

For how the Linux Kernel, a highly decentralized, completely open source project, with a single monotonic product, tyrannically lead (a good thing) - is developed.

Permissions, Partial Checkouts, Sub Repos, Vendoring, pub/sub... How many companies bought into git and then had to buy more tooling (like artifactory) because their 3rd party dependency's needed a home. Thats a feature that git does not support because git, as designed, did not need it.

Think about how much better your life would be if every time you typed npm,pip,goget,cargo it fetched THROUGH your repo. If those updates triggered code reviews of whatever changes you're going to consume. You are code reviewing those updates aren't you (someone is, cause supply chain attacks don't last that long)

Git has some weak points, Google doesn't use it for a reason. Epic created lore for a reason, This exists for a reason. Im not sure that any of them are the next thing that replaces GIT but it's getting to be time. Tools like this are going to keep popping up till someone gets it right.

But Piper is a reimplementation of perforce which makes me wonder why they couldn't just license it. Why does it make sense to do this. Perforce should scale to the level they're talking about. Google were using it even when they had many tens of thousands of developers and multiple changesets per second and presumably it got better since then

Before the Piper switchover, Google’s Perforce instance was running on one of the most expensive PCs ever built, with over $1m of DRAM. Its centralized design was not a setup one would want to copy.

Yes but that was 15 years ago and do you really think the lifetime cost of building and running a custom VCS will be less than $1m, all in?

Also IIRC from the original 2011 Perforce admins paper before Piper, they said they had seriously overspecced the RAM and could use a lot less. There's an annotated copy here: https://www.anantjain.xyz/posts/perforce

Google implemented Piper because Perforce simply didn't scale well. In the years since, P4 has barely improved at all. Licensing P4 would not help and Google doesn't offer Piper licenses.

It scaled pretty well compared to everything else. I was there, they were running tens of thousands of engineers and hundreds of p4 commands per second off a 16 core box with a few replicas before starting the Piper migration. Commit rates were comparable to what Anthropic report. And although you say it barely improved, they were doing that sort of scale on 15 year old hardware and the p4 admins wrote a paper where they said Perforce had improved scalability a lot over time, so it's not like the software was static. Architecturally Scion sounds rather similar.

It's always a question of opportunity cost. The culture that led to Piper also led to them creating their own IDEs and everything else, often with questionable outcomes. Google had the profitability to get away with that kind of profligacy but do the AI labs really want to go the same route?

If you're employing 10,000 people and CodeSearch makes them all 2% more efficient, then why not do it? I think Google made their money back easily on that investment.

Cider and Cider-V were both forks of existing IDEs with Google-specific stuff wedged in. They weren't greenfield projects.

Blaze was absolutely worth it. Nothing else comes close.

I'm sure not _every_ tooling project was a win, but I don't think it's fair to frame it as "every Cider engineer could have been ramping up remarketing and advertising instead." Google's early days involved trying everything and keeping what worked. The tooling improvements worked.

Right, let me try and articulate my unease with this decision better. It's not really technical. I'm sure the Anthropic devs did a fantastic job.

But... there's a lot of decisions that make sense for a company like Google or Meta that don't make sense for other companies. Google, Meta, Apple and a few others like them are nearly unique. They have extremely profitable quasi-monopolies that have proven impregnable to competitors, and the second price auction system they use automatically sets prices to whatever the market will bear.

Thanks to that they they can pay enormous salaries, fund many high risk/low ROI projects and still have lots left over. In such an organization projects like creating your own build system, VCS, IDEs, email system and so on can be rational, even though they can't actually measure the productivity impact of a developer tool to one percentage point of precision.

All this is nothing like normal business. Normal businesses face peer competitors, meaning pricing is under continuous downwards pressure. Across all industries the profit margin is only 10%, but that's an average that includes the tech sector. Industries with a lot of competition stabilize at margins around 3% e.g. supermarkets or airlines.

When we look at AI labs, what do we see? They spend like they are Google, but the market they're in looks nothing like ads or SaaS. Instead they are in vicious competition selling largely undifferentiated products to price sensitive customers who display almost no brand loyalty. Quite surprisingly to those of us who got used to the FAANG and SaaS era, AI firms look more like airlines than tech firms.

In normal companies the rules and culture are totally different. Decisions are driven by people with MBAs who use terms like "core competency", "outsourcing" and "margin compression". In-sourcing is rare because it's expensive and risky. If your margin is only 3% then you don't compete with your own supply chain unless it's absolutely required. Doing that without a shit ton of spreadsheets showing it's necessary is the sort of decision that will get you fired, pronto. You use things off the shelf. If nothing is available for free then you're expected to spend months in vendor negotiations trying to squeeze another 5% off the contract, and this is the kind of work valued in such a culture which is why MBAs rise to the top.

Historically the software industry has avoided this because of ads, the ZIRP era, lock-in, the explosive growth of VC up to 2017, and low growth in other sectors like pharma. But that era could never last forever and seems to be ending now. A strong signal is the growth of Bending Spoons, whose business model can be summed up as buying SaaS companies run by people who can't psychologically handle a high interest rate environment and then just running them like a normal business.

I realize acutely that the reason I don't run a top tier AI lab is because of this mindset, but if I were running Anthropic I'd be trying to find ways to cut costs dramatically. For a decade+ you never heard the words "tech startup" and "bankruptcy" together in a sentence, partly because VC firms forced firms to acquihire startups that weren't working out, making failure look like success. But this week Character.AI went into Chapter 11. None of us know the true figures but it looks like AI firms don't have the margins to justify acting like a Google or a successful SaaS. Corporate cultures imported from those companies risk blowing everything up.

Everything you say makes sense. Except: if you are Anthropic, it may actually be very inexpensive to spin up a new source control system. They are in the unique position of getting #1 frontier performance (better than Mythos 5.1, probably) for the cost of the electricity and cooling.

The costs include opportunity costs. They could sell those tokens into the market; demand is high so at some price they would clear. In a normal business environment the cost of using their own models would be an inter-departmental internal charge.

I am pretty sure they recognize that if they aren't constantly improving, and _fast_, they will be overtaken--either by OpenAI or distillation. So it's worth it to focus on improving fast as a critical business need. "Just sell the tokens instead" is a harvest-time decision. We're not there yet.

These productivity gains must go somewhere.

I feel like "didn't scale well" is unfair to Perforce. It scaled to accommodate an absurd monorepo that might have been, at the moment they switched to Piper, the largest single software project in history. It scaled to handle the needs of every organization in the industry except Google and Microsoft.

In the age of AI writing code, maybe the question flips from "why not license it" to "why not reimplement it"?

Is it really their comparative advantage? Perforce can use Claude too but can amortize the cost over many customers so it should be cheaper and faster to reuse.

I mean 30k CLs per day isn't much. That's one every few seconds. Well within what a decent perforce setup can do with enough replicas.

You loose the free promo for your LLM, though.

Perforce can amortize the cost of Claude, but Anthropic can just use idle Claude-hours for free. They're already renting the datacenter capacity.

We can assume there is some price that would clear those Claude hours, especially as all the labs seem to constantly struggle with overload. So it's not free, there is opportunity cost to using Claude themselves.

Not using the full names is a mitigation for talent poaching.

There are orgs that are moving to not including names at all as the next step on that trajectory.

Apple has always been there.

Not always. Before Jobs II, the apps would have credits in the about section.

re: PPS: Employees are an attack vector. Making their identities harder to discover is a protection.

Gives me a vaguely creepy feeling, but it's reasonable.

All of this is unsustainable in short, not to mention medium term (not just for affordability, even just security reasons) so I don't think there is a reason to look into scaling this mess.

So? That's true of any employee at any company worth more than a billy and that's not a small amount of companies. I have gotten personal text messages from the CEO of my company, emails, and fake LI invites all at companies nobody has ever heard of.

> Given their own constraints and characteristics of their own. It only makes sense to build their own homegrown solution based on prior arts.

Does it, though?

What problem do they actually have that requires redesigning a whole new vcs?

Merge conflicts? That's not exactly a vcs problem but a "we changed the same code at the same time" problem. No tooling on earth eliminates the need to verify conflict resolutions if agent A renames int foo to int bar while agent B renames int foo to int baz.

Growing repo size? They should take a long hard look at what they are doing. How is their software architected? Is every single little change and half-baked AI churn commit pushed to the main repository, or does the main repo only receive the deliverable? Is everything under the sun tracked in a mono repo or are projects stored independently?

Do they take any precaution at identifying churn and taking steps to minimize it?

Frankly, this reads like a bullshit PR stunt, much like the bullshit curl vulnerability findings. They have a self-inflicted problem, and their solution is to persist the problem and mitigate the problems by rolling out ad-hoc tooling? It reads like "if all you have is a hammer" kind of situation.