Hacker News Reader

Comment by philipp-gayret | Hacker News Reader

I'm curious in what is the value of this kind of solution. Having run my own software factory for just a week or two, I'm at well over 1000 agent jobs (; a more flexible variant of what a swimlane on a scrum board represents). If I did a year of having the factory running, I would end up with 10~50K tickets across my repo's, then what? Do you keep them forever?

I don't follow what the value is in putting all that in a Git repo, let alone putting everything through a cycle of git/commit/push. The source of truth is the code, so if you're capturing this for additional context about why things were built, then you may as well follow the path of Entire; former GitHub CEO's company, and record the entire agent session to get the full context.

View on HN

I assume with 1000 agent jobs you mean completed jobs, not jobs running in parallel.

My solution for keeping the historical context of my projects: In docs/plan/, I have plans currently being executed. They get deleted when the work is done, and their contents gets folded into the permanent documentation in docs/.

I have the rule for the agents to put into the long-living documentation only that which is

1. not obvious from the source code (surprisingly much is obvious for agents), 2. information that an experienced engineer would not to rebuild the project (ignoring if it would look different).

Your 1000 changes in a few weeks matches the order of magnitude of changes that I did in a recent project of mine. It's a tool for managing agents, so a bit of a circular example, but anyway, if you want to take a look at the layout and CLAUDE.md instructions, it's open source: https://github.com/sadilek/obeya

I used to use this approach as well for managing many agents and myself. I do think the bloat problem is real as well as the need to handle multiple disjoint workstreams.

My solution was to put tasks and their dependencies in a sqlite db. https://github.com/mhalstrom/maximizepm take a look if you're interested

Why not use Linear/Plane/Paperclip?

I built an issue tracker that persists issues as code, which you can run in a separate, linked repo, so you don't need to litter your code repo. If you do run it the same repo it puts it in a state branch, so it isn't really in the way.

https://ljtn.github.io/epiq/

One benefit of persisting issues as code is traceability of intent and keeping track of vision drift. Epiq enables this via time travel, so you can trace the board evolution by going back in time, filtering for specific sessions, etc.

I like it, especially the name :)

This is a milestone on the journey for sure. If people could jump all the way to the end right into Software Factory Mode, they would. But people must practice the skill to get there. Part of that practice for me was tasks within the repository.

It's a way to share the context between team members and agents before it is built. You can refine it and transform it as you adjust it. I do the same thing now, even with a software factory, at an epic/initiative level. The only difference is the altitude at which we operate.

There is also something to say about having git history that shows the tasks change from scaffold -> refinement -> pristine. Frontier agents can see how the human in the loop operated during that period and translate it into human-on-the-loop policy.

Yep, this isn't a great solution for software factories.

As I see it - you need to track spec (a declarative process) and also tasks/progress (an imperative process). You do need to manage blockers so tasks should largely be a dependent graph.

There's also a third thing which emerges - which is "design decisions along the way". I do actually keep this in the repo as well, but I'm not sure this is correct.

Beads combines all three, which I'm not sure is correct, but seems quite brilliant.

But someone still has to write the requirements? I am not familiar with software factories like this to be honest...

>The source of truth is the code

this doesn't feel true anymore

Reply on news.ycombinator.com