Hacker News

points by sadilek 3 days ago | 0 comments

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

[–] biggestriverman 3 days ago

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

[–] adamsmark 3 days ago

Why not use Linear/Plane/Paperclip?

[–] ionetan 3 days ago

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.

[–] trendschau 3 days ago

I like it, especially the name :)