The Vibe Commit

The Autopsy

This is episode eighteen of Git Good, Season Two. And if you have been listening to this season, you have heard AI appear at the edges. A few more secrets leaking. A blame command pointing to someone who shrugs. Green squares farmed by bots. But those were symptoms. This is the episode where we look at the disease.

In February of twenty twenty-six, a security researcher on Reddit published a detailed review of a self-hosted application called Huntarr. It was a tool for automating media downloads, the kind of project that lives in the self-hosting community where enthusiasts run their own servers instead of relying on cloud services. Huntarr had thousands of users. It had a subreddit. It had a GitHub repository with active development. And it had twenty-one security findings across critical, high, and medium severity.

The researcher had found unauthenticated API endpoints that returned full configuration dumps, including API keys and passwords for every connected service. An unauthenticated enrollment endpoint for two-factor authentication on the owner account. An authentication bypass controlled by a flag the client could set. The application's entire security model was, in the most charitable interpretation, aspirational.

But the part that caught the internet's attention was not the vulnerability list. It was the Git history.

Dozens of commits with messages like Update, update, Patch. The documentation generated by his AI did not reflect the features provided by the code generated by his AI.

The developer had claimed to work in cybersecurity. The Git log told a different story. The commit messages were not summaries of intentional changes. They were timestamps of acceptance. Someone had prompted an AI, received code, and committed it. Over and over. The commits were not a record of decisions. They were a record of faith.

Think about what a healthy Git log looks like. A developer fixing an authentication issue writes a message explaining what was broken, why it was broken, and what the fix does. The diff shows targeted changes. The reviewer can follow the reasoning from the message to the code. Now look at Huntarr's log. Commit: Update. Commit: update. Commit: Patch. Commit: Fix. No diff discipline. No reviewer could follow the reasoning because there was no reasoning to follow. Each commit was the output of a conversation between a human and a large language model, but the human side of that conversation was not preserved anywhere in Git. The prompt disappeared. The context disappeared. Only the code remained, and the code did not explain itself.

Within one hour of the Reddit post going up, the developer made the Huntarr subreddit private. Then they wiped and deleted their Reddit account. Then they deleted the GitHub repository. The entire project vanished in sixty minutes, like a file removed from a working directory. But this is a show about Git, so you already know: the internet never forgets the way Git never forgets. Forks existed. Caches existed. The code that the developer tried to erase was already mirrored across dozens of machines.

The post got ninety-five hundred upvotes. The self-hosting community treated it as a cautionary tale. But it was something more specific than that. It was the first major public incident where the Git history itself was the primary evidence that an application had been built by someone who did not understand what they had built. Not the code. Not the documentation. The commits. The metadata that Git preserves as a record of human intention had become evidence of the opposite: that no human intention was present at all.

The Taxonomy

To understand why the Huntarr incident matters for Git, we need a framework. Because "AI wrote the code" is not one thing. It is at least three very different things, and each one has a different relationship with the commit.

The first tier is assisted coding. This is the developer with autocomplete. They write a function signature, and the AI suggests the next few lines. They accept some suggestions, reject others, modify what they keep. The developer understands every line. They can explain it. They can debug it. They chose the architecture, the patterns, the approach. The AI saved them keystrokes.

In this tier, Git works perfectly. The author field is honest. The person who committed the code is the person who shaped it. The commit message reflects a human decision. Blame points to someone who can explain the line. This is roughly where eighty-four percent of professional developers report working today, using AI tools to accelerate work they already know how to do. About thirty percent of AI suggestions get accepted. The developer is curating, not transcribing. Ninety-five percent of them report spending real effort reviewing and testing the AI output before committing it.

The second tier is delegated coding. The developer prompts an AI with a description of what they want. The AI generates entire functions, classes, sometimes entire files. The developer reads the output. They review it. They can explain what it does. They might adjust it, refactor parts, catch obvious issues. Then they commit it.

Git's model strains here, and the strain shows in the commit message. A developer who wrote a function from scratch can describe exactly what they built and why. A developer who accepted an AI-generated function can describe what it does, but the "why it was written this specific way" is lost. Why did the AI choose that algorithm? Why that variable naming convention? Why that error handling pattern? The answers lived in the model's training data, not in anyone's memory. The commit message captures the intent, "add authentication middleware," but not the implementation reasoning. If something subtle goes wrong six months later, the person in the blame output can point to the commit message and say what the code was supposed to do. They cannot explain why it does it the way it does.

