Some feedback

[cgwalters]

I recently started investing in GitHub Agentic Workflows, and I have a lot of thoughts about it versus this project (and others).

https://blog.verbum.org/2026/08/21/agentic-ai-and-software-forges/

Things I think are good about this one:

• I love the social aspects of this project, stuff like leaderboards etc
• Seeing the usage in bluefin and similar projects especially with local models is awesome

Things I think should change

• The project is a huge mix of features and patterns without (AFAICS) a clearly defined architectural "core" (trying to be both interactive and automatic is hard - GH-AW only does the latter)
• Sandboxing cannot be optional
• The "ACMM ladder" I think is too naive. A pattern I see emerging is using CODEOWNERS files, (AI) risk analysis on individual PRs to decide what to merge. So framing this in terms of "levels" is too coarse.
• The "ACMM ladder" also implies that autonomous merges is the end state - but is it really? I don't like implying that people with human-in-the-loop at this PR approval gate level are somehow not as advanced.

There's more, but just starting this.

[castrojo]

Sandboxing cannot be optional

I'm reworking the contributor and review experience now. It will optionally use gVisor or KVM directly if enabled on the host. Should be done in the next couple of days.

I was reminded of gVisor when I saw it's application to the CNCF! Feels like we're going to just turn that on for podman at some point too. I've not yet measured the KVM launch performance, but the tool is a batch tool anyway startup time isn't a factor as much as the sandbox itself.

[cgwalters]

I just want to emphasize that I have a really strong opinion that:

• Most things should be stored in git i.e. we're git-ops even for non-software things
• Since you're using a forge you should have CI
• Your AI should be aligned with your CI

Hive is really growing into its own parallel thing, with no clear alignment story with CI system infrastructure.

I'm not saying it's wrong but it's not what I want personally.

Like when I see things like this

I think "how is a hive different from a GitHub repository"?

And I mean that in a very fundamental way, like how is work tracked, how does one observe activity, how do people talk.

But also: How does sandboxing work?

It will optionally use gVisor or KVM directly if enabled on the host. Should be done in the next couple of days.

So to connect the two threads I recently generated https://github.com/bootc-dev/cgwalters-devspace-sandbox which - there's no rocket science here but the key thing I'm trying to push even my "interactively steered" agentic sessions into GHA runners or equivalent.

Some things may end up using my desktop infrastructure, but basically I'm trying to stick to a principle that e.g. if the target is GitHub, I'll have GitHub-adjacent coordination tooling like e.g. having a VM on my desktop join as a runner and get dispatched that way.

My personal infra uses forgejo as source of truth, and it's really key to me to not be fundamentally tied to GitHub - so I have some parallel stuff going on in that space, but it uses Forgejo actions of course in a somewhat GH-AW style way.

[cgwalters]

I was reminded of gVisor when I saw it's application to the CNCF!

I think the CNCF is great and gVisor is useful in many cases, but it's another tool in the toolbox, I think WASM for example is actually much stronger sandboxing and is actually what we want for many things (esp closer alignment with serverless-style stuff). There's so much usage of basically shell-script like things in CI workflows that it gets hard.

Feels like we're going to just turn that on for podman at some point too.

I think that would break way too many things to do by default. Looks like gVisor has improved its scope and syscall compatibility a lot though.

[cgwalters]

Another example here is

Agents cannot push directly to main. All changes go through PRs with full audit trails.

I mean, everyone should already have been doing that for even human owned repositories! GitHub has always supported a nice checkbox "Require a PR to merge". There's nothing new for agents in this.

I am trying to get serious that even at small scale, even if I (+agents) are literally the only thing operating on a repo, it will always go through a PR.

A different way to frame this is:

"Do we need to invent something new for agents? (commit merge policy, sandboxing, work tracking, etc)" - in my opinion the default answer is "no".

Of course, there's huge details here like some of these systems are designed for human scale and become less optimal at agent speeds, this is where things like beads is interesting, I don't have a lot of real world experience with it, but I guess I've already gotten way more output than I can feasibly review even without it.

[cgwalters]

Another thing I want to provide as input to this system, I think the reality is that we will always have multiple humans using different workflows even before AI, but obviously now it suddenly becomes very relevant to think "how do two different humans-and-AI harnesses interact on the same forge"?

And that problem domain drives some really interesting concerns again about ensuring that things like orchestration and work tracking have a fundamental lowest-common-shared-denominator in using forge-native tracking and not some out of band thing.

[cgwalters]

Another one here, when I look at https://docs.hivecommons.dev/docs/dibs/overview/introduction

My thoughts immediately go to "why not just use GitHub discussions for this"? I mean it's basically what it was for before agents existed (again a theme!). There's even built in "create issue from discussion etc".

Of course, agents can streamline this whole thing - once an issue is created they can help refine implementation details, etc.

But the point remains, forges already have tons of ways to exchange semi-structured data between humans and agents.