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