GitHub simply isn't an agent code building platform. They're a RoR git host from 2008 running on an ancient MySQL setup that by some miracle continues to stay up, some of the time.
Their APIs are garbage from an agentic perspective. Try using Terraform to curate your GH org of a few hundred repos. Just running the `tf plan` will take 10min, because it's making thousands of API calls. Where's the bulk and batch APIs? No such thing. They are simply not agentic scale. Want to rerun the plan for your entire cloud vendor with thousands of VMs, IAM roles, buckets, etc... it'll run faster than checking on your repo labels.
GH needs rewritten from the ground up. The "repo is everything" arch has been creaking and falling over form many years now.
Lack of a local runner is my biggest peeve. Any novel GHA workflow creation results in a PR with 100 commits, until you can finally sort out all the non-obvious idiosyncrasies. For any modestly complex workflow, I move everything to a bash or TS file and call that, and then you can use _coding tools_ and a _local_ dev/eval loop.
How funny that GitHub Actions' lack of tools forces you to make a bunch of billed cloud runs with GitHub for workflow edits. I'm sure their PMs are very concerned about this trend.
A local runner would certainly help, but only to some extend. When you need to support multiple OS (Windows, Linux, macOS) and architecture (x64, arm64), not everything can be tested locally.
Try writing a regression test for your Github Action.. I'll wait.
It's a pretty ridiculously half-baked feature. But a lot of these devtools are--it's arguably even worse in the observability vertical. You have all these metrics and dashboards you're using to make critical business and operational decisions yet no way to actually ensure they're telling you what you think they are. Clown shit.
My understanding is the us.githubstatus.com is only if you are using GitHub enterprise with a custom subdomain and data residency in the US because then *some* of the infrastructure is separate from GitHub.com.
They _are_ the LLM coding agent vendor, and are _owned_ by MS, the ~majority~ biggest shareholder of OpenAI. How can you NOT consider that 20x+ scaling in your capacity roadmap projections, where you are trying to get everyone to use these agents as part of your core OKRs?
Or, maybe your #1 IT priority was moving everything to Azure instead ;)
The last several years have been monotonically busier for me, year over year, and I've been a principal contributor in this game for many years. Sure, I can push out 1000 PRs a year by riding 4 concurrent agent hoards, but at some point our heads will simply explode. There's a human limit here, at some point.
I got a new boiler installed recently. $20K. I looked up the _retail_ price for the components/fittings/consumables, ~$6K. Even with overhead, that plumber made a good take for 2 days work. I'm only half kidding when I suggest the kids of today should be destined for the trades.
I hate predictions, but when the dust settles, Copilot will take the lead. They are deep in the enterprise ecosystem, and they practically give it for free.
Their APIs are garbage from an agentic perspective. Try using Terraform to curate your GH org of a few hundred repos. Just running the `tf plan` will take 10min, because it's making thousands of API calls. Where's the bulk and batch APIs? No such thing. They are simply not agentic scale. Want to rerun the plan for your entire cloud vendor with thousands of VMs, IAM roles, buckets, etc... it'll run faster than checking on your repo labels.
GH needs rewritten from the ground up. The "repo is everything" arch has been creaking and falling over form many years now.