There is a question that did not exist two years ago, and now it sits in every codebase that has touched an AI agent: who wrote this line? Not who last touched it, not who signed the commit, but who actually produced the bytes. A human, or a model.
It sounds like a philosophical question until you have a mostly vibecoded project and you want to carve out a few corners where the agent should not touch your code. Then it becomes a practical one. An open source tool called us-vs-them just appeared on Hacker News and it answers exactly this question, using nothing more than your existing git history.
No annotations. No special markup. No metadata files you have to keep in sync. Just git log, diffing, and some clever thinking about how authorship degrades over time.
The core idea
A git repository already records who made each change. Every revision of a file carries an author. The tool walks the version history of a file in order, diffs each revision against the previous one, and assigns each line a provenance: human or agent. The trick is that you only tell it which side yours is on. Everyone else is assumed to be a machine.
The output is a set of ranges with a score between 0.0 and 1.0. A line that reads 1.0 was fully human authored. A line that reads 0.0 was fully agent authored. A line that reads 0.46 was originally written by a human but has been modified by an agent to some degree.
us-vs-them --ours dan@example.net README.md
1-3 0.00
4 1.00
5-7 0.00
8-20 0.46
21-164 0.00In this example, line 4 is the only fully human-authored line. Lines 1 through 3 and 5 through 7 were written by the agent. Lines 8 through 20 were originally human text but got partially rewritten by an agent, scoring 0.46. The rest is pure machine output.
The metaphor the author uses is islands and sea. Human-authored lines are islands. Agent-authored lines are the surrounding sea. The algorithm does not just track individual lines but tries to identify coherent regions of text, factoring in how lines join, split, and dilute in authorship across versions. It wants to tell you "this block of 12 lines is mostly yours" rather than a pixelated map of individual lines.
Why this is harder than it looks
The naive version of this tool would be trivial: check git blame, look at each line's author, tag it. Done. The reason this tool exists at all is that the naive version produces garbage in real use.
Consider what happens when an agent rewrites a paragraph. Maybe it kept the first sentence because it was already correct, restructured the middle, and added two new lines at the end. A line-level blame would show the first sentence as human-authored and the rest as agent-authored. But the first sentence is now part of an agent-authored paragraph. The context around it changed. Is it still "human" in any meaningful sense?
Then consider what happens when a human edits one character in a line that an agent wrote. The blame switches to the human. But the line is fundamentally agent text with a typo fix. The tool handles this by diluting the score. A one-character edit by a human in a 40-line agent paragraph does not flip the whole paragraph to human. It nudges the score slightly.
This is the part that touches on a genuine research problem. When you track authorship at the line level, every edit is a question about where the boundary of "this thing" is. If I wrote a function and an agent rewrote the body but kept the signature, is the function mine? If the agent wrote the function and I rewrote the docstring, is it theirs? The tool cannot answer these questions definitively, but it provides a continuous score that lets you make the call yourself.
The commit attribution problem
One thing that came up immediately in the HN discussion is a practical gotcha that the tool has to work around. When you run an AI coding agent locally, the agent makes commits using your git identity. So git blame shows your name on everything, and the tool has no way to distinguish human from machine.
The author solves this in two ways. First, for agents like Claude Code, they use hooks to intercept bash calls and prepend git environment variables that set the author to "claude" instead of the human user. Second, for sandboxed agents, they set git env vars directly in the sandbox environment.
This is a hack. It works, but it requires you to configure your agent setup ahead of time. If you have been committing agent code under your own name for months and decide you want provenance tracking now, the tool can only tell you about changes going forward. Your history is already polluted.
This came up in the comments. One person said: "Maybe I'm missing how people use AI these days but when I have an agent working locally, all git commits have my authorship attached." They are right, and it is the kind of thing that makes provenance tracking more of a discipline than a tool. You have to care about attribution before you need it.
Does it even matter?
The most interesting comment thread on the HN post was not about the tool's implementation but about whether the problem is worth solving at all. One person put it bluntly: "I hardly use an editor anymore, and I'm not alone. All that matters is who is signing off on the commit."
That is a real position. In a world where a developer reviews every agent commit before merging, the reviewer is the one who owns the result. Whether the text was generated or typed does not change the fact that a human took responsibility for it. The bytes do not have a moral status. The merge button does.
But there is a counterargument that I find more convincing. The author frames it in terms of trust gradation within a codebase. You already have this instinct with human code. Some parts of a codebase were written by someone who deeply understood the problem and whose code you do not touch without a good reason. Other parts were written by an intern and you rewrite freely. You carry a mental map of which is which.
With agents, that mental map breaks down. An agent can produce 500 lines of code that look competent and are subtly wrong in a way you only discover three weeks later. If you could tag the code you personally wrote and reviewed as "do not rewrite without checking with me," you give the agent a respect boundary. Without that signal, the agent treats all code as equally editable, including your carefully reasoned parts.
The tool's author says they use it primarily for documentation and knowledge management, not code. That is probably the right instinct for now. Markdown files have a different relationship with correctness than source code. A README that got half-rewritten by an agent is a communication problem. A function that got half-rewritten by an agent is a bug waiting to happen, but the fix for that is tests, not provenance.
The broader picture
This tool is small and specific, but it is part of a pattern I have been watching all year. The first generation of AI coding tools was about generation. Can the model produce code? The second generation was about orchestration: can the agent run a loop, edit files, run tests, and commit? The third generation, which is just starting, is about governance. Now that agents can write and ship code, how do we track what they touched, audit what they changed, and protect what matters?
On arxiv this week, there is a paper called "An End-to-End Agent Auditing Engine" that tackles a related problem from the research side: building a system that can audit agent decisions across an entire task trajectory. Another paper, "TEPA," looks at how to revoke stale memories in language agent systems, which is the same provenance question at a different level: not "who wrote this line" but "which of this agent's memories are still valid."
The common thread is that we have spent two years making agents more capable and almost no time making them accountable. Tools like us-vs-them are the first dip into that water. They are rough, they make assumptions, and they will probably look primitive in a year. But the direction is right.
What it is and what it is not
us-vs-them is a CLI tool written in Clojure (Babashka), installed via bbin. It runs against any git repository. You pass it a file path and tell it which git identities are the humans. It walks the history and gives you a range-based score.
It is not a magical AI detector. It cannot tell you whether a given piece of text came from a language model by analyzing the text itself. It relies entirely on git commit metadata. If the metadata is wrong, the output is wrong. It is only as trustworthy as your commit hygiene.
It is also not a replacement for code review. Knowing that an agent wrote a line does not tell you the line is bad. Knowing a human wrote it does not tell you it is good. The tool gives you one piece of context: the origin of the bytes. What you do with that context is still your problem.
Who should care about this
If you are working alone on a small project and you review everything the agent produces, you probably do not need this. The mental overhead of setting up commit attribution correctly and interpreting the output is not worth it for a solo project where you are the only pair of eyes.
If you are working on a team where multiple people and multiple agents contribute to the same files, this gets more interesting. The ability to say "lines 1 through 40 are human-authored, the agent should be cautious here" is a real guardrail. It does not stop the agent from touching those lines, but if you integrate the provenance check into a pre-commit hook or a review tool, you can flag when an agent's diff crosses into human territory.
The author mentioned that their main use case is actually agentic memory: knowledge management systems where the agent maintains notes, the human edits some of them, and the agent should preserve the human edits during future updates. That is a narrower use case than code provenance, but it might be the one where this approach actually sticks.
My take
I like this tool because it is honest about what it does. It does not claim to detect AI churn. It does not claim to measure code quality. It does one thing: tells you who wrote what based on git history. The limitations are clear, the code is open, and the author admits that for their own projects they mostly use it on documentation rather than source code.
The bigger question this tool raises is one that I do not think anyone has answered yet. When your codebase is a collaboration between a human and a model, what does ownership mean? If I wrote the architecture and the agent filled in the implementation, is that my code? If the agent wrote the first draft and I rewrote every function body, is that the agent's code?
The legal answer is probably "it is all your code if you committed it." The engineering answer is: it depends which lines you are looking at and what you mean by "yours." us-vs-them gives you a way to start asking that question with data instead of vibes. It is not the final word, but it might be the first good tool for a conversation we are going to be having for a while.