In the same way that Mastodon didn't replace Twitter even when Twitter went to shit, I don't believe in the various GitHub alternatives becoming a broadly-used thing. Maybe we'll end up with more GitHub-alikes like Codeberg, mabye we'll end up with some communities adopting novel forges like Tangled and Forgejo. But it beggars belief that most of the millions of GitHub's users would switch to something so much more complicated. Has the same energy as "20XX is finally the year of linux on the desktop".

My very personal hot take: the likeliest happy future is _most likely_ to happen through improving GitHub. I vote with my feet to do that from inside, and that's all I wanted to add. Hence "I hope we do the things that make you want to come back one day." I believe in it enough that I choose to work here on exactly that, because like Mitchell, I care very much about the platonic ideal of GitHub. He's ready to move on, and I'm not yet. There's no value judgment hiding inside that.

I'm not encouraging Mitchell to stay, I'm saying that my version of his post is about _me_ staying to make a brighter future, and adding my context on why I still believe that.

And finally I closed with "I hope we win you back" to be extra clear about it!

Nothing prevents usage of GH in a decentralized fashion. There's nothing magical about git remotes. Just add some more, figure out a process that works for you, have fun!

In reality: when I want to send a letter I don't want to figure out a process from scratch. I want to go to the local post office, buy a stamp, and post a letter.

Convenience is a spectrum and different people land in different spots. What irks me is when I lack the choice. And that's not the case here.

It's safe to say that I'm hypersensitive to these antipatterns and have been looking out for them at GitHub, and I don't see them.

What Microsoft wants GitHub to be is pretty much what GitHub wants GitHub to be. A home for all developers, playing a central role in the production of both public and private software. That alignment was never there with Heroku/Salesforce.

GitHub is not perfect but I don't think it's "degraded faster" at all. It's _grown_ faster. Much much much faster. And it's had to expand into the AI field, which is not an incremental thing like "hey let's launch a new feature or better dashboards." Nobody knows what AI wants to be when it grows up. GitHub in 2026 fundamentally resembles a pre-PMF startup in many ways because of that. I'm obviously not an unbiased observer, but I wouldn't count us out just because it's an uphill. Everyone's on that same uphill.

Having experienced both firsthand, I fundamentally disagree that there's a parallel. GitHub/MSFT has the median amount of corporate bullshit. Not more, not less.

It's a product that is _de facto_ present in nearly all developer scenarios. There are scenarios where I personally believe public management is better than private management, e.g. single-payer healthcare is strictly better than the bullshit we have in the US now. It's fundamentally cheaper for the polity when the government negotiates with healthcare providers than each private insurer.

I don't think that's fundamentally the problem facing GitHub, and I don't think it would be better in any way — for anyone — if it were regulated like a utility. But again, I write javascript for a living. Take what I'm saying with a big-ass rock of salt.

Will redirect to an image file whose title is your user ID! :D

