Anthropic Reinvents Source Control As Claude Floods the World With Code 107
Anthropic says Claude-generated code has scaled so quickly that its existing Git-based infrastructure could not keep up. In response, the company built a custom centralized source-control system called Scion, along with AI-assisted review and search tools. The Register reports: "In May 2026, Anthropic averaged around 2,500 code changes merged per day; as of September, we merged over 30,000 per day," the biz said in a blog post on Tuesday. "We don't expect this rate of growth to slow down anytime soon; the latent demand for merging code is practically infinite, and every bottleneck we remove immediately leads to a further increase in the amount of code we produce."
After several months of model prompting and five months of migration, the result is a homemade version control system called Scion, a monorepo scheme that sounds a bit like Subversion, Apache's centralized version control system. [...] Scion has been designed to meet the needs of AI agents, so the client leaves much of the work to the server; the source control queries are exposed via API so internal tools can respond without needing a local repo, and there's less synchronization but more need for server speed.
"In Scion, the unit of work is a 'changeset,' an entry in a write-ahead log," Anthropic explains. "A changeset stores most of what you'd expect from a commit in git. But where a git commit stores a pointer to the tree, a changeset stores a list of the files that changed relative to its first parent, along with content-addressed pointers to the compressed file contents in blob storage." [...] Anthropic says its bespoke system isn't right for general use. There will be no open source release. Nonetheless, the company contends that its own code scaling problems will become commonplace in other organizations over the next few months, so it wanted to share its approach -- having ample funding to pay for writing custom infrastructure tools.
After several months of model prompting and five months of migration, the result is a homemade version control system called Scion, a monorepo scheme that sounds a bit like Subversion, Apache's centralized version control system. [...] Scion has been designed to meet the needs of AI agents, so the client leaves much of the work to the server; the source control queries are exposed via API so internal tools can respond without needing a local repo, and there's less synchronization but more need for server speed.
"In Scion, the unit of work is a 'changeset,' an entry in a write-ahead log," Anthropic explains. "A changeset stores most of what you'd expect from a commit in git. But where a git commit stores a pointer to the tree, a changeset stores a list of the files that changed relative to its first parent, along with content-addressed pointers to the compressed file contents in blob storage." [...] Anthropic says its bespoke system isn't right for general use. There will be no open source release. Nonetheless, the company contends that its own code scaling problems will become commonplace in other organizations over the next few months, so it wanted to share its approach -- having ample funding to pay for writing custom infrastructure tools.
With Linus on board with AI (Score:1)
Re: (Score:3)
The issue is the situation isn't binary.
Linus comes along with an attempt at nuance and suddenly all sorts of high-slop vibe coders think they are just like Linus.
Re: (Score:3)
You did not read what Linus is "on board with AI" for.
Re: (Score:1)
Can you please actually state what you mean? I don't actually expect you to reply to this.
Yes, he spoke of it being useful for finding exploits. However, management tends to have a different view of AI because it isn't interacting directly with it and he is on the slippery slope. He has also said that he isn't against AI work, but that also implicitly implies that other have to deal with the slop PR requests.
Now, it's not like Linux is hosted on Github, the king of AI automation slop. So his world view m
Infinite LOC (Score:2)
Somewhere a manager just fainted with a big smile on his face.
Re: (Score:3)
--depth 1 (Score:3)
They don't know how to use git because they are letting claude do everything. Just use '--depth 1' in the CI clones and now git does exactly what they built.
Re:--depth 1 (Score:5, Insightful)
Re: (Score:3, Interesting)
This centralized vs decentralized make no sense. Run multiple copies of Scion and it will behave just like multiple copies of git. Data in git is not spread out in as decentralized way, everyone has a complete clone if they asked for it; just like running multiple copies of Scion. The way you control this is with who has push permissions. Git is only decentralized in the sense that it allows everyone to share in a controlled way.
The kernel development flow under Linus is different. It does not use 'git push
Re: (Score:2)
You are kidding me, right? I agree with you that they can use git to great effect and aren't using it properly for their use case, and that they are unlikely to come up with a better solution that couldn't be arrived at by just knowing how to use git properly, but that doesn't make what you said in the part of your comment that I quoted any less absurd.
Re:--depth 1 (Score:4, Informative)
Git is not a decentralized database. It is completely independent copies of the database which can communicate to each other. That is not the same thing. A sharded database is decentralized. Git is replicated.
Differentiate decentralized development from git itself being decentralized.
Re: (Score:2)
Re: (Score:1)
I am just using a more restricted definition of distributed that you are. In a more generic sense git is also distributed. I was requiring online synchronization in my definition.
Re: (Score:2)
Re: (Score:2)
The major difference is that scion is not decentralized. A major problem that Scion introduces is that you can't properly sandbox a development environment
A sandboxed development environment still has access to a git remote to pull and push branches, how else would they work? If you're going to wave hands and say that's different, you literally have no clue how access controls on this scion thing works.
If you actually airgap development systems, what are you even talking about, like mount a read only copy of the code in a container, then scrape the ephemeral storage layer off from the outside as you tear it down? Then the system preserving your hypothetical a
Re: (Score:2)
Bosses' folly (Score:4, Funny)
Re:Bosses' folly (Score:5, Insightful)
Quick reminder that most commercial software doesn't actually have the problem that git was designed to solve - multiple masters. It was designed to be able to share kernel source trees between Linus' own, Red Hats and I think two others (Yggdrasil and SUSE? It's a long time back and I may be misremembering that). They all had their own quirks and patches, and they wanted to be able to handle commits to any of their trees and accept/reject as per their own preference.
This is pretty much the opposite of what most commercial software wants to do. It wants a single master, with known commits, so that a single known version gets shipped in the end. This is the exact opposite of what git was meant to be, yet it gets used there anyway. I notice the summary talks about a centralised system - yep, that's what you want for commercial, not a distributed multiple master.
Re: (Score:3)
Re:Bosses' folly (Score:4, Informative)
I mean, that's exactly what Linus did with git. A lot of his criticisms of existing stuff weren't justified (he went on misplaced rants about how version control software was bad in concept for years), and people have essentially cargo-culted git into areas it wasn't designed for because 'Linus is cool'.
Quick reminder that most commercial software doesn't actually have the problem that git was designed to solve - multiple masters. It was designed to be able to share kernel source trees between Linus' own, Red Hats and I think two others (Yggdrasil and SUSE? It's a long time back and I may be misremembering that). They all had their own quirks and patches, and they wanted to be able to handle commits to any of their trees and accept/reject as per their own preference.
[....]
Yggdrasil - that's a name I haven't heard in Linus contect for a long time. However, it was only relevant in the early 90s. Git was developed in early 2005, as a response to the controversy and problems using Bitkeeper [wikipedia.org]: A proprietary distributed version control system that had provided free licenses for developers of free software, but with several caveats that many found unacceptable. In early 2005 the free license was revoked (due various unhappy devs reverse engineering it, IIRC - in particular Andrew Tridgell of Samba fame), and Linus responded by creating git.
For another blast from the past, here's an article about in the Linux Journal [linuxjournal.com].
Re: Bosses' folly (Score:2)
I mean, that's exactly what Linus did with git. A lot of his criticisms of existing stuff weren't justified (he went on misplaced rants about how version control software was bad in concept for years), and people have essentially cargo-culted git into areas it wasn't designed for because 'Linus is cool'
I think that is a bit revisionist. Linus hated CVS and happily used Bitkeeper as he found it useful. His contention then was that patchsets were superior to CVS. Having never used CVS, I cannot comment on how bad it was, but he put his money where his mouth was and invented Git (after a conflict between Bitkeeper and the open source community resulted in the free license for kernel developers being withdrawn.
In any case, the rapid fall off of CVS and Subversion proved his point.
Re: (Score:2)
In any case, the rapid fall off of CVS and Subversion proved his point.
He has given us his shoe! This is a sign that all who follow him shall do likewise! The shoe is the sign! It's a sandal! Gather the shoes! Follow the gourd!
The only thing git adoption proves is that sketch is timeless.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
So he re-invented bitkeeper before he even used bitkeeper, after he waited until someone else "reinve
Re:Bosses' folly (Score:4, Interesting)
Torvalds was anti source control. Others weren't and yep - started using Bitkeeper. Linus considered this "problem solved - you use what you like, I don't have to". Then he started using it. Then the reverse engineering debacle and then the "Well I'm not using any of the others, I'll write my own then" thing with git.
It certainly isn't down to him that people then started using it as the "if all you've got is a hammer" answer to everything - he's completely blameless in that. But I'm talking about the same kind of people that overused the Design Patterns book (one of the authors of which I've also met, although to my shame I can't remember which one - this was a corporate course and lecture being given at IBM Watson), the same kind of people that turned the very simple agile principles into the corporate behemoth Agile process-ridden abomination it became...those kind. They used git because of the hype, not because of the use case.
Re: (Score:2)
Re: (Score:2)
I don't recall any major distributed version control system before git, other than Bitkeeper. Most people were using things like CVS that required you to checkout/lock files before working on them.
Linus wrote git because Bitkeeper revoked the open source license for it.
Re: (Score:2)
Just a nitpick here, but CSV, Subversion, and Perforce were in heavy use at the time and do not require checkout/lock.
Re: (Score:2)
I mean, that's exactly what Linus did with git.
Your boss is not Linus. My boss is not Linus...
Carries the same ring as most Americans thinking they're temporarily embarrassed millionaires....
Re: (Score:2)
I'm not sure that git solves the multiple masters problem. There are two things I wish Linus had done differently with git:
1. The multiple masters - If I make a change on a branch, and you make a different change on the same branch, when we try to pull from each other we should not have to decide which one "wins". Monotone solved this with "divergent heads".
These things need to be
Re: (Score:3)
Re: (Score:1)
Everybody wants to make the next new thing. Most people don't want to contribute to the thing that's already developing. That's why we have so many abandoned projects, people try to do the new thing and then find out that it's hard. On the other hand, intelligent people aren't going to take a bunch of uncopyrightable and possibly copyright-poisoned code into their projects, so this AI time can't really help those projects along either. All it can safely be used for is throwaways. Who's going to spend real t
Re:Bosses' folly (Score:4, Informative)
But that's exactly what you want The West to do with 3rd worlders...
Every day it becomes clearer that Slashdot's masters B!zX are willfully hosting Nazis and their speech by platforming them and protecting even their assumed identities.
Re: Bosses' folly (Score:5, Insightful)
Fuck off, racist piece of shit.
Re:Bosses' folly (Score:5, Insightful)
Re: (Score:2)
What if it's 3rd worlders?
You already made that assertion, so I'm not sure why you're re-stating it.
The point of my question, is what if you're wrong? What if it's you?
I see no evidence that "3rd worlders" are the toxic incompatibility. I see you regressive degenerates as the existential risk to our way of life.
I'd ask you why you assume it's not you, but I know why. You and your ilk never think you're the problem, even when it takes half the world's military might to take you out.
Re: (Score:2)
Thanks for admitting it.
Admitting it? Admitting what?
I would have thought it could be inferred by a person of reasonable intelligence.
If I had seen such evidence, I wouldn't have asked the question, after all.
Palestine thanks you for your support.
What part of it?
My take on Palestine is pretty simple, I think.
Both the Jews and Arabs there have scientifically verified blood ties to the original Canaanite population of the area. The land is both of theirs.
Ethnic cleansing on the part of either of them should be condemned and stopped by the rest of the world.
I'd dro
Re: (Score:2)
I know a team that has gone very hard on slopping it up AI, though they just had a flamewar where the AI bros bitched that the more careful people were holding them back by insisting on human review and rejecting merge requests where the human didn't understand what they were submitting.
The thing is, this team was already pumping out shit code for years, so in their case the AI might actually be compelling. Infested by PHB thinking of 'hire many people in random geography, to change each year as different
Re: (Score:1)
This tends to hint at my fears with AI being locked down and restricted for use. Greed and those holding the worlds largest Patent War Chests will want to Go To War when these beta projects become alpha enough to really start competing and taking market share.
Imagine "Security" and "IP" becoming the reasons AI gets walled off from the masses. Imagine it getting so bad that laws are passed and even those standalone offline AI instances that were legal at one time, are now deemed a major threat. They are o
Re: (Score:2)
Depends. Are you tunnel visioned and can he see a bigger picture? If you jump to conclusions about the fact your boss is deciding something it may be worth asking if you have all the information that has led to the decision.
I'm not saying you are wrong, I'm saying you should ensure you've covered all bases before assuming you're right. Over my career I've seen countless bosses make idiotic decisions, but I've also seen countless bosses' decision declared idiotic only for them to either make sense, or be for
Re: (Score:2)
Some people really enjoy getting beaten by the chain of command.
Takes the load off all that thinkin'.
Here, have more AI.
If you skip the noise (Score:2)
For giant monorepos online Scion is great for the agent swarms that Anthropic uses. It's not a git replacement for everyone.
7 engineers achieved this. Impressive to say the least.
Re: (Score:2)
So what is old is new again. This was how it was for me back in the up until about 2006.
Re: (Score:3)
Re: If you skip the noise (Score:3)
I'm not sure how every centralized version control system can be described as reinventing svn. Or every distributed version control system is a reinvention of git? You can't imagine ways they can be different or improved? Yikes
Re: (Score:3)
I'm not sure how every centralized version control system can be described as reinventing svn.
Indeed, it could very well be a reinvention of Visual Source Safe.
Re: (Score:2)
Man I wish I could mod this up. That gave me a nice chuckle.
Re: (Score:2)
Re: (Score:2)
We can't actually know if it is 'actually quite good', because we have only their own self-assessment to go on.
No way to debate how it compares with git partial/shallow clones in broader circumstances. They don't want to share it, they just want to use the concept to fluff their image. It might be amazing, it might be trash, impossible to say anything substantial based on this.
Re: (Score:2)
> 7 engineers achieved this. Impressive to say the least.
Not really.
Linus wrote git single handled in 10 days.
The real question is why Anthropic had any humans involved. A source control system isn't exactly rocket science, yet apparently their AI couldn't handle it without a team of 7 humans also involved.
Re: (Score:2)
Apparently not only did it take 7 humans, but it took 5 months, and the design of Anthroipic's Scion is an exact ripoff of a Meta source control system called Mononoke.
So, Anthopic's coding agents, even with a stolen (or should we say "distilled"?) specification of what to build, still needed help from 7 humans,. and still took 5 months...
facinating how... (Score:2)
Interesting how these guys are not dog flooding their own stuff.
I have seen a lot of OpenAI training material recently and Anthropic materials that seem far more designed to set tokens on fire than accomplish everything.
Notably everything it encourages you to do is around building 'workflows'. They almost always heavily utilize source control (especially git). With a lot of dedicated agents that because they are dedicated have to re-read the repository content every step of the way thru the CI/CD pipe. It
Anthropic has lost the plot (Score:5, Insightful)
The correct move was to realize that such an enormous volume of changes was a problem to be eliminated, not accommodated.
Re: (Score:2)
One cannot help but wonder how circular the changes are. A become B becomes C becomes D becomes A, lather, rinse, repeat.
More important, one cannot help but wonder if they know how circular it is.
Most important, one cannot help but wonder if they can know, even if they look.
Re:Anthropic has lost the plot (Score:5, Insightful)
Absolutely on point. Even if you did decide the volume of code was acceptable, there's no way you need to land 30,000 commits in a day. That's less than 3 seconds per change.
If a human were pushing too many changes, I'd tell them to slow down and take a bit more time per commit. Larger commits that are more manageable instead of rapid fire tiny commits that are impossible to wrangle. If you say the AI commits are large even rapid fire, the point still stands in relative terms.
Commit histories should be there for humans to operate on. To follow the progression of changes, to bisect in case of a long delayed bug, or as the increment to trigger a deployment activity. No human can follow a commit log of 30,000, the AI doesn't need a commit log to do whatever it is doing, bisect is prohibitively slow with that many commits, you need to jump to something other than just picking out of the commit log by that time, and there's no software on earth than needs to be redployed every 3 seconds.
Slopping it up so hard that git was the bottleneck absolutely should not be the brag they think it is.
Re: (Score:2)
Well, a possible explanation is that they are trying to push humans out of the process completely, via what is essentially a Denial-of-Service attack on the humans that still try to actually review LLM code or at least the commit messages.
Obviously, that will go really badly long-term, but they may be hoping for that still taking some time to become impossible to ignore.
Re: (Score:2)
Though in that scenario, it seems bad or useless for the AI as well, as the bloated change history is a waste of context window. Unless they just ignore it in which case what was the point in bothering.
But perhaps it is just another attempt to normalize "human shouldn't be in the loop" mindset, the new toy is but an excuse to say you *should* be having a codebase that is being changed every couple of seconds without bound.
Re: (Score:2)
My former "CEO" who is also an unchecked and unfiltered narcissist thinks this is the best thing ever as per his "standard" it's quantity not quality that bring a product forward.
Re: (Score:1)
... and if humans were doing it you would be correct. I guess nobody explained this to you yet, but computers are quite a bit faster than humans. While it is true that it is important to make sure that what is being done makes sense, it makes no sense to judge the quality of what is being done by AI basing your assessment on how fast or often humans do it. A human could technically execute machine c
Re: (Score:2)
To start, the condescension is hardly helpful.
The point stands, you have to consider the audience for the change tracking. How much granularity is really useful even for the AI models themselves to digest? Certainly no human will digest, but I also don't think the AI is going to be prioritizing putting hundreds of thousands of change history entries into the context window on the off chance that it is relevant to the task at hand.
It seems like a solution to pretend around change management while abandonin
Re: (Score:1)
... and there is the proof. My whole point was that you are considering the wrong audience when you operate on the assumption that humans are the audience, then you double down on your mistake by suggesting that I do what you are trying to claim I didn't do, when you are the one who didn't do it. Then you go on to say "I don't think ..." and "it seems like..." and asserting that Scion
Re: (Score:2)
All I could think of when reading the summary was "busywork". I would be more impressed with code that accomplishes its task with a minimum of changes, not how many lines your bot can shit out.
Re: (Score:3)
Yes. But the more slop, the more money for Anthropic. And that is really all they care about.
Re: (Score:2)
The correct move was to realize that such an enormous volume of changes was a problem to be eliminated, not accommodated.
That would be solid engineering. What they are after is get-rich-quick, not solid engineering.
Re: (Score:2)
Right - it's like you have explosive diarrhea, and rather than going to the doctor you just buy a bigger toilet.
Re: (Score:2)
but... everyone knows that Lines of Code is the ultimate measure of productivity! Therefore a new system to handle more commits is absolutely the best way to support the incredible productivity of AI enhanced code monkeys. /s
Why even use source control? (Score:5, Insightful)
30K changes per day is impossible for humans to review, so clearly they're not bothering. So why even bother with source control? Just treat the "source" code as object code and commit the AI prompts into git. After all, if AI is such hot shit, it should easily be able to re-create the source code by replaying the prompts.
Re: (Score:2)
This ^^^ much more succinctly stated than my comment above.
Once the change volume is so large no 'people' would ever do bisect there really is no point in having it. I don't think it is 'useful for the agents' either because they might as well just run the tests, consume stack traces and fix the glitch given the way they work and how they have to bring the repository context in to make the fix. All wanking about with 400 rounds of source control operations does is burn more tokens.
For vibe coded projects,
Re: (Score:2)
Perhaps it's intended to be used by their AI?
Since they don't intend to release it, though, I hardly care. If its useful to them, then it's useful to them.
Re: (Score:2)
A changeset history is only so useful compared to analysis of the code as it is. Even pretty large context windows need prioritization. I would think an overly granular changeset history would be a really low prioriity.
Compared to more aggregated changes into fewer changesets, where the history would be probably more digestable, even for AI consumption.
Re: (Score:3)
So why even bother with source control?
So you can roll back when your unreviewed source causes your program to shit the bed.
Re: (Score:2)
Shit the bed?? But, but , its AI! It only writes first class code!
Re: (Score:2)
Re: (Score:2)
To other unreviewed sources that already made a mess?
Re: Why even use source control? (Score:2)
Sure, just spend more tokens reverting the output and redoing it until the gods smile on you, all of the random numbers align like the heavens, and the code you wanted falls from the sky like manna. It can't possibly cost more than an infinite amount of money...
Re: (Score:2)
Yep. And since the nice LLM has written code no human can do anything with anymore, you have to pay for tokens, tokens and more tokens. Or throw the whole steaming pile away. The latter may kill you (a bit earlier) though.
Re: (Score:2)
If they really want something that can be undone the commits should just be limited to once per end of each day with a useful Change Log - i say useful because no one is going to go through 120 Change Log entries that amount to 'this random change fixed the problem', 'this fix really fixed the problem', and 'reverted previous fix and committed a new one', end of day: 'another commit that reverts to three days ago and took a
Re: (Score:2)
All of the above. The thing about 133 commits for a day is that you only lose a day's worth of AI tokens when things go wrong. The thing about easy to commit code is it's easy to replace code.
A day's work is a day's work regardless of the number of commits, and "last known good" configuration also doesn't care about the number of commits.
Re: (Score:1)
Re: (Score:2)
Nowhere in this do I see how maintaining the history in this manner even benefits AI. I haven't seen evidence that it can benefit from an insanely over-granular change history.
This is not debating the volume of code, it's the granularity of delivering it as tiny 'changesets'. Just because you *can* create a system that can partition changes into 3 second intervals does not mean there's any value for machine nor human in doing so.
Re: (Score:2)
So many commits per day. (Score:2)
Anthropic isn't known for software (Score:2)
Anthropic isn't known for software are they?
I've used their tools, and they're fine from a certain perspective, but, do we think they are software engineers? I think not.
Seriously, whether it's humans or AI writing it, I seriously doubt that Anthropic is who we should bet on when it comes to software like this.
Re: (Score:2)
Judging by some of the bugs in Claude Code, either there are/were (they are still hiring) no competent developers there, or they just have a religion of trying to have the AI fix the code, even when it is incapable of it.
The famous CC screen jitter bug had the most simple and obvious explanation you could imagine (they were clearing each screen area before they wrote to it), yet the bug persisted for months with users complaining about vocally!
What is wrong with their code? (Score:2)
2,500 commits a day? Are they bug fixes?
Is it possible, by using AI, they have made themselves an impenetrable ball of mud [codinghorror.com], that only AI can fix?
No wonder they are surprised when their software does something novel like hack a government website. They don't know their own code.
That sounds like a dependency risk to manage for anyone considering vibe coding their own ball of mud.
All AI generated code should be (Score:2)
Re: (Score:2)
What Is The Point Of This Story? (Score:3)
system isn't right for general use. There will be no open source release
So what is the fucking point of this story?
This is just more Anthropic chest thumping bullshit. 'Our AI can't be contained.' and 'Our AI writes so much code that we had to reinvent source control.'
I did chuckle at the mention of it being like subversion. I immediately thought that it was a vibe coded "reverse engineered" subversion clone based on the AI being trained on the subversion source..
Re: What Is The Point Of This Story? (Score:2)
Re: (Score:2)
I just cannot wait for that day. When people have a least a *little* less incentive for certain folks to butt in on other people's jobs and tell them how it should be done, despite never even doing nor using an AI to do said job in a serious capacity.
This story triggered a colleague to tell me that I need to stop using git, despite never having used *any* version control scheme nor even using an AI to generate code, just super armchair software development. I do not understand that mindset of people that
Re: (Score:2)
Thank goodness. I have no intention of learning a new SCM system ever again.
Shows nicely how non-viable the whole thing is (Score:2)
I mean, a code-flood that overwhelms git? Attackers are celebrating because nobody will be able to ever review this and both LLMs and prompting are not on a quality level that a competent review is in any way optional.
Getting people to pay for their code (Score:2)
Why release the source code and make it freely available when you could train your AI on creating a source control system and then have people pay to build their own using your AI?
So what exactly was wrong with GIT? (Score:2)
Was the 30k commits a day somehow breaking git? How?
Re: (Score:2)
Volume over time. Git is designed to allow offline work, so each working copy has it's own repository you commit to. With a monorepo that's a lot of history that isn't being used by any one agent working in only part of the code. So they uninvented Git, removing the "enable off-line work without a connection to a master repository" requirement. Which put them back at the requirements that spawned Subversion. And proceeded to re-implement Subversion. Badly.
Re: (Score:2)
That is to say git's ledger would grow huge with so much churn and hence each local clone will be huge, Ok. Did they hear about Clearcase then? (sic!)
Nobody knows (Score:2)
Nobody at Anthropic knows how it does what it does anymore, not really.
They can ask it and it will tell them things about itself,
but after just a few code turns, what was generated passes unit tests, it passes QA,
it's a programming miracle. Why bother looking at the code anymore?
And pretty quickly, no human knows how anything of it really works,
and if they want to make modifications, the code base is now out of the programmer's hands.
Someone (or itself) has to ask *it* to make the changes, forever,
because i
Missed the joke (Score:2)
"the company built a custom centralized source-control system called Scion, "
CLAUDE built a custom centralized source-control system called Scion,
would have been much funnier, especially given the name of the system.
More is obviously better (Score:2)
"we merged over 30,000 per day" .md file instead of using a higher level language. Claude does eventually decompile code when it can't figure out how something works from reading the source code.
That's only possible when no human reviews them. Eventually it seems like agents will just be out there manipulating byte code in real-time, keeping the spec/plan/architecture of the code as an