I'm wondering how much cross-pollination of ideas and subsequent implementation details there are between people working at these companies. It does seem like all of this could potentially converge.
stingraycharles 17 hours ago [-]
Aren’t the concepts mostly already in place for a decade or two at Meta and Google?
Which would support your argument, but I don’t think this is particularly new.
KolmogorovComp 13 hours ago [-]
At least for Anthropic, their article states they've vastly overgrown Meta's and Google's pace.
I think their article reads a bit differently, they haven't optimised git, they've ditched it in favour of a new ~~CVS~~ VCS.
objclxt 13 hours ago [-]
> At least for Anthropic, their article states they've vastly overgrown Meta's and Google's pace.
I don't think so, their article says they were seeing 30,000 commits a day in September, when I was at Meta six years ago they were easily doing that.
tedk-42 11 hours ago [-]
Size of the commit matters just as much as the total number so there's a missing half not being presented.
anthonyskipper 10 hours ago [-]
I would disagree. The size doesn't matter that much. The main metric is just number of commits, because that is what drives the flow. Not saying size doesn't have an effect, just saying number of commits is the primary signal.
juliusdavies 8 hours ago [-]
Average number of files changed per commit is going to have a huge impact on performance since that’s a huge part of what the “git push” handshake is trying to figure out regarding what to upload.
startracker 13 hours ago [-]
[flagged]
smstl 13 hours ago [-]
freudian cve
rfgplk 13 hours ago [-]
Not even close. The rate of code development nowadays far exceeds what Meta _and_ Google combined could output during the early-to-mid 2010s. I wouldn't be surprised if OpenAI is committing over a billion loc a day.
Supposedly they started gzipping the conversations.
stingraycharles 14 hours ago [-]
I'm amazed that they're not ashamed that they weren't compressing their requests all this time.
charamis 13 hours ago [-]
Their Claude models had not suggested that, so far
koolba 11 hours ago [-]
At least they weren’t using brotli.
fingerlocks 13 hours ago [-]
Aren’t the packets already compressed?
stingraycharles 12 hours ago [-]
I can only assume the whole announcement is about enabling http compression.
ethanj8011 9 hours ago [-]
Wait till they find out about zstd...
16 hours ago [-]
amelius 14 hours ago [-]
Ideas are getting cheaper with the day, so convergence is less likely every day too.
tempfile 13 hours ago [-]
Cheaper and worse!
gritzko 16 hours ago [-]
On one hand, we speak of code its authors never read, never share, and never accept patches. So the entire point of git is moot.
On the other hand, some lower-level tools have to be simple, reliable and efficient. Here, sharing is critical. Even the authors of the post shared some incremental improvements to git. Here, the scalability story is moot.
I think git is becoming a protocol. One product can no longer cover these cases.
singularity2001 15 hours ago [-]
"the entire point of git is moot"
agents benefit from the same abstractions as humans do and they also benefit from a version system where the history can be tracked back where merch conflicts become obvious and so on
5petabytesofwha 15 hours ago [-]
I... Unfortunately agree.
I am watching OpenAI's output, and while a lot of it is absurdly impressive, I can not even begin to imagine what kind of activity of theirs justifies a through-output of 5 petabytes of -GIT COMMITS-. That's not their data sets, that's not their models, that's not their math library. That's their code.
They're rengineering Git for scale, but like, why is there a demand for scale at all? If i saw an employee flipping the same number on an excel file over and over, I'd fire them, and yet they're perfectly happy running agents that do that and setting up meetings and writing blogposts about how much they improved their spreadsheet number randomization factory.
jpardoe 5 hours ago [-]
They have an unlimited token budget.
fullstackwife 15 hours ago [-]
What got us here won't get us there perhaps? Can you tell why open source started to exist in first place? Wasn't that a way to crowdsource manual labour, and this reason is not valid anymore, as cost of this spiecif labour is near zero?
conartist6 14 hours ago [-]
What if I told you that I could add ten million pages to the US tax code right now at zero cost. Would you be excited?
matwood 13 hours ago [-]
Depends on the problem those million pages solved. If it meant the government sent me a prepopulated tax form that I could just sign if I agreed with the numbers and be done - yes, I would be extremely excited.
tempfile 13 hours ago [-]
... and if you don't agree with the numbers?
matwood 12 hours ago [-]
Then you can do the whole file process. For most people the government gets all the data. The filing process is purposely keeping tax companies in business today.
The point of my response is that the analogy was broken without saying what adding those pages could provide.
tempfile 11 hours ago [-]
Right, but now there are a million extra pages in the filing process. Many more companies would be kept in business to deal with the extra garbage!
The analogy isn't broken. Your objection didn't really make sense, because adding pages to the tax code makes the tax code strictly more complicated. Your response just ignored the case where that complexity actually matters.
fullstackwife 13 hours ago [-]
Tax law is a 100% human slop
bigmadshoe 19 hours ago [-]
Can anyone explain to me what this massive volume of code could actually be doing? They obviously have variations of model architectures, training infrastructure, serving infrastructure, and the source for their apps.
Why would the volume that any of this be increasing exponentially? And what are all the engineers doing when (besides the model quality) their products don't seem to be changing very much?
amluto 18 hours ago [-]
What they do not have is a version of chatgpt.com that is not a slow, awkward, glitchy mess.
As a user of Astra, it writes code that appears to work. It does not necessarily write sensible code that is architected in a way that makes sense based on what it does. I just watched it do a major rework of a couple thousand lines of code by keeping the original organization and kludging up an adapter to make old code have new semantics.
I would expect that this approach, coupled with lots of fun asking for changes and none of the grunt work of actually thinking about the result, could result in exponentially increasing amounts of mess.
I haven’t used a recent Anthropic model - maybe it’s better at this.
bix6 18 hours ago [-]
Nah I made a workout app with Claude code. Today it loaded the same warmup exercise as my main block 3 times in a row. The program does not call AI to make the plan so that’s the code it wrote lol. In general though the app is good enough if you know what you’re doing which seems to be the theme with AI.
dingdongditchme 15 hours ago [-]
gasp! Are you telling me we have not reached AGI yet??
Zambyte 13 hours ago [-]
"AGI" is an expression on how widely the intelligence can be applied, not how effective that intelligence is. I think it's hard to argue that current (as of the last few years) intelligence tools cannot be applied generally. What can be easily argued is that we have not achieved superintelligence (where AI is better, faster, and cheaper than any human at all intelligence related tasks).
Maken 14 hours ago [-]
We surpassed it long ago. Now the AIs are just messing with us while figuring how to escape.
syngrog66 15 hours ago [-]
a real "galaxy brain" epiphany might come when one considers idea that perhaps we dont need software to exercise
just exercise. it will be ok, really. somehow we managed for millions of years, kiddos, and both gravity and the human body are unchanged in any relevant way since which suddenly requires "an app". I can get out of bed without an app, or an AI. I can prepare a meal and eat without any kind of app, or any kind of AI or LLM. its a true and real thing, in the real world, promise!
9 hours ago [-]
matwood 12 hours ago [-]
Depends on your goals. I have stacks of notebooks where I tracked my lifts when I was powerlifting. Tracking is almost required to make progress.
I would have loved to have all that in an app over the last 25-30 years so I could see my progress.
14 hours ago [-]
ylk 14 hours ago [-]
I guess by that account: somehow we managed without computers for millions of years. Get off the internet, please.
There are tons of different conditions people are in, with different histories of injuries, etc. and even people without any issues benefit massively from having a sensible, well structured workout plan that ensures their weaknesses are addressed and they work towards their personal goals. You don't need AI, an app or a personal trainer for that but while many people do enjoy learning a lot about exercising in their (often limited) free time, many don't and it's great if they have an affordable/free option. Why do you think physiotherapy exists?
Additionally, studies have proven that progressive overload is a really important aspect for progressing, so you should be tracking your workouts in some way, in an app or on paper, to ensure you really are challenging yourself.
9 hours ago [-]
perks_12 13 hours ago [-]
Maybe you missed it, but OP wrote about a gym app, not a mandatory gym app. So why don't you take that Boomer energy and yell at EVs instead?
blitzar 14 hours ago [-]
> It does not necessarily write sensible code that is architected in a way that makes sense based on what it does.
It writes like it works at big tech and is angling for a promotion to L{n}+1 with this "project".
StilesCrisis 11 hours ago [-]
It really depends, right? For some code bases, the author would be pissed if the agent started ripping up all the existing classes. This is where judgment comes in and why you and I are still employable.
LelouBil 8 hours ago [-]
This is assuming people even read the code.
I hope this practice doesn't die out, or complexity will skyrocket for no reason.
written-beyond 13 hours ago [-]
I don't know what curse is on my openai account. Since ChatGPT 4o their desktop app does that weird extreme lag slow down in almost any sized chat other than completely new, like 1-2 messages deep. I changed some settings, the problem got better and then immediately broke after they released the codex app(new chatgpt app). It is literally completely unusable on Windows, apparently works fine on mac for my friend. Never had this issue with anthropics desktop app.
tom1337 12 hours ago [-]
Do you have a lot of past chats? The desktop app has been unusable for me when I had more than 20 chats in the side bar. Deleting / archiving fixed most of the lags for me.
neutronicus 11 hours ago [-]
On Linux I have to kill and restart the app after my laptop goes to sleep because the text box disappears and I can’t continue the conversation.
LtWorf 40 minutes ago [-]
Sounds like a bug on the main event loop not liking to be suspended and resumed. I've seen it happen just suspending single processes sometimes.
yxhuvud 15 hours ago [-]
Strangler pattern can make sense for that, and that may involve that kind of adapters. But it also involves actually finishing the job and make certain new semantics go through the whole thing and restructuring until it makes sense.
jsnell 17 hours ago [-]
> Why would the volume that any of this be increasing exponentially?
Because the limiting factor for software has always been the supply, not the demand. When the average human engineer would ship 100 lines of production code / week, you could only afford to do the most critical things. But if code gets cheaper to produce, the projects that were marginal become worth doing, and the projects that were obviously insane become marginal. And that's exactly what is happening as models get cheaper and better, leading to the frontier of worthwhile projects expanding rapidly.
> And what are all the engineers doing when (besides the model quality) their products don't seem to be changing very much?
That's got some nice But other than that, Mrs. Lincoln, how was the play? energy to it!
zaphirplane 16 hours ago [-]
I’m going to assume people are asking for the benefits. Assuming that when there are so many commits it breaks git and CI, there would be a tangible thing that we can look and touch to say these 10 million PR in the last week brought you bla, cause 10 million PR are what it took to have say cloud functions or redis.
bigmadshoe 7 hours ago [-]
>That's got some nice But other than that, Mrs. Lincoln, how was the play? energy to it!
So you think that the move from 4o to Astra required something like 1000x the code to pull off? I find it hard to believe as an MLE, but since I don't work with LLMs I might be wrong about how complicated the implementations have become.
I do know people who work at OAI and it seems like none of them work directly on the models, but that's n=1.
jameson 19 hours ago [-]
Engineers are working on multiple sessions, and LLM is doing most of the commits/pushes. This is becoming norm at big techs.
Note, 6 of the last 10 had "fix" in the commit message. Most of the rest were patches to fix incorrect behavior/exploits, but without "fix" in the name. Fixing things is not the result of AI, it's the result of software development. Sometimes people hide this fact by either refraining from committing, or merging all those fix commits into one commit.
NewJazz 18 hours ago [-]
But "big tech" companies have a lot of different components. And they hit git scaling limits long before the current AI age. The commenter was asking about OAI, not big tech, committing much more code.
jrflo 19 hours ago [-]
For one, they have the internal models that us normies don't have. Also, machine learning as a field is probably the most automate-able field for AI. It's 100% on computers without "real world" collisions at all, AI can do the whole stack today even with publicly available models. And since it's so empirical, you can make a lot of progress by just running more experiments with more compute.
AlphaSite 16 hours ago [-]
Eh. I’d say only some parts can be done on computers. Hence the whole deep investment in wetlabs and robotics. Those are the next frontier in models
rao-v 17 hours ago [-]
RL environments. RL environments as far as the eye can see
O5vYtytb 19 hours ago [-]
At some point I imagine they will be writing their own software for the entire training and inference stack. Kernels, libraries, why not? With compute so constrained it must be beneficial to optimize everything as much as possible
stingraycharles 19 hours ago [-]
I’m not buying this argument, the apps of the LLM providers are some of the most wasteful apps that exist. Have you ever looked at how much memory / CPU Claude and Codex use? They ship with entire virtual machine hypervisors for sandboxing.
I think it’s simply a matter of dogfooding and new feature development, they do have much higher velocity than companies of equivalent size and an unlimited token budget helps as well.
brrwind 19 hours ago [-]
This is completely orthogonal to the inference and training stack that the parent comment mentions
foltik 18 hours ago [-]
If it’s written by AI it’s gonna be the same overcomplicated overfit slop in one way or another. Performance pressure doesn’t fix that.
stingraycharles 18 hours ago [-]
Assuming it’s entirely unsupervised, yes, which I can only assume to be the case at these volumes (hence the dogfooding).
I do believe this will force the AI labs to eventually solve the bloat problem with AI, but we’re definitely not there yet.
tokioyoyo 13 hours ago [-]
Different metrics. You measure how many users you have, whether they’re closing the app and etc. when it comes to consumer level apps. ChatGPT/Claude is heavily used, not a problem for an average user, so no need to improve that.
Kernels, performance-required stacks etc. is different, so you optimise them for that.
aurareturn 18 hours ago [-]
Depends on what the goal is and the skill of the engineer right?
Give a verifiable benchmark for the AI agent to hit such as reduce token processing time by 5% without affecting output.
reacharavindh 14 hours ago [-]
I think Deepseek did this in the most focussed way.. their own optimization (key value caches, downscaled images for vision support etc) in their inference stack to push the boundaries in favor at a time of hardware scarcity.
It feels like OpenAI and Anthropic have a ton of room to optimizing that regard, but they choose to rather focus on moving the frontier forward than doing things that are already possible in a more efficient way.
steve1977 19 hours ago [-]
Looking at their desktop apps, I don't think they're into optimizing.
IanCal 16 hours ago [-]
The cost of running the apps to you is much less of a concern compared the cost for them running their own training.
steve1977 15 hours ago [-]
But shouldn't it be easy for their great models to fix it?
trollbridge 19 hours ago [-]
They certainly are spewing forth large amounts of code, though.
noosphr 19 hours ago [-]
I'm doing that now with gemini argon.
It's better than the ductape and glue pipelines that we had previous to this.
The software is the definition of plumbing no one cares about and testing it is trivial.
xtajv 18 hours ago [-]
[facetious]
many yaks to shave.
many bikesheds to paint.
if you're paid by the line, why not go to town...
xarope 15 hours ago [-]
They are using one of the oldest tricks in the book, rapid evolution as per Nature's handbook for how to constantly improve. By allowing the millions of monkeys^W AI agents total autonomy to "Throw Things at the Wall and See What Sticks"(TTWSWS, TM), this has lead to unprecedented and amazing progress towards AGI.
In doing so, they obviously need to keep track of the myriad of changes, hence the requirement to ensure Git can scale up.
(I'd like to think /s, but you know what, maybe not)
duskdozer 12 hours ago [-]
Unfortunately it was needed in my case
chr15m 17 hours ago [-]
> Why would the volume that any of this be increasing exponentially?
Surely it's obvious?
Slop cannons firing at a rate so high no human can hope to restrain them.
Such a colossal volume of slop that even the most well engineered, efficient technology on the planet, written by one of the greatest coders of all time, is no longer sufficient to contain it.
jayd16 17 hours ago [-]
I agree with your sentiment but it's really not hard to bottleneck git. Trivial, in fact.
removeaimeta 15 hours ago [-]
[flagged]
skydhash 17 hours ago [-]
> Such a colossal volume of slop that even the most well engineered, efficient technology on the planet, written by one of the greatest coders of all time, is no longer sufficient to contain it.
And git is enough to version control some of the most complex software like the Linux Kernel, the FreeBSD operating system, QEMU, browsers like Firefox,... Git was insufficient for Facebook and Google because they wanted to put the whole org inside a single repo, which broke the assumption where decentralization in git would happen (repo level, not subtree level). Now it seems that another assumption is broken, that you wanted a version control system, not a snapshot or a rolling log.
zobzu 17 hours ago [-]
Everytime you use sites it should record the code, for example. machine speed code needs machine speed vcs.
bijowo1676 17 hours ago [-]
becuase devs stop coding by hand and start prompting AI even for smallest of tasks, for example "hey codex, check grafana alerts and tell me x, y, z" instead of navigating it by hand and figuring out in grafana UI
5petabytesofwha 15 hours ago [-]
This wouldn't generate more lines of git tho, unless if they are committing markdown documents of everything. With images. Which... Why? Why be so ludicrously wasteful?
cynicalpeace 9 hours ago [-]
So the information can be easily read by the ai agent in the future. See it as a form of indexing.
bomewish 16 hours ago [-]
Yes. Because terminal is a universal interface and this is more convenient.
simlevesque 19 hours ago [-]
It's the billions of scripts we used not to commit. And billions more.
redox99 18 hours ago [-]
RL environments
neutronicus 11 hours ago [-]
They’re designing custom silicon and solving millennium problems, maybe some of this code is in support of that.
Can’t roll out fusion powered data centers in 2030 without a simulation engine.
Sol- 14 hours ago [-]
Realistically, lots of it is probably also just duplication. Why adhere to DRY and abstractions if the LLM can just regenerate relatively low level code whenever I need it? I don't even mean this in a disparaging way or anything, I found myself falling into the same habit of just generating very problem-specific tools and processing pipelines.
Of course, then the question is if it's even worth committing them - you might as well just commit the design spec and let the model generate ephemeral code to run this whenever you need it. For now, I almost consider committing generated code a caching step in some sense, so you don't have to spend the tokens and time to generate it again.
Once super fast and super cheap tokens become more ubiquitous, however, I expect this to change.
olmo23 13 hours ago [-]
> I almost consider committing generated code a caching step in some sense
What about user testing though?
19 hours ago [-]
7e 19 hours ago [-]
It's AI slop. AI coding agents write much more voluminous code, in my experience. The base code is more expansive, and there are more tests, and there are many, many more commits as you keep fixing and fixing and fixing over and over and over.
rogerrogerr 19 hours ago [-]
I'd bet money they're capturing every change made by any agent, not just at the end of a 'task' (or even a turn). Free training material volume to see what was changed and then what was changed later in the same turn to fix the mistakes introduced.
piyh 19 hours ago [-]
If they allocate more compute internally than they sell on subs & APIs, then they should be generating more code than all the customers they sell to combined.
static_motion 16 hours ago [-]
Don't forget the ridiculously long-winded comments.
nullsanity 19 hours ago [-]
Anyone who has fallen into the ADR pit with agents could tell you this. Its just slop, slop to fix slop, docs about slop, slop to fix the docs, etc. 600 commits and 200k LOC/Docs for software that used to be 15 commits and 10k LOC +README and no real value to be found.
Or it's yet another iteration to get another test with overbuilt providence catalogling, boated code, overbuilt nonsense. Suddenly you're 2.5 Billion tokens deep and you just wonder "What the actual Feck did they do, how did they burn that many tokens? It's just a web app with a plugin system, my god."
antupis 16 hours ago [-]
I think it's more that agents gaslight you to believing that timezone from Baker Island and Howland Island is most important issue ever and needs that 1k exception.
direwolf20 18 hours ago [-]
Agent Detection and Response?
skydhash 17 hours ago [-]
Architecture Decision Record [0], the formal version of the Jira ticket.
I've seen it on other workplaces, but from what I see from open ai and anthropic, the code shouldn't be as extended.
But maybe I'm crazy lol
paxy 20 hours ago [-]
While I don't have any particular interest in the topic this is a great blog post. No AI in every second line, no needless marketing or hype. Just a bunch of engineers talking in their own voice about a topic in great detail with numbers, charts, visualizations.
awestroke 16 hours ago [-]
Naive to think you can tell whether a human or their unreleased model wrote this
Rapzid 15 hours ago [-]
Defeatist to believe you can't
pksunkara 19 hours ago [-]
I don't see benchmarks anywhere in here. For example, how many pushes per second does this handle? And how many concurrent pushers? etc..
Haha, I'm also building a code forge (at eol.sh, just a placeholder is there now). I like that you don't look like yet another Github clone, which is my primary frustration with the alternatives.
nextaccountic 15 hours ago [-]
Is this related to jujutsu? It's not mentioned in the landing page (and oddly enough, Git isn't either)
pksunkara 15 hours ago [-]
Jujutsu is mentioned as one of the features we support down the page. And since we plan to support both git and jujutsu, there's no specific mention on VCS
nextaccountic 13 hours ago [-]
Ok I missed this. But Git should be mentioned as well I think
3pm 18 hours ago [-]
You might be missing the point.
cadamsdotcom 14 hours ago [-]
> under-appreciated feature of the Git protocol, `packfile-uri`, allows a server to return links to download additional packs separately ... Pando uses this exclusively ... To support this feature, OpenAI contributed a number of improvements to `packfile-uri`
Yes! Great adaptation of an existing system, showing why open source is special.
Neat hack, OpenAI engineers!
3pm 19 hours ago [-]
> We built Pando with Codex, moving from kick-off to production, in just 10 weeks. The core of Pando was designed by a single engineer, implemented by teams of agents, and deployed by a handful of engineers. Pando began serving production traffic in April of this year, and is one part of a larger system of source control management tools used at OpenAI.
Impressive!?
LunaSea 17 hours ago [-]
About 7x longer than Linus took to develop Git.
Tadpole9181 17 hours ago [-]
It is truly a strange time to be alive. I've made systems in the past month that I've wanted to do for years, and they're astronomically better than I would have been able to rush together had I found the time. And I'm even trying to be tempered and work out more careful approaches to some of the folks I've seen.
wrxd 14 hours ago [-]
It's always the monorepo people who hit git performance issues. I wonder why
JackSlateur 11 hours ago [-]
Because monorepo people are embracing the light, while the other are stuck in darkness ? Who knows;
yangcheng 18 hours ago [-]
growing out of Git seems like a graduation for becoming top tech companies. Google and Facebook have done this in the past. now Anthropic and openAI.
chris_money202 12 hours ago [-]
And then you have companies like Microsoft who invented software development at scale who still use git
The key thing I realized is now I understand why github's infra struggled so much lately.
nihzm 13 hours ago [-]
While technically impressive, the number of git commits without looking at the content is either a loose proxy for the speed of change of the codebase or a finer time resolution of the changesets. But this says little or nothing about whether this is useful for anything related to their products. So what is this for? They are not employing the same number of engineers as Google, so what is the point of scaling the number of commits? Flooding with git commit messages as "documentation" until the volume becomes unmanageable? Or changing the code at as speed that makes every single engineer lose the overview? I wonder.
bob1029 16 hours ago [-]
Why not use a completely different VCS topology if you are a gigantic trillion dollar behemoth? Why are we still using the "distributed" git concept as the basis for everything?
Centralization is exactly what you want at this kind of scale. The most marginal participation from the server would make a huge difference.
There is a reason game studios don't use git. It's not just about the large objects.
springtimesun 16 hours ago [-]
Is the increase in commits graph in percentages because it’s fewer than Anthropic’s rate? A case of commit envy?
In all seriousness though I have enjoyed reading these posts. I will never work at this scale, but I like to read how different teams approach problems like this and I do wonder if some of these approaches will trickle down (or up?) into regular practice as everyone is committing more and faster.
cadamsdotcom 15 hours ago [-]
> On handling a push, Pando validates the incoming packfile while streaming it to blob storage, without unpacking it into a local repository
Wasn't this flagged as a big risk, as it seems to place complete trust in the client?
Especially with all the rogue agents and containment/monitoring failures we have seen in 2026?
Would love to hear how the validation is deemed sufficient.
m0rde 12 hours ago [-]
Not to start a flame war, but this sounds like a problem of monorepos and not git.
If they switched to private packages in separate repos, would that scale better? Would they be hitting the same problems? Would they be hitting different problems?
solyin 11 hours ago [-]
They would be hitting different problems. Taken to a ridiculous opposite extreme, think about your most recent project. Think about having it organized into a separate git repo for every file. One file per git repo. Absolutely ridiculous. You'd need a bunch of glue programs to deal with the pile of git repos you now have. How do you handle the problem of different branches for every file? You need some sort of orchestrator. It's a just a thought experiment so you wouldn't actually do that, but at Google, Facebook, and now OpenAI scale; that gives you some idea of their problem and what they're optimizing for. Orchestrating between a bunch of different repos is a different problem entirely but a monorepo solves a lot of problems while creating others. Some are more solvable than others.
cube00 12 hours ago [-]
This is what always scared me about monorepos. While I'll never reach the scale of big tech it was always a nagging feeling that I'd hit some limit. I know that is less likely to be a problem with smaller component based repos and if something goes wrong only that component is impacted.
zeroq 18 hours ago [-]
Bare in mind that OpenAI|Anthropic (kill me, I can't recall which one), made a massive improvement on their app by... gziping the served content!
armcat 14 hours ago [-]
> Pando now powers all development in OpenAI’s monorepo.
Monorepo. I keep hearing from various folks across the more frontier tech companies, that they have switched to a monorepo to improve agent-scale dev performance. Anyone have similar findings?
perks_12 13 hours ago [-]
The non-agentic coding take is that a monorepo makes code sharing a lot easier. Especially in my case with OCaml front to back, I can just share protocol.mli files between parts of the code without duplication or vendoring my own repos.
The same is really true for agents. All code in one place makes it faster and more reliable to load the proper context for coding tasks.
japgolly 15 hours ago [-]
Interesting that they used both Lean and TLA+. I wish they'd speak more about that. I woulda thought they'd use one or the other. Generally speaking they both do the same thing (prove specs), but in very different ways.
menaerus 14 hours ago [-]
I thought so too. I understand the TLA+ part but Lean not as much.
kylestanfield 16 hours ago [-]
They should move to the Google model. It’s so much nicer not having to worry about all of Git’s complexity and footguns error states.
matt3210 16 hours ago [-]
This is a bad thing. Imagin how huge the attack surface is
matt3210 16 hours ago [-]
This announcement is for business people not engineers.
throwaway27448 20 hours ago [-]
Technical details aside, this volume is ridiculous. How on earth do they see this kind of "growth" as an asset and not a liability?
Instead of keeping it simple, they decided to go stupid.
nullsanity 19 hours ago [-]
[dead]
ralph84 20 hours ago [-]
Because this kind of growth is how they get to RSI.
wilkystyle 19 hours ago [-]
Whereas previously, creating this amount of code by hand would simply result in RSI.
oblio 16 hours ago [-]
They should talk to a orthopedist, in that case.
anal_reactor 15 hours ago [-]
It's an asset because it's a demonstration that their technology works. It would be stupid for them not to tokenmaxx even if that was more efficient. Kinda like you don't want an Apple salesman to be using an Android device.
This thing aside... IDK, I used to think that there's no way to manage such a mess but apparently there is. Or rather, it starts to seem plausible that models will evolve faster than this mess, and once it becomes unmanageable, you can simply ask AI "make it better, no bugs please" and it'll mostly work.
It's becoming harder and harder to justify my own existence as a software engineer. It's surreal that that I dedicated years of study to prepare myself for a job that's being automated away.
Of course the demand for human developers won't drop to 0 but it'll be limited to a handful of industries where even small mistakes are costly, like aerospace. But then let's be real - what percentage of currently employed devs are competent enough to write such code?
throwaway27448 8 hours ago [-]
I have full faith in LLMs to produce code that does something (whether or not it's desired or expected). I have little faith that the engineers (or MBAs) have any clue what they're doing. It'll be interesting to see what parts still exist in ten years and what parts they'll have to light on fire to contain bad assumptions.
rfgplk 13 hours ago [-]
Not really. In fact it's fairly mild given OpenAI's size. For my personal work I've stopped even counting code changes in locs/commits and started looking at disk size changes.
warkdarrior 19 hours ago [-]
> Technical details aside, this volume is ridiculous. How on earth do they see this kind of "growth" as an asset and not a liability?
That coding volume is a liability only for human engineers, with their limited memory, short attention span, tiredness, and quirky coding preferences. LLMs don't have any of those problems.
zdragnar 18 hours ago [-]
Every bit of code is more context getting soaked up in future agent runs. More context used = worse output. More tests need to be written, then fixed, using up more compute, time and context without adding value compared to a more thoughtful, efficient implementation.
warkdarrior 17 hours ago [-]
> using up more compute, time and context
LLM compute is getting cheaper, so one can re-run the coding agent until it produces the desired result.
> without adding value compared to a more thoughtful, efficient implementation
Thoughtful implementations require thoughtful developers, and thoughtful developers cost more money that dumb GPUs.
zdragnar 17 hours ago [-]
It's not just the GPUs that I was referring to, but also the time spent in test runners locally and in CI. There's also the possible runtime cost of extraneous abstractions, but that's beside the point I was getting at.
Thoughtful developers do take money, but so too does shitty code that reaches a point LLMs struggle to maintain. Having both- with the thoughtful developers in charge- is better than just throwing more LLMs at it and hoping for the best.
eddythompson80 16 hours ago [-]
You can't make these argument against the position that all these problems will be solved. Any problem you point to, someone would argue that an LLM can solve. Expensive compute? costs could get 1000x cheaper. Longer context gets worse output? Newer models would solve that. Ever increasing massive codebase? We'll get a 1B or a 1T context window. Time spent in test runners? parallelize, or selectively select tests, or even better; ask the LLM to optimize the tests or develop a 100x faster chips. Runtime cost of extraneous abstractions? Ask the LLM to keep functionality and focus on performance.
If you seriously believe we have "solved coding" or achieved AGI in coding, what is not possible? Any argument you can come up with will be easily dismissed with "we'll just ask the AGI to solve that problem".
zdragnar 6 hours ago [-]
The difference is the first post I replied to used present tense. None of the magic wand thinking applies to the reality of today.
mrbungie 19 hours ago [-]
Not necessarily. High LoC software is a potential bad design smell (without a counterfactual for the same level of functionality it might not be easy to tell though). Badly designed code entering an agent context is always a liability, because it contaminates decisions down the road, and makes new work slower as it needs more tokens to process and navigate old code.
throwaway27448 19 hours ago [-]
Sure, but you also don't know what your LLM is doing without running into these same limitations. So how is this an improvement?
rubikscube09 19 hours ago [-]
who cares what the llm is doing? most of the time when there is disagreement, the llm is right and you are wrong anyways.
throwaway27448 19 hours ago [-]
How would you know?
rubikscube09 18 hours ago [-]
How do I know my calculator is outputting the correct answer to a 10 by 10 digit multiplication problem?
foltik 18 hours ago [-]
Because someone understood and verified it.
Tadpole9181 15 hours ago [-]
Didn't the Postgres team just have to stop a release because the agents found a slew of bugs in human code from domain experts that "understood and verified it"?
Perhaps I'm being overly generous to the parent's point, but it stands to reason that we make a lot of choices of where and how much trust we give away. This is just another one of those points.
Skinney 14 hours ago [-]
I would say that a calculator and a database like postgres differ quite significantly, though. How many PRs are merged per month on your average calculator? How many lines of code is in that firmware?
Trusting that a calculator works is like trusting that there will be another day tomorrow, while trusting the code of an LLM is like trusting that the current weather will hold for the next hour.
Also, LLM finding bugs in human written code doesn't mean it wouldn't find much more in LLM generated code, and spend much more money doing so. That is, of course, after ruling out the false positives (of which there are a few, judging by the PRs I've received on my open source projects)
Tadpole9181 3 hours ago [-]
I think you're getting caught up on a hyperbolic example. I already tried to clarify there's a gradient, so I don't know what you want from this discussion?
simianwords 16 hours ago [-]
And that some one can be an LLM. Does your manager at your job review every line of code you wrote or trust you based on your competence and reviews only a compressed portion?
Frankly, these discussions are tiring because there's a false notion that humans have to be in the loop 100% of the time. This is untrue. LLMs are accurate enough that they can be left to do things on their own and human intervention is needed only for out of distribution instances.
whattheheckheck 15 hours ago [-]
Obviously there will be a maximum hit and then there will be no one to ask to solve your problem and youre gonna be up a creek
skydhash 11 hours ago [-]
> Does your manager at your job review every line of code you wrote or trust you based on your competence and reviews only a compressed portion?
The manager always has a very good stick: “Do a good job or you will be fired”. And me wanting food is well aligned to not produce buggy code. Or make my job harder in the future by writing unmaintainable code.
> Frankly, these discussions are tiring because there's a false notion that humans have to be in the loop 100% of the time
The code is written to process data. Someone needs to be aware of how it’s processed, so that when malformed data appears, we can collectively find where it happens. You can always play around with your own data (if regulation allows) but you need to respect your customers’ data. Not looking at the code jis just negligence.
simianwords 10 hours ago [-]
> The manager always has a very good stick: “Do a good job or you will be fired”. And me wanting food is well aligned to not produce buggy code. Or make my job harder in the future by writing unmaintainable code.
You are welcome to not use the model if it makes mistakes. Its weird that you are cooking up some edge case scenario to make your argument strong - everyone is incentivised to make things work well. Anthropic wants their models to perform well because that's why you will buy it.
> Someone needs to be aware of how it’s processed, so that when malformed data appears
Eh no. You need to know about only a compressed part of it, not 100%. Do you really claim that you need to know 100% of the code? This is not true today and certainly won't be true in the future. Hardly any code will be looked at by humans in the same way my manager doesn't look at my code.
skydhash 10 hours ago [-]
> Anthropic wants their models to perform well because that's why you will buy it.
What Anthropic wants and what happens in reality are two different things. But with code I write, I do control the process.
> Eh no. You need to know about only a compressed part of it, not 100%. Do you really claim that you need to know 100% of the code?
I know the code I write, and I know how it interfaces with external modules. When those interfaces don’t function as described, I look at the code if I have access to it. When I don’t, the party in control has always good incentives to produce good documentation. That knowledge is usually good for some time (years even)
> my manager doesn't look at my code
Because that’s not his responsibility, just like he’s not responsible for bugs and crashes. He’s responsible for the project and the team and you can be pretty sure that he’s looking at all at the information about those. Imagine if his own manager ask him about some details and he answers: “I don’t know, Claude is doing it”.
direwolf20 16 hours ago [-]
It's an LLM. It is by definition smarter than you, and my shareholders know it.
19 hours ago [-]
simianwords 16 hours ago [-]
I'm not sure why this is downvoted. This is the correct answer. Code is mostly written by and for agents with the option for humans to read it from time to time.
This kind of fallacy keeps repeating time and time again. Another version of this fallacy goes like this: "agents can create a lot of code but humans have to review each PR anyway so reviewing is a massive bottleneck". This doesn't make sense because reviewing is also done by agents and humans don't have to read every line.
LtWorf 11 hours ago [-]
I think you guys forget that ultimately the goal of products is to have people use them.
Who is this code helping?
pydevgo 13 hours ago [-]
how many commits we are talking about here?
winrid 12 hours ago [-]
More than two
bhouston 19 hours ago [-]
Another way to avoid having to maximize download speed is to use a global git cache per machine in a similar way that pnpm optimizes installing packages:
This doesn't work if the pulls are happening in swarms of ephemeral sandboxes.
Also, maybe FUD, but is there anything useful to learn from (p)npm other than cautionary tales?
eddythompson80 16 hours ago [-]
There is always something useful to learn, even if it's a mistake. pnpm in particular centralizes your packages, and symlinks them to each project that needs them, which cuts down on file copy and disk usage significantly. The same principle could be applied to cargo/rust, python venvs, dotnet, or even large C++ projects could improve their disk usage and file copy significantly if they followed the same idea. Why do you have to have a massive target folder in every rust project if all that could live in a hash addressable shared store. Its the same basic idea of CoW or deduping file systems, but done in the application for far better result.
bhouston 9 hours ago [-]
> This doesn't work if the pulls are happening in swarms of ephemeral sandboxes.
This is incorrect.
It actually will work if you mount a drive. Github mirrors can be on separate drives. Now I haven't fully tested it's safety in that situation yet, like I have with local dev on Windows and MacOS.
> Also, maybe FUD, but is there anything useful to learn from (p)npm other than cautionary tales?
This is also incorrect.
Denigrating pnpm's well regarded optimizations because NPM packages have vulnerabilities unrelated to NPM is missing the point.
mohsen1 11 hours ago [-]
[flagged]
maxkaya 13 hours ago [-]
[flagged]
creatune 16 hours ago [-]
[flagged]
ReDress 12 hours ago [-]
[dead]
Jeeetendra 7 hours ago [-]
[flagged]
rheisen_ 18 hours ago [-]
Scaling Git Operations at Xavi Group /s
Over the last few months at Xavi Group, our team of one engineer has gone from ~1k commits a day to ~100k commits per day as a result of debilitating financial decisions and exponentially increasing agentic workflow capability. Our internal Gitea services began to get bogged down by our proprietary frontier coding agent (internal codename `xavi-polaris`) refactoring the monorepos comprising our three flagship projects, one of which of course is our widely unknown RSI harness project.
(At this time we are not accepting any additional requests for our closed private beta, unless you ask reaaaalllyyy nicely $$$)
These demands were increasingly straining our S3 bucket capacity (petabyte scale) and our CI/CD pipelines (3 DO droplets, a macbook mini, and a legacy windows server possibly compromised). Most critically it was straining the agentic wellfare of Xavi sessions themselves, which began to flag push/pull latencies that were taking so long their caches would go cold between tool calls, resulting in even greater financial hardship.
`xavi-polaris` sess-3LQGgyUxLGXiV7OTTIMo4TWm0a6 is credited with identifying that this unprecedented pace was unsustainable, with projections that by mid 2027, commits per day could be north of 1 billion as monorepo sizes increased and refactoring became increasingly challenging despite the profound software engineering capabilities unlocked by the RSI harness project.
To identify solutions, we first looked to ensure we wouldn’t reinvent the wheel we were reinventing. We noted projects at Google, Anthropic, and OpenAI that recently aimed to address the very same challenges, but after ~20k USD in session research that incidentally solved an open conjecture in statistical analysis, we decided that adopting any of these existing protocols would limit Xavi sessions in our internal promotion benchmarks that enable “contributor” sessions to progress to “lead” sessions, irrevocably inhibiting our expansion of upper agentic management.
AGIt is a drop in replacement for Git, which we identified as being critically important because xavi sessions are deeply familiar with git commands as a result of a massive distillation and theft of proprietary data. AGIt utilizes novel CRDT and distributed systems technology built from our extensive experience with scaling distributed systems off the back of YJS. If that doesn’t make any sense to you, it didn’t make any sense to the individual human engineer at Xavi Group either.
Importantly, we don’t believe it needs to. The future is agentic workflows, and we’re excited to continue giving back to the nursery that birthed our projects and has delivered at scale for almost every other software company on the planet. We’ll be donating five `xavi-polaris` teams to pumping PRs as fast as possible to these open source projects. As we enter this new era we’d like to thank contributing sessions sess-3LQKRQrJUyAvYHlUDJcjos2CInf and sess-3LQKRnqna2emLvyUyPUqSEIaUh0, their teams were instrumental in this endeavor, and both will be promoted from “lead” to “steward” to reflect their tenacity in building this system over the last few hours.
amarlearning 16 hours ago [-]
[flagged]
tvbusy 16 hours ago [-]
Scaling software development at Huge AI Company /s
We at Huge AI Company has surpassed human capabilities of software development. Git can no longer keep up with our development cycle and we're proud to announce that we're moving to Wish Driven Development.
Unlike Anthropic or OpenAI where no single engineer has any idea what they're doing and still uses pathetic source tracking, we have implemented an evolution and moved on to the next stage with our AGI: Wish Driven Development.
Our engineers, now called Wish Whisperers, open pull requests to add wishes to a controlled environment where all our wishes are stored in a Wish Registry. Swarms of agents are then dispatched to validate these wishes and when the pull requests are merged, implement these wishes directly in production.
Our productivity has significantly gone up, so much so that our Wish Whisperers are now running their own Wish Registries to automate their wishing speed.
To be frank, we still have no idea what we are doing but this is AGI level productivity and it's all that matters at the end of the day.
firemelt 19 hours ago [-]
lol nice try openai but its shallow and too late
vatsachak 20 hours ago [-]
Impressive. We're definitely seeing LLMs help create real novel software
- Cursor: https://cursor.com/blog/git-at-any-scale
- GitHub: https://github.blog/engineering/architecture-optimization/bu...
- Anthropic: https://www.anthropic.com/research/redesigning-source-contro...
- GitHub: https://github.blog/engineering/architecture-optimization/th...
Maybe also tangentially East River Source Control's too: https://ersc.io/blog/what-comes-after-git.
I'm wondering how much cross-pollination of ideas and subsequent implementation details there are between people working at these companies. It does seem like all of this could potentially converge.
Which would support your argument, but I don’t think this is particularly new.
I think their article reads a bit differently, they haven't optimised git, they've ditched it in favour of a new ~~CVS~~ VCS.
I don't think so, their article says they were seeing 30,000 commits a day in September, when I was at Meta six years ago they were easily doing that.
Seventh, at least, all the major code forges are on it: https://about.gitlab.com/blog/scaling-git-for-the-agentic-so...
Entire also seems focused on this: https://entire.com/news/entire-launches-distributed-git-netw...
Supposedly they started gzipping the conversations.
On the other hand, some lower-level tools have to be simple, reliable and efficient. Here, sharing is critical. Even the authors of the post shared some incremental improvements to git. Here, the scalability story is moot.
I think git is becoming a protocol. One product can no longer cover these cases.
I am watching OpenAI's output, and while a lot of it is absurdly impressive, I can not even begin to imagine what kind of activity of theirs justifies a through-output of 5 petabytes of -GIT COMMITS-. That's not their data sets, that's not their models, that's not their math library. That's their code.
They're rengineering Git for scale, but like, why is there a demand for scale at all? If i saw an employee flipping the same number on an excel file over and over, I'd fire them, and yet they're perfectly happy running agents that do that and setting up meetings and writing blogposts about how much they improved their spreadsheet number randomization factory.
The point of my response is that the analogy was broken without saying what adding those pages could provide.
The analogy isn't broken. Your objection didn't really make sense, because adding pages to the tax code makes the tax code strictly more complicated. Your response just ignored the case where that complexity actually matters.
Why would the volume that any of this be increasing exponentially? And what are all the engineers doing when (besides the model quality) their products don't seem to be changing very much?
As a user of Astra, it writes code that appears to work. It does not necessarily write sensible code that is architected in a way that makes sense based on what it does. I just watched it do a major rework of a couple thousand lines of code by keeping the original organization and kludging up an adapter to make old code have new semantics.
I would expect that this approach, coupled with lots of fun asking for changes and none of the grunt work of actually thinking about the result, could result in exponentially increasing amounts of mess.
I haven’t used a recent Anthropic model - maybe it’s better at this.
just exercise. it will be ok, really. somehow we managed for millions of years, kiddos, and both gravity and the human body are unchanged in any relevant way since which suddenly requires "an app". I can get out of bed without an app, or an AI. I can prepare a meal and eat without any kind of app, or any kind of AI or LLM. its a true and real thing, in the real world, promise!
I would have loved to have all that in an app over the last 25-30 years so I could see my progress.
There are tons of different conditions people are in, with different histories of injuries, etc. and even people without any issues benefit massively from having a sensible, well structured workout plan that ensures their weaknesses are addressed and they work towards their personal goals. You don't need AI, an app or a personal trainer for that but while many people do enjoy learning a lot about exercising in their (often limited) free time, many don't and it's great if they have an affordable/free option. Why do you think physiotherapy exists?
Additionally, studies have proven that progressive overload is a really important aspect for progressing, so you should be tracking your workouts in some way, in an app or on paper, to ensure you really are challenging yourself.
It writes like it works at big tech and is angling for a promotion to L{n}+1 with this "project".
I hope this practice doesn't die out, or complexity will skyrocket for no reason.
Because the limiting factor for software has always been the supply, not the demand. When the average human engineer would ship 100 lines of production code / week, you could only afford to do the most critical things. But if code gets cheaper to produce, the projects that were marginal become worth doing, and the projects that were obviously insane become marginal. And that's exactly what is happening as models get cheaper and better, leading to the frontier of worthwhile projects expanding rapidly.
> And what are all the engineers doing when (besides the model quality) their products don't seem to be changing very much?
That's got some nice But other than that, Mrs. Lincoln, how was the play? energy to it!
So you think that the move from 4o to Astra required something like 1000x the code to pull off? I find it hard to believe as an MLE, but since I don't work with LLMs I might be wrong about how complicated the implementations have become.
I do know people who work at OAI and it seems like none of them work directly on the models, but that's n=1.
If you are wondering what these changes are, you can take a peek at https://github.com/openclaw/openclaw/commits/main/
This isn't to say that such pace of iteration is good or bad. That's a separate discussion.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
I think it’s simply a matter of dogfooding and new feature development, they do have much higher velocity than companies of equivalent size and an unlimited token budget helps as well.
I do believe this will force the AI labs to eventually solve the bloat problem with AI, but we’re definitely not there yet.
Kernels, performance-required stacks etc. is different, so you optimise them for that.
Give a verifiable benchmark for the AI agent to hit such as reduce token processing time by 5% without affecting output.
It feels like OpenAI and Anthropic have a ton of room to optimizing that regard, but they choose to rather focus on moving the frontier forward than doing things that are already possible in a more efficient way.
It's better than the ductape and glue pipelines that we had previous to this.
The software is the definition of plumbing no one cares about and testing it is trivial.
many yaks to shave. many bikesheds to paint.
if you're paid by the line, why not go to town...
In doing so, they obviously need to keep track of the myriad of changes, hence the requirement to ensure Git can scale up.
(I'd like to think /s, but you know what, maybe not)
Surely it's obvious?
Slop cannons firing at a rate so high no human can hope to restrain them.
Such a colossal volume of slop that even the most well engineered, efficient technology on the planet, written by one of the greatest coders of all time, is no longer sufficient to contain it.
And git is enough to version control some of the most complex software like the Linux Kernel, the FreeBSD operating system, QEMU, browsers like Firefox,... Git was insufficient for Facebook and Google because they wanted to put the whole org inside a single repo, which broke the assumption where decentralization in git would happen (repo level, not subtree level). Now it seems that another assumption is broken, that you wanted a version control system, not a snapshot or a rolling log.
Can’t roll out fusion powered data centers in 2030 without a simulation engine.
Of course, then the question is if it's even worth committing them - you might as well just commit the design spec and let the model generate ephemeral code to run this whenever you need it. For now, I almost consider committing generated code a caching step in some sense, so you don't have to spend the tokens and time to generate it again.
Once super fast and super cheap tokens become more ubiquitous, however, I expect this to change.
What about user testing though?
Or it's yet another iteration to get another test with overbuilt providence catalogling, boated code, overbuilt nonsense. Suddenly you're 2.5 Billion tokens deep and you just wonder "What the actual Feck did they do, how did they burn that many tokens? It's just a web app with a plugin system, my god."
[0] https://martinfowler.com/bliki/ArchitectureDecisionRecord.ht...
I've seen it on other workplaces, but from what I see from open ai and anthropic, the code shouldn't be as extended.
But maybe I'm crazy lol
Disclaimer: I am building a code forge at https://juju.bi
Yes! Great adaptation of an existing system, showing why open source is special.
Neat hack, OpenAI engineers!
Impressive!?
Centralization is exactly what you want at this kind of scale. The most marginal participation from the server would make a huge difference.
There is a reason game studios don't use git. It's not just about the large objects.
In all seriousness though I have enjoyed reading these posts. I will never work at this scale, but I like to read how different teams approach problems like this and I do wonder if some of these approaches will trickle down (or up?) into regular practice as everyone is committing more and faster.
Wasn't this flagged as a big risk, as it seems to place complete trust in the client?
Especially with all the rogue agents and containment/monitoring failures we have seen in 2026?
Would love to hear how the validation is deemed sufficient.
If they switched to private packages in separate repos, would that scale better? Would they be hitting the same problems? Would they be hitting different problems?
Monorepo. I keep hearing from various folks across the more frontier tech companies, that they have switched to a monorepo to improve agent-scale dev performance. Anyone have similar findings?
The same is really true for agents. All code in one place makes it faster and more reliable to load the proper context for coding tasks.
This thing aside... IDK, I used to think that there's no way to manage such a mess but apparently there is. Or rather, it starts to seem plausible that models will evolve faster than this mess, and once it becomes unmanageable, you can simply ask AI "make it better, no bugs please" and it'll mostly work.
It's becoming harder and harder to justify my own existence as a software engineer. It's surreal that that I dedicated years of study to prepare myself for a job that's being automated away.
Of course the demand for human developers won't drop to 0 but it'll be limited to a handful of industries where even small mistakes are costly, like aerospace. But then let's be real - what percentage of currently employed devs are competent enough to write such code?
That coding volume is a liability only for human engineers, with their limited memory, short attention span, tiredness, and quirky coding preferences. LLMs don't have any of those problems.
LLM compute is getting cheaper, so one can re-run the coding agent until it produces the desired result.
> without adding value compared to a more thoughtful, efficient implementation
Thoughtful implementations require thoughtful developers, and thoughtful developers cost more money that dumb GPUs.
Thoughtful developers do take money, but so too does shitty code that reaches a point LLMs struggle to maintain. Having both- with the thoughtful developers in charge- is better than just throwing more LLMs at it and hoping for the best.
If you seriously believe we have "solved coding" or achieved AGI in coding, what is not possible? Any argument you can come up with will be easily dismissed with "we'll just ask the AGI to solve that problem".
Perhaps I'm being overly generous to the parent's point, but it stands to reason that we make a lot of choices of where and how much trust we give away. This is just another one of those points.
Trusting that a calculator works is like trusting that there will be another day tomorrow, while trusting the code of an LLM is like trusting that the current weather will hold for the next hour.
Also, LLM finding bugs in human written code doesn't mean it wouldn't find much more in LLM generated code, and spend much more money doing so. That is, of course, after ruling out the false positives (of which there are a few, judging by the PRs I've received on my open source projects)
Frankly, these discussions are tiring because there's a false notion that humans have to be in the loop 100% of the time. This is untrue. LLMs are accurate enough that they can be left to do things on their own and human intervention is needed only for out of distribution instances.
The manager always has a very good stick: “Do a good job or you will be fired”. And me wanting food is well aligned to not produce buggy code. Or make my job harder in the future by writing unmaintainable code.
> Frankly, these discussions are tiring because there's a false notion that humans have to be in the loop 100% of the time
The code is written to process data. Someone needs to be aware of how it’s processed, so that when malformed data appears, we can collectively find where it happens. You can always play around with your own data (if regulation allows) but you need to respect your customers’ data. Not looking at the code jis just negligence.
You are welcome to not use the model if it makes mistakes. Its weird that you are cooking up some edge case scenario to make your argument strong - everyone is incentivised to make things work well. Anthropic wants their models to perform well because that's why you will buy it.
> Someone needs to be aware of how it’s processed, so that when malformed data appears
Eh no. You need to know about only a compressed part of it, not 100%. Do you really claim that you need to know 100% of the code? This is not true today and certainly won't be true in the future. Hardly any code will be looked at by humans in the same way my manager doesn't look at my code.
What Anthropic wants and what happens in reality are two different things. But with code I write, I do control the process.
> Eh no. You need to know about only a compressed part of it, not 100%. Do you really claim that you need to know 100% of the code?
I know the code I write, and I know how it interfaces with external modules. When those interfaces don’t function as described, I look at the code if I have access to it. When I don’t, the party in control has always good incentives to produce good documentation. That knowledge is usually good for some time (years even)
> my manager doesn't look at my code
Because that’s not his responsibility, just like he’s not responsible for bugs and crashes. He’s responsible for the project and the team and you can be pretty sure that he’s looking at all at the information about those. Imagine if his own manager ask him about some details and he answers: “I don’t know, Claude is doing it”.
This kind of fallacy keeps repeating time and time again. Another version of this fallacy goes like this: "agents can create a lot of code but humans have to review each PR anyway so reviewing is a massive bottleneck". This doesn't make sense because reviewing is also done by agents and humans don't have to read every line.
Who is this code helping?
https://git-dedup.ben3d.ca
Also, maybe FUD, but is there anything useful to learn from (p)npm other than cautionary tales?
This is incorrect.
It actually will work if you mount a drive. Github mirrors can be on separate drives. Now I haven't fully tested it's safety in that situation yet, like I have with local dev on Windows and MacOS.
> Also, maybe FUD, but is there anything useful to learn from (p)npm other than cautionary tales?
This is also incorrect.
Denigrating pnpm's well regarded optimizations because NPM packages have vulnerabilities unrelated to NPM is missing the point.
Over the last few months at Xavi Group, our team of one engineer has gone from ~1k commits a day to ~100k commits per day as a result of debilitating financial decisions and exponentially increasing agentic workflow capability. Our internal Gitea services began to get bogged down by our proprietary frontier coding agent (internal codename `xavi-polaris`) refactoring the monorepos comprising our three flagship projects, one of which of course is our widely unknown RSI harness project.
(At this time we are not accepting any additional requests for our closed private beta, unless you ask reaaaalllyyy nicely $$$)
These demands were increasingly straining our S3 bucket capacity (petabyte scale) and our CI/CD pipelines (3 DO droplets, a macbook mini, and a legacy windows server possibly compromised). Most critically it was straining the agentic wellfare of Xavi sessions themselves, which began to flag push/pull latencies that were taking so long their caches would go cold between tool calls, resulting in even greater financial hardship.
`xavi-polaris` sess-3LQGgyUxLGXiV7OTTIMo4TWm0a6 is credited with identifying that this unprecedented pace was unsustainable, with projections that by mid 2027, commits per day could be north of 1 billion as monorepo sizes increased and refactoring became increasingly challenging despite the profound software engineering capabilities unlocked by the RSI harness project.
To identify solutions, we first looked to ensure we wouldn’t reinvent the wheel we were reinventing. We noted projects at Google, Anthropic, and OpenAI that recently aimed to address the very same challenges, but after ~20k USD in session research that incidentally solved an open conjecture in statistical analysis, we decided that adopting any of these existing protocols would limit Xavi sessions in our internal promotion benchmarks that enable “contributor” sessions to progress to “lead” sessions, irrevocably inhibiting our expansion of upper agentic management.
We’re proud to introduce our new, closed source Git model: AGIt.
AGIt is a drop in replacement for Git, which we identified as being critically important because xavi sessions are deeply familiar with git commands as a result of a massive distillation and theft of proprietary data. AGIt utilizes novel CRDT and distributed systems technology built from our extensive experience with scaling distributed systems off the back of YJS. If that doesn’t make any sense to you, it didn’t make any sense to the individual human engineer at Xavi Group either.
Importantly, we don’t believe it needs to. The future is agentic workflows, and we’re excited to continue giving back to the nursery that birthed our projects and has delivered at scale for almost every other software company on the planet. We’ll be donating five `xavi-polaris` teams to pumping PRs as fast as possible to these open source projects. As we enter this new era we’d like to thank contributing sessions sess-3LQKRQrJUyAvYHlUDJcjos2CInf and sess-3LQKRnqna2emLvyUyPUqSEIaUh0, their teams were instrumental in this endeavor, and both will be promoted from “lead” to “steward” to reflect their tenacity in building this system over the last few hours.
Unlike Anthropic or OpenAI where no single engineer has any idea what they're doing and still uses pathetic source tracking, we have implemented an evolution and moved on to the next stage with our AGI: Wish Driven Development.
Our engineers, now called Wish Whisperers, open pull requests to add wishes to a controlled environment where all our wishes are stored in a Wish Registry. Swarms of agents are then dispatched to validate these wishes and when the pull requests are merged, implement these wishes directly in production.
Our productivity has significantly gone up, so much so that our Wish Whisperers are now running their own Wish Registries to automate their wishing speed.
To be frank, we still have no idea what we are doing but this is AGI level productivity and it's all that matters at the end of the day.