GitHub is the wrong shape for this new world
depot.dev
depot.dev
Well yes but git itself is the tool at the base of the pyramid you call GitHub and co. It seems you actively want git to look like all the other things you are used to and they are all walled gardens.
GitHub takes git and basically turns it back into subversion and co. Instead of all that anarchic "no repo is king" long haired hippie nonsense, you want central control 8) I do too but only within my company, so we use gitea (other git control freak enablement platforms are available).
Why not go back to basics and start with git? Just git. Add a comms channel - it can be telephone, SMS, email, Slack, semaphore or smoke signals. Then add stuff on top of the basics and see what happens.
Quite a large project works like that already. You might have heard of Linux.
Or stick with a canned effort like GitHub (I use it for some things) and accept that you get what you are given if you abrogate your options to someone else.
One of the greatest features of git is that it is not reliant on a centralized repo! Why graft centralization onto a tool that doesn't want it?
The non-git features of GitHub, like actions and CI and the issue tracker and all that stuff are fine, but I'd argue don't really belong as part of your source control system. If you need that stuff, you should be able to pick and choose the tools you want to use, rather than just live with whatever GH gives you. But they really have nothing to do with git.
I contend that issues/tickets are as much a part of the code as comments and commit messages, and tightening the link is valuable, especially when you need to decide whether to take down an old fence. Which is a conundrum, because I agree about choosing your tools.
git for code management
something else for discussion of that management
When people start thinking about what it would take for their friend to pull their repo from their home computer, they almost always decide they'd rather let Microsoft host some of their code for ~free. Actually making code accessible from a computer you own on the Internet takes way more money, time, and risk than whatever you'll pay them.
I mean how do you handle authorization and connectivity from remote clients, you go to a PGP key signing ceremony and set up a firewall and buy a static IP and/or domain and host it on a server?
Maybe instead you use some signin technology designed for centralized enterprises to manage, and a third party idp host, or a vps on someone's cloud signing access tokens? If you send it over email on a domain you don't own then you're strictly worse off, because a big company is getting all your code anyway and you made everything more annoying for no benefit. Do you also host your own email, and rotate ssh keys across all your devices, and set up linux users on your friends' servers or your various personal-use servers across the world, in the year of our lord 2026?
If you're just making code accessible as read-only files accessible over the Internet it's a little easier, you get hammered by bots and humans will probably never discover it organically unless you're a centralized company, but at least you don't have to let anybody try to authenticate. You can argue that it's still technically distributed, but not in the way people mean when talking about version control, unless you think Facebook is also distributed.
TBH I can't see how anybody who has even considered letting people use ssh keys to push code to a personally-owned/operated internet-exposed server, for anything that mattered enough to care, and say that git "doesn't want" centralization.
But, even though the Linux the project created git specifically for their own workflow, and is in the running for the largest and most complicated decentralized software project ever known, they still operate git.kernel.org. They still have a central master repository server.
Just because git clone gets you a first class copy of the repository doesn't mean you don't need a source of truth or a centralized master to operate and coordinate the project. Control is not the totality of the benefits of centralization, and we should not confuse the structure of the tool with the best structure of a project that uses that tool.
I don't know how you got to this. GitHub was designed fundamentally for the decentralized world. That's why forking is so easy, it was designed so that everyone can fork a repo and merge between themselves.
That's why GitHub has the vulnerability where if you have a private fork of a public repo, all of your commits are also public (because the internals was designed for an open social coding world)
You can make your CI less intensive, that doesn't require a different Github. What features would a 'differently shaped' platform have?
It's going to keep growing way past how it is now. I often drive 4-8 agents at a time, many in the cloud or on different machines, and use github as a kind of send-off point or starting point literally every single time. In a couple months I hope to be doing that with 10-20 and if it were cheaper I'd go even further, because why not? But even now I'm spending $0.25-$5 every single time I send out an agent to do a sizable thing and obviously they are positioned to capture some of that, because nobody else just lets me pay them $5/mo for git and basic hosting that Just Works (when it's up) and gets out of my way.
So why do they not want me or anybody else to pay them to create delegated/short-lived identities, or at least make their auth token story better so that if there is a way to set that up properly, people use that instead of sending commits "Co-written by Claude Opus 5" (literally every single commit by Claude is a missed opportunity for Microsoft to provide a real identity/auth solution for coding agents)?
Why is there no Mythos-like code review specialist model that for non-F100 companies to get defensive cybersecurity reviews? Or why not even just a cheap and good / smart and fast specialist to review my agents' or my own work for problems. Have they not even talked about doing that? I'm not going to pay some chatgpt wrapper company run by 24 year olds to do that, I want to pay the company that I already pay for that kind of stuff, that has the most data of anybody in the world to do it.
Why can't I gig out work on github either? Do you know how many developers there are on the periphery that want that kind of work and spend their time on reddit/discord/github trying to break into the industry? If I could chuck $5 at some task for a guy in another country trying to break into software to do, without all the overhead and sketchiness it involves now, why wouldn't I do that? That's literally the same thing that people do with LLMs.
Why does github codespaces not have some SKU/version for colleges to offer students as learning environments or companies interviewing developers to use for dev environments? My company tried working on this btw, and the only real barrier to entry is how much you need to trust a company to give them all your developers' credentials by virtue of having root on the computers their credentials and IP come from. It would be 1000x easier to sell this to non-enterprises if your name was Microsoft, and everyone was already your customer and trusting you with identity/ip anyway.
Github actions are not interesting to me because I can just ask my computer to create a cloud vm and test stuff in there, and it does, and I don't have to configure YAML or learn some specific way to do it. That's like the opposite kind of product github should focus on, it's almost a market for lemons because if your usage is enough for the profit to matter to Microsoft you can just pay a guy to migrate you to any other compute provider. Github has unique/best-in-the-world assets and opportunities for products and services with way better margins/growth because of how deeply the global software and developer community depends on them.
Let me pay $1/mo/delegate identity and $100/mo on bounties and $10/pop on interview hosting and $0.10/hr for agent sandboxes. It would be so much easier for Microsoft/Github to create and win these markets than anybody else and it's where the growth is
> I often drive 4-8 agents at a time, many in the cloud or on different machines,
To do what? How many hours a day do they run? I find it hard to come up with use cases for agents to be doing so much work constantly, but that might just be me.
So it's a throughput problem. If there are multiple separable-enough things I also want to do, and I'm already sitting there working, I start adding more things simultaneously until I'm fully occupied. I'm also trying to get better at firing off work that is useful enough to be worth doing if it costs $2 and 10m prompting with a 50% success rate, but not worth doing if it costs me 4hr of focused work with a success rate still not close to 100%. I think right now there is a lot to be gained looking at the economics of "more annoying than hard"/grindy dev work. Now you can just pay something purpose-built for grindy dev work a fraction of what it would cost you.
For example, it's relatively common for me to need to build Envoy with bazel and wait 1-2hr for my LLM agent to get past that (because it maybe takes 30m but if it ignores the cache, or makes mistakes requiring do-overs, you multiply that), or I want to have it do a bunch of benchmarking or testing that has a 10m-20m iteration time and a lot of things to iterate on. I just let them have at it and check to make sure they don't get stuck, and do something else.
I'm also trying to get better at firing off work that is useful enough to be worth doing if it costs $2 and 10m prompting with a 50% success rate, but not worth doing if it costs me 4hr of focused work with a success rate still not close to 100%, because I think right now there is a lot to be gained looking at the economics of "more annoying than hard"/grindy dev work now that you can just pay something purpose-built for grindy dev work a fraction of what it would cost you, or that can read more words in a minute than you can in one day. If it doesn't work or I just abandon it halfway it doesn't matter because it cost me $1 and if it's important I'll just pay one more $1 later.
I had three subagents working for 15m each earlier today gathering a bunch of data about a software dependency I was evaluating using, and they went through a ton of git commits/open source committee meetings/roadmap and historical data, and reviewed all its code. At API rate maybe it would have cost >$10, but I pay subscription rates and it was basically just a 5m writeup of resources to check and things to clarify/evaluate for me while I waited on another thing. To review all that output, and coordinate it/save it, and make it easier to include artifacts, code, etc. I just tell them to write it up in a git repo and push when they're done.
IMO the biggest bottleneck with agentic development is the iteration-time and how much human effort it takes to do the last 20% to take it from slop to actually-done, IMO. But I think many things become worth doing to a slop-level of quality if the time/compute is cheap, it's useful enough to you, and the primary barrier to having it is just taking the time to ask for it.
> I often drive 4-8 agents at a time, many in the cloud or on different machines,
To do what? How many hours a day do they run? I find it hard to come up with use cases for agents to be doing so much work, but that might just be me.
To be fair, there are lots of forges that are better than GitHub; knowing how to GitHub better than GitHub is an extremely low bar.
I hosted my own forgejo server used by actual other people * very slightly* before it was cool, and just to get started I had to go through this giant list of configs governing important auth/cred stuff and also random ass features and everything else, then I set up auth using my existing reverse proxy, then I had to figure out how to use JWT for access via the git CLI because I wasn't going to give every client an ssh key to The Server with All the Code or coordinate all that.
Then, finally, it all worked and I thought I'd check out the CI or some of the other interesting features I had heard of/seen like static site hosting. After looking into those and how mature they were, I realized this was really only for hobbyists, or people who want to make hosting git repos a part time job but also don't use/care/know about the stuff that makes a "forge" more than just a git server.
Personally, I liked the idea of self-hosting a forge with the assumption I could trust it as a CI service, and maybe allow unauthenticated read access, and have good authorization/authentication for my collaborators. I had a ton of 3p git repos to host and 1p repos to test on so it made sense to try since Github is not meant for that use case. I also evaluated gitea and saw they were offering a commercial multitenant service where my 3p hosting wouldn't be welcome and even otherwise I'd basically be at odds with them, and gitlab but they wanted me to run a whole damn cluster and felt a little too 2018.
If you're Codeberg and run the project it could be worth investing in making it better, but then you're literally making it your full time job. I wasn't going to make mine doing container stuff for them though. To their credit I checked their docs on just now and it seems to be in much better shape.
I went back to github because I like paying $5 or whatever for something that works, has many people on it, a bunch of integrations and generally enough quality to put in front of paying customers, and is secure. It's an insane value for anybody who has priorities higher than hosting their own git forge. So I think pretty much nobody knows how to do Github better than Github.
So the general basic primitives of git — diffs, commit history , content hash addressing are pretty optimal. If you wanted to implement version control in anything—even like a Notes app with undo—you’d eventually end up reinventing the same ideas
This is funny, as all the listed primitives and this scale of reliable build infra is the exact shape of Buildkite.
And also quicker/easier to screw up in subtle and insidious ways!
If GitHub is the wrong shape for this new world. Well, show me a hint of what the new world should look like?
To me it seems like everyone is frustrated, mostly at how fast things are changing, but not necessary because the existing tools suddenly became trash/irrelevant.
A lot of us are still contending with the fact that large amount of code is being produced and we don't know what the fuck to do about it. And we're less intimate with the code and product we ship than we were before.
1) you start acting like a senior staff level engineer and you stop caring so much about implementation and start caring about the things that actually matter, the architecture, the performance profile, the scalability, the test coverage, the monitoring, the velocity of development, etc etc.
Or 2) you don't scale.
LLMs can write 10k lines of code per day like its nothing. You can't review that with a jade handled magnifying glass and keep all that in your mind. After a few months, you could easily have 250k lines of dense production code + much more in tests and tooling etc.
You either have a team of people to watch over that, or you don't. You're not scaling yourself to be able to review all that and keep it all in your mind.
If other people are scaling, and you're not, you're unlikely to do as well as them. BUT, it's not impossible if you're really good. Being really good scales way less than using LLMs effectively.
Google doesn't work because they rely on hope that every person they hire doesn't do things they shouldn't. It works because they make it nearly impossible to do things you shouldn't. You need to build systems as well. Or you don't. Just do it the old way.
Pick your poison.
AI seldom pushes back, embraces complexity, does a lot of due diligence (however often superficial), and then completely misses the point and lays a trap on the code.
It’s not nearly as trustworthy as an actual team of humans.
What architecture doesn’t care about implementation? What performance profile doesn’t care about the details of the implementation? What does the test coverage is about if it’s not the implementation? What are you monitoring? The specs or the implementation?…
Not caring about the implementation seems like not caring about the materials when building an house, with eyes stayed only glued to a novel’s like description of the house.
LLMs don't have human attention to detail, IME
This is essentially the state of all blog posts now. As well as much code. Lots of content, not a lot of value.
My email is in my bio
What seems much harder to me is the coordination model at large, that we stick forever with one source of all authority who is the sole owner arbitrator and gate for all things. In corporate maybe that keeps going and that is a huge huge bulk of sw dev.
But I think we have so much more potency & capability, that a single coherent frontier for the software is an organizational constraint that won't be the only means forever. Letting ideas bake and marinate and cross pollinate and fork... With such vast new capability & power I feel like a single tip or one or two is going to dislodge as the only big pattern.
I see works like https://v-it.org, and in that I see not the new world, but new multitudes. And that's better!
They already are. you don't have to use github, or all it's features, git is the protocol, CI/CD are the added on composable blocks. Most platforms offer crypo signature verification, there's also opensource options.
Basicaly wtf are you on about? that's 5mins I'm not getting back.
I was expecting it to be awkward or annoying but it just kind of worked. I write issues, I tell the clanker to look at the issues, it generates PRs, I review the PRs and test them.
I was expecting something to really be a snag this week but I have enjoyed the process and using the tools. And the advantage of using the clanker is I go from issue to PR in a few minutes and don't "page out" my own context of the problem which is not the case usually with an open source contribution.
I still feel like software needs to move at least at the pace of someone with a vision and taste to test and review which forges like GitHub seems fine at.
I think this article makes some great points though I'm not sure if GitHub itself is the limiting factor. My view is that the new abstractions are yet to be discovered or widely adopted but I'm seeing some clear patterns arise. This is something I spend a lot of time thinking about because the new abstractions must fit within existing paradigms to provide a smooth transition and to overcome trust barriers.
I think I still have some work on the packaging side. Will likely need to narrow down my focus to cater to this new deep tech trend I see coming. I'm kind of waiting for some influencer to invent the right terminology for what I've been working towards so that I can jump on that bandwagon.
Deep tech trends need to permeate into the business lingo before they can get any traction and to do that, the new abstraction has to prove itself in some influential circles and earn itself a new label/buzzword.
Then can you clarify what it's actually saying, concretely?