zlacker

This is clearly going to develop the same problem Beads has. I've used it. I'm in stage 7. Beads is a good idea with a bad implementation. It's not a designed product in the sense we are used to, it's more like a stream of consciousness converted directly into code. There are many features that overlap significantly, strange bugs, and the docs are also AI generated so have fun reading them. It's a program that isn't only vibe coded, it was vibe designed too.

Gas Town is clearly the same thing multiplied by ten thousand. The number of overlapping and adhoc concepts in this design is overwhelming. Steve is ahead of his time but we aren't going to end up using this stuff. Instead a few of the core insights will get incorporated into other agents in a simpler but no less effective way.

And anyway the big problem is accountability. The reason everyone makes a face when Steve preaches agent orchestration is that he must be in an unusual social situation. Gas Town sounds fun if you are accountable to nobody: not for code quality, design coherence or inferencing costs. The rest of us are accountable for at least the first two and even in corporate scenarios where there is a blank check for tokens, that can't last. So the bottleneck is going to be how fast humans can review code and agree to take responsibility for it. Meaning, if it's crap code with embarrassing bugs then that goes on your EOY perf review. Lots of parallel agents can't solve that fundamental bottleneck.

>>qcnguy+(OP)
>This is clearly going to develop the same problem Beads has. I've used it. I'm in stage 7. Beads is a good idea with a bad implementation. It's not a designed product in the sense we are used to, it's more like a stream of consciousness converted directly into code. There are many features that overlap significantly, strange bugs, and the docs are also AI generated so have fun reading them. It's a program that isn't only vibe coded, it was vibe designed too.

Yeah this describes my feeling on beads too. I actually really like the idea - a lightweight task/issue tracker integrated with a coding agent does seem more useful than a pile of markdown todos/plans/etc. But it just doesnt work that well. Its really buggy and the bugs seem to confuse the agent since it was given instructions to do things a certain way that dont work consistently.

>>ac29+ZW
I tried using beads. There kept being merge conflicts and the agent just kept one or the other changes instead of merging it intelligently, killing any work I did on making tasks or resolving others. Still haven't seen how beads solves this problem... and it's also an unnecessary one. This should be a separate piece of it that doesn't rely on agent not funging up the merge.

>>qcnguy+(OP)
100%.

There's a lot of strange things going on in that project.

try to add some common sense, and you'll get shouted out.

which is fine, I'll just make my own version without the slop.

>>qcnguy+(OP)
Huh. I was going to try it, but maybe I need to vibe-code my own agent issue-tracker.

Or did you find one that's good?

>>qcnguy+(OP)
> Beads is a good idea with a bad implementation

> Course, I’ve never looked at Beads either, and it’s 225k lines of Go code that tens of thousands of people are using every day. I just created it in October. If that makes you uncomfortable, get out now.

>>skybri+Seb
Why can't you use an issue tracker that is built into the git control, like forgejo? It feels like it would be easy to use this with an API key, out or direct database access (I'm doing both with agents). If you self host, you've got a very standard and reliable issue tracker. Why does beads need to exist? What can't an agent do with that setup I've described above?

>>qcnguy+(OP)
I am wondering if it would be a viable strategy to vibe code almost "in reverse" - take a giant ball of slop such as beads, and use agents to strip away feature after feature until you are left with only exactly what you need, streamlined to your exact workflow. Maybe it'd be faster to just start from scratch, but it might be an interesting experiment. Most of my struggles with using beads so far have come from being off the #1 use case of too many of its features, and having to slog through too much documentation to know what to actually use.

>>laxori+hC1
How long until Atlassian makes "JIRA for Agents" where all your tasks and updates and memory aren't stored in Git (so no merge conflicts) but are still centralized and shareable between all your agents/devs/teams..

And also auditable, trackable, reportable, etc..

>>qcnguy+(OP)
You might like linear-beads[1] better. It's a simpler and less invasive version of beads I made to solve some of the unusual design choices. It can also (optionally) use linear as the storage backend for the agent's tasks, which has the excellent side effect that you as a human can actually see what the agent is working on and direct the agent from within linear.

Despite it's quirks I think beads is going to go down as one of the first pieces of software that got some adoption where the end user is an agent

[1]: https://github.com/nikvdp/linear-beads

>>xrd+Olb
I believe the idea is that it's for managing many fine-grained todo's to keep the agents on track. When multiple code agents are working at the same time and when there's a merge conflict, the code agents can do the merges, too.

But yeah, I'm only running one code agent at a time, so that's not a problem I have. I should probably start with just a todo list as plain text.

>>nikvdp+Oqb
Looks interesting. Might want to link to Linear in the README; I hadn't heard of it before.

What do you like about Linear? Is it suitable for hobby projects?

>>skybri+Seb
Look at cc-mirror, and use the mclaude there.

It unlocks a (still) hidden multiagent orchestration function in Claude code. The person making it unminified the code and figured out how to unlock it.

I find it quite well done - I started a orchestrator project a few days ago and scrapped it because it'll be fully integrated soon it seems.

>>qcnguy+(OP)
Re Beads - doesn't seem to have been covered a lot on HN but I found these. Others?

Show HN: I replaced Beads with a faster, simpler Markdown-based task tracker - >>46487580 - Jan 2026 (2 comments) (<-- I've put this one in the SCP - see >>26998308 for explanation)

Solving Agent Context Loss: A Beads and Claude Code Workflow for Large Features - >>46471286 - Jan 2026 (1 comment)

Beads – A memory upgrade for your coding agent - >>46075616 - Nov 2025 (68 comments)

Beads: A coding agent memory system - >>45566864 - Oct 2025 (1 comment)

>>skybri+1ub
Good call, added a link.

Linear is great, it's what JIRA should've been. Basically task management for people who don't want to deal with task management. It's also full featured, fast (they were famously one of the earlier apps to use a local-first sync-engine style architecture), and keyboard-centric.

Definitely suitable for hobby projects, but can also scale to large teams and massive codebases.

>>sbarre+kqb
you've already hooked up Jira access via MCP/skills jira-cli, yeah?

>>qcnguy+(OP)
> And anyway the big problem is accountability.

It's 2025, accountability is a thing of the past. The future belongs to the unaccountable and their AI swarm.

Facebook burned something like $70bn on "metaverse" with seemingly zero results. There's a lot more capital (and biosphere) to burn on AI agents.

>>sbarre+kqb
they already did, it's called 'JIRA'. not even joking.

>>fragme+pHb
Oh I don't use JIRA currently, but I used it at a previous job.

I was sort of kidding with "JIRA for Agents", obviously using the API and existing tool you can make agents use it.

We use Github at my current job and similarly have Claude Code update issues and PRs when it does work.