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.
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 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.
99.9% of clients are behind NAT or working on code owned by someone other than just themselves. Unless your "decentralized" repos are on two devices you control on the same private network, or you think carrying hard drives around to your friends' computers manually is a reasonable way to do it, or your decentralized version control is distributed over a centralized companies' email services, this is such a hard problem to solve
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.
I'm not going to pretend I know how to do Github better than Github, but I almost can't believe how poor their support is for fine grained access tokens, org/individual credentials, etc. are in the same era as Copilot/VSCode/AI devtools and vibe coding, as they drown in a rapidly growing volume of agent-driven usage.
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.
It's usually not 24/7, it's that when I use just 1 agentic coding tool there's too much variance/hand-holding to go do something else, and also often a lot of downtime in between turns as they work.
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.
There are two that I know of, and neither seem to do a better job at solving my problem of providing a place to host and distribute open source software.
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.
A lot of the choreography in standard GitHub workflows (make a branch and send a pull request and do the integration tests) is about teams with multiple devs working in multiple branches. If you just want to move fast with AI on a greenfield project then commit and push suffices
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
"The winners of the next decade won't build a better pull request. They'll build the infrastructure that makes software generation, validation, and deployment operate at machine scale."
This is funny, as all the listed primitives and this scale of reliable build infra is the exact shape of Buildkite.
A lot of words, but essentially says nothing useful.
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.
My personal take is that if you want to scale in engineering you really only have 2 options.
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.
The problem I see is that in a traditional company a senior engineer would push back on complexity and know when to do due diligence.
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.
> 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
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.
I think you misunderstand - it’s not that you shouldn’t be capable of evaluating and improving the implementation, but that it’s usually irrelevant. A very large majority of the time, “good enough” is fine. Fix things people complain about, and use the rest of your time to do more important things.
I couldn't agree more. I've been building something that is trying to solve this problem, an abstraction layer for code that you, your agents and co-workers can all use together. I would love the chance to talk to you and get feedback if you're willing.
GitHub is fine. The thing that’s changed is that we’re unlikely to need large teams anymore. Merging code will be easier and if planned properly (using AI planning skills), the work can be broken up with clear boundaries.
> These aren't features of a developer tool. They're infrastructure primitives. Just as we stopped thinking about provisioning individual servers and started thinking about compute, storage, and networking as composable building blocks, software delivery needs the same shift.
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.
Software engineering hasn't changed. Every aspect of it is the same as 4 years ago. A code monkey churns out poorly designed code and poorly deploys it. Nobody really pays attention and it kinda looks like it works - until it doesn't. The only difference now is the code monkey's name is Claude and everyone can hire him. But every part of the SDLC, every component, every way it's used, are all identical. Same difference as a hammer and a nail gun. The job of a house framer didn't change, it just got faster and slightly easier.
This week I created a "clanker" account backed by an LLM agent on GitHub and have been iterating with it on one of my open source projects as if it was just a super fast contributor. And... it has been fine.
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 generate a lot of code, a lot of PRs, a lot of issues and git/Github are fine for me. As a software engineer, I face many challenging issues but git is not one of them.
As tools I see no real issue, as agents seem readily able to coordinate and work alongside people, using these same tools. Same for the other forges. The offerings differ but there's vastly more isomorphism, sameness than difference.
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!
I suspect a fair percentage of AI skeptics would be closer to neutral were there less SaaS-bros declaring all existing systems hopelessly obsolete in the hopes of selling their own ten a penny wares.
This is a good article. I've been working on infrastructure to facilitate safe vibe coding with a focus on data synchronisation with simple access control and analytics. See https://saasufy.com/
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.
"I think of GitHub as a collaboration tool."
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.
Yea, I keep saying: "Git doesn't need a hub."
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.
Git doesn't need a hub.
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.
> issue tracker
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.
I absolutely agree with you that the paraphernalia around code is required but tools for the job.
git for code management
something else for discussion of that management
why not something like fossil scm but built around git itself?
99.9% of clients are behind NAT or working on code owned by someone other than just themselves. Unless your "decentralized" repos are on two devices you control on the same private network, or you think carrying hard drives around to your friends' computers manually is a reasonable way to do it, or your decentralized version control is distributed over a centralized companies' email services, this is such a hard problem to solve
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.
You have achieved enlightenment!
I don't feel like this article really answers the question of why this is the wrong shape. CI takes too long? What else?
You can make your CI less intensive, that doesn't require a different Github. What features would a 'differently shaped' platform have?
I'm not going to pretend I know how to do Github better than Github, but I almost can't believe how poor their support is for fine grained access tokens, org/individual credentials, etc. are in the same era as Copilot/VSCode/AI devtools and vibe coding, as they drown in a rapidly growing volume of agent-driven usage.
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 am genuinely curious:
> 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.
It's usually not 24/7, it's that when I use just 1 agentic coding tool there's too much variance/hand-holding to go do something else, and also often a lot of downtime in between turns as they work.
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'm not going to pretend I know how to do Github better than Github
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.
There are two that I know of, and neither seem to do a better job at solving my problem of providing a place to host and distribute open source software.
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.
I am genuinely curious:
> 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.
The article failed to describe the problem or a solution. But it was fun seeing the phrase “paradigm shift” again, which feels very 1998.
But do we really need a paradigm shift in how we express the concept of a paradigm shift? It's not like the meaning of the words expired.
A lot of the choreography in standard GitHub workflows (make a branch and send a pull request and do the integration tests) is about teams with multiple devs working in multiple branches. If you just want to move fast with AI on a greenfield project then commit and push suffices
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
"The winners of the next decade won't build a better pull request. They'll build the infrastructure that makes software generation, validation, and deployment operate at machine scale."
This is funny, as all the listed primitives and this scale of reliable build infra is the exact shape of Buildkite.
A lot of words, but essentially says nothing useful.
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.
My personal take is that if you want to scale in engineering you really only have 2 options.
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.
The problem I see is that in a traditional company a senior engineer would push back on complexity and know when to do due diligence.
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.
> 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
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.
I think you misunderstand - it’s not that you shouldn’t be capable of evaluating and improving the implementation, but that it’s usually irrelevant. A very large majority of the time, “good enough” is fine. Fix things people complain about, and use the rest of your time to do more important things.
and this is why everything needs 32+GB of RAM and an assload of storage.
LLMs don't have human attention to detail, IME
>A lot of words, but essentially says nothing useful.
This is essentially the state of all blog posts now. As well as much code. Lots of content, not a lot of value.
I couldn't agree more. I've been building something that is trying to solve this problem, an abstraction layer for code that you, your agents and co-workers can all use together. I would love the chance to talk to you and get feedback if you're willing.
My email is in my bio
GitHub is fine. The thing that’s changed is that we’re unlikely to need large teams anymore. Merging code will be easier and if planned properly (using AI planning skills), the work can be broken up with clear boundaries.
Probably we should create a jjhub based on jujutsu VCS, with good interactions between agentic AI and humans built right from the beginning
There are like 4 companies doing this right now.
Why, I like it very much, For any other platform, they need time to build the trustworthy with all engineer.
> These aren't features of a developer tool. They're infrastructure primitives. Just as we stopped thinking about provisioning individual servers and started thinking about compute, storage, and networking as composable building blocks, software delivery needs the same shift.
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.
This is an advert
So?
Software engineering hasn't changed. Every aspect of it is the same as 4 years ago. A code monkey churns out poorly designed code and poorly deploys it. Nobody really pays attention and it kinda looks like it works - until it doesn't. The only difference now is the code monkey's name is Claude and everyone can hire him. But every part of the SDLC, every component, every way it's used, are all identical. Same difference as a hammer and a nail gun. The job of a house framer didn't change, it just got faster and slightly easier.
> The job of a house framer didn't change, it just got faster and slightly easier.
And also quicker/easier to screw up in subtle and insidious ways!
This week I created a "clanker" account backed by an LLM agent on GitHub and have been iterating with it on one of my open source projects as if it was just a super fast contributor. And... it has been fine.
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 generate a lot of code, a lot of PRs, a lot of issues and git/Github are fine for me. As a software engineer, I face many challenging issues but git is not one of them.
As tools I see no real issue, as agents seem readily able to coordinate and work alongside people, using these same tools. Same for the other forges. The offerings differ but there's vastly more isomorphism, sameness than difference.
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!
Flagged as LLM slop.
I suspect a fair percentage of AI skeptics would be closer to neutral were there less SaaS-bros declaring all existing systems hopelessly obsolete in the hopes of selling their own ten a penny wares.
[flagged]
[flagged]
[flagged]
This is a good article. I've been working on infrastructure to facilitate safe vibe coding with a focus on data synchronisation with simple access control and analytics. See https://saasufy.com/
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.
> This is a good article.
Then can you clarify what it's actually saying, concretely?