Us vs. Them Hit Hacker News. Its Human vs. AI Labels Depend on Git Identity

Us vs. Them reached Hacker News with 42 points and a conflict that agentic editors increasingly create: which lines should an AI hesitate to change?

The open-source experiment assigns human-versus-agent scores to ranges of text by replaying a file’s Git history. It needs no labels inside the document. That makes its approach unusually compatible with existing repositories, but the simplicity conceals a critical dependency.

The system does not detect whether prose sounds synthetic. Instead, it trusts the identity attached to each revision and calculates how later edits alter earlier authorship. The primary opponent is therefore not humans against models. It is explicit revision history against uncertain identity.

That distinction matters as coding agents gain permission to modify whole repositories. A model can now rewrite documentation, configuration, tests, and production code within one session. Teams need more than a final diff when deciding which changes deserve close review.

Us vs. Them proposes a small but provocative control signal. Human-written regions become protected “islands,” while machine-written regions remain easier for another agent to replace. The idea turns provenance from a disclosure label into editing policy.

The Hacker News Project Turns Git History Into Authorship Scores

Us vs. Them treats every saved revision as evidence, then carries that evidence forward as later authors modify the same text.

The developer, identified on GitHub as eighttrigrams, describes the project as line-level provenance for text under agentic editing. Its project repository provides both a library and a command-line interface.

The implementation starts with an ordered series of document versions. Each version must have an identifiable author who can be classified as human or agent. The tool then compares those versions rather than inspecting the final text alone.

Its output groups lines into ranges and assigns each range a score. A score of 1.00 represents a fully human-authored range. A score of 0.00 represents a fully agent-authored range.

Intermediate values describe mixed history. The repository gives 0.46 as an example of a human-originated range that agents later modified. This produces a spectrum instead of forcing every surviving line into a binary category.

The project calls coherent human regions “islands” inside a “sea” of generated text. That metaphor reflects an important design decision. The unit being protected is not always one unchanged line.

An editor might split a paragraph, join two sentences, or adjust part of a human-written block. A strict last-editor rule would declare all touched material machine-authored. Us vs. Them tries to preserve some prior contribution after partial modification.

The current interface asks users to classify authors through Git identities. The --ours argument names humans, while every other identity counts as an agent. The inverse --theirs option names agents and treats everyone else as human.

Users choose whichever side has fewer identities. The tool rejects using both options together. This keeps the command small, although it places classification responsibility on the operator.

The motivating examples are concrete. A developer may use an agent to generate most of an application, then personally rewrite a sensitive component. Another session should not casually replace that human-controlled region.

The same problem appears in documentation. An agent may draft an entire README before a maintainer carefully rewrites its opening. Future agents should retain freedom elsewhere while treating the opening as deliberate editorial judgment.

This is more than a colorful visualization. The score can become context for an agent, a review interface, or a repository check. Each consumer can apply a different threshold without changing the underlying document.

A coding assistant might receive a warning before editing a high-scoring range. A pull request could highlight changes that remove human-authored islands. A reviewer could prioritize those changes without reading every generated line equally.

That is the project’s immediate change. Git history, normally consulted after a problem, becomes an input to the next agentic action.

Human Authorship Is Becoming an Editing Permission

The important question is not who deserves credit for every token, but where automated editing should encounter resistance.

Traditional version control records changes without assigning moral value to them. A line is current or obsolete, regardless of who wrote it. Agentic editing changes the operational meaning of that neutrality.

An agent can inspect a task, choose files, write changes, run tests, and revise its work. Broader autonomy increases the number of correctable mistakes. It also expands the area where human intent can disappear before review.

Consider a configuration file mostly produced by an assistant. An engineer may manually tighten one permission, add a warning, and document why the restriction exists. A later agent sees only text unless the history enters its context.

A normal diff shows what the later agent changed. It does not automatically signal that one removed line represented a deliberate human exception. Reviewers must reconstruct that importance from comments, commit messages, or memory.

Us vs. Them converts authorship history into a machine-readable hint. High human provenance does not prove a line is correct. It says that a person invested direct editorial effort there and may have encoded judgment worth preserving.

That signal pressures two groups. Agent developers need methods for respecting local intent, while engineering teams need policies that do not freeze repositories around every human keystroke.

