fat

lmao - thank you!

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: "diff@example.com" },

  committer: { name: "Diff Bot", email: "diff@example.com" },

  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: "docs@example.com" },

  })

  .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.

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!

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 jacob@pierre.co

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.

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

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 :)

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 jacob@pierre.co

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).

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 jacob@pierre.co

not open access yet, sorry :(

haha <3

all upgrades will be free, once v4 is stable :)

fwiw, we generally just try to do what the language does:

border-radius <- css dashes

document.createElement <- js camel (except constants, etc.)

etc…

I'll probably write up something at length about this decision when/if it happens… but this is the current thinking:

CSS transitions are just total shit to deal with in javascript.

What people often don't realize is that there is an event for transitionEnd in javascript – but this isn't always fired in a reliable way – only when a transition successfully ends (which isn't all the time).

This is incredibly problematic because often really important functionality is tied to the completion of transitions.

Because these functions never finish, sometimes you're left with dead dom nodes or weird incomplete states.

What's more, there isn't a performance benefit to using css transitions – the benefit is that they were suppose to be make transitions easier and provide a nice separation of style from logic – but they end up being incredibly more difficult and because of the necessary fallback logic, the styles end up leaking back into your logic anyways. It's a pain in the neck :/

With bootstrap we really just want to give everyone the most reliable product we can, and css transitions just aren't that.

Also, from what I hear, the spec is basically dead in the water – and a reliable cancel event isn't in the works (unless this has changed in the last month or so)… which is more of a reason to consider alternatives.

Most likely we will end up going with some sort of combination. CSS transitions when we don't need a reliable "complete" event – and css transitions when we don't really care (though this case is becoming more infrequent).

yep, twitter has been great. And mark and i didn't leave to start a bootstrap support company :P

ha, well that is definitely not happening anytime soon…

but, here is a whole thing on "why less" I wrote up about it a long while back, and it still holds true today: http://wordsbyf.at/2012/03/08/why-less/

haha! mark loves these, i think he started doing them way back at zurb.

we took them away because they are hooorible for perf – and were exposing a memory leak bug in chrome i believe

hm… sorry it came off that way. :(

fwiw, the amount of technical things i've learned from working on bootstrap is not proportional to the amount of work i've put into this project… at all. But, i never expected it to be, and that's totally fine.

Have I learned any technical things? lol sure, of course!

Funnily, the accessibility thing you linked to wasn't really something I learned building bootstrap… the presentation was all about how accessibility is too hard to really learn… and you need to become a specialist, which is sad times. Paul Irish wrote a great post about it a while back: http://paulirish.com/2012/accessibility-and-developers/

maybe i learned that i knew nothing, but that was about it :P

My friend Dustin (who created this writing topic on medium) asked me to write about the single most important thing i learned from working on bootstrap.

And for me, that single thing was that I love working with people and hate working alone.

It took me a while to realize that what was bumming me out the most about running bootstrap (and other projects) was that as they became more successful, there was more of an expectation that i would be working on them all the time (which meant the expectation that i would be working on them independently/alone all the time).

That's ok from time to time, but isn't why I get excited about free software and ultimately i became pretty depressed/negative about the whole thing.

I'm just now starting to identify what makes we want to continue to dedicate all my free time to a project like bootstrap. And right now, the main motivation is to spend time creating stuff with my favorite people.

I can assure you – it's definitely not to learn more about css/js !! :)

yep, lots of legal hurdles to go through – took us like 6 months – but now they have a full time opensource shepherd @cra which makes this much smoother

aww <3

right now it's under the Apache License v2 – but we're working to move it to MIT for 3.0.0

I think of the community as owning bootstrap at this point… maybe that's cheesy? Or naive…

I also think twitter played a larger roll than just hardware. Mark and I were both deeply embedded into the twitter culture (with access to great resources and really smart engineers to bounce ideas off of) and i think bootstrap has a very "twittery" feel as a result.

Mark and I built bootstrap while we were employed at twitter on twitter hardware. Also, undeniably it was largely influenced by our work there (and later would largely influence a lot of the code at twitter as well as power lots of projects both internally and publicly) – but it was never a company mandated project. It was something that Mark and I came up with on our own and pursued outside of work hours.

awesome! This is exactly what we were running into too :D

aww no problem :) Hope it's useful!

why would you name something after an already successful project with the same name.

face palm

this was switched up a bit today. That said - for the ladies out there - girls can be bros. total bros.

yeah we felt the same way, but we're trying to move off of mustache.js for performance reasons (also for size in our new tweet embeds projects).

lol sorry, i'll take the blame for that.

The link was originally just a placeholder for our awesome designer @dhg (who rocked the site in like an hour).

I missed the link before it got pushed, and forgot to swap it out.

When first published it didn't even point to an actual js page. :(

Anyways, I've fixed the redirect, but should have just removed the link all together. I've updated it now to point directly to github.

The main reason that we're using github to host this (and bootstrap) rather than a proper cdn is because it makes publishing new versions super fast and easy.

Of course we don't recommend that you hotlink from github for any serious application. You should bundling these with your other assets :)