The Invisible Commit: Where Every Thread Meets

The Commit

This is episode twenty-one of Git Good, Season Two.

Here is a commit. It was pushed to a production repository on a Tuesday afternoon in early two thousand twenty-six. The author field says a developer's name. The commit message is four lines long, clean and conventional, starting with a verb in the imperative mood: "Refactor authentication flow to support multi-tenant sessions." The diff is eleven hundred lines across fourteen files. A pull request was opened, reviewed, approved, and merged. The continuous integration pipeline ran, the tests passed, and the code was deployed to production. Within forty minutes of the push, real users were running the new code.

None of that is unusual. It happens thousands of times a day across the industry. What makes this commit interesting is what actually happened behind the metadata.

The developer whose name appears in the author field did not write the code. An AI agent did, working from a prompt that described the desired behavior in three sentences. The commit message was generated by a separate tool that analyzed the diff and produced a summary, a tool the developer never read the output of because it was configured to run automatically. The pull request was reviewed by CodeRabbit, the AI review service that episode four described processing millions of pull requests. The review produced seven comments. The developer glanced at the summary, saw no blockers, and clicked merge. The pipeline, configured months earlier, did the rest.

Now ask Git what happened. Run git log. The log says a human authored the change on that Tuesday. Run git blame on any of those fourteen files. Blame points to that human, to that commit, to that date. Run git show on the commit hash. The message reads like the developer sat down, understood the authentication flow, refactored it thoughtfully, and described what they did. Every piece of metadata tells a story. And every piece of that story is fiction.

The author field names a person who typed a prompt. The commit message describes work nobody performed. The diff contains eleven hundred lines that no human evaluated in full. The review was conducted by a system that cannot be held accountable. The blame will point to someone who, if asked in six months what this code does, will shrug.

This is not a hypothetical. In two thousand twenty-five, forty-one percent of all new code pushed to repositories globally was AI-generated. Nearly three out of four developers used AI coding tools daily. Tens of millions of pull requests were merged. The math is simple. This commit, or something functionally identical, is being pushed right now, as you listen to this sentence.

The Metadata Gap

The commit was the atom of version control. The indivisible unit. Every feature Git offers, branching, merging, blaming, bisecting, reverting, depends on the assumption that a commit represents a meaningful, authored, intentional change.

That assumption held for twenty years. It is breaking now.

The gap between what Git records and what actually happens has been widening all season. Episode one described the wall that keeps people from understanding Git at all. Episode two showed the solo developer whose commit messages are a wasteland because nobody else will ever read them. Episode four described the review fatigue that was already setting in before AI made it worse. Episode eleven revealed the secrets that leak through commits at twice the baseline rate when AI is in the loop. Episode thirteen showed that Git does not even verify who you claim to be. Episode fourteen documented the green squares turning into noise. Episode seventeen described the maintainers drowning in pull requests they never asked for. Episode eighteen defined the three tiers of AI-assisted development and showed what happens when vibe-coded commits enter a real repository. Episode nineteen laid out the security numbers. Episode twenty followed the money that does not flow back.

Every one of those threads arrives here, at this commit. The wall means the developer who clicked merge may not fully understand the code they approved. The identity gap means the author field is trusted on faith. The review fatigue means the AI approval was a relief, not a concern. The security debt means vulnerabilities may be buried in those eleven hundred lines. The green squares mean this commit counts toward a contribution graph that hiring managers will evaluate. The funding crisis means the open source libraries this code depends on are maintained by people who cannot afford to keep doing it.

One commit. Twenty threads. And Git, the system designed to be the permanent record of every change, faithfully recorded all of it. Faithfully and incorrectly.

The Numbers

CodeRabbit, the company whose AI reviewed our hypothetical commit, published a report in December two thousand twenty-five that quantified the gap. They analyzed four hundred and seventy pull requests, comparing AI-authored changes to human-authored changes. The findings were specific. AI-authored code produced ten point eight three issues per pull request. Human-authored code produced six point four five. That is one point seven times more issues from AI code.

The type of issues mattered more than the count. Performance inefficiencies, things like excessive input-output operations and redundant computations, appeared nearly eight times more often in AI-generated code. These are not the kinds of bugs that crash a program. They are the kinds that make it slow, that waste resources, that accumulate quietly until someone notices the server bill has doubled.

AI-authored changes produce approximately one point seven times more issues than human-authored changes. The highest category is performance inefficiency, where the ratio reaches nearly eight to one.

And this is the code that gets reviewed. The code that goes through a pull request, that gets comments, that someone at least glances at before merging. The vibe-coded projects from episode eighteen, the ones with commit messages like "Update" and "Patch," do not go through this process at all. They go straight from the AI to the repository to production, and the only review they receive is whether the application appears to work when someone opens it in a browser.

The traditional metrics for measuring software delivery are breaking under this pressure. Deployment frequency goes up because AI generates code faster. Lead time goes down because the pipeline is automated. Change failure rate becomes harder to measure because the failures are subtle, performance degradation and security vulnerabilities rather than outright crashes. Mean time to recovery loses meaning when nobody is sure what the code is supposed to do in the first place.

