Version Control for Everything

AI 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.

Imagine using claude-code outside of a git repository. Even for small things like refactors, using AI would be very stressful and error prone:

Even 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.

Managing 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:

and you’re interested in using an LLM to find places where some information hasn’t made its way from one service to another e.g. update an issue with new information after an email conversation . This task is hard in isolation though I think that today’s LLMs could do it but the biggest issue is that none of these services have built-in mechanisms that would allow the LLM to propose an action to be reviewed by a human.

Without 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.

If you’re ok with leaving github, google docs, etc, then you could move this functionality into git. Jane Street famously does code review by embedding code review comments directly in the source code as code comments , and this workflow decision makes it trivial to involve LLMs in code review because everything in the process is tracked with version control. Why not put issues alongside the codebase? Pull request and code-review metadata in source control? Design docs from Google Docs to checked-in markdown? It would be ideal if all of these were stored in the same repository as the code itself so that changes to code, issues, and docs could be made in a single atomic update instead of having to coordinate across services.

In 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.

Although I’ve framed this blog post as “things that would make LLMs more useful outside of programming”, you could just as easily replace “LLM” with “Junior Developer” or “Senior developer” and all of the points would hold. 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.

It 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

Here are some links that you might find interesting: