Entire Launches a New Generation of Git Hosting for Human-AI Collaborative Coding

Entire: A new-generation Git hosting built specifically for "humans and Agents writing code together"

The @GoEntire founded by the former GitHub CEO isn't building another "website like GitHub"—it's redoing code hosting, review, CI, and Agent session memory all around "human-machine collaborative coding": using Trail to replace the diff-centric PR timeline, using a distributed Git service to handle high-frequency Agent pushes, and using Continuous Memory to write sessions and decisions back into the repository, so the next round of Agents doesn't have to relearn from scratch. https://t.co/IztavEEbbc

Why traditional PRs are no longer enough The Entire team believes that coding Agents and review Agents now go back and forth in the same PR leaving long comments, changing code, and reviewing another round. For humans, this timeline increasingly resembles "an audit log that only Agents read," making it hard to tell at a glance: whether the loop has stabilized, and whether it's safe to merge. Trail aims to surface key information at the top of the page (the evaluation scores produced by Agents after each push, and unresolved issues) so people can first check "is it stable enough," then decide whether to merge.

Trail: The three steps of review 1. Open a Trail: you can open one from a bug / feature request, or, like opening a PR, directly from the Agent side before or after starting work. A single Trail can span multiple repositories, binding together changes that should be merged together.

2. Run evaluations on every push: after code is pushed, review Agents each score it in cloud sandboxes and write their reasoning, compared in the article to figure-skating judges. Common examples in Entire's own repositories include Security, Slop (nonsense / over-generation), and Human Review Required. Each evaluation shows the trend of recent scores; when a score is orange, you can keep having the coding Agent revise per the feedback until it turns green. The article emphasizes: a single one-shot pass often misses key issues; only multiple rounds with scores stabilizing is reliable. Preset Agents for code quality, security, Slop, etc. can be toggled per repository; you can also customize via the UI or a .json in the repository. Under the hood it uses Claude Code, Codex, etc., with sandboxes provided by Daytona and E2B.

3. Close unresolved issues before merging: Agents can also return specific findings and suggested fixes, marked with severity levels. Unclosed ones stay pinned on the Trail, while resolved ones are collapsed by default. Both humans and Agents can address or dismiss them. Repositories can set gates: for example, requiring human approval, CI passing, and key findings cleared before merging is allowed.

CI: First integrating Buildkite and Depot The Entire team emphasizes: the faster Agents write, the more CI must serve as a safety net for "whether changes exceed the intent of the prompt." CI is configured at the project level (multiple repositories under the same project often share one set of infrastructure). After connecting Buildkite, each push builds on Buildkite or your own infrastructure, and the result appears as a check on the Trail; failures can block merging; Agents can also close the loop themselves via the Buildkite API / CLI / MCP. If you previously used GitHub Actions, you can migrate with bk pipeline convert. Depot is compatible with GitHub Actions workflows, with no need to go through GitHub in between; depot ci migrate can discover and migrate workflows, and supports importing secrets / variables. Billed by the second, so faster runs are relatively cheaper.

Distributed hosting and push speed Entire built its own Git-compatible source service, paired with distributed object storage and a transactional ref database. The article gives its own open benchmark: pushes up to about 89 times faster than GitHub and about 6 times faster than Cursor Origin; the table roughly estimates throughput at about 418 pushes/sec for Entire, about 4.7 for GitHub, about 65 for Cursor, about 15 for Pierre, and about 10 for GitLab. It can replicate across multiple regions or stay in a single region, meeting residency and scaling needs; currently available in the US, EU, Australia, and India. Repositories live under projects under an organization or personal account; when creating a project, choose the primary region and then replicate.

There are three ways to use it: create a repository natively in Entire (web or CLI); mirror with the GitHub App, where GitHub can remain the source of truth and Trail can also layer on top of PRs; when mirroring, pushes still go through GitHub, and if GitHub goes down the mirror can still clone / fetch, and Agents can push to branches prefixed with entire/unmirrored/; or migrate (US mirrors can Detach, or use the entire-migrate plugin, or fetch locally and then push).

Continuous Memory: Writing understanding into the repository too The Entire team likens CI / CD's convergence and release of code to how "understanding" must also be continuously passed forward: the repository should become the memory Agents truly need. Two open-source, local-first plugins in the CLI work together: · entire-graph: parses locally with tree-sitter, providing a precomputed map of the repository (ranked search, definitions, callers, types, routes, change impact, with file:line references); the article says tests can save up to about 71% of tokens; no network, no model calls, no API key lookups. · entire-brain: indexes past Agent sessions on top of graph (recorded into Git history via the Entire CLI), binding "why it was changed this way" to "what was changed." It can also connect to the Entire backend to share team memory; each Trail shows the memory left by Agents, so reviewers can see the decisions made at the time. Example: when fixing a billing rounding bug, graph traces the call chain and tests, while brain provides the original intent, the fix already shipped, and pitfalls hit in the last change.