Six Months with Git-Native Issue Tracking: Am I Still Using Beads?

Sat, 27 Jun 2026 10:00:00 -0500

Back in January, I wrote about discovering beads, a git-native issue tracker built specifically for AI-assisted development. I was pretty hyped. Having agents track their own tasks natively inside the git repo felt like the missing link for long-running autonomous workflows.

It’s been six months. So, the inevitable question: am I still using it?

Short answer: yes, but no longer as my default.

So this is where my task-tracking workflow actually landed in mid-2026.

The Shift Away From the Default

In January, I was trying to force beads into every single project I spun up. New repo? Init beads. Quick experiment? Init beads. As the months went on, I realized I was over-engineering things.

For a lot of projects, the task tracking built into Claude Code is good enough for day-to-day work. If an agent just needs to hold a checklist for a couple of hours during a coding session, standing up a full git-native tracking system is overkill. The lightweight, ephemeral tasks handle that perfectly, and they disappear when the session ends, which is exactly what you want for session-scoped work.

Wrapping the Real Things

For durable issue tracking, I pivoted back to where the code already lives.

Instead of leaning on beads, I built a couple of custom agent skills that wrap the GitHub CLI (gh) and the GitLab CLI (glab). Now when an agent needs to pull down tasks, update tickets, or log a blocker, it just talks directly to GitHub or GitLab through those wrappers.

The split looks like this: the remote issue tracker is the source of truth, and lightweight Claude Code tasks handle immediate session context. That combination has been far more resilient for me than routing everything through a separate system. The truth stays where my teammates and my future self will actually look for it.

Where Beads Still Lives

I haven’t abandoned beads. It still sticks around on a handful of repos where it’s useful.

The big one is my Obsidian vault, the “second brain” I wrote about earlier this week. When I’m managing personal research, blog pipelines, or local-only projects that don’t need a heavy GitHub project board, the git-native approach is still fantastic. No remote, no API, no ceremony, just issues that travel with the repo. Version 1.0 leaned into that even harder by moving to an embedded Dolt backend, basically git for your database, so there’s no separate server to babysit and the full history lives right alongside the code.

Beads isn’t worse than I thought in January. It’s just a sharper tool than I was treating it as. I was reaching for it everywhere when it was really built for a specific shape of project.

The hype of January has settled into the pragmatism of June. Not every project needs a custom tracking system, and sometimes letting your agents talk to GitHub directly is the easiest path forward.

What are you using to keep your agents on task these days?

I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @logan@llbbl.blog.

Task-tracking on LLBBL Blog

Six Months with Git-Native Issue Tracking: Am I Still Using Beads?

The Shift Away From the Default

Wrapping the Real Things

Where Beads Still Lives