Hacker News Reader

Comment by zhynn | Hacker News Reader

I looked into beads but I didn't see a way to make it work any better than fossil, and fossil does more stuff. My typical setup is to use the repo as a working directory, the tickets for todo, wiki/forum for conversation. There is also a chat interface, but I haven't tried that with agents yet.

But I love fossil for this. You can create users for all of the agents (or agent roles). The CLI for fossil is just a binary and it compiles nearly everywhere.

+1 over here for agentic fossil. With fossil the "work" is integrated in with the code. Beads separates this out, the beads are instances of work that agents can consume, and they aren't part of the work repo. I could see why you might want this, but I still think that fossil gives you more utility.

More info on beads if you are curious: https://github.com/gastownhall/beads

View on HN

i feel like dropping the review and test phase -- especially in the agentic context - is incredibly spicy though.

So if I wanted to use fossil scm, i'd have to find a way to glue that on, and now ... we'Re basically in the same situation as with any other solution: it supports only a subset of the feature we want.

and especially CI pre "merge" is a hard requirement, and fossil doesnt have any concept for that i think?

But the last time i evaluated it was in the mid 2010s, so things may have progressed since? but couldn't find anything on cursory glance and AI confirmed that position, but we all know how often its wrong... so how did yall solve that issue?

yes, I agree: architecthre design, linting, commit msg structure, unit testing and other ci gates helps to direct the agents into building better software.

Fossil doesn’t have GitHub PR capabilities per-se. But its design philosophy is different with a focus on smaller groups of devs and not so much drive-by patches. I think in the case being discussed for AI agents, it can be simplified.

If you want human review on the code I’m thinking keep it simple and just review in branches/tags before merging OR even just have loose patch files.

As we’re seeing with resurgence of command-line utility by agents, that extends equally well to the O.G. diff/patch. A PR is literally just a diff with commentary and an approval process prior to merging. Diffs can be attached to forum topics and so-forth.

Lots of possibilities, but I think the main thing discussed here is how is version control better suited to AI agents moving forward.

in my case, i use opencode with oh-my-openagents. Omo has an orchestrator in charge and manage all the intetactions between agents. ADRs store decisions and beads store decisions as well (including design ones), then multiple agents work on a single bead.

Reply on news.ycombinator.com