Version control for everything: why AI agents need git for non-code tasks
Agentic coding tools have taken off, but non-programming use cases lag because they lack version control. The author argues that without git-like guardrails, LLMs can't safely edit docs, calendars, or issues. He proposes a proxy layer for staging changes or moving everything into git, noting that Jane Street's code-review-in-comments workflow makes LLM involvement trivial. The post concludes that better version control benefits humans too, and points to local-first software and Irmin as relevant resources.
It’s not just agent-style LLMs that would benefit from this integration, _I_ would be more productive if all of my tools had branches, version history, and atomic changes.
- cfjgvjh
I really really want to do version control for everything, but most of my data is binary so it really doesn't agree with git; I tried using LFS as well but it didn't work for my specific workflow.
Hopefully something less text oriented comes along in the future.
Lore looked interesting for this purpose.
- PaulRobinson
Ah, we've got back to the "we should event source everything, and allow ourselves to change history and re-snapshot current state", idea gaining followers again.
Well, yeah. But it's hard. Also, git is not the solution to this, it's just the screwdriver you have in your hand right now.
- Klaster_1
> Design docs from Google Docs to checked-in markdown?
This worked pretty well for the team I'm in. Design docs in Google Docs were really hard to keep in sync with decisions and not properly agent accessible. Initially, we were concerned lack of comments would be an issue, but this didn't really came true - a Slack channel does a good enough job. With this flow, the design author makes a decision and review results, agent propagates it to individual areas, and from those to tasks (those are in MD too), and then copies descriptions to Jira. No more "we changed a thing but missed one place that depends on it", or at least not as bad as before.
- ammar_az
The approach of having everything next to the code seems good in theory but it's just a nightmare in practice for big projects.
Imagine your git history filled with commits from project managers where every little change in requirements and docs has its own commit.
We've tried that and ended up having to rebase our branches multiple times a day while we lost the overview of code changes completely.
The main issue that code can live in multiple branches while development but you can't apply that to docs and requirements where you need to have one centralized source of truth for everyone.
I think we will start to see more adaptation from collaboration tools to provide/accept the info in text format making it suitable for agents as a working solution. Meanwhile, I've seen that having two repos (One for Code and one for docs) is the best solution for the current tools available
- ssivark
> We use issue trackers and pull requests to manage work, people write documentation and communicate over email, instant messaging, and in meetings. Keeping all of the information in these channels synchronized and up to date is a full time job.
The crux of what OP wants seems to be transparent interfaces to the data store backing each of these services. Version control would be about tracking changes when this data mutates, which seems somewhat orthogonal to this stated need.
I wonder whether a nice solution to this would be to have a distributed architecture where each node can publish / subscribe to updates and maintain a local copy it operates on, with conflict resolution for eventual consistency.
PS: Checkout Perkeep for a take on aggregating all your data in one place.