fat · HackerTrans

letzten Monatdiscuss

lmao - thank you!

vor 5 Monatendiscuss

Sure – our API is built specifically for common LLM workflows. Here's a great example.

LLMs are often used for changing code. If an LLM creates a patch that touches 10 files, you need to take the following steps to save that patchfile on GitHub using their rest API.

.

1. Get the base branch SHA

2. Create a new branch (ref)

3. Create blobs (one per file… 10 blobs!)

4. Create a tree containing those 10 file changes

5. Create a commit

6. Update the branch ref to point to the new commit

7. Pull the GitHub api until it stops returning 422's (an eventual consistency issue when GitHub is under high load)

.

About 15 total requests…

With code.storage you just post the complete diff:

```

const result = await repo.createCommitFromDiff({

  targetBranch: "my-branch",

  commitMessage: "Apply generated SDK patch",

  author: { name: "Diff Bot", email: "[email protected]" },

  committer: { name: "Diff Bot", email: "[email protected]" },

  diff,

});

```

or better you can stream us your updated files, and we'll apply the diff for you.

```

const result = await repo

  .createCommit({

    targetBranch: "main",

    commitMessage: "Update dashboard docs",

    author: { name: "Docs Bot", email: "[email protected]" },

  })

  .addFileFromString("docs/changelog.md", "# v2.1.0\n- refresh docs\n")

  .addFile("public/logo.svg", await fs.readFile("assets/logo.svg"))

  .deletePath("docs/legacy.txt")

  .send();

```

On top of ergonomics, we have first class APIs for git notes, grep, get archive (include/exclude by blob), and other filesystem behavior that is exceeding helpful when working with LLMs.

fat

vor 5 Monatendiscuss

Git is ~ really ~ great at document storage :P

We have folks using us to back crms, design tools, and all kinds of "non-code" stuff.

Please reach out - would love to connect!

fat

vor 5 Monatendiscuss

To be fair to GitHub (which i have a lot of love and respect for), we're building very different products.

GitHub is a social consumer coding product first. There's user models, review and discussion primitives, ci, etc.

Code Storage is just a headless, api-first infra product. No users, no review primitives, no rate limits, etc.

Our company is obsessively focused on only 3 things:

1. reliability at scale 2. performance 3. code api surface

happy to dive into any of these in more detail if you want to shoot me over an email [email protected]

fat

vor 5 Monatendiscuss

We're actually meant to be less of a consumer product than i think you mean by this (but i may have misunderstood).

We're more targeting enterprise as storage infrastructure provider – selling directly to platforms who generate a bunch of code and need a place to put it.

end users wont really know we exist.

fat

vor 5 Monatendiscuss

thanks for the feedback – we definitely have work to do on communicating what we're up to.

Sorry about the audio - will get that patched

fat

vor 5 Monatendiscuss

Ahh good question…

Here's the timeline if you're interested.

3 years ago we started building a direct competitor to GitHub with the theory that you need to build code storage, code review and CI to truly compete.

We spent about a year prototyping this all out, raised some money, and then started building this for real [tm].

Code storage felt like a HUGE moat for GitHub. Most of our competitors in the code review space:

- graphite - linear - (now cognition) - etc

All built directly on GitHub's apis – but we wanted to go down to the metal (something wrong with us).

A year and half into doing this, a few folks reached out and asked how we were scaling git… i waved my hands around a bunch and explained how hard of a distributed systems problem scaling git was… explained git three-phase commits, etc.

Fast forward a few more months, and we started standing up single tenant clusters of our infra for a few different codegen companies that also needed storage solutions.

And now here we are :)

fat

vor 5 Monatendiscuss

planning to share more in the next month or so :)

But have been slowly signing folks up – if you want to shoot me an email, can get you setup [email protected]

fat

vor 5 Monatendiscuss

pretty much - low friction git* repos for massively parallelized agentic use.

(can think of it kinda like what stripe does for payments… headless git infra, where you get an api key, and store / create as many repos as your customers need).

fat

vor 5 Monatendiscuss

Hey everyone,

Wow, you scooped us! we weren’t really expecting to launch here just yet, but happy to answer any questions y’all have :)

First, Pierre is building code storage for machines -- think GitHub’s infrastructure layer, but API-first and tuned for LLMs.

What does that actually mean? We’ve spent the last 18+ months speed running GitHubs infrastructure (with a lot of help from early GitHub folks)… this is Github’s spoke architecture with a few modern twists + object store for cold storage.

Up until this point, GitHub is the only team that’s built a truly scalable git cluster (gitlab, bitbucket, etc. are all enterprise plays, with different tradeoffs).

Code.Storage is meant to be massively scalable… and we’ll be doing a larger post on what that means, and the scale we’re already doing soon hopefully :)

On top of this, we’ve invested a TON of time into our API layer – we have all the things you’d expect, list files, create branch, commit, etc. – with some new api’s that agents have found helpful: grep, glob based archive, ephemeral branches (git namespaces), etc.

Right now we’re in private beta – but happy to do my best to answer any questions in the short term (and if you’re working on anything that might benefit from code storage or storing code like artifacts – please reach out to [email protected]

fat

vor 5 Monatendiscuss

not open access yet, sorry :(

comments