Live data from Hacker News

GitHub is the wrong shape for this new world

depot.dev

21–30 of 53 posts

Re: GitHub is the wrong shape for this new world

#22

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 cl…

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.

Re: GitHub is the wrong shape for this new world

#23

Earlier quoted context omitted.

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 cl…

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.

Re: GitHub is the wrong shape for this new world

#24
post #5

"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…

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…

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

Re: GitHub is the wrong shape for this new world

#27

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…

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 wr…

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.

Re: GitHub is the wrong shape for this new world

#28
post #24

Earlier quoted context omitted.

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…

> 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

Re: GitHub is the wrong shape for this new world

#29
post #5

"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…

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…

You have achieved enlightenment!
Post reply on HN