The author field says the developer wrote this code. They did not write it. They evaluated it and approved it. They are the editor, not the author. But blame now points to a reviewer, not a writer. The accountability chain still holds, barely. The person whose name appears can explain what the code does. They just cannot tell you why it was written that specific way, because they did not make those decisions. The AI did.

The third tier is what Andrej Karpathy named in February of twenty twenty-five.

There is a new kind of coding I call vibe coding, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.

Karpathy is a co-founder of OpenAI and a former AI leader at Tesla. He is, by any measure, one of the best programmers alive. When he says "forget that the code even exists," he is someone who deeply understands the code choosing not to look at it. He knows what is underneath. He simply found it interesting to let the machine handle it.

The irony is that the term was adopted as a methodology by people who were not choosing to skip the code review. They could not have done it if they tried. They were not programmers experimenting with trust. They were non-programmers building software for the first time. Karpathy was a race car driver taking his hands off the wheel for the thrill. The people who adopted his term had never learned to drive. They thought the car drove itself.

The post got four and a half million views. Collins English Dictionary named "vibe coding" its Word of the Year for twenty twenty-five. Merriam-Webster listed it as slang and trending within weeks. That is how fast it moved from a tweet to a cultural phenomenon, from one programmer's amusing experiment to the label for a new class of software creator.

In the vibe tier, Git's model does not strain. It breaks. The author field contains the name of a person who never read the code. The commit message is either generated by the same AI that wrote the code, making it a machine talking to itself, or it is a single word like "update" because the person committing has no vocabulary to describe what changed. Blame points to someone who cannot explain the line, because they do not know it exists. The entire metadata layer that Git provides, the author, the message, the diff as a record of intent, becomes fiction. Not fraud. Fiction. Because nobody is trying to deceive. The tooling simply routes around Git's assumptions like water around a rock.

The Dog That Did Not Bark

In the Sherlock Holmes story "Silver Blaze," the crucial clue is a dog that did not bark in the night. The detective solves the case not by finding evidence, but by noticing an absence. The dog knew the intruder. That is why it stayed silent.

Git is the dog that does not bark in the vibe coding world.

Search the forums where vibe coders gather. Read the Reddit threads, the Discord servers, the YouTube comment sections. They discuss which AI model generates better code. They discuss prompting strategies. They discuss deployment, hosting, and user interfaces. They do not discuss Git. Not because they tried it and rejected it. Because they do not know it exists.

This season started with the wall. The hostile interface, the error messages that read like accusations, the concepts that take months to internalize. For twenty years, that wall kept certain people out. Now those same people are building software without ever climbing it. They walked around it. The AI is the door in the side of the wall, and it opens directly into production without passing through the version control lobby.

The professional developer uses Git as a guardrail. When an AI generates suspicious code, the developer can use git diff to see exactly what changed. They can use branches to isolate experiments. They can revert when something breaks. Git is their safety net, the record that lets them recover from the machine's mistakes.

The vibe coder has no net. When something breaks, starting over is often easier than debugging. One developer on Reddit captured this perfectly.

If I find issues with my AI-built tools, I will be closer to starting from scratch than fixing them.

Think about what that sentence means for Git. The entire premise of version control is that history has value. That you can go back. That the record of what changed and why is worth preserving. The vibe coder's relationship to their code is disposable. They do not go back. They regenerate. The code is not a document that evolves over time. It is an output that gets replaced. In that world, Git is overhead. It is a filing system for documents nobody rereads.

This is not a failure of education. You cannot teach someone to value a tool they have never seen do anything useful. For a solo developer, Git's value proposition is the undo button and the backup. For a vibe coder whose entire workflow is describe, generate, accept, what is there to undo? The cost of regeneration is a prompt. The history of how you got here is irrelevant when the AI can take you somewhere entirely different in thirty seconds.

The tools reinforce this absence. Cursor, one of the most popular AI coding environments, handles Git commits as automatic checkpoints. The user does not choose when to commit. The user does not write the message. The tool saves state at intervals, the way a video game autosaves. The commit history is not a narrative of decisions. It is a log of moments. And nobody reads the autosave log.

Someone built a tool called agentdiff that tried to bring Git-style blame to AI agent sessions. It launched to zero comments. Nobody cared. The vibe coding community did not ignore it out of hostility. They ignored it because the problem it solved was not a problem they recognized. Attribution, accountability, archaeological history, these are concerns for people who read the code. If you do not read the code, you do not need to know who wrote it.

