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.
Counterpoint, many updates would also cause many commits just for keeping tasks updated, adding noise to the project history.
Nothing stopping people from keeping tasks in a separate repository, of course - this would also make it simpler to just allow commits straight to `main`.
This doesn’t work in an org with stakeholders that don’t have access to the code base, I.e. most of the other company. You still need tickets, a way for stakeholders to follow, update, etc. those tickets, and a way to prioritize the tasks those tickets represent.
Totally agree that stakeholders need access, but I think that’s solvable with an interface layer on top of the repo rather than a reason to avoid the workflow.
Relational databases exist for a reason. Every effort that starts with “I really want to use this tool so let me shove a use case into it” always ends in disaster. Git has a purpose, and building an information management system is not one of them.
To start, how are you going to run queries on this bug tracker? How are you going to make sure it stays up to date for everyone at the company with sub-second latency? How are you managing access control? How do you keep the size under control over time?
While I understand the appeal of having local files that agents can read, I think the best way to do it might be pulling the needed files from a database.
By its nature, tasks are linked in relationships of parenthood and sequence, so databases are naturally suited for storage. Plus, they need ownership relations.
So, something like Jira but please oh god not Jira, where you can pull a subset of the DB (for example a project) locally and have some script generate the needed files (requirements) from what would be a Jira description.
When someone sells hammers, they want you to hammer screws. Typemill is a document product and naturally, they want you to use that. It looks very polished and nice though, shame not packaged for distro though.
That's true, but it might also be the case that they think this is a good way to work and that's why they built the product in the first place. (I don't agree, though, I think tasks are more suited for DB storage).
Typemill is open source with some paid plugins, I totally agree that a Markdown CMS is not the right solution, but it is an easy way to experiment with new workflows like this. I guess we will see other software in future if tasks will make the journey into the repos.
Tangibly related - I use Linear for ticket management and I'm in love with this. After being defiled by Jira in my $dayjob, I couldn't believe I'll find a ticket management app I would love so much I literally advertise for free.
These kinds of things are an EM’s wet dream. Especially an EM who knows they are not adding anything to the team but are capable of putting together a slide, mentioning “productivity reached X” without mentioning the baseline, and still being able to sell that improvement.
"AI coding agents work best when everything they need lives in the repository" honestly not true, they work best if they have all the information up front, local filesystem is pretty cheap path to that.
Better path is an orchestration agent that composes a short spec with the slice of the details for a slice of the work. Tickets end up being too verbose as people try to cover every potential aspect / use LLMs to generate them.
It's a very bad idea! ticket managers do more than just store ticket text! also duplicating a ticket text in the repo it's just wrong.. then why don't you put your db data into the repo too ?
Yes! There are some existing projects and posts on the idea of tickets in-the-repo.
Usually the problem is that it's not very friendly for Product Folks and SMEs so I've been working on a local first, git backed project management and documentation tool (Think Jira and Confluence).
So as to not hijack this post, I won't paste a link here (not to mention it's ready for prime time yet) but send me a message if you're interested (it's open source and visible so it's not too hard to find either)
Nah. There's a manager at my company that's pushing this, and it sucks for pretty much everyone except him. I suppose it's fine if you're delegating sprint management to AI agents, but everyone except the manager is going to be using this tool to manage sprints.
I was doing something like this manually, but for my own solo-dev projects. I wonder if your opinion is still the same for this case. I totally understand this is not really working when working on a team, but for planning -> delegating to LLMs this works really well for me
Better to keep tasks in a separate repo imo, or at least make sure they aren't committed.
I always follow one rule: looking at the git history should tell me what each change did, and the commit message alone should be enough to understand what actually changed.
If you mix tasks with code changes, you will just confuse your future self.
Moreover, you can set up something like beads to handle task delegation and status updates for your agents.
A lot of the tools we have to use are designed for meat proxy's (JIRA etc...) yes, you can allow the agents access to the task repo via api or MCP, but at the end of the day, the tool starts to become the bottleneck, Iike the idea of putting the tasks and issues into git, it means all info for why a change was made is in one place, accessable forever, just need to expand agents to non-software dev world.
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.
But someone still has to write the requirements? I am not familiar with software factories like this to be honest...
I'm not a beads user - but it rather brilliantly solves a lot of problems in this space
Tickets change faster than code. Having to create a PR to update a ticket sounds like a bureaucratic nightmare.
Then you go the nanoservice route, with double the repos!
This is a problem of requiring PRs for everything, not of putting tasks in the repo.
PRs or not, git workflows are always going to be many orders of magnitude slower than simple database reads/writes.
Counterpoint, many updates would also cause many commits just for keeping tasks updated, adding noise to the project history.
Nothing stopping people from keeping tasks in a separate repository, of course - this would also make it simpler to just allow commits straight to `main`.
This doesn’t work in an org with stakeholders that don’t have access to the code base, I.e. most of the other company. You still need tickets, a way for stakeholders to follow, update, etc. those tickets, and a way to prioritize the tasks those tickets represent.
Nothing a front-end can't solve. To the end user it doesn't matter if data is stored in a database or git, as long as it just works.
But counterpoint, an AI / machines can talk to Jira and other ticket management systems just fine, they have REST APIs and MCP servers nowadays.
Totally agree that stakeholders need access, but I think that’s solvable with an interface layer on top of the repo rather than a reason to avoid the workflow.
Or the other way around. An API for the robot to read tickets
Relational databases exist for a reason. Every effort that starts with “I really want to use this tool so let me shove a use case into it” always ends in disaster. Git has a purpose, and building an information management system is not one of them.
To start, how are you going to run queries on this bug tracker? How are you going to make sure it stays up to date for everyone at the company with sub-second latency? How are you managing access control? How do you keep the size under control over time?
While I understand the appeal of having local files that agents can read, I think the best way to do it might be pulling the needed files from a database. By its nature, tasks are linked in relationships of parenthood and sequence, so databases are naturally suited for storage. Plus, they need ownership relations. So, something like Jira but please oh god not Jira, where you can pull a subset of the DB (for example a project) locally and have some script generate the needed files (requirements) from what would be a Jira description.
When someone sells hammers, they want you to hammer screws. Typemill is a document product and naturally, they want you to use that. It looks very polished and nice though, shame not packaged for distro though.
That's true, but it might also be the case that they think this is a good way to work and that's why they built the product in the first place. (I don't agree, though, I think tasks are more suited for DB storage).
Typemill is open source with some paid plugins, I totally agree that a Markdown CMS is not the right solution, but it is an easy way to experiment with new workflows like this. I guess we will see other software in future if tasks will make the journey into the repos.
Tangibly related - I use Linear for ticket management and I'm in love with this. After being defiled by Jira in my $dayjob, I couldn't believe I'll find a ticket management app I would love so much I literally advertise for free.
These kinds of things are an EM’s wet dream. Especially an EM who knows they are not adding anything to the team but are capable of putting together a slide, mentioning “productivity reached X” without mentioning the baseline, and still being able to sell that improvement.
I kind of fear this would cause agents to get lost in previous outdated context, ultimately wasting time and tokens.
"AI coding agents work best when everything they need lives in the repository" honestly not true, they work best if they have all the information up front, local filesystem is pretty cheap path to that.
Better path is an orchestration agent that composes a short spec with the slice of the details for a slice of the work. Tickets end up being too verbose as people try to cover every potential aspect / use LLMs to generate them.
I have a rest API client for linear and the robot can read the ticket this way ? And comments made by Products and Design folks.
It's a very bad idea! ticket managers do more than just store ticket text! also duplicating a ticket text in the repo it's just wrong.. then why don't you put your db data into the repo too ?
Yes! There are some existing projects and posts on the idea of tickets in-the-repo.
Usually the problem is that it's not very friendly for Product Folks and SMEs so I've been working on a local first, git backed project management and documentation tool (Think Jira and Confluence).
So as to not hijack this post, I won't paste a link here (not to mention it's ready for prime time yet) but send me a message if you're interested (it's open source and visible so it's not too hard to find either)
Nah. There's a manager at my company that's pushing this, and it sucks for pretty much everyone except him. I suppose it's fine if you're delegating sprint management to AI agents, but everyone except the manager is going to be using this tool to manage sprints.
Funny that you and vhodges say basically the same thing, mirrored. :)
Nope, you're breaking Git history with that.
You should think about what your history represents. Just move the task manager somewhere else and track it there.
I was doing something like this manually, but for my own solo-dev projects. I wonder if your opinion is still the same for this case. I totally understand this is not really working when working on a team, but for planning -> delegating to LLMs this works really well for me
Better to keep tasks in a separate repo imo, or at least make sure they aren't committed.
I always follow one rule: looking at the git history should tell me what each change did, and the commit message alone should be enough to understand what actually changed.
If you mix tasks with code changes, you will just confuse your future self.
Moreover, you can set up something like beads to handle task delegation and status updates for your agents.
https://github.com/gastownhall/beads
A lot of the tools we have to use are designed for meat proxy's (JIRA etc...) yes, you can allow the agents access to the task repo via api or MCP, but at the end of the day, the tool starts to become the bottleneck, Iike the idea of putting the tasks and issues into git, it means all info for why a change was made is in one place, accessable forever, just need to expand agents to non-software dev world.