It's okay to have emotions. I have similar emotions. I'm GitHub User 22723 which is effectively the same as you (considering there's ~180m GH accounts nowadays)

My version of your post reads differently:

"GitHub only gets better if people who give a shit stick around to make it better"

Walking away would be easy. I felt that way when I left Heroku ~six years ago. I left that job and never opened the Heroku dashboard again, after nearly a decade of happy use. I felt that it was irredeemable, and though it took a while, Salesforce did eventually succeed in running it fully into the ground.

I don't feel the same about GitHub. It is precisely because it's precious that I can't walk away. I'm not the only one here who feels that way.

In the past few years, GitHub has absorbed both a fundamental paradigm shift (agentic coding) AND several different hockey sticks of growth. It's messy. I'm not always proud of the results or the product choices we are forced into. But none of it feels like the Heroku/Salesforce debacle. Occam's razor applies here: it's not "more AI coding" and it's not "big bad Microsoft." It's scale, and a fundamental shift of the ground under all of our feet.

I hope we do the things that will make you want to come back. I hope we spark that joy in you again! It's not stupid to have big feelings about something that is so central to our lives as developers. Fuck that noise.

For examplpe, https://github.github.io/gh-aw/blog/2026-01-13-meet-the-work... has several examples of agentic workflows for managing issues and PRs, and those examples link to actual agentic workflow files you can read and use as a starting point for your own workflows.

The value is "delegate chores that cannot be handled by a heuristic". We're figuring out how to tell the story as we go, appreciate the callout!

This is early research out of GitHub Next building on our continuous AI [1] theme, so we'd love for you to kick the tires and share your thoughts. We'd be happy to answer questions, give support, whatever you need. One of the key goals of this project is to figure out how to put guardrails around agents running in GitHub actions. You can read more about our security architecture [1], but at a high level we do the following:

- We run the agent in a sandbox, with minimal to no access to secrets

- We run the agent in a firewall, so it can only access the sites you specify

- We have created a system called "*safe outputs*" that limits what write operations the agent can perform to only the ones you specify. For example, if you create an Agentic Workflow that should only comment on an issue, it will not be able to open a new issue, propose a PR, etc.

- We run MCPs inside their own sandboxes, so an attacker can’t leverage a compromised server to break out or affect other components

We find that there's something very compelling about the shape of this — delegating chores to agents in the same way that we delegate CI to actions. It's certainly not perfect yet, but we're finding new applications for this every day and teams at GitHub are already creating agentic workflows for their own purposes, whether it's engineering or issue management or PR hygiene.

> Why is it on github.github.io and not github.com?

GitHub Pages domains are always ORGNAME.github.io. Now that we've moved the repo over to the `github` org, that's the domain. When this graduates from being a technology preview to a full-on product, we imagine it'll get a spot on github.com/somewhere.

> Why is GitHub Next exploring this?

Our job at GitHub is to build applications that leverage the latest technology. There are a lot of applications of _asynchronous_ AI which we suspect might become way bigger than _synchronous_ AI. Agentic Workflows can do things that are not possible without an LLM. For example, there's no linter in existence that can tell me if my documentation and my code has diverged. That's just one new capability. We think there's a huge category of these things here and the only way to make it good is to … make it!

> Where can I go to talk with folks about this and see what others are cooking with it?

https://gh.io/next-discord in the #continuous-ai channel!

[1] https://githubnext.com/projects/continuous-ai/

[2] https://github.github.io/gh-aw/introduction/architecture/

(edit: right I forgot that HN doesn't do markdown links)

We recently moved this out of the githubnext org to the github org, but short of dedicating some route in github.com/whatever, github.github.io is the domain for pages from the github org.

Some Nordic MCUs are easy too, specifically nrf52840.

Have fun!

_People_ are getting outsized value from AI in the ways they apply it. Photographs come from the photographer, not the camera.

Having something round up the likely areas of the codebase that needs touching feels magical. It doesn't always succeed! But it feels pretty magical to get that boost when you're new to some part of a codebase (which, real talk, code I wrote > 1 month ago, I must page back into memory).

Making it easy for me to progressively add context for the model is an accurate analogue for how I think as a developer when tackling a task. I have to build a mental model of how things work. And then a plan for how I'm going to change it.

Maybe for the kinds of tasks you usually tackle, it won't have value. But the amount of context it's attempting to bring to bear on whatever task you give it is categorically more — and better — than any other tool I've seen. I have seen (and been the author of) spaghetti. Could I make CW generate spaghetti? Surely. That's why it's a tool for developers, not a substitute for developers.

- https://www.youtube.com/watch?v=FARf9emEPjI by Dev Leonardo - https://www.youtube.com/watch?v=XItuTFn4PWU by Ahmad Awais

And keep an eye on https://x.com/githubnext, we'll be sharing / linking to more in-action things.

Any PR created with Workspace will have a link to a readonly copy of the workspace so you can see how it happened. We expect those to start circulating as people get access!

When GUIs first came out, editors were just "terminal editors in a window". Took a while for the modern concept of an IDE to happen, with hovers, red squigglies, sidebars, jump to definition. All of that was possible on the first day of the GUI editor! But it took a while to figure out what everyone wanted it to be.

I think we're at a similar inflection point. Yeah, everyone today (myself included) is comfortable in the environment we know. VS Code is lovely. And AI (plus realtime multiplayer) is not a display technology. But I think it's a material technology shift in the same vein as those two moments in history. I would not bet that the next thirty years is going to continue look like today's VS Code. I don't know to say what it WILL look like — we have to keep prototyping to find out.