We removed Git from a production product: roadmap-driven development

On 11 July, we archived .git

On 11 July 2026, we compressed the .git directory of Junyr (our sovereign e-mail and business-management platform, in production, with more than 90 operational features), dropped the archive onto a backup server, and removed Git from the working tree. Ever since, any git status there answers exactly what it should: fatal: not a git repository.

This is a documented, reversible decision: the archive exists, and so does the restore procedure. It follows from an observation many teams will make in the years ahead. When code is no longer written by human hands but by orchestrated AI agents, Git still versions something; it is simply no longer the thing that matters.

Four days later, as we publish this: fifty plans recorded in the registry that replaced Git, twenty already delivered, and a batch of twelve plans implemented in a single day then promoted to production the day after: a cutover gated on service health, zero rollback.

This article tells the story of what we put in Git’s place, why it works and, above all, the cases in which you should not imitate us.

What Git versions, what it no longer versions

Git was created in 2005 by Linus Torvalds for the development of the Linux kernel, to solve one precise problem: hundreds of humans editing the same files in parallel, with no central authority. All of its primitives (the branch, the merge, the diff, the blame) stem from that problem: reconciling the simultaneous work of people typing text. For that problem, Git remains unmatched, and nothing here says otherwise.

But when AI agents write most of the code, three silent shifts take place.

The diff stops being the unit of review. Nobody seriously reads a 3,000-line diff generated in twenty minutes. Code review by reading the diff (the social function of the pull request) was already dead in practice in teams that had adopted agents; it survived as a ritual. Figures published in May 2026 by The Register give the measure of the problem: AI-generated projects grew 206% year-on-year on GitHub, and generated code piles up 10.83 issues per pull request, against 6.45 for human code [2]. More volume, less readability, more defects per batch: control can no longer be the re-reading of the produced text. It has to move: upstream towards the decision, downstream towards tooled verification.

The commit stops carrying the intent. A commit message written by an agent describes what changed, not what was decided. The real intent lives elsewhere: in the prompt, in the plan, in the orchestration session. Scott Chacon, co-founder of GitHub, acknowledges it himself: Git’s interface has barely changed since 2005, and version control needs rethinking for humans and agents. His wager: “the best engineers of the future will be the best writers” [1].

The branch stops being the right level of parallelism. The merge conflict is the artefact of a choice: parallelising at the level of the code. If you parallelise at the level of decisions (several plans investigated at the same time) and serialise the writing (one implementer at a time), the merge conflict does not become easier to resolve: it disappears from the system.

The industry sees the same problem and mostly answers with “a better Git”: agent-friendly interfaces, reworked parallel branches, dedicated tooling [1][2]. Even Cursor has gone this route: it announced Origin in June 2026, a Git forge “for the agentic era” built for dozens of agents running in parallel, where human review is explicitly redesigned as bulk approval, or even delegated to another agent [4]. That is the right answer for large human teams. In our context (one product, one human decision-maker, agents doing the writing), we chose the radical answer: remove Git and version something else.

The inversion: version the intent, not the text

This inversion has an academic name. In early 2026, a movement called spec-driven development took shape: the specification becomes the source of truth, the code a derived artefact, generated from it or verified against it. The literature distinguishes three degrees of rigour: spec-first (the spec precedes the code), spec-anchored (the spec remains the living reference), spec-as-source (the code is no longer maintained directly at all) [3]. GitHub, AWS and the main agent tools each have their own flavour.

Our variant moves the cursor slightly: we do not version full specifications, we version decisions. The nuance is practical. An exhaustive specification ages poorly and is hard to review; a decision (which mechanism to reuse, which approach to take, which contracts to honour, what is explicitly out of scope) ages well and can be reviewed in one screen. Code, meanwhile, has become what the casting is to a mould: regenerable, verifiable, replaceable. What is rare and precious is the mould.

Hence the name we give the method: roadmap-driven development. The roadmap becomes the operational registry through which every change to the product passes, updated continuously rather than reviewed quarterly.

In practice: two tables, one CLI, six states

The replacement infrastructure fits in one sentence: a dedicated database, two tables, a shell CLI of a few hundred lines.

The first table is the inbox, all the upstream material: ideas, backlog items, notes, and bug reports from beta users, surfaced automatically from production. Every item is triaged explicitly: dismissed, or promoted into a plan.