The forced response is better change prioritization. As automated edits grow, reviewing every generated modification with equal intensity becomes difficult. Provenance scores offer one way to direct scarce human attention.

This idea also applies beyond source code. Policy documents, research notes, product requirements, and internal knowledge bases often combine generated drafts with carefully revised passages. Their final form hides the collaboration process.

A product manager might accept an agent’s market summary but personally rewrite the decision and its constraints. Another agent should distinguish supporting prose from the approved decision. A flat document offers no such hierarchy.

People already create informal protection mechanisms. They add comments such as “do not change,” isolate files, strengthen tests, or repeat instructions in prompts. Those methods communicate importance, but they require manual markup or supporting infrastructure.

Diff-based provenance promises lower friction because Git already records versions. Teams would not need a custom document format. Existing Markdown, source files, and other plain text could remain unchanged.

That compatibility gives the Hacker News project its strongest practical angle. Many provenance proposals begin by requiring new metadata at creation time. Us vs. Them tries to recover a useful signal from history teams already maintain.

The project also fits a wider shift toward provenance-aware knowledge work. A searchable engineering knowledge base can preserve documents, but retrieval alone does not explain who shaped each passage.

Agentic systems need both context and boundaries. Context tells an agent what the repository contains. Boundaries tell it which parts reflect intentional human control and deserve extra caution.

The pressure is likely to persist because generated text is cheap to replace. Human attention is not. Systems that identify concentrated human judgment can help protect the scarcer resource.

The Mechanism Avoids AI Detection, but Inherits Git’s Assumptions

Version history offers stronger evidence than writing style only when author identities and editing paths remain trustworthy.

Most AI-text detectors analyze a completed passage and estimate whether its linguistic patterns resemble model output. That approach becomes unstable after human revision, paraphrasing, or domain-specific writing.

Us vs. Them asks a narrower question. It does not infer who wrote the final text from style. It reconstructs which declared author introduced and modified each region.

That is closer to accounting than detection. The system observes transactions and carries ownership information through later changes. It does not inspect the prose and guess what produced it.

Research describes human and AI co-authorship as a distinct attribution problem. A broad authorship survey separates human attribution, AI detection, model attribution, and mixed human-machine attribution into different tasks.

The mixed case is especially difficult for output-only classifiers. A paragraph might begin as model text, receive a human rewrite, return to an agent, and undergo another human correction. The final style cannot reliably expose that sequence.

Version history preserves the sequence, assuming each relevant state was committed. It also provides an explainable path. A reviewer can inspect the revisions behind a score rather than trusting an opaque probability from a classifier.

The project’s range model adds another layer. Simple line attribution often identifies the last commit touching each line. Us vs. Them instead tries to account for coherent regions, splits, joins, and diluted authorship.

Git’s own blame documentation illustrates why this becomes complicated. Git offers separate options for detecting lines moved within a file or copied across files. Those operations require similarity thresholds and cannot establish creative origin by themselves.

A diff sees deletion and insertion. It does not understand whether an agent preserved a human idea while rewriting its syntax. Any numerical provenance system must translate textual similarity into an authorship rule.

Suppose a person writes a four-line safety check. An agent renames variables and restructures the condition without changing its purpose. One policy might preserve substantial human provenance because the intent survives.

Another policy might assign most authorship to the agent because the surface text changed. Neither choice follows automatically from Git. The scoring algorithm encodes a judgment about how contribution survives transformation.

The same ambiguity appears when an agent moves a human paragraph unchanged. A location-based approach might lose its history. A move-aware approach can preserve it, but only if matching recognizes the copied passage.

Short lines present another challenge. A heading such as “Security Requirements” contains too little text for reliable similarity analysis. Yet its placement and surrounding structure may represent a significant human decision.

Generated material can also absorb human content. An agent might take three human sentences and expand them into ten. The resulting range contains human direction, machine wording, and possibly new claims.

Us vs. Them acknowledges this through the idea of dilution. Intermediate scores express blended history rather than certainty. That is sensible, but users still need to know how each transformation changes the number.

A score such as 0.46 looks precise. Its practical meaning depends on the algorithm, thresholds, and available commits. Teams should treat it as a policy signal, not a forensic measurement of creative ownership.

