HN

Comments (115)

• Menu

  usrme
  By my count, this OpenAI post is the fifth major article on the topic of scaling, with the previous four being:- 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.
• Menu

  bigmadshoe
  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?
• Menu

  paxy
  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.
• Menu

  pksunkara
  I don't see benchmarks anywhere in here. For example, how many pushes per second does this handle? And how many concurrent pushers? etc..Disclaimer: I am building a code forge at https://juju.bi
• cadamsdotcom
  > 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!
• Menu

  yangcheng
  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.
• cadamsdotcom
  > On handling a push, Pando validates the incoming packfile while streaming it to blob storage, without unpacking it into a local repositoryWasn'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.
• bob1029
  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
  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.
• japgolly
  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.
• Menu

  3pm
  > 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!?
• zeroq
  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!
• kylestanfield
  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.
• aizk
  The key thing I realized is now I understand why github's infra struggled so much lately.
• matt3210
  This is a bad thing. Imagin how huge the attack surface is
• matt3210
  This announcement is for business people not engineers.
• Menu

  throwaway27448
  Technical details aside, this volume is ridiculous. How on earth do they see this kind of "growth" as an asset and not a liability?
• Menu

  bhouston
  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:https://git-dedup.ben3d.ca
• creatune
  [flagged]
• tvbusy
  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.
• amarlearning
  [flagged]
• rheisen_
  Scaling Git Operations at Xavi Group /sOver 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.
• firemelt
  lol nice try openai but its shallow and too late
• vatsachak
  Impressive. We're definitely seeing LLMs help create real novel software