Why GitHub is the Wrong Shape for This New World
I argue that the current software engineering paradigm, centered on GitHub as a collaboration tool, is breaking under the pressure of AI agents. With code generation exploding across teams, human-centric workflows like pull requests have become bottlenecks. We must shift from viewing software delivery as a sequence of human actions to treating it as high-throughput infrastructure primitives.
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.
- gerdesj
"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.
- cortesoft
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?
- mypalmike
The article failed to describe the problem or a solution. But it was fun seeing the phrase “paradigm shift” again, which feels very 1998.
- firasd
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
- mitchjj
"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.