idan

We haven't posted a project page yet on the githubnext site! Maggie's talk (https://maggieappleton.com/zero-alignment) is the best reference right now.

was not expecting a HN crossover with /r/formula1 today, but here we are

I do work at GitHub. I shared the above as a nuanced "yes and" to the pain that Mitchell is feeling.

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.

Correct, sorry I thought this was pretty obvious but in retrospect maybe not.

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!

Shrug

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.

shrug, I can't fix a lot of things in our reality, but I'd love to leave software development in a better state than when I found it

derp, haven't touched that in a while. TY!

Salesforce never understood Heroku. Salesforce's understanding of Heroku, if such an understanding ever existed, was wildly different than what Heroku understood it wanted to be. Benioff's penchant for buying himself a company every year did not help — "no headcount this year, we're buying Mulesoft/Quip/Tableau/Slack/$WHATEVER. And oops we spent too much money on dreamforce. Sucks that your pager rotations are burning people out!" It was very clear they did not give a shit about us, as evidenced by resources.

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.

Caveat, I'm not a lawyer, I don't speak for the company, yadda yadda

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.

hah, my cheat here is https://github.com/YOURHANDLE.png

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

Hi there! Longtime fan and hubber here.

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.

https://github.github.io/gh-aw/#gallery down the page has a list of concrete applications

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!

Hello HN! The Agentic Workflows project has been on the githubnext.com website for a while, and we recently moved the documentation and repo over to the `github` org.

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)

Nope, it uses Copilot CLI under the hood (with your token)

Any github pages site is, by default, ORGNAME.github.io.

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.

Also espressif RISC V mcu's like the ESP32-C3 and -C6 are fantastic.

Some Nordic MCUs are easy too, specifically nrf52840.

Have fun!

This has all the energy of people saying "ah, you take such great photos, you must have a good camera"

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

That hasn't been our experience using it in-house! It's not perfect, but not every software engineering task is some galaxy-brain architectural shit. Sometimes, you have to lay down some bricks. And sometimes, to lay down bricks, you need to touch more than one tiny patch of code.

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.

GitHub Stars have had access to this since last week, and a few of them have made in-use videos:

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

You have succeeded at hiring an electrician in THIS world? What's their number? Do they actually show up when they say they will?!?!?!!1!one

I'm sure we'll share some of the strategies we used here in upcoming talks. It's, uh, "nontrivial". And it's not just "what text do you stick in the prompt".

When video terminals first came out, everyone started out using line editors even though line editors make no sense when you can display arbitrary buffer. It took a while until editors changed to be "screen native". But they did change, meaningfully.

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.

Bingo.

Well, that's basically the heart of Copilot Workspace! The whole UX is structured to make it easy for the human to steer.

- Alter the "current" bullet points in the spec to correct the AI's understanding of the system today - Alter the "proposed" bullet points in the spec to correct the AI's understanding of what SHOULD be - Alter files/bullets in the plan in order to correct the AI's understanding of how to go from current to proposed.

That said, I think there's definitely a future where we might want to explore how we nudge humans into better issue-writing habits! A well-specified issue is as important to other humans as it is to AI. And "well-specified" is not about "more", it's about clarity. Having the right level of detail, clear articulation of what success means, etc.

I mean, I don't disagree!

The leading coefficient of these tools successfully getting you to/near the goal is all about clearly articulating the domain and the job to be done

Ergo, it's pretty important to craft experiences that make their core mechanic about that. And that's how Copilot Workspace was designed. The LLM generating the code is in some ways the least interesting part of CW. The effort to understand how the code works, which files must be touched, how to make coordinated changes across the codebase — that's the real challenge tackled here.

I mean we explored that a little with Copilot Voice :D https://githubnext.com/projects/copilot-voice/

But yeah, the important part is capturing your intent, regardless of modality. We're very excited about vision, in particular. Say you paste a screenshot or a sketch into your issue...

How many students / people early in career would benefit from having something to help them explore ideas?

How many don't have the advantages I had, of a four-year university, with professors and TAs and peers to help me stumble through something tricky?

How many have questions they feel embarrassed to ask their peers and mentors because they might make them look stupid?

Don't give up. This is a generational opportunity to lift up new developers. It's not perfect (nothing is). But if we sweat hard enough to make it good, then it is our chance to make a dent in the "why are there not more ______ people in tech" problem.

Exactly this.

When was the last time you wrote assembler?

We are indeed thinking about how to do that in a way that feels natural in VS Code. :)

Hello! GitHub Next here, happy to answer questions and unpack how we think about AI tools for developers (spoiler: it's less about codegen and more about helping with the rest of the dev cycle — building an understanding of how the system works, clearly specifying how it should change, etc)