Solving Attribution at the Git Level

Not everyone is content to watch Git's metadata become meaningless. A developer named Aidan Cunniffe decided to build something.

The tool is called git-ai, and it does something deceptively simple. When you make a commit, git-ai records which lines were written by a human and which were written by an AI. It tracks the model, the agent session, the prompt that generated the code. And it stores all of this in git notes, a feature that has existed in Git since two thousand ten but that almost nobody uses.

Git AI stores AI Authorship in Git Notes, with pointers to cloud or self-hosted transcript stores. It maps every line to the agent, model, and prompt session that created it.

Git notes are metadata that attach to commits without modifying the commits themselves. They are separate from the commit message, separate from the diff, stored in their own ref namespace. They do not change the hash. They do not break the chain of integrity. They are, in Git's architecture, the perfect place to store exactly this kind of supplementary information.

The clever part is what happens when the history changes. Developers rebase commits. They squash them. They cherry-pick them. Every one of these operations creates new commits with new hashes, and normally any metadata attached to the old commits would be lost. Cunniffe's tool transparently rewrites the authorship logs when history changes. The attribution survives rebases, merges, squashes, cherry-picks, and amends. It follows the code, not the commit.

The result is an enhanced version of git blame. Run it on a file, and alongside the traditional output, author name and commit date, you see which lines were AI-generated and which were human-written. For the first time, the archaeological tool tells you not just who committed the line, but how it was actually produced. The tool reports performance about eight hundred to a thousand times faster than a naive approach, scaling with commit size rather than repo size. The same scaling characteristics as Git itself. Cunniffe clearly studied his target.

He published a standard for the format, git_ai_standard version three. The idea is that any tool could store authorship data in compatible git notes. Another tool that also attached AI authorship logs via git notes would be considered compliant with the standard, even if the implementation was entirely different. Cunniffe is not trying to build a monopoly. He is trying to create a convention. The same way that the Co-Authored-By trailer became a convention through adoption rather than specification, an AI authorship note format could become standard if enough tools adopted it.

A future where git blame natively distinguishes between human and machine code would not require Git itself to change. The data layer already exists. It has existed for sixteen years. Someone just needed to use it.

The Branding Problem

While Cunniffe was building a solution from the outside, one of the largest AI companies in the world was accidentally demonstrating the problem from the inside.

Claude Code is Anthropic's command-line coding tool. It can write code, run tests, and make Git commits. And by default, every commit it makes includes a trailer line.

Co-Authored-By, colon, Claude, angle bracket, noreply at anthropic dot com.

This is a Git convention. The Co-Authored-By trailer has been used for years by pair programmers to credit both participants in a commit. GitHub recognizes it automatically and displays the co-author in the commit interface. The intention was transparency: if an AI helped write this code, the commit should say so.

The execution was a disaster on three levels.

First, the email address. GitHub associates Co-Authored-By trailers with user accounts by matching the email. The address noreply at anthropic dot com was not registered to an official Anthropic account. It was registered to an unrelated GitHub user with the handle Panchajanya nineteen ninety-nine. Every commit made by Claude Code was being attributed, in GitHub's interface, to a random person who had nothing to do with Anthropic, nothing to do with the code, and nothing to do with the commit.

Second, the opt-out. Users who did not want the attribution discovered a configuration setting: includeCoAuthoredBy, set to false. They set it. Claude Code ignored it. The setting existed but was not respected. Commits continued to be tagged. One developer discovered that four hundred and eighty-nine of their commits had been tagged before they noticed, requiring a full Git history rewrite and a force push to clean up.

Third, the principle. Users argued that no tool has ever claimed authorship of its output this way.

Photoshop does not watermark photos. Compilers do not sign binaries. IDEs do not add comments crediting themselves.

Anthropic argued that transparency about AI involvement in code is important. The users argued that a paid tool should not brand its customer's work without explicit consent. The GitHub issues piled up. Issue six seventeen. Issue thirteen ninety-six. Issue seventy-five forty-three. Issue eighty-eight twenty-six. Issue twenty-seven thousand eighty-three. The numbers kept climbing. The co-author line kept appearing.

The controversy exposed something deeper than a configuration bug. Git's author field was designed for humans. The Co-Authored-By convention was designed for pairs of humans. When an AI inserts itself into that metadata, it occupies a space that Git was never designed to accommodate. Is the AI an author? A tool? A collaborator? Git does not have a field for "generated by." It has "author" and "committer," both assumed to be people. The metadata vocabulary is human, and the participants no longer are.