The instruments designed to tell us whether software development is healthy are giving us readings from a world that no longer exists.

Think about what happens when something breaks. A user reports that the application is slow. An on-call engineer opens the repository. They run git log and see last Tuesday's commit. They run git blame on the file that handles authentication. The blame points to a name. The engineer messages that person. And that person says, honestly, I do not know. I prompted an AI and it rewrote the authentication flow. The commit message says "Refactor authentication flow to support multi-tenant sessions." I did not write that message. A tool did. I do not know what multi-tenant sessions means in this context. The AI decided that was the description.

So the engineer tries git bisect. The standard practice: mark the last known good commit, mark the current bad commit, and let Git binary-search for the one that introduced the regression. But the commit in question is eleven hundred lines across fourteen files. Bisect can narrow it to the commit, but the commit is not a coherent unit of human thought. It is a bulk generation. The debugging tool designed to find where something went wrong can find the when but not the why, because there was no why. There was a prompt.

The Attribution Problem

The git-ai tool from episode eighteen offers one answer to this gap. Aidan Cunniffe built a drop-in replacement for git blame that tracks which lines were written by a human and which by an AI, using Git notes to attach authorship metadata without modifying the commit itself.

The tool is open, the specification is at version three, and as of early two thousand twenty-six, almost nobody uses it. The gap between the problem being diagnosed and the solution being adopted is vast, because the people who most need this tool, the vibe coders from episode eighteen, have never heard of git blame in the first place, let alone git-ai blame.

The Agent Problem

Scott Chacon, who we met in episode three building GitButler, called it the workflow crisis.

The hard problem is not generating change. It is organizing, reviewing, and integrating change without creating chaos.

GitButler's virtual branches, the tool episode three described in detail, are designed for exactly this moment. When three AI agents produce changes simultaneously, the developer needs a way to sort, review, and integrate those streams without drowning. The bottleneck is no longer writing code. The bottleneck is understanding code that arrives faster than any human can read it.

And then there is Jujutsu, the Git wrapper from episode three that makes every operation undoable. If the invisible commit is a problem of authorship and accountability, Jujutsu's answer is different from git-ai's. It does not track who wrote what. It makes it trivially easy to inspect, modify, and reverse any change, regardless of who or what produced it. The philosophy is not "record the truth about authorship" but "make the consequences of any commit reversible."

Four People, One Commit

Take the invisible commit from the opening and place four people around it. This season has followed four perspectives, and all of them are standing in the blast radius.

The solo developer, the person from episode two who uses five commands and treats Git as a save button, does not see a problem. They have always used Git without understanding it. AI writing the code is no different from copy-pasting from Stack Overflow, which is what they were doing before. The commit message was always "fix stuff." The author field was always them. Nothing has changed except the code is better than what they used to write.

The vibe coder, the person from episode eighteen who types nothing into Git because the AI handles everything, does not know this commit exists. Not in the abstract sense. They literally do not know there is a commit. The AI wrote the code, the AI committed it, the AI pushed it. The vibe coder saw a working application in their browser and moved on. If you showed them the git log, they would not know what they were looking at.

The team developer, the person from episode four who sits in code reviews and worries about merge conflicts, feels the weight of the invisible commit every day. Their pull request queue is longer than it has ever been. The AI-generated PRs are clean, well-formatted, and numerous. They approve them faster than they used to because the AI review already flagged the obvious issues. They tell themselves they are in the delegated tier. But the truth is they stopped reading the diffs three weeks ago. There are too many. The AI says it is fine. They click merge.

The open source maintainer, the person from episode seventeen who wakes up at two in the morning to a flood of notifications, sees the invisible commit arrive as a pull request from a stranger. The PR is polite, well-structured, and fixes a real bug. The commit message is perfect. The code looks reasonable. But something is off. The fix is correct in isolation but misunderstands how the library is actually used in production. The maintainer cannot tell if a human misunderstood the codebase or an AI hallucinated a solution based on the README. The result is the same. They have to review it, understand it, test it, and either merge it or write a polite rejection. Either way, it costs them thirty minutes they do not have.

Four people. Four different relationships to the same invisible commit. And Git treats all four the same. Author field. Timestamp. Hash.

The Pause

The ESO maintainers from episode seventeen showed what a deliberate pause looks like. They stopped all releases, all patches, all support, and the Kubernetes community had to confront the fact that invisible infrastructure depends on people who can walk away.

Connect it. The invisible commit travels through a pipeline that depends on ESO to manage secrets. ESO depends on a maintainer who nearly quit. The commit itself was written by an AI that was trained on open source code whose authors, as episode twenty described, were never compensated. The commit is reviewed by another AI. The human in the loop is a prompt and a merge button. And Git, the system that records all of this, stores the human's name as the author, the generated text as the message, and the timestamp as the only fact it got right.

The Question

