Why Git Doesn't Quite Fit AI-Assisted Workflows
Git is excellent for human developers making deliberate changes. But when AI agents iterate rapidly on your code, the workflow assumptions start to break down.
Git is genuinely one of the best developer tools ever made. It’s been the backbone of software development for almost two decades, and for good reason: the model of staging, committing, and branching works incredibly well for human developers making deliberate, discrete changes to code.
That said, we’ve noticed that developers using AI coding assistants heavily tend to run into some friction with the traditional git workflow. It’s worth exploring why that happens and what can be done about it.
How Git Assumes We Work
Git was designed with a particular mental model in mind. A developer decides to make a change, works on it until it’s ready, stages the relevant files, writes a commit message describing what was done and why, then continues to the next task. There’s a natural rhythm of work-stage-commit that creates a clean, meaningful history.
This works beautifully when you’re in control of each change and have the mental context to describe it coherently.
How AI Assistants Actually Work
When you’re working with tools like Cursor, Claude, or GitHub Copilot, the dynamic is different. A single task might involve the AI making dozens of file modifications across multiple attempts. You might try three or four different approaches before finding one that works. The AI iterates rapidly, often faster than you can meaningfully review each change.
In practice, this means developers often end up with either:
- Long stretches without any commits, because stopping to commit breaks the flow
- Large commits with many unrelated changes bundled together
- Vague commit messages like “AI changes” or “WIP” because summarizing 40 file changes is tedious
- Occasionally, lost work when the AI takes things in an unexpected direction
Git is doing exactly what it was designed to do here. The workflow assumptions just don’t quite match how AI-assisted development actually happens.
The Core Tension
The fundamental issue is that git requires intentional action to record state. You have to decide to commit, and you have to write a message. This is great for creating a meaningful project history, but it adds friction during rapid iteration.
When an AI assistant is making changes quickly and you’re focused on reviewing and guiding those changes, stopping to create commits feels like an interruption. And if you skip the commits, you’re flying without a safety net.
Some developers have adapted by creating “checkpoint” commits before risky AI operations, or by working on separate branches for each experiment. These are reasonable workarounds, but they add overhead and don’t fully solve the problem of capturing the iterative exploration that happens during AI-assisted work.
A Complementary Approach
We built mrq to work alongside git. Git remains the right tool for collaboration, code review, deployment pipelines, and maintaining a clean project history. mrq adds automatic, continuous state capture during your development sessions.
When you’re iterating with an AI assistant, mrq watches your file system and captures snapshots automatically. You don’t need to stop and commit, as the state is just preserved. If something goes wrong, you can restore any previous snapshot with a single command.
Once you’re happy with where things landed, you can still commit to git as usual. The difference is that during the messy exploration phase, you have a safety net that doesn’t require you to think about version control at all.
Finding the Right Balance
There’s probably no single “right” approach here, and different developers will prefer different workflows. Some people are disciplined about git commits and don’t feel the need for additional tooling. Others find that automatic state capture lets them work more confidently with AI assistants.
If you’ve experienced the frustration of losing AI-assisted work or find yourself avoiding experiments because you’re not sure you can get back to a working state, it might be worth trying a tool designed specifically for this workflow. We’re running an open beta at dashboard.getmrq.com if you’d like to give it a shot.
Written by mrq team