Git Forge Entire Rebuilds Code Review for AI Agents
Entire has launched a Git Forge built for a specific problem: the pull request, the centrepiece of software collaboration for fifteen years, was designed for humans reviewing each other's occasional code. It was not designed for a world where AI agents generate, review and iterate on code at high speed, in volumes no human timeline can absorb. The Git Forge category, which GitHub and GitLab have owned for a decade, is being rebuilt around that reality, and Entire is the most closely watched attempt because of who is leading it.
The company is led by Thomas Dohmke, the former GitHub CEO, and its premise is blunt. Human-to-human platforms like GitHub and GitLab transformed collaboration by centring it on asynchronous code review and version control. A platform for agents has to centre on something else: the asynchronous orchestration, versioning and auditing of AI agents working alongside humans. Reporting on the launch came from InfoQ, with additional summaries covering the same material.
The launch matters beyond one startup, because it names a failure mode that most engineering organisations are currently experiencing and most tooling is not addressing. When agents write the code, and other agents review it, the pull request timeline stops being a conversation. It becomes noise.
Why the pull request broke
Dohmke's diagnosis is the sharpest sentence in the announcement, and it deserves to be quoted in full.
“The pull request [timeline] has become an audit log that only the agent reads. It does not provide the information for the developer to decide whether they can merge with confidence.”
Anyone who has run a multi-agent workflow will recognise the failure. An agent opens a pull request, a review agent posts findings, the coding agent pushes fixes, and the loop repeats. By the time a human looks, the timeline holds forty comments of machine-to-machine negotiation. The human's actual question, can I merge this safely, is buried somewhere in it, and answering it means reading all of it.
The deeper problem is not volume but trust. Code review by humans has always carried an implicit confidence model. I know this reviewer, I understand their concerns, and I can judge whether the remaining risk is acceptable. Agent findings arrive without that context. A wall of automated comments provides no signal about whether the code is ready, which findings matter, and which agent complaints are noise. The developer ends up either rubber-stamping everything or reading everything, and both are failures.
The Git Forge answer: trails
Entire's core concept is the trail, which replaces the pull request as the unit of work.
A trail can be initiated from a bug report, a feature request, or manually, and it can span multiple repositories. Whenever new code is pushed to a trail, a review agent running in a cloud sandbox evaluates the changes and returns a score with a rationale. The evaluation covers code quality, security, slop, and whether human code review is required.
The scores are the interface. Eval results sit at the top of the page and update on every push, so a developer opening a trail sees immediately whether the work is trending toward mergeable or still churning. If the slop score is orange, the developer can ask their coding agent to improve the code and push again, which triggers a new evaluation. Findings must be resolved or closed before a merge is allowed, and teams can configure repository-level Gates that define the conditions for approval.
Two design details separate this from a standard CI badge. First, the Git Forge shows the last five runs alongside the current one, because single evaluation runs are unreliable. In the company's words, one-shot loops are often missing a critical issue, and repeating the loops and stabilising the scores is what makes agentic coding succeed. A score that has held steady across six runs means something that a single green check does not.
Second, the evaluation agents themselves are configurable, through the interface or through repository-level JSON. That matters because a slop detector tuned for a frontend repository is useless for a compiler, and teams will not trust evaluations they cannot tune. The multi-repository scope of a trail also changes what a review agent can see: a change that touches an API and its consuming service can be evaluated against both, rather than being reviewed twice by two reviewers who each see half the picture. That is a genuinely new capability for a Git Forge, and it matches how agents actually work, which is across repositories rather than within them.
Continuous memory: fixing the missing “why”
The second foundational concept is continuous memory, which preserves accumulated knowledge in the repository so agents can reuse it across sessions instead of starting every task from scratch.
It ships as two open-source tools. Entire-graph builds a precomputed map of the Git repository, with ranked code searches, definitions and callers, types and routes. Entire-brain layers a persistent memory store on top, combining the codebase map with previous agent sessions and information recorded in Git history.
The stated goal is to give agents the right context at the right time, or in the company's phrasing, the “why” behind the “what changed”. That phrasing points at a real wound in modern development. Commit messages were always bad, documentation always rotted, and the answer to “why is this here” always lived in one senior engineer's memory. Agents made that weakness acute rather than creating it, because now there is no one who remembers. This is the gap the Git Forge memory layer is designed to close, and it is a gap every team feels.
The technical shape of the solution is worth noting, because it is where a Git Forge has a natural advantage. A repository's Git history is already a complete record of every change, every author and every moment. What it lacks is the reasoning layer, the connections between changes and the decisions behind them. Building the memory layer on top of the repository, rather than in a separate wiki or chat history, means the knowledge lives where the code lives, and it updates as part of the same workflow. Tools that store agent memory outside the repository have always struggled with drift, because the code moves and the notes do not.
For teams, the practical implication is onboarding as much as agent quality. A new engineer, human or agent, inherits not just the code but the accumulated reasoning about it. That is the promise, and it depends heavily on whether the recorded sessions are actually useful six months later, which is the kind of claim only long-term use can test.
The debate about this played out publicly on Hacker News. One commenter argued that engineers delegate writing code to agents because programming languages and tools leave much to be desired, implying better tools would fix the memory problem too. An Entire employee, Haimantika, pushed back in a reply worth quoting: the problem was never languages or tools, it is that the reasoning gets thrown away between the person and the artifact, and agents made that acute because now there is no one who remembers. Both positions are defensible, and the disagreement is really about whether agent collaboration is a tooling problem or a knowledge-management problem. The Git Forge answer is that they are the same problem.
The exchange is worth dwelling on because it captures the real disagreement about where agent-era development tools should invest. If the root cause is language ergonomics, then the fix arrives through better compilers, type systems and agent-friendly frameworks, and the Git Forge layer is a convenience. If the root cause is that code has never carried its own reasoning, then the fix has to live where the code lives, and a forge with memory is the only place that can happen. Most teams will recognise both forces in their own history: bad tooling pushed them toward delegation, and lost reasoning made the delegation riskier than anyone admitted.
What is not disputed is the cost of the status quo. Every team that has onboarded a new developer into an agent-heavy codebase has watched them ask questions the repository cannot answer. Every team that has inherited an agent-written service has had to reverse-engineer intent from tests and commit messages. The Git Forge argument is that those costs are optional now, because the reasoning can be captured where it happens rather than reconstructed after the fact.
Push speed and the distributed Git Forge architecture
Beneath the workflow features sits an infrastructure claim: pushes run up to 89 times faster than GitHub on Entire's fully distributed architecture.
The number should be read with the usual caveats about vendor benchmarks, but the direction is logical. Agent workflows push far more often than human workflows, and push latency becomes a loop cost. If an agent iteration involves a dozen pushes across a dozen trails, seconds per push turn into minutes per task. A Git Forge built for that workload would naturally optimise push throughput first, which is exactly what a distributed architecture buys.
The claim also signals who the product is for. Teams running one agent occasionally will not notice push latency. Teams running a fleet of agents across many repositories will notice it constantly, and they are the customers this Git Forge is built for.
Integrations with CI platforms Buildkite and Depot round out the picture, which suggests Entire intends to sit alongside existing continuous integration rather than replace it. That is a sensible boundary: the Git Forge owns collaboration and evaluation, while the CI platform keeps building and testing, and neither has to absorb the other's job.
What trails change for engineering managers
The interesting audience for a Git Forge like this is not the developer opening the trail. It is the engineering manager who currently has no answer to basic questions about agent-driven development.
In a conventional pull request world, managers measure merged pull requests and review latency, and both metrics are meaningless when agents generate most of the code. Trails with stabilised eval scores give managers something better: a per-unit-of-work quality trend that exists independently of any human's judgement. A team can see whether its slop scores are improving week over week, whether security findings cluster in particular services, and whether human review is being requested more or less often as the agents mature.
The Gates concept also turns review policy into configuration. A manager can require that security findings are cleared, that human review is triggered above a risk threshold, and that scores stabilise before a merge, all as repository-level settings rather than as tribal knowledge enforced by whoever is reviewing that day. That is the difference between hoping agents are well supervised and being able to prove it, and the second one is what auditors, customers and regulators actually ask for.
For organisations under compliance obligations, a Git Forge that logs every evaluation run, every finding and every resolution becomes an audit trail by default. That is a quiet feature with a loud future, because agent-generated code is already raising questions in regulated industries that conventional pull request histories cannot answer.
A crowded field, and what it means
Entire is not alone. The source-control arena now includes Zed's DeltaDB, Anthropic's Scion, East River Source Control, Cursor's Origin, and the decentralised Radicle, alongside incumbents GitLab and GitHub. GitLab's 19.5 release, days before this launch, made agentic development a governed part of its DevOps platform.
The pattern behind the names is a consensus forming across the industry: agent-native development needs infrastructure that humans and agents share, and the existing forges are retrofitting rather than rebuilding. The Git Forge category has effectively split into two strategies. Incumbents are adding agent governance to platforms built for humans, which preserves their enormous network advantages. Startups are building platforms for agents from scratch, which preserves speed and focus but starts with no users.
History offers caution for both sides. Source control platforms are sticky because they hold the code, the history and the workflows of an organisation, and switching costs are among the highest in software. A Git Forge startup has to be dramatically better to justify a migration, not just somewhat better. At the same time, the incumbents carry fifteen years of assumptions about human review cadence, and retrofitting agent-scale orchestration onto that foundation is genuinely hard. The truthful position is that nobody knows how this market settles, and the entire Git Forge category is an early bet on the answer.
Migration cost deserves specific attention, because it is the obstacle that determines the timeline. Moving a Git Forge means moving repositories, permissions, integrations, historical issues and organisational habit at once. The last item is usually the hardest.
Teams that run agents across many repositories will find the evaluation and memory features tempting, and they will find the migration conversation much harder than the demo. A realistic adoption path for most organisations is a single repository pilot, then a team, then a business unit, over a year or more. That pace favours incumbents in the short term and rewards the startups that can survive long enough for the industry's agent share to reach them. It also means the Git Forge question is not urgent for most teams today, and it will be urgent for most teams within two years.
Whether the new entrants win or the incumbents adapt, the requirements are now visible. Agents need orchestration, versioning and auditing as first-class concepts. Humans need confidence signals rather than comment streams. Both need memory that survives sessions.
For teams evaluating the options, the question is less which Git Forge wins and more which workflow fits. Teams running occasional agents inside an existing GitHub process can wait; the incumbents are adding agent governance quickly. Teams whose development is already majority-agent, where human review time is the bottleneck, are the ones who will feel the pull-request problem badly enough to move.
Teams building agent infrastructure elsewhere will also find the ideas portable. Programmatic tool-calling platforms and agent workspace tools are solving adjacent parts of the same loop, and Git backends designed for agents approach it from the storage side. A Git Forge sits at the collaboration layer, which is why it might matter more than any single piece underneath it.
Questions readers are asking
What is a Git Forge?
A Git Forge is the platform layer around Git repositories: hosting, pull requests, code review, permissions and project management. GitHub and GitLab are the dominant examples. Entire's version is a Git Forge redesigned so that human developers and AI agents can collaborate without the human side drowning in machine-generated process.
Is Entire replacing pull requests?
It replaces the pull request with trails as the unit of work. A trail still contains pushes, reviews and findings, and code still merges at the end. What changes is that evaluation scores and stabilised runs, rather than a comment timeline, carry the information a human needs to merge with confidence. The Git Forge still supports review, it just makes the machine part of it legible.
Does the 89x push speed claim hold?
It is a vendor claim, and no independent benchmark accompanies the launch. The architecture makes the direction plausible, because agent workflows push far more frequently than human ones, but teams should benchmark against their own workload before committing.
Does continuous memory work with my current agents?
The memory tools, entire-graph and entire-brain, are open source, which means they can be evaluated independently of the hosted Git Forge. Whether they integrate cleanly with a given coding agent depends on that agent's context mechanisms, and teams should test with their own sessions rather than assuming compatibility.
The bottom line
The pull request is fifteen years old, and it is showing its age in exactly the place the industry is growing fastest. A Git Forge built for agents, with trails that surface stabilised evaluation scores and memory that preserves the reasoning behind changes, is a credible answer to a problem most teams are currently solving by reading machine comment streams or ignoring them.
The sceptical view is that incumbents will absorb these features and the Git Forge market will not need another challenger. The supporting view is that the pull request is load-bearing infrastructure, and load-bearing infrastructure rarely gets replaced by a plugin. Either way, the measure of success is the same: a developer opens a trail, sees confidence where a conversation used to be, and merges. Everything else is detail.