Here is the argument this season has been building toward. The commit, as Torvalds designed it, was a contract. A snapshot of the entire project at a moment in time, cryptographically sealed, attributed to a person. That contract assumed the person understood the change, intended it, and would stand behind it. Every feature Git provides depends on those assumptions. Blame assumes the author can explain the code. Bisect assumes each commit represents a coherent change. Revert assumes someone decided what the change meant and can decide to undo it. The entire model rests on the idea that a commit is an act of authorship.

What happens when it is not?

One answer is that nothing happens. Code ships. Tests pass. Users do not notice. The commit works the same regardless of who or what produced it. Git does not care about intent. It cares about content. A snapshot is a snapshot. A hash is a hash. Maybe the metadata was always aspirational, a polite fiction that only mattered when something went wrong.

But things do go wrong. When they go wrong, the first question is always "what changed and who changed it." git log. git blame. git bisect. The entire debugging and accountability infrastructure of modern software depends on commits being meaningful. When the invisible commit breaks production, and eleven hundred lines of AI-generated code contain a subtle performance regression buried in file nine of fourteen, the person whose name is in the author field does not know where to look. They cannot bisect meaningfully because the commit is not a coherent unit of thought. It is a dump of generated code that happened to pass the tests.

The three responses this episode has described represent three different bets about the future. Cunniffe bets that the commit model can be saved by adding better metadata. Track the authorship. Record the provenance. Make the invisible visible. Chacon bets that the workflow model needs to change. The commit might still be the unit of record, but the process of producing, reviewing, and integrating commits needs to be redesigned for agents. Jujutsu bets that the undo model matters more than the authorship model. If any commit can be trivially reversed and inspected, the question of who wrote it becomes less urgent.

None of them say the commit is dead. All of them say the commit, as currently practiced, is not enough.

What Remains

There is a line from Chacon that cuts through the noise.

We are all teaching swarms of agents to use a tool built for sending patches over mailing lists.

That is the season in one sentence. Git was designed by a Finnish-American programmer who needed to manage patches from a global team of kernel developers. It was designed for text, for humans, for a world where the hard part was writing code. The hard part is no longer writing code. The hard part is knowing what was written, by whom, and whether it should be trusted.

The invisible commit is not a failure of Git. It is a success of Git. The system is so resilient, so reliable, so deeply embedded in every layer of software development, that it continues to function perfectly even when the assumptions it was built on no longer hold. The plumbing works. The water flows. The question is whether anyone is checking what is in the water.

Episode eighteen defined the three tiers of AI-assisted development: assisted, where the human understands the code, delegated, where the human reviews but did not write it, and vibe, where nobody reads the code at all. The invisible commit is what happens at the boundary between delegated and vibe. The developer intends to be in the delegated tier. They prompted the AI. They glanced at the review. They clicked merge. But eleven hundred lines across fourteen files, reviewed by an AI, deployed in forty minutes. At what point does delegation become vibe coding with better optics?

The honest answer is that nobody knows yet. The line between delegated and vibe is not a cliff. It is a slope. And the slope is greased by every tool that makes the process faster, every review bot that says "approved," every pipeline that deploys on merge without asking questions. The developer who reads every line is in the assisted tier. The developer who reads the summary is delegated. The developer who reads nothing but clicks merge because the bot said it was fine, they have slid into vibe without noticing. The commit looks the same in all three cases. Git cannot tell the difference.

This is the season's argument, and it is not a comfortable one. Git won. It won so completely that it became invisible, the way plumbing is invisible, the way electricity is invisible. And like plumbing and electricity, it was designed for a specific era. The pipes were sized for a certain flow. The wires were rated for a certain load. The flow has changed. The load has increased. The infrastructure still works, but it is being asked to do something it was never tested against.

The tools are being built. Cunniffe's attribution logs. Chacon's virtual branches. Jujutsu's undo-everything model. Regulations demanding provenance. Maintainers demanding respect. The response is real. But the response is scattered, fragmented, early. There is no coordinated answer to the invisible commit because there is no coordinated body that could provide one. Git is not a company. It is not a consortium. It is a tool maintained by volunteers, extended by startups, hosted by corporations, and used by everyone. The answer, if one comes, will emerge the way Git itself emerged. Someone will build something that works, and the rest of the world will adopt it because they have no choice.

Until then, the commits keep flowing. Tens of millions of pull requests every year, and accelerating. Each one with an author field, a message, a diff, and a hash. Each one telling a story about what happened.

Some of those stories are true. Fewer than you think.

git notes. The feature almost nobody uses, built in two thousand ten. It attaches metadata to any commit without modifying the commit itself. The hash stays the same. The history stays clean. But the note is there, visible to anyone who asks. git notes add minus m "AI-generated, reviewed by CodeRabbit, deployed via pipeline" and suddenly the invisible commit has a footnote. It will not fix the problem. But it might be where the fix starts.

That was episode twenty-one of Git Good, Season Two. Next time, the last episode. Twenty years of Git, and the question of what comes next.