The second table is the plan registry. Each plan carries an identifier (T-001, T-002…), its dependencies, its risk level, and its full text. It moves through six states: draft → ready → approved → doing → done (plus abandoned). The full lifecycle:

roadmap next                 # next free identifier
roadmap submit T-042.md      # the plan enters the registry, the draft becomes disposable
roadmap approve T-042        # human gate: nothing gets implemented without it
roadmap claim T-042          # ONE implementer at a time
roadmap done T-042           # delivered, verified, recorded in the journal

Four rules hold the whole thing together.

1. Every agent session plans by default. None implements without an explicit order. N planning sessions run in parallel; each explores the code, investigates its subject and submits a plan. The plan must be “decision-complete”, actionable without further exploration: exact files, existing mechanisms to reuse, contracts (signatures, schemas), tests to write, explicit out-of-scope. No full code: one to three screens. A plan that is too risky is split into plans chained by dependencies.

2. The human gate is absolute. An unapproved plan never gets implemented. This is code review moved to where it becomes possible again: reviewing a one-screen decision rather than a 3,000-line diff. Approval commits; it is the application to software development of the principle we defend for all agents: the agent proposes, the human commits.

3. A single writer. Implementation is carried by one orchestration session at a time, multi-agent inside, following the UltraCoding loop: parallel implementers, adversarial review, verification before delivery. First step after the claim, a freshness pass: cheaply checking that the files and mechanisms named by the plan still exist as described. If the code has moved since the plan was written, the plan goes back to submission and through the gate again. And any re-submission of an already-approved plan mechanically invalidates its approval: you cannot slip a change under an old signature. Research is exploring the opposite path: several agents writing in the same workspace, every write validated against the current state of the files and rejected if the agent’s view is stale. The STORM framework (May 2026) gains 18.7 points on a coding benchmark that way against Git-worktree isolation [5]. That is our freshness pass, applied continuously, file by file; we preferred to serialise: a little less throughput, one entire class of conflicts fewer to govern.

4. The journal is authoritative. Whatever ships is recorded in an append-only journal: what shipped, when, why, with which follow-ups. The product’s history reads as a narrative of dated decisions, not as a commit log.

The equivalence table

The honest question is “what performs each of Git’s functions?” Here is the mapping, function by function:

Function performed by Git	What replaces it
Branches, worktrees: parallelise the work	Plans investigated in parallel; serialised writing (single-writer). The merge conflict disappears from the system, not merely resolved
Pull request: review before integrating	Human approval of the plan before implementation, plus tooled verification after (tests, lint, checks)
Log, blame: understand the past	Plan registry and append-only journal: the history of decisions, not of lines
Revert: go back	Deployment as complete images, previous version tagged rollback, cutover gated on service health
Bisect: find the origin of a regression	More than 200 numbered, executable anti-regression rules, a gate of nearly 700 checks, plus real-database test suites
Remote, push: back up	Daily off-site archive of the code and automatic export of the registry on every write (restore tested, not assumed)

The most important line is bisect. Git lets you find the offending commit after the fact; executable anti-regression rules forbid the known regression from ever returning, at every verification. It is the same shift as for review: from retrospective control over the text to permanent control over the behaviour.

Four days in: the numbers

The switch dates from 11 July 2026. As of 15 July: 50 plans in the registry (20 delivered, 10 in progress, 7 approved and awaiting implementation, 13 awaiting the gate), and around forty items in the inbox, including the beta bug reports surfaced from production. On 13 July, the orchestrator implemented a batch of 12 approved plans in one day; on the 14th, the batch went to production: a healthy cutover first time, zero rollback.

What the removed friction gave back: no more worktrees to set up, no more merges between agent sessions, no more rebasing. Planning sessions never tread on each other: they only ever write to the registry. And the system’s bottleneck has become exactly the one you want: human decision time at the gate, a few minutes per plan.

Two safety nets stay permanently in place: the complete .git archives, meaning the decision is reversible in one command, and the registry export shipped every night in the off-site backup; the restore procedure was tested the very day of the switch.

The honest part: when you should absolutely not imitate us

This method works because five conditions hold. If even one is missing, removing Git is folly.