The distinction protects the project’s useful contribution. Diff-based provenance does not have to settle legal authorship to improve agent behavior. It only needs to identify regions where caution is justified.

Commit Identity Is the Weakest Link in Human vs. AI Provenance

The tool can track declared authorship, but it cannot independently verify whether a declared human actually wrote a revision.

Git commits contain author and committer fields. Those fields help reconstruct history, yet an ordinary repository does not guarantee that the named identity corresponds to the keyboard or model behind the change.

An agent can operate through a developer’s local account. Its commit may carry the developer’s name and email because those values came from Git configuration. Us vs. Them would classify that revision according to the configured identity.

The opposite can happen when a person edits through an automation account. A human-created correction may appear under a bot identity. The resulting score would understate human involvement.

Shared sessions make the boundary even less clear. A person may ask an agent for a patch, modify several lines, and commit the combined result once. The commit identity records one author for a mixed process.

Git supports co-author trailers, but those are commit-level declarations. They do not map separate contributors onto specific lines. They also depend on participants recording the collaboration accurately.

Signed commits improve assurance that a particular key approved a Git object. GitHub documents how signed commits receive verification based on cryptographic signatures and associated identities.

A valid signature still does not prove manual composition. A developer can sign an agent-produced patch after reviewing it. That signature establishes approval and integrity, not the physical origin of every line.

This limitation defines the primary opponent clearly. Explicit history beats stylistic guessing when the history is trustworthy. Uncertain identity weakens the entire chain before the scoring algorithm begins.

Missing history creates a second weakness. Some teams squash many revisions into one commit. Others paste model output, edit it locally, and save only the final state.

In both cases, intermediate collaboration disappears. The tool can analyze only versions that survive. A clean linear history may therefore provide less provenance than a messy sequence of small commits.

Rebasing can rewrite commit structure, while cherry-picking can duplicate changes under new metadata. Repository imports may collapse prior development into one initial snapshot. File generation can also overwrite content without preserving useful intermediate states.

These are not obscure edge cases. Teams routinely squash pull requests to maintain readable history. Agentic workflows often create temporary changes that never receive individual commits.

The project’s classification options introduce a third weakness. Every identity not placed on the named side receives the opposite classification. An unknown contractor, integration, or misconfigured account can silently receive the wrong label.

That binary setup is convenient for a prototype. Production use would benefit from an unknown state. Unclassified authors should not automatically become human or agent when the evidence is incomplete.

A mature policy may need at least four categories: verified human, declared agent, mixed session, and unknown. Approval could remain separate from authorship. That would prevent a reviewed agent change from masquerading as manually written text.

There is also a risk of overprotecting weak human work. A provenance score measures contribution history, not correctness. Human-written code can contain defects, stale assumptions, and insecure patterns.

An agent should hesitate around a high-scoring range, but it should not treat that range as sacred. The proper response may be requesting review, supplying stronger evidence, or proposing a change with a clear explanation.

Conversely, low-scoring text is not disposable. An agent-generated migration, test, or compliance statement can become operationally important after deployment. Runtime dependency and reviewer approval can outweigh initial authorship.

Teams therefore need several signals. Provenance can sit beside ownership rules, test coverage, security sensitivity, recent incidents, and explicit approvals. No single score should determine whether an edit proceeds.

The project’s strongest framing is advisory. It can surface human concentration and trigger different review behavior. Presenting its output as proof of origin would exceed what the repository history establishes.

The Real Competition Is History-Based Control Versus Embedded Metadata

Us vs. Them wins on adoption friction, while richer provenance systems win on identity, context, and portability.

History-based provenance requires no special markup in the tracked file. That preserves plain text and keeps documents compatible with existing editors, renderers, and repositories.

The approach also works retrospectively. A team can analyze an established project if its history and identities remain available. It does not need every contributor to install a specialized authoring application first.

Embedded metadata takes the opposite route. An editor or agent can record who generated, accepted, revised, or approved each block at the moment of action. That captures details a later diff cannot reconstruct.

The cost is integration. Metadata needs a schema, storage location, identity model, and rules for copying content between systems. Tools must preserve it when users export, merge, or paste text.

Inline markup can also clutter source files. A Markdown document loses some simplicity if every block carries authorship tags. Sidecar files avoid visual noise, but they can drift away from the content they describe.