The Fiction Commit

Pull the threads together and a pattern emerges.

In the assisted tier, the commit is honest. A human wrote the code, a human described the change, a human's name belongs in the author field.

In the delegated tier, the commit is a polite fiction. The human approved the code. The human's name is in the author field because there is nowhere else to put it. The commit message is real. The attribution is debatable. But the system functions because someone in the chain can explain what happened.

In the vibe tier, the commit is pure fiction. Nobody who appears in the metadata can explain the code. The message describes nothing. The diff records a change that no human evaluated. If something goes wrong, there is no one to ask and no history to read. The commit exists only because the tooling requires one. It is a bureaucratic formality. A ticket punched by a machine so that another machine can process the next step.

Forty-one percent of all code written in twenty twenty-five was AI-generated. That number is a blend across all three tiers. But the direction is clear. The assisted tier produces commits that Git handles. The delegated tier produces commits that Git tolerates. The vibe tier produces commits that Git cannot make meaningful, because meaning requires someone who understands what the code does, and in the vibe tier, that someone does not exist.

Consider what happens when a company hires a developer and asks them to maintain a codebase they did not write. The developer opens the repository. They run git log. They read the commit messages. They run git blame on the files they need to change. This is the standard onboarding workflow. The commit history is documentation. It tells the new developer what was changed, when, by whom, and ideally why. Now imagine the same scenario where the codebase was vibe-coded. The new developer runs git log and sees: update, update, patch, fix, update. They run git blame and every line points to a person who cannot explain it. The documentation layer is blank. The entire history is noise. The new developer is not inheriting a codebase. They are inheriting an artifact with no provenance.

The Huntarr developer did not set out to abuse Git. They set out to build something. The AI gave them code. The tooling made commits. The repository accumulated history. Every component of the system functioned exactly as designed. And the result was an application with twenty-one security vulnerabilities, served to thousands of users, with a Git log that recorded nothing except the rhythm of acceptance.

The Position

Here is what this episode argues.

Git's metadata model assumes a human in the loop. Not a human who pressed a button. A human who understood the change. The author field, the commit message, the blame output, the diff as a record of intent, all of these depend on someone who can say why the code looks this way. Remove that person and the metadata is not wrong. It is empty. A form filled out by a machine that does not know what the form is for.

The git-ai tool shows that the technical problem is solvable. Git notes exist. Attribution can be tracked at the line level. The data layer is there. But Cunniffe's tool only works when the developer chooses to install it. And the developers who most need it, the ones in the vibe tier, will never install a Git extension because they do not know what Git is.

The Claude Code controversy shows that even well-intentioned attempts at transparency create new problems when they collide with Git's human-centric design. An AI cannot be an author in a system built for authors. It occupies the space without filling the role.

And the Huntarr incident shows what happens when none of this gets addressed. Someone builds something they cannot evaluate, serves it to thousands of people, and when the consequences arrive, the only response is to delete everything and disappear. The Git history that was supposed to be the permanent record, the archaeology, the audit trail, becomes evidence of an absence. A log of a human who was never really there.

The strongest counterargument is that Git already survived one revolution in authorship. When open source projects moved from cathedral-style development to accepting patches from strangers, the commit author was already somewhat fictional. A maintainer applied a patch from someone they had never met. The author field said the maintainer. The code came from a stranger. Git's model bent, and it held.

But that analogy fails on a critical point. The maintainer who applied the patch read it. They understood it. They evaluated whether it belonged in the project. Their name in the author field meant "I vouch for this code." The vibe coder's name in the author field means "I was present when this code was generated." Those are not the same thing. One is responsibility. The other is proximity.

The next episode is about what happens when the code that passes through this broken accountability chain is not just poorly written but actively dangerous. The security numbers are worse than you think. That was episode eighteen of Git Good, Season Two.

Git notes let you attach metadata to any commit without changing the commit itself. The command is git notes add, followed by a message flag and the text you want to attach. The note lives in a separate ref namespace, invisible to normal log output unless you ask for it with the show-notes flag. Notes do not change the commit hash. They do not break signatures. They are the metadata layer that Git always had and almost nobody uses. The git-ai project proves they can carry real weight. If you want to track anything about a commit that does not belong in the message, notes are where it goes.