1. A single human decision-maker. Two humans editing the same code need merging: that is precisely the problem Git solves better than anything. A team of human developers should keep Git.
2. Diff review had already stopped being the real control. In our case, the code is written by agents and controlled by tests, executable rules and systematic verification. If your developers genuinely read the diffs, the pull request is your review tool. Keep it.
3. A promote-only production environment, never edited directly, with a proven rollback path (images, cutover gated on health).
4. A dense executable safety net: real-database tests, anti-regression rules, a gate of checks. Without it, removing Git means removing your last net.
5. Tested backups: the important word is “tested”.

You also have to name what is genuinely lost: fine-grained bisect when a regression slips past the rules, line-by-line blame, and external-contribution tooling. An open-source project lives by pull requests and cannot do without them. If one of those uses is vital to you, the answer is not to imitate us, but to follow the path the industry is charting: a Git rethought for agents [1].

What this says to a business leader, beyond code

You will probably never remove Git from your systems. The real subject is the shift this story illustrates, and it extends beyond software.

When agents produce (code, but also sales proposals, campaigns, reports), the scarce resource that deserves a registry, states and a signature is no longer the artefact produced. It is the human decision. Roadmap-driven development is nothing more than that: a registry of intents in which every entry is explicit, approved, dated and traceable; the agent investigates, the human commits, execution is verified, the journal is authoritative.

It is the same loop we install at our clients with the MATIA Method™, function by function: generation becomes abundant everywhere; governance of the decision becomes the standard everywhere. The question to put to your teams (or to your provider) is less about “do you use AI?” than about the governance around it: where is the registry of what your agents are allowed to do, who signed each authorisation, and what verifies the execution? An organisation that answers by showing you a system has understood the era. An organisation that answers “it’s in the commits”, or worse “in the chat history”, has a governance problem, not a tooling problem.

In one sentence

Git versioned the work of human hands; when the hands become agents, what needs versioning (and keeping under human signature) are the decisions.

To install this governance loop (a registry of intents, a human gate, verified execution) in your AI projects, see the MATIA Method™ and the AI Express Audit & Roadmap.

Going further

• In the same series: Vibe coding is dead: enter UltraCoding, the production line that implements the plans, and Agentic systems engineering: the human in the loop, the “the agent proposes, the human commits” principle applied to every agent.

Paul-Antoine TUAL, AI Transformation Leader · Croissance et Transitions (SAS) · MATIA Method™ · Junyr Mail™ · Junyr Agents™

---

Sources: verified, July 2026

[1] a16z Podcast, “Rethinking Git for the Age of Coding Agents”, interview with Scott Chacon (co-founder of GitHub, CEO of GitButler), 21 April 2026, Git’s interface barely changed since 2005, version control to be rethought for humans and agents, “the best engineers of the future will be the best writers”. https://a16z.com/podcast/rethinking-git-for-the-age-of-coding-agents-with-github-cofounder-scott-chacon/ [2] Joab Jackson, “Git is unprepared for the AI coding tsunami”, The Register, 15 May 2026, +206% AI-generated projects on GitHub year-on-year (2025); 10.83 issues per pull request for generated code against 6.45 for human code; Scott Chacon: “run locally, mirrored globally”. https://www.theregister.com/devops/2026/05/15/git-is-unprepared-for-the-ai-coding-tsunami/5241480 [3] Deepak Babu Piskala, “Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants”, arXiv:2602.00180, 30 January 2026, the specification as the source of truth, code as a derived artefact; the three degrees spec-first / spec-anchored / spec-as-source. https://arxiv.org/abs/2602.00180 [4] Cursor (Anysphere), “Origin”, a Git forge “for the agentic era”, announced at the Compile conference on 17 June 2026, built for agents running in parallel (vendor demo: 22.6 commits per second on one repository), review designed as bulk approval; waitlist, release announced for autumn 2026. https://cursor.com/origin [5] Mengyang Liu, Taozhi Chen, Zhenhua Xu, Xue Jiang, Yihong Dong, “Multi-agent Collaboration with State Management” (the STORM framework, STate-ORiented Management), arXiv:2605.20563, 19 May 2026, concurrent agent writes validated against the current state of the shared workspace, stale writes rejected on the fly; +18.7 points on Commit0-Lite and +1.4 on PaperBench against Git-worktree isolation. https://arxiv.org/abs/2605.20563

The internal figures (50 plans, the batch of 12, lead times, checks) come from Junyr’s development registry, read on 15 July 2026, four days after the switch described here.