A Product Hunt Listing Called 'AVP' Is Really a Bet Against Git for AI Agents

A Product Hunt listing titled “AVP” bills itself as an open source alternative to Git for AI coding agents. That is the entire public record we could verify: a name, a one-line pitch, and a discussion thread. There is no repository link we could confirm, no author named, no release notes, no benchmark. If you search “AVP” today, the top result is a Wikipedia disambiguation page that lists, among other things, Alien vs. Predator and Apple Vision Pro. That is the state of the evidence.

We are writing about it anyway, because the pitch is a real thesis and the thesis is worth arguing with. Someone believes Git, the version-control system that has organized software work since Linus Torvalds wrote it in 2005, is the wrong substrate for a coding agent. That claim deserves a hearing even when the product does not yet.

What Git assumes, and what agents break

Git was designed around a human committing at human cadence. A developer edits files, stages a coherent change, writes a message, pushes. The unit of work is the commit, and the commit assumes an author with intent who can explain themselves in a sentence.

A coding agent does not work that way. It writes in bursts, rewrites its own output, branches speculatively, and abandons most of what it tries. An agent running a long task might touch forty files across a dozen exploratory branches in the time a human would make one commit. The commit graph becomes noise. The diff becomes unreadable. The human reviewer, who is the whole point of the review step, gets a wall of churn.

This is not a hypothetical. Every team running agents in production hits some version of it. The common workarounds are ugly: squash everything into one commit and lose the reasoning, or let the agent commit freely and spend the afternoon reading a graph that looks like a subway map after an earthquake. Neither is a system. Both are a patch over a mismatch between the tool and the worker.

The real question is provenance, not storage

Strip away the branding and “an alternative to Git for agents” is really a proposal about provenance. Git stores snapshots. What an agent workflow needs is a record of why each snapshot exists: which prompt produced it, which tool calls ran, which tests passed, which model version was in the loop, and what the agent was trying to do when it went sideways.

That is a different data model. It looks less like a commit graph and more like an append-only log of agent actions with the file state attached. Some of this already exists in fragments. Evaluation harnesses like those from LangSmith and Weights & Biases log agent traces. Anthropic and OpenAI both ship trace tooling for their own agents. But none of it is version control, and none of it lives where the code lives.

An open-source project that put the trace and the tree in the same place would be genuinely useful. It would also be hard, because it forces a decision about what a “change” means when the author is a stochastic process. Git’s answer, the diff, assumes a stable before and after. An agent’s answer might be a distribution of attempts, most of which should be discarded.

Why this is a business story, not just a devtools story

The reason to care about a thin Product Hunt listing is that the version-control layer is where agent tooling is converging, and whoever owns it owns a lot. GitHub, now inside Microsoft, is the default home for code and has been pushing its own agent features through Copilot. GitLab sells the same layer to enterprises that want it on-premises. Cursor and the other agent-native editors sit on top of Git today because there is nothing else to sit on.

If agents become the primary authors of code, the system that records their work becomes the system of record for the entire software supply chain. That is a position with real leverage: audit, compliance, reproducibility, and the ability to answer “who wrote this and why” when something breaks in production. A startup that gets the agent-native version-control primitive right is not selling a nicer git. It is selling the ledger.

Which is exactly why the thinness of the AVP listing matters. A one-line pitch on Product Hunt is not a product. It is a signal that someone sees the gap. The gap is real. The question is whether the person who posted it can build the thing, and whether anyone can build it before GitHub, GitLab, or one of the agent labs folds the same idea into what they already ship.

What we can and cannot say

We cannot verify that AVP exists as working software. We cannot name its authors, its license, its architecture, or its relationship to Git’s object model. We have not seen a repository, a demo, or a single line of code. Anyone evaluating it should treat the listing as a claim, not a fact, until those artifacts appear.

What we can say is that the problem it names is real and unsolved. The teams running coding agents at scale are patching around Git’s assumptions every day, and the patches are not converging on a standard. The first credible open-source project to give agents a native record of their work, with the trace and the tree in one place, will find an audience. Whether that project is called AVP is a detail. Whether it ships is the story.

Watch the repository, not the listing.