I feel like this solution hallucinated the concept of Workflow Lock File (.lock.yml), which is not available in Github Actions. This is a missing feature that would solve the security risk of changing git tag references when calling to actions like utility@v1
I find this confusing: I can see the value in having an LLM assist you in developing a CI/CD workflow, but why would you want one involved in any continuous degree with your CI/CD? Perhaps it’s not as bad as that given that there’s a “compilation” phase, but the value add there isn’t super clear either (why would I check in both the markdown and the generated workflow; should I always regenerate from the markdown when I need changes, etc.).
Given GitHub’s already lackluster reputation around security in GHA, I think I’d like to see them address some of GHA’s fundamental weaknesses before layering additional abstractions atop it.
It looks like it does have an MCP Gateway https://github.com/github/gh-aw-mcpg so I may see how well it works with my MCP server. One of the components mine makes are agent elements with my own permissioning, security, memory, and skills. I put explicit programatic hard stops on my agents if they do something that is dangerous or destructive.
As for the domain, this is the same account that has been hosting Github projects for more than a decade. Pretty sure it is legit. Org ID is 9,919 from 2008.
Stuffing agents somewhere they don't belong rather than making the system work better with the agents people already use. Obvious marketing driven cash grab.
I keep wondering if this is what kills GitHub. Anthropic have done a pretty good job of making Claude work well with GitHub, and it makes all the GitHub agent stuff feel pointless to me. But they keep adding it in more and more places, and I’m guessing most people just keep ignoring it and using Claude.
Would they think it’s worth introducing restrictions to make it harder to use Claude with GitHub in the hopes that it forces us to use their endless collection of agent stuff instead? I think they probably would choose that tradeoff.
There's a lot of hate in this thread, but there are plenty of engineers chomping at the bit for autonomous workflows, because browser-use isn't there yet, and cloud expenses from major providers are also unappealing with so much relatively powerful local compute.
It’d be fine if they included a big disclaimer at the top that this is beta software and they’re not liable for blah blah blah, but without such a disclaimer it’s reasonable to assume the software is ready for production. I think much of the hate is coming from GH misrepresenting its software and people being surprised by the many minor bugs.
Somehow i want to ask what's the actual job of those former software engineers. Agents everywhere, on your local machine, in the pipeline, on the servers, and they are doing everything. Yes, the specs also.
I cannot recommend Gitea enough. It is easy to install, can be very well integrated into the usual corporate Microsoft networks (ldap/adfs) and has very simple workers, which just reliably execute the actions defined in the .gitea folder of your repository. Installing workers is an extra step, but you don't really need a PhD to get it running.
You can build a very efficient and reliable CI pipeline this way and you are not dependent on third parties at all. The interface is mostly 1:1 Github. Just the bullshit is ripped out.
This is an extension for the gh cli that takes markdown files as input and creates github actions workflow files from them. Not just any workflow files, but 1000-line beasts that you'll need an LLM to explain what they do.
I tried out `gh aw init` and hit Y at the wrong prompt. It created a COPILOT_GITHUB_TOKEN on the github repo I happened to be in presumably with a token from my account. That's something that really should have an extra confirmation.
The landing page doesn't make it clear to me what value this is providing to me (as a user). I see all of these things that I can theoretically do, but I don't see (1) actual examples of those things (2) how this specific agentic workflow helps.
I want to see where we're at in 2 years, because these last couple of months have been pretty chaotic (but in a good sense) in terms of agents doing things with other agents. I think this is the real wake-up-call, that these dumb and error-prone agents can do self-correcting teamwork, which they will hopefully do for us.
Two years, then we'll know if and how this industry has completely been revolutionized.
By then we'd probably have an AGI emulator, emulated through agents.
I noticed this unusual line in go.mod and got curious why it is using replace for this (typically you would `go get github.com/Masterminds/semver/v3@v3.4.0` instead).
I found this very questionable PR[0]. It appears to have been triggered by dependabot creating an issue for a version upgrade -- which is probably unnecessary to begin with. The copilot agent then implemented that by adding a replace statement, which is not how you are supposed to do this. It also included some seemingly-unrelated changes. The copilot reviewer called out the unrelated changes, but the human maintainer apparently didn't notice and merged anyway.
I like how it accumulated 3 such replacements before finally getting fixed as a reaction to this comment with PR 14543[0], but after review, two "fix unit tests" commits were added, one of which replaces claude with copilot and the second one messing up the docs markdown, getting merged after that. Agentic workflows are the battle...
This is a solid step forward on execution safety for agentic workflows. Permissions, sandboxing, MCP allowlists, and output sanitization all matter. But the harder, still unsolved problem is decision validation, not execution constraints. Most real failures come from agents doing authorized but wrong things with high confidence. Hallucinations, shallow agreement, or optimizing for speed while staying inside the permission box.
I’m working on an open source project called consensus-tools that sits above systems like this and focuses on that gap. Agents do not just act, they stake on decisions. Multiple agents or agents plus humans evaluate actions independently, and bad decisions have real cost. This reduces guessing, slows risky actions, and forces higher confidence for security sensitive decisions. Execution answers what an agent can do. Consensus answers how sure we are that it should do it.
Often code is seen as an artifact, that it is valuable by itself. This was an incomplete view before, and it is now a completely wrong view.
What is valuable is how code encode the knowledge of the organization building it.
But what it is even more valuable, is that knowledge itself. Embedded into the people of the organization.
Which is why continuos and automatic improvement of a codebase is so important. We all know that code rot with time/features requests.
But at the same time, abruptly change the whole codebase architecture destroys the mental model of the people in the organization.
What I believe will work, is a slow stream of small improvements - stream that can be digested by the people in the organization.
In this context I find more useful to mix and control deterministic execution with a sprinkle of intelligence on top.
So a deterministic system that figure out what is wrong - with whatever definition of wrong that makes sense.
And then LLMs to actually fix the problem, when necessary.
45 comments
[ 0.28 ms ] story [ 50.6 ms ] threadThis is on GitHub's official account. For some reason GitHub is deploying this on GitHub pages without a different domain?
YAML: check
Markdown: check
Wrong level of abstraction: check
Shit slop which will be irrelevant in less than a year time: check
Manager was not PIP'd: check
[1] https://github.com/marketplace?type=models
Given GitHub’s already lackluster reputation around security in GHA, I think I’d like to see them address some of GHA’s fundamental weaknesses before layering additional abstractions atop it.
As for the domain, this is the same account that has been hosting Github projects for more than a decade. Pretty sure it is legit. Org ID is 9,919 from 2008.
Would they think it’s worth introducing restrictions to make it harder to use Claude with GitHub in the hopes that it forces us to use their endless collection of agent stuff instead? I think they probably would choose that tradeoff.
I stopped using GH actions when I ran into this issue: https://github.com/orgs/community/discussions/151956#discuss...
That was almost a year ago and to this date I still get updates of people falling into the same issue.
You can build a very efficient and reliable CI pipeline this way and you are not dependent on third parties at all. The interface is mostly 1:1 Github. Just the bullshit is ripped out.
I tried out `gh aw init` and hit Y at the wrong prompt. It created a COPILOT_GITHUB_TOKEN on the github repo I happened to be in presumably with a token from my account. That's something that really should have an extra confirmation.
Two years, then we'll know if and how this industry has completely been revolutionized.
By then we'd probably have an AGI emulator, emulated through agents.
There is just so much going wrong here.
[0] https://github.com/github/gh-aw/pull/4469
https://github.com/github/gh-aw/pull/14543
I’m working on an open source project called consensus-tools that sits above systems like this and focuses on that gap. Agents do not just act, they stake on decisions. Multiple agents or agents plus humans evaluate actions independently, and bad decisions have real cost. This reduces guessing, slows risky actions, and forces higher confidence for security sensitive decisions. Execution answers what an agent can do. Consensus answers how sure we are that it should do it.
Especially on the angle of automatic/continuos improvement (https://github.github.io/gh-aw/blog/2026-01-13-meet-the-work...)
Often code is seen as an artifact, that it is valuable by itself. This was an incomplete view before, and it is now a completely wrong view.
What is valuable is how code encode the knowledge of the organization building it.
But what it is even more valuable, is that knowledge itself. Embedded into the people of the organization.
Which is why continuos and automatic improvement of a codebase is so important. We all know that code rot with time/features requests.
But at the same time, abruptly change the whole codebase architecture destroys the mental model of the people in the organization.
What I believe will work, is a slow stream of small improvements - stream that can be digested by the people in the organization.
In this context I find more useful to mix and control deterministic execution with a sprinkle of intelligence on top. So a deterministic system that figure out what is wrong - with whatever definition of wrong that makes sense. And then LLMs to actually fix the problem, when necessary.