{"slug": "version-control-for-everything", "title": "Version Control for Everything", "summary": "AI-assisted agentic coding has reached escape velocity, but non-programming use cases lag due to a lack of version control, according to an analysis. The author argues that without version control, using AI for tasks like refactoring is stressful and error-prone, and proposes that adding a proxy layer or moving workflows into git could enable human review of AI-proposed actions across services like GitHub, Google Calendar, and Slack.", "body_md": "# Version control for everything\n\nAI assisted agentic coding has reached escape velocity, but non-programming use cases haven’t seen the same degree of adoption. I believe that the main reason for this is the lack of version control.\n\nImagine using claude-code outside of a git repository. Even for small things like refactors, using AI would be very stressful and error prone:\n\n- It would be near-impossible to track the changes that the LLM made. Auditing the LLM generated code is useful in the moment to ensure that changes are reasonable before moving on to another task, and in the future when you want to understand why some code was written\n- The LLM could put the codebase in a bad state and you’d have no way of reverting This is true even if the LLM is incredibly smart and didn’t make any “mistakes” - the human prompter forgetting to tell it about a design constraint could be bad enough\n- There’s no split between the “development branch” and “prod”\n- You can’t parallelize development by having multiple LLMs work on different branches\n\nEven when I pay Claude to work on a small script, I always create a new git repo just to make my life easier. But outside of coding, it’s nearly impossible to find tooling that has the same guardrails and affordances.\n\n## Case study: software development outer loop\n\nManaging the software development process is hard. 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. In this scenario, let’s say we’re concerned with the following systems:\n\n- github issues (read/write)\n- pull requests (read/write)\n- google calendar (read/write)\n- google docs (read/write)\n- gmail (read)\n- slack (read)\n\nand you’re interested in using an LLM to find places where some information hasn’t made its way from\none service to another\ne.g. update an issue with new information after an email\nconversation\n. This task is hard in isolation\nthough I think that\ntoday’s LLMs could do it\nbut *the biggest issue is that none of these services have\nbuilt-in mechanisms that would allow the LLM to propose an action to be reviewed by a human.*\n\n### Option 1: a proxy layer\n\nWithout changing any of the underlying services, you could imagine building a proxy to add a “pull requests” layer that would allow staging changes across multiple underlying services and allow review before publishing the changes. An agent would act through this proxy, which would aggregate the mutations until someone could review, approve, and publish them.\n\nThis is challenging for a few reasons:\n\n- Building one-off systems like this is time consuming, it’s tied to the specific workflow and complexity grows as you need to integrate more services.\n- “Revert” would probably be out of reach. Underlying services might not provide functionality necessary to implement “undo\" especially when reverting a change that has already had other changes stacked on top of it .\n- Detecting and resolving merge conflicts in the underlying services isn’t always possible.\n- There’s no atomicity. If someone clicks the “publish” button and one service rejects the change for any reason, all the previous changes to other services are already out in the world. This is especially troubling if the already-published changes can’t be reverted\n- The layer on top of the underlying services prevents you from seeing what the whole state of the\nworld would look like if you were to merge the change.\nImagine having to do code\nreview, but could only look at the diff instead of being given the diff\n*and*the ability to see the entire contents of the codebase before and after the diff is applied.\n\n### Option 2: put everything else in git\n\nIf you’re ok with leaving github, google docs, etc, then you could move this functionality into git.\nJane Street famously\n[does code review by embedding code review comments directly in the source code as code comments](https://www.janestreet.com/tech-talks/janestreet-code-review/),\nand this workflow decision makes it trivial to involve LLMs in code review because everything in the\nprocess is tracked with version control.\nWhy not put issues alongside the\ncodebase? Pull request and code-review metadata in source control? Design docs from Google Docs to\nchecked-in markdown? It would be ideal if all of these were stored in the same repository as the\ncode itself so that changes to code, issues, and docs could be made in a single atomic update\ninstead of having to coordinate across services.\n\nIn my view, the main obstacle here is that without serious dedication, the user experience for humans would be a major downgrade. This isn’t insurmountable, but it would be a lot of work.\n\n## A better world for LLMs is a better world for me\n\nAlthough I’ve framed this blog post as “things that would make LLMs more useful outside of\nprogramming”, you could just as easily replace “LLM” with “Junior Developer”\nor\n“Senior developer”\nand all of the points would hold. It’s not just agent-style LLMs\nthat would benefit from this integration, *I* would be more productive if all of my tools had\nbranches, version history, and atomic changes.\n\nIt can be hard to get management to invest in developer productivity tooling, but for the next few years I think it’d be easier to justify spending on “AI Infrastructure” that happens to be a better experience for devs as well. Maybe you could use this to your advantage :D\n\n## Extra reading\n\nHere are some links that you might find interesting:\n\n- The\n[Local-First Software movement](https://www.inkandswitch.com/essay/local-first/local-first.pdf)has been championing merge-based and conflict-free techniques for synchronizing data and documents. [Irmin](https://irmin.org/)is an OCaml library for building git-like databases with branches, merges, etc.", "url": "https://wpnews.pro/news/version-control-for-everything", "canonical_source": "https://tyoverby.com/posts/version-control-for-everything-else/", "published_at": "2026-08-17 19:28:44+00:00", "updated_at": "2026-08-17 19:41:46.498213+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "developer-tools"], "entities": ["Claude", "GitHub", "Google Calendar", "Google Docs", "Gmail", "Slack", "Jane Street"], "alternates": {"html": "https://wpnews.pro/news/version-control-for-everything", "markdown": "https://wpnews.pro/news/version-control-for-everything.md", "text": "https://wpnews.pro/news/version-control-for-everything.txt", "jsonld": "https://wpnews.pro/news/version-control-for-everything.jsonld"}}