Back to Explore
NewsVibeFix 编辑部Updated Oct 27, 2026

Entire Goes Public: The Former GitHub CEO Wants Review to Judge Evidence, Not Diffs

On October 26, 2026, Entire, founded by former GitHub CEO Thomas Dohmke, went public: the first Git forge built for agents and humans to work together. Its target is not one button but the whole pull request model — every push scored by multiple agents in sandboxes before it can merge.

Entire's official launch art: Entire Launches an Independent Git Forge for Agent-Human Collaboration
Entire's official launch art: Entire Launches an Independent Git Forge for Agent-Human Collaboration

In one sentence: what gets reviewed has changed

On October 26, 2026, Entire — founded by former GitHub CEO Thomas Dohmke — made its case in public: the first Git forge built for agents and humans to work together. What it wants to replace is not one button on GitHub, but the whole Pull Request model. From now on, every push is scored in a sandbox by multiple agents, across quality, security, and slop (low-quality AI-generated content); teams can set gates that require a human sign-off or a passing CI run before anything merges. A human can still have the final word, but no longer has to read every line of the diff before daring to give it.

That sentence deserves to be taken seriously, and deserves skepticism in equal measure. Seriously, because it names a real bottleneck: agents now write code far faster than humans can read it, and review has become the narrowest part of the pipeline. Skeptically, because the flashiest numbers in Entire's announcement — pushes up to 89 times faster than GitHub, and a codebase graph that saves up to 71% on tokens — are explicitly the vendor's own measurements, not yet independently verified. This article separates the announcement's facts from its vendor claims, keeps what can be verified, flags what cannot, and ends with an adoption checklist a small team can use today.

What happened: one announcement, three new primitives

Entire's October 26, 2026 announcement says the product is available to every developer from that day. It is built on three, in Entire's words, fundamentally new primitives. The first is the Trail, the review unit that replaces the Pull Request. The second is distributed Git hosting, a new source-control server compatible with Git. The third is Continuous Memory, a system that syncs sessions into the repository so agents can always query them. At the same time, Entire announced integrations with Buildkite and Depot, so that builds and tests keep pace with how fast agents ship.

The background is worth one paragraph. Entire raised $60 million in February 2026, which its announcement describes as the largest seed round in developer-tools history; the team has since grown to 50 people with experience spanning GitHub, Microsoft, Atlassian, DigitalOcean, and more. Two earlier releases — mirroring and the Entire CLI for tracking agent sessions — laid the groundwork for this announcement. The roadmap lists self-hosting of Git nodes, public repositories, live-streamed sessions, and more partner integrations. In other words, what launched is a starting point: several capabilities developers care about most, including public repositories, are still in the "coming soon" column.

What a Trail actually is: from reading diffs to reading evidence

The classic Pull Request works like this: a developer forks a repository, changes code, and sends the diff to a maintainer, who reads it, comments, waits for fixes, and merges. Dohmke's quote in the announcement names exactly where that model breaks. The Pull Request once revolutionized development by replacing diffs and patches on email lists with forks and mergeable changes; but today, he argues, agents write almost all of the code, faster and more complex than ever before, and the old review method cannot keep up.

A Trail inverts the flow. After every push, multiple agents score the change in a sandbox, across dimensions including code quality, security, and slop. Entire compares a Trail to an airline pilot's heads-up display: instead of one long raw diff, the developer sees a structured set of evaluation results. All of this data is available not only in Entire's web interface but also through the open-source Entire CLI, so coding agents can address findings in a loop while the human developer validates progress. When every evaluation is satisfied, the code can merge — according to Entire, without the developer needing to look at the code itself.

Three design choices inside that description are worth pulling apart. First, review changes from a one-off human judgment into a continuous, loopable evaluation: an agent finds a problem, an agent fixes it, the fix is evaluated again, and the human validates rather than laboring line by line. Second, the raw material of review changes: Entire explicitly treats the developer's idea, the agent's trace, and the outcome of the session as first-class artifacts for review alongside the code. Review is no longer only "is this final code correct," but also "how did this agent think, where did it go wrong, and was it corrected." Third, the merge condition becomes configurable: a team can require a human sign-off, or a passing CI run, turning "merge" from one person's decision into a set of conditions.

My judgment is this: the real bet behind Trails is not whether agents can review code, but whether the evaluations themselves can be trusted. Done well, a Trail turns review from manual labor into judgment work. Done badly, it merely dresses up "merged without understanding" in a more respectable outfit. Any team trying this should start with four questions: who wrote the evaluations, against what standard, can the team rewrite them, and when an evaluation conflicts with human intuition, who wins? The announcement does not go deep on these points, and that is precisely what a trial period needs to test.

Distributed Git hosting: read "89x" as a vendor claim first