Us vs. Them chooses compatibility over completeness. Its “no markup” constraint makes immediate experiments possible. It also means the system must infer continuity whenever text changes.

Event-based provenance can record more than author identity. It can capture the model, prompt context, approval action, source material, tool call, and reviewer. Those details help explain why an agent produced a change.

Yet more metadata does not guarantee more trust. An agent can mislabel its own activity, an integration can omit events, and users can bypass the instrumented editor. Provenance remains only as reliable as its capture path.

A combined model offers the most credible direction. Git history can provide an independent structural record, while signed agent events provide richer creation data. Differences between the two records can trigger review.

For example, an agent platform could create commits under a dedicated, signed identity. It could attach a machine-readable statement describing generated files and human-approved ranges. The repository would retain both the final text and its declared process.

Human edits made outside that platform would still appear through normal history. The diff-based layer could carry their provenance forward. Unknown or conflicting events would receive lower confidence rather than a forced label.

This architecture changes the score from a single authorship number into several dimensions. A range could have high human contribution, confirmed agent modification, and explicit human approval.

Those dimensions answer different questions. Contribution asks who shaped the text. Approval asks who accepted responsibility. Integrity asks whether the record changed after signing.

For engineering teams, approval often matters more than composition. A model can generate correct code that a qualified maintainer reviews closely. A human can also write unsafe code without meaningful review.

For writers and researchers, contribution may matter more. They may need to disclose which passages originated with a model, even after human editing. A version-aware system can reveal that collaboration more accurately than one final label.

For organizations, retention and portability become central. Provenance stored only inside one agent platform disappears when the organization switches tools. Git-derived records remain usable wherever the repository travels.

That makes Us vs. Them less a complete provenance platform than a useful baseline. It demonstrates how much policy can emerge from ordinary version history. It also exposes the information that version history never captured.

What Hacker News Readers Should Watch Next

The project’s value will depend on three signals: scoring tests, agent integration, and stronger identity handling.

The first signal is whether the repository expands its behavioral tests around real editing patterns. The project already points readers toward tests as the clearest explanation of its algorithm.

The next useful cases include paragraph rewrites, reordered blocks, copied sections, squash merges, generated files, and alternating human-agent edits. Published expected scores would make the system easier to evaluate.

This signal would strengthen the project if independent users can predict and reproduce its output. Large score changes from minor formatting would weaken the claim that coherent authorship survives ordinary editing.

The second signal is integration with an actual coding agent or review workflow. A command-line report proves that scores can be calculated. It does not show whether the information changes agent behavior.

A practical experiment could require an agent to request confirmation before modifying ranges above a threshold. Another could prioritize pull request review when a change removes a high-provenance island.

Success should be measured through outcomes, not screenshots. Useful measures include reverted edits, reviewer corrections, missed defects, and unnecessary approval prompts.

Too many warnings would create provenance fatigue. Too few would make the system decorative. The best threshold will probably depend on the repository and the sensitivity of each file.

The third signal is an identity model that moves beyond an allowlist. Dedicated agent identities, signed commits, mixed-session labels, and an explicit unknown state would address the project’s most important limitation.

That change would strengthen history-based provenance because it improves the evidence entering the algorithm. Without it, increasingly capable agents may continue committing through human accounts and erasing the distinction.

A public format for exporting ranges would also matter. Other agents and review tools need a stable way to consume the result. A portable sidecar could preserve plain text while avoiding dependence on one command.

The broader lesson is already visible. AI provenance becomes more useful when it guides a decision instead of merely decorating a document with a label.

For developers, that decision is whether an agent can modify a line automatically. For reviewers, it is where to spend attention. For organizations, it is which changes require accountable human approval.

Us vs. Them does not solve those governance questions. It gives them a concrete input derived from infrastructure many teams already use.

The approach remains vulnerable to incomplete commits, shared identities, and ambiguous rewrites. Those limits should shape adoption from the start. A score should initiate scrutiny, not end it.

If you manage an agent-edited repository, inspect one file’s history and identify where human judgment actually resides. Then ask whether your next agent can see that boundary.

That exercise is more revealing than debating whether the final text “looks AI-written.” The Hacker News discussion points toward a better question: does your editing system preserve enough evidence to respect human intent?