Patchwork is a version control system built from scratch for a world where AI agents are writing and editing code alongside each other, all at the same time. It is not a wrapper around Git. It is not a plugin or an extension. It is an entirely new system, designed from the ground up around the assumption that dozens -- or hundreds -- of automated agents might be modifying the same codebase simultaneously, and that the system itself needs to keep everything coherent without anyone stopping to coordinate.
Think of Git like a library. You walk in, check out a book, take it home, scribble some notes in the margins, and bring it back. The system works beautifully as long as people check out books one at a time, or at least work on different books. A few people can even work on the same book if they are careful about which chapters they touch.
Now imagine 50 people all check out the same book at the same time. Each person takes it home, rewrites entire chapters, and then tries to return their version. The librarian is now staring at 50 different copies of the same book, each with conflicting edits, and somehow needs to produce one coherent final version. That is what happens when you point a fleet of AI agents at a Git repository.
Git was designed for humans doing mostly sequential work. One person opens a pull request, it gets reviewed, it gets merged, and then the next person's pull request gets its turn. The whole workflow assumes a relatively small number of authors, working at human speed, with time to stop and resolve conflicts by hand. AI agents shatter all of those assumptions. They work fast, they work in parallel, and they do not pause to chat about merge conflicts over coffee.
Every agent starts from the same snapshot of the code, but the moment they begin editing, their copies start drifting apart. Agent A renames a function. Agent B adds a parameter to that same function. Agent C moves the file entirely. The longer they work in isolation, the further apart their copies drift, and the harder it becomes to stitch everything back together. With enough agents working long enough, merging becomes not just difficult but catastrophically complex -- the kind of problem where the merge itself introduces more bugs than the original work fixed.
Git captures history in commits. A commit is a deliberate, human-sized snapshot: "here is what the code looked like after I finished this chunk of work." But agents do not work in human-sized chunks. They make a continuous stream of small edits -- dozens or hundreds per minute. Git only sees the final result when the agent decides to commit. Everything in between is invisible. If something goes wrong halfway through an agent's work, there is no record of the intermediate steps. The history is full of gaps.
In Git, you do not know what other people are doing until they push their branch and you try to merge. That works fine when merges happen once a day and a human can sit down and sort things out. But when 50 agents are all editing in parallel, "find out at merge time" is far too late. By the time Agent A discovers that Agent B already deleted the file it has been editing for the last ten minutes, a lot of wasted work has already happened. There is no mechanism for agents to see each other's in-progress changes and adjust accordingly.
In Patchwork, every single file-level edit is recorded immediately. Created a file? That is an operation. Modified a file? Operation. Renamed it? Operation. Deleted it? Operation. These operations are written into a shared, append-only log the moment they happen -- not when someone decides to "commit."
Think of it like a shared Google Doc. In a Google Doc, you do not "save" your work in big batches. Every keystroke shows up in real time, and the full history of every change is preserved automatically. Patchwork does the same thing for code. The log of operations is the history, and it captures everything.
Instead of branches, Patchwork organizes work into "changes." A change is a named unit of work -- roughly analogous to a pull request, but with an important difference. As an agent works, Patchwork automatically creates numbered versions of the change: v1, v2, v3, and so on.
Think of it like drafts of a document rather than separate copies. When you are writing an essay, you do not create a whole new file for each round of edits. You just keep revising the same document, and each revision is a new draft. If draft 5 turns out to be worse than draft 3, you can go back. Everyone can see which draft is current without having to compare entirely separate copies.
This means there is no "divergence" in the Git sense. Agents are not working on isolated copies that drift apart. They are creating successive versions of a change, and the system always knows how each version relates to every other version.
In Git, you "check out" a branch, and your local directory becomes a copy of that branch. In Patchwork, you get a "view" instead. A view is a composed picture of the codebase: it starts with the current state of the main line, layers your in-progress changes on top, and can optionally include other agents' changes as well.
Think of it like a magic window. You are looking at the real, current state of the world -- not a snapshot from whenever you last pulled. Your own changes are overlaid on top, like sticky notes on a window. And if you want, you can toggle on another agent's sticky notes too, so you can see what they are doing before either of you is "done."
This is how Patchwork solves the awareness problem. Agents are not working in sealed-off silos. They can see the live state of the codebase and each other's work-in-progress, which means they can react and adjust in real time rather than discovering conflicts after the fact.
When a change is ready to land, it does not just get merged immediately. It enters a submit queue -- think of it like a deli counter. You take a number, and changes get tested and landed in order.
But here is the clever part: the queue does not test changes one at a time. It uses speculative testing, similar to how a system called Zuul works. Say changes A, B, C, and D are all in the queue. Rather than testing A, waiting for it to pass, then testing B, the system tests all four simultaneously. Change A is tested on its own. Change B is tested as if A already passed. Change C is tested as if A and B already passed. And Change D is tested as if A, B, and C all passed.
If everything passes, all four land almost immediately. If B fails, the system throws out B's results and re-tests C and D without B in the picture. This means the queue moves fast when things are going well, and it self-corrects when they are not, all without any human intervention.
-
Operation -- A single file-level change. Creating a file, modifying a file, deleting a file, or renaming a file. The smallest unit of work that Patchwork tracks.
-
Change -- A named unit of work, roughly like a pull request. It groups together all the operations that make up a logical piece of work, like "add the login page" or "fix the billing bug."
-
Version -- A snapshot of a change at a particular point in time. As an agent works on a change, Patchwork creates versions automatically -- v1, v2, v3 -- so there is always a clear history of how the change evolved.
-
View -- A lens through which you see the codebase. Your view starts with the current state of main and layers your changes on top. You can also include other agents' changes in your view if you want to see what they are working on.
-
Workspace -- A local directory on disk that stays synced with your view. When your view updates (because main moved forward, or because you added new operations to your change), your workspace updates to match.
-
Queue -- The ordered pipeline that tests and lands changes. Changes enter the queue when they are ready, get tested speculatively in order, and land on main when they pass.
Patchwork is built for a specific set of situations, and it is worth being honest about that.
You would reach for Patchwork when you have multiple AI agents editing the same codebase simultaneously. If you have one developer working on a project alone, Git is fine. Patchwork is designed for the scenario where parallelism is the norm, not the exception.
You would use it when you need real-time awareness of what is changing. If your agents need to see each other's in-progress work and react to it -- rather than discovering conflicts hours later at merge time -- Patchwork's views give you that.
And you would use it when you want a continuous history of every edit, not just commit-sized snapshots. If understanding exactly what happened between "the code worked" and "the code is broken" matters to you, Patchwork's operation log gives you a complete, unbroken record of every change that was made and when.
If none of those describe your situation, Git is a battle-tested tool and there is no reason to replace it. Patchwork exists because the rise of AI agents created a new class of problems that Git was never designed to handle.