Entire's second primitive is distributed Git hosting. It claims a new source-control server compatible with Git, with pushes up to 89 times faster than GitHub and 6 times faster than Cursor Origin, making it, in its own words, the fastest Git forge in production today. Developers can create, migrate, and natively host private repositories in the region of their choice, with the US, EU, India, and Australia available at launch and further expansion on the roadmap.

This needs to be stated plainly: 89x and 6x are Entire's own figures. The announcement publishes no test methodology, repository size, network conditions, or comparison baseline. Until an independent party reproduces them, responsible coverage can only describe them as vendor-measured, not as established fact. But even after discounting the numbers, the direction still holds: when agents push every few minutes, the latency of Git hosting and CI stops being a minor cost and becomes the infrastructure that decides how fast the agent loop can spin. Entire treats speed as the forge's core selling point rather than a bonus feature, and that prioritization is itself a response to the agent era.

For real users, two other points may matter more than the headline number: region choice and the migration path. Regional hosting is concrete value for teams with data-compliance requirements; and "you can migrate an existing private repository" decides how cheap it is to try. The hardest problem for any new forge was never the feature list — it is persuading a team to put a real repository on it. The smoother the migration, the lower that barrier.

Continuous Memory: memory moves from chat history to repository asset

The third primitive, Continuous Memory, may be the easiest of the three to underestimate. The idea is to sync agent sessions into the Git repository, making that data constantly available and searchable to coding agents. It is powered by two components: a codebase graph that helps agents find answers faster and, according to the vendor, saves up to 71% on tokens; and an agentic brain that turns previous agent sessions and prompts into a durable memory system agents can query and learn from, so they stop repeating mistakes.

This answers a pain everyone who has coded with an agent knows: start a new session and the agent has forgotten the pitfalls from last time, the conventions unique to this project, and why a particular piece of code was written that way. It has to re-learn by trial and error. Putting memory in the repository turns "project experience" from one person's chat history into a shared team asset. For an indie vibe coder, the effect is even sharper: you are the whole team, so a memory system is your second brain, and the more it remembers, the less tuition you pay twice.

But once memory becomes an asset, it also becomes a liability. First, memory goes stale: what was correct three months ago may be an anti-pattern today, and the announcement says nothing about forgetting or correction mechanisms. Second, memory can leak: sessions may contain secrets, internal endpoints, or customer data, so what gets scrubbed before syncing, and who can read those memories, are security questions to settle before switching it on. Third, memory can entrench bias: what an agent "learns" from past sessions may include past mistakes, and the line between "never repeating an error" and "institutionalizing an old error" is exactly one good correction mechanism wide. In a trial, do not only test how fast it remembers — test how cleanly it forgets, and how transparently it is wrong.

The CI integrations: the bottleneck has moved past writing code

Entire's integrations with Buildkite and Depot deserve their own section, because they name the other half of the story. Depot co-founder and CEO Kyle Galbraith put it directly in the announcement: the bottleneck has shifted from writing code to everything after it. Buildkite CEO Kevin Gounden made the complementary point: every change still has to be built and tested before it ships, and this year the industry has felt that throughput grow exponentially.

The mechanics are straightforward: developers can convert existing workflows with Buildkite's bk pipeline convert command or use Depot CI, then subscribe the repository in Entire. From then on, builds start on every push, with results landing natively in Trails. CI stops being an external check outside the review and becomes a piece of evidence inside it. The practical effect is real: no more jumping between two systems during review, build failures and evaluation failures in the same view, and a shorter loop for agent fixes.

For teams still on GitHub Actions, the significance is that migration cost is reduced: workflows can be converted rather than rewritten. The same caution applies, though: how much of a complex workflow a converter covers, and how much needs hand repair afterward, is only knowable by running it against a real repository. The announcement's promise is a direction; the trial's result is the evidence.

What it means for vibe coders and small teams

Here is a possibly counterintuitive judgment: the first beneficiaries of a product like Entire may not be large companies, but small teams and indie developers. A large company's review process carries compliance, audit, and permission layers, so switching forges is an organizational change. A small team's review process is often just "the author reads it once more" — precisely where agent output overload hits hardest. For a small team, a Trail that scores automatically, supports gates, and archives the agent's trace is like hiring a tireless first reviewer.

"First to benefit" does not mean "migrate everything tomorrow." I would suggest four steps. First, trial on a mirrored or non-critical repository: let Trails run alongside your real workflow and judge evaluation quality before handing them any merge authority. Second, observe read-only for two weeks: count false positives and false negatives, and pay special attention to the security evaluations — false positives are tolerable, false negatives are not. Third, set gates before automating anything: keep at least "CI passing plus human sign-off" on critical branches, and do not start with "merge automatically when all evaluations pass." Fourth, sort out memory governance before memory itself: understand the scrubbing rules and permission scope for session syncing before turning Continuous Memory on, so governance precedes memory rather than chasing it.

There is also a longer-term judgment. Entire's arrival signals that the competitive dimension for Git hosting has changed: where providers once competed on interface, integrations, and ecosystem, they now compete on who best understands how agents work. GitHub and GitLab will not leave that dimension uncontested; evaluation-style review and memory systems will appear across vendors sooner or later. Entire's first-mover advantage is not any single feature, but the fact that it was designed for agent-human collaboration from day one, with no legacy compromise and no need to stay backward-compatible with an old model. Whether that advantage lasts depends on whether it can make evaluation trustworthiness real before the roadmap items — public repositories, self-hosted nodes — land.

Questions still unanswered

The announcement leaves at least five questions worth pursuing. First, pricing: no prices were published, and the free allowance and team pricing will decide whether small teams can stay long-term. Second, timing for public repositories and self-hosted nodes: without public repositories, Entire cannot yet host open-source collaboration; without self-hosting, compliance-sensitive teams are still one step short. Third, evaluation customizability: can teams write their own evaluations, plug in their own security rules, and audit evaluation results? Fourth, who defines slop: who decides what counts as low-quality AI content, and what is the appeal path for a wrong call? Fifth, independent verification of the vendor's performance numbers: 89x, 6x, and 71% all need third-party reproduction under disclosed conditions.

None of these questions is a reason to dismiss Entire, but each one decides who it fits and where to use it first. What is genuinely exciting is not a slogan like "the Pull Request is dead," but the shift underneath it: review is moving from "a human reads the diff" to "a human judges the evidence." If that shift holds, future code review will look more like a pilot reading instruments: you may not have touched every part by hand, but you must be sure the instruments themselves are accurate. Entire's Trail is a first step in that direction — and whether the instruments are accurate is a question the next few months of real trials will have to answer.

Background: from Checkpoints to the Git Forge

Entire did not appear out of nowhere. In February it shipped Checkpoints, an open-source tool that records an AI coding agent's prompts, decisions, and session history alongside code changes, so that why an agent changed something stays answerable later. The same month it disclosed a $60 million seed round at a $300 million valuation, with Microsoft's venture arm M12 among the backers — which explains how a company without a fully public product could launch on October 26 positioned directly as a GitHub alternative. On hosting, Entire currently offers repositories in the US, India, Australia, and the EU; public repositories and self-hosted nodes remain on the roadmap, and that is its clearest present gap: open-source collaboration and compliance-sensitive teams both still have to wait. One more number belongs in context: GeekWire's launch coverage notes that GitHub alone saw 7.38 billion commits in September 2026 — the agent-driven write flood that Entire's distributed Git hosting is built to answer. Context is not evidence, though: until third parties reproduce them under disclosed conditions, the 89x, 6x, and 71% figures should be cited as vendor claims awaiting verification, not as established facts.

Why now

Entire's October 26 timing has another layer: GitHub's annual Universe conference opens two days later, on October 28–29, and agent-driven load has already strained GitHub through 2026 — GeekWire notes one August outage lasting nearly eight hours, and IncidentHub counts 257 GitHub incidents between May 2025 and April 2026. Entire is not the first challenger to rethink hosting either: Cursor launched its own hosting service, Origin, in August, which is exactly the rival Entire's '6 times faster than Cursor Origin' claim is aimed at. Read together, Entire's real bet becomes clear: not that one feature is better, but that agents will keep writing code faster than humans can read diffs, so the 'human reads every line' model itself has to go. If that bet is right, the review-tool race is just starting; if it is wrong, Entire is another challenger telling a new story in GitHub's shadow. The next few months matter more than today's slogans: public repositories, self-hosted nodes, and independently reproduced performance numbers.

Views 0Comments 0

Comments (0)

ME
0/1000
Loading comments...

Sources

Browse projectsPublish your project

Related articles

An illustration on secure AI-assisted coding; not a Codex official screenshot
News
Codex CLI 0.164.0: Ten Preset Slots That Fold Your Daily Repetition Into the Tool

Released October 23, 2026, Codex CLI 0.164.0 brings no new model. Its stars are ten /presets slots, inline /model and /permissions arguments, and session recovery that loses less. This article judges it by the operations layer: what to adopt today, and what is just tidied-up edge work.

Developer WorkflowProduct LaunchOpenAI Codex
An illustration of a developer writing code on a laptop in an office; not a Claude Code official screenshot
News
Claude Code's Slow Tools Stop Blocking the Conversation: MCP Tasks in Public Beta

Announced October 22, 2026 and available from v2.1.304, MCP Tasks let a slow tool answer with a task number, work in the background, and pause mid-task to ask you a question. This article separates it from automatic backgrounding, lists the elicitation rules, and explains why it is not a workflow engine.

Developer WorkflowClaude CodeProduct Launch