When Agents Write the Code, Governance Becomes the Operating Layer
Last Updated on 29 June 2026 at 15:12
TL;DR:
- Git can remain the system of record for accepted software change.
- Agentic delivery exposes the need for real-time coordination, validation, accountability, and auditability above Git.
- The governance question comes before the tooling question: who may act, under which constraints, with which evidence, and through which route to acceptance.
There is a sentence circulating quietly among technical teams, product builders, and anyone now working seriously with coding agents: Git no longer feels like the right paradigm. The formulation is imprecise, but it identifies a real change in delivery pressure.
The claim points to role displacement rather than technical obsolescence. Git remains technically useful and operationally valuable. Indeed, Git still does what it was designed to do with remarkable discipline: preserve history, compare states, isolate work, restore prior versions, carry releases, and create a record that can be audited after the fact. For regulated environments, financial systems, security-sensitive products, and any software organisation that still cares about production accountability, this remains valuable.
The discomfort comes from another place.
Git was built around a rhythm of human work. A developer changes a set of files, commits periodically, pushes to a remote repository, opens a pull request, waits for review, receives comments, adjusts, rebases, merges, and moves to the next increment. The process was already slow for high-pressure delivery. With agents, the mismatch becomes visible.
Agents do not naturally work in the same cadence. They investigate, branch, generate, test, rewrite, compare, forget context, rehydrate context, and produce candidate changes at a speed that makes the old ritual look administrative. They can work in parallel. They can explore several approaches at once. They can produce four possible implementations while a human team is still deciding which ticket label applies.
The toolchain still asks them to behave like humans at the end of a sprint.
That is the real fracture.
The direction is already visible in current tooling. Worktrees let developers operate several working trees attached to the same repository. Coding agents can research a repository, plan an implementation, make changes on a branch, and open a pull request. Merge queues already recognise that a change can pass in isolation and still require validation against the latest target branch before it enters the main line. These mechanisms are useful signals. They also show the gap. The industry is adding coordination fragments around Git, while the operating model remains organised around branches, pull requests, and periodic reconciliation.
Git’s future role is changing
The relevant question is whether Git should remain the daily operating model for agentic software delivery.
Indeed, a ledger is not the same thing as an operating system. A record is not the same thing as coordination. A commit is not the same thing as intent. A branch is not the same thing as ownership. A pull request is not the same thing as readiness.
In practice, a ledger stores accepted state. Coordination governs intent, ownership, readiness, dependency, and risk before that state is accepted. Git is strong at the first function. Agentic delivery exposes the need for the second.
For years, software teams treated Git as more than a version control system. It became the coordination surface, the review surface, the release surface, the evidence surface, and sometimes the governance surface. That was convenient because the human delivery system was already constrained by meetings, tickets, reviews, sprint boards, and release gates. Git could absorb a large part of the operational burden.
Agentic delivery changes the load profile.
When several agents work at once, the main difficulty is not storing file history. It is knowing which candidate change is still valid, which one conflicts with a later architectural decision, which one silently weakens a security rule, which one duplicates another agent’s work, and which one satisfies the task locally while damaging the system globally.
Git records changes without carrying intent, assumption validity, or governance status. Git does not encode why the change was attempted, whether the underlying assumption remains valid, or whether the work became obsolete when another agent modified the surrounding context three minutes earlier.
That is no longer a marginal limitation but the central point of the work.
The old workflow hides latency
The classic commit-push-review workflow was never as clean as its diagrams suggested.
It created a comforting sequence: work first, review later, integrate at the end, discover conflict when the team was already emotionally attached to the solution. This was tolerable when the number of simultaneous changes was limited and the human pace was slow enough for the process to catch up.
Agentic work compresses that timeline. More work can be produced before anyone has verified whether the work should exist.
This is where the operational risk changes. The bottleneck shifts into governance: coordination, validation, ownership, and consequence.
A coding agent can produce a plausible patch. Another can produce a plausible alternative. A third can adjust documentation. A fourth can repair tests. Individually, each output may look reasonable. Together, they may create architectural drift, duplicated logic, broken invariants, diluted ownership, or a system that passes tests while becoming harder to govern.
The failure mode is familiar outside software.
In transformation programmes, teams often produce progress artefacts faster than the organisation can absorb them. Dashboards improve. Meetings multiply. Workstreams report green. The real constraint remains unresolved because no one is governing the relationship between activity, evidence, decision rights, and consequence.
Agentic software delivery risks the same pattern.
More output can increase reconciliation work when coordination and validation lag behind production.
Worktrees are a symptom
The discussion around worktrees is revealing. Worktrees may be technically useful. They allow multiple working directories against the same repository. They help isolate parallel tracks. They can support agents that need separate sandboxes.
But as a human mental model, they are already a sign that the abstraction is leaking.
The user should not need to think in worktrees. The user should think in intent, surface, risk, dependency, and readiness. The orchestration layer should decide how many workspaces are needed, how they are isolated, how they receive upstream changes, and when they should be retired.
Worktrees and branches address the mechanics of parallelism. They allow unfinished work to remain isolated, comparable, and eventually reconciled. Their limitation appears when they are asked to carry governance meaning. A branch can contain a candidate change. It does not inherently express ownership, risk class, policy status, architectural constraint, or the conditions under which the work may advance.
Worktrees should therefore be treated with nuance. They are useful infrastructure for parallel work, experimentation, hotfixes, and agent isolation. They allow unfinished work to remain isolated, comparable, and eventually reconciled. Their limitation appears when they are asked to carry governance meaning. A branch can contain a candidate change. A worktree can isolate its files. Neither inherently expresses ownership, risk class, policy status, architectural constraint, or the conditions under which the work may advance.
Human teams have historically compensated for this limitation through convention. Branch names, ticket identifiers, review habits, senior memory, release calendars, and informal ownership rules supplied the decision context that Git itself did not encode. Agentic workflows weaken that arrangement because agents cannot safely rely on tacit organisational memory. They require explicit, machine-readable context.
That context includes the origin of the instruction, the accountable owner, reserved files or surfaces, applicable policy gates, sufficiency tests, controlling architectural decisions, dependency conflicts, concurrent agent activity, and the effect of upstream changes on the validity of the plan. Without these signals, the system can produce and isolate work, but it cannot reliably govern whether that work remains legitimate.
Git records the candidate state after the work has taken form. Agentic delivery needs governance earlier: while the work is being generated, contested, invalidated, redirected, or prepared for acceptance.
Real-time coordination becomes the missing layer
The better model places a real-time agentic delivery layer above Git.
A real-time agentic delivery layer would treat Git as a settlement mechanism, not as the primary place where work is coordinated. Agents would operate inside managed execution spaces. They would receive live context changes. They would know when a file, module, API, test suite, or architectural surface has become contested. They would be interrupted when their assumptions expire. They would not wait until pull request time to discover that the world has moved.
The system would maintain leases, not only branches. It would track intent, not only diffs. It would evaluate readiness continuously, not only at review time. It would connect tests, policy, architecture, security, and release state before the human reviewer is forced to reconstruct the story manually.
The unit of work would shift.
Today, the visible unit is often the pull request. In an agentic system, the visible unit should be the governed candidate change: a bounded intervention with declared intent, known affected surfaces, evidence generated during execution, risk classification, and a proposed route to settlement.
Git receives the accepted state.
The operating layer manages the path to that state.
Code review moves upward
The weakest part of the current debate is the idea that code review is starting to feel less necessary.
What is becoming less necessary is low-value human review: style comments, obvious syntax issues, formatting disputes, repetitive checklists, naming arguments, and manual scanning for issues that tools can detect better. As such, low-value human review is losing relevance.
Today, code review is becoming more selective, risk-based, and consequential.
When agents write more code, review must move upward. The reviewer should not spend time pretending to be a slower linter. The reviewer should examine whether the change respects architecture, security boundaries, product intent, data handling, backward compatibility, observability, performance budgets, operational reversibility, and release governance.
This is a different kind of review.
It is closer to executive control than peer correction. It asks: does this change deserve to become part of the system of record?
That question will not disappear because an agent produced the patch. It becomes more necessary because the patch may look clean while the underlying reasoning is shallow, stale, or misaligned.
The new review model will be risk-based. Low-risk, well-tested, isolated changes may settle automatically. High-risk changes should trigger human review, architectural review, or security review. Some areas should never be modified by agents without explicit approval. Some changes should be allowed only when a named invariant is proven by tests.
This model can be faster because it concentrates human attention where consequence and ROI is highest.
The correction is not less review but a better-routed review. Human attention should move away from formatting disputes, repeated checklist items, and defects already captured by tests or static analysis. It should concentrate on architecture, reversibility, security posture, data exposure, user impact, contractual risk, and the decision to make a change permanent. In that model, review becomes a governance act. The reviewer is no longer only reading code; but deciding whether the system should absorb the consequence of that change.
The future workflow is event-driven
The more mature delivery model will not be organised around periodic reconciliation alone but more around state changes.
When work changes, the system should react while the work is still in motion. A modified file should signal the agents affected by that change. A changed upstream decision should make dependent work visible as potentially stale. A failed test should return to the owning agent with context, not simply appear as a red mark in a pipeline. A security-sensitive surface should trigger a stricter gate before the change travels too far. A shared dependency touched by two agents should be detected as a live collision, not discovered only when the branches are already mature.
The same logic applies to governance. A policy change should re-evaluate open work. A release window should admit only candidates with sufficient evidence. An accepted change should then move into Git as settlement: recorded, comparable, auditable, and recoverable.
This is the delivery model agentic systems make necessary. The centre of gravity moves from administrative review after production to governed coordination during production. Software delivery becomes a living execution system: responsive to change, explicit about consequence, and disciplined about what is allowed to become permanent.
And this is how software delivery begins to resemble a living execution system rather than a sequence of administrative, human-based rituals.
The distinction matters for organisations that operate under pressure.
In calm code development environments, inefficiency is hidden inside calendars. In distressed environments, every delayed signal has a cost. Late conflict discovery is a cost. Manual reconciliation is a cost. Review queues are a cost. Broken assumptions are a cost. Rework disguised as progress is a cost.
Agentic systems will not remove those costs automatically. This approach may even increase them if governance remains manual.
The governance question arrives before the tooling question
The temptation will be to buy or build the orchestration layer too quickly.
That would repeat a familiar mistake. Organisations adopt a tool to solve what is actually an operating model problem. The result is another layer of automation over unclear ownership.
Before selecting an agentic development platform, teams need to define the governance model that Git previously absorbed through convention, professional discipline, and the slower rhythm of human coordination.
The model has to answer questions that were once distributed across senior judgement, code review habits, release routines, and informal team memory. Which changes may be automatic. Which surfaces require human approval. Which policies are hard gates. Which tests produce evidence, and which merely confirm hygiene. Which architectural decisions can be made machine-readable. Which logs are sufficient to reconstruct intent, sequence, and responsibility. Which failures require rollback, quarantine, escalation, or refusal. Which agents may act, where they may act, and under which constraints.
Without this prior architecture of control, real-time automation increases movement before it increases mastery. The organisation receives more patches, more branches, more candidates, more test traces, and more apparent progress, while the underlying decision system remains under-specified.
The conversation therefore belongs at the level of execution governance: how automated work is authorised, constrained, evidenced, reviewed, escalated, accepted, and finally allowed to enter the system of record.
A mature agentic delivery system will need the same disciplines that complex transformation programmes need: clear decision rights, traceable evidence, bounded autonomy, escalation routes, exception handling, and a record of why certain choices were accepted.
The difference is speed.
In human delivery, governance gaps may take months to surface. In agentic delivery, they can surface in hours.
Git remains the evidence space
The likely future reduces Git’s role as the primary interface and keeps it as the system of record.
Git remains the evidence space. It stores accepted facts: commits, tags, releases, diffs, history, rollback points, forensic trails. It remains useful precisely because it is conservative. It does not need to become intelligent. It needs to remain reliable.
The intelligence belongs above it. The agent fabric should manage work in motion. Git should preserve work that has passed control. That separation is healthy. It mirrors a broader rule in execution work: thinking space and evidence space must not be confused. They need separate rules. Exploration needs fluidity. Record needs discipline. When every experiment is treated as evidence, the system becomes noisy. When every evidence step is treated as an experiment, the system becomes unsafe.
Agentic software delivery needs both.
The workspace should be alive, adaptive, interruptible, contextual, and real-time.
The ledger should be stable, auditable, boring, and recoverable.
A simple case shows the failure pattern. One agent updates the onboarding flow. Another changes the permissions model. A third refactors the notification layer. Each branch can look correct. Each local test suite can pass. The risk appears in the interaction between the three changes: the onboarding flow now depends on a permission state that the notification layer no longer observes. Traditional pull requests may reveal the conflict late, after each agent has already produced apparently valid work. Agentic delivery needs earlier coordination: live dependency signals, stale-assumption warnings, shared state awareness, and consequence-based review routing before the merge discussion starts.
The deeper shift
The discomfort around Git is therefore a signal of a deeper shift.
Software delivery is moving from a document-and-review rhythm to a governed execution rhythm. The old model assumed that humans produced scarce changes and tools helped record them. The new model assumes that machines can produce abundant changes and governance must decide which changes deserve permanence. This changes the role of senior engineering, architecture, QA, security, and delivery leadership.
Judgement becomes the scarce resource because agentic delivery changes the economics of production before it changes the quality of decision.
The first judgement concerns system shape: which components should remain stable, which interfaces can tolerate change, where complexity is allowed to accumulate, and which dependencies must remain legible to the organisation.
The second concerns risk: whether a change is reversible, whether its consequences are local or systemic, whether it modifies a sensitive surface, and whether the organisation can still explain the decision after the immediate productivity gain has disappeared.
The third concerns automation boundaries. Some tasks can be delegated because their criteria are explicit, repeatable, and testable. Others require interpretation, accountability, or institutional memory. In those cases, automation can assist the work, but it cannot legitimately absorb the decision.
The final judgement concerns permanence. Agentic systems can generate changes that are syntactically correct, locally useful, and operationally plausible. That does not make them worthy of entering the system of record. The governing question is whether the change strengthens the architecture, preserves accountability, and reduces future burden — or whether it merely converts present velocity into deferred liability.
Agentic development exposes weak governance earlier because work now moves faster than the organisation’s ability to interpret, constrain, and accept it.
This also changes how organisations should separate thinking from evidence. Agentic work creates a large volume of intermediate reasoning: prompts, plans, failed attempts, partial patches, regenerated files, test traces, discarded options, and rewritten branches. Treating all of that as permanent record creates noise. Treating none of it as record creates risk. The operating model needs two spaces with different rules. Thinking space is where agents explore, test, and discard. Evidence space is where accepted decisions, validated changes, ADRs, release notes, test outcomes, and accountable approvals are preserved. Git belongs mainly to the evidence space. The agentic coordination layer governs the movement from one space to the other.
This distinction matters most in regulated or governance-heavy environments. A banking platform, healthcare workflow, public-sector system, or client-data process cannot treat faster code generation as faster delivery by default. The relevant question becomes whether the organisation can prove what changed, why it changed, who accepted the risk, which controls passed, which exceptions were granted, and whether rollback remains credible. Agentic delivery raises the standard for traceability.
Many teams will discover this transition through operational friction rather than deliberate design. They will read increased code production as evidence of accelerated delivery, while the binding constraint quietly moves into reconciliation. The organisation will receive more patches, more branches, more candidate changes, and more apparent progress. It will also inherit more overlapping work, more unexplained assumptions, more inflated diffs, more unnecessary modifications, and more decisions that have to be reconstructed after the agents have already acted.
Mature teams will preserve Git, but they will narrow its function. Git will remain the evidentiary ledger: the place where accepted change is recorded, compared, audited, and recovered. Daily coordination will move into a real-time execution layer above it. That layer will make policies machine-readable, expose architectural constraints to agents, classify review by risk, connect tests to evidence, and define the conditions under which generated work can become permanent.
The difference is not a matter of tooling elegance. It is a matter of execution control. Agentic delivery becomes credible only when speed is bounded by visible decisions, enforceable policies, contextual validation, and accountable acceptance. Without that governance layer, automation does not create order. It accelerates the movement of unresolved disorder through the system.
The claim that Git no longer represents the right paradigm is useful as an intuition, but insufficient as a diagnosis. It points to the pressure created by agentic production, while leaving the role of Git itself under-specified.
Git is not disappearing from the delivery architecture. Its function is narrowing and becoming more institutional. It is becoming the ledger beneath agentic execution: the durable record of accepted change, validation history, review outcome, and rollback capacity. The missing layer sits above it. Agentic software delivery now requires real-time governance for work in motion: coordination of intent, visibility of dependency, detection of stale assumptions, routing of review by consequence, and disciplined movement from exploratory output into accountable record.
Git can remain the ledger. Agentic software delivery now requires an operating model for real-time coordination, validation, accountability, and auditability above it.
For leadership teams, this becomes the first diagnostic point. The first decision is rarely the choice of agent, IDE, repository host, or pull-request interface. The prior decision concerns the organisation’s ability to govern work that now moves faster than its existing control rhythm. That requires a clear map of decision rights, review thresholds, evidence rules, escalation paths, release gates, and accountability boundaries.
Tooling can support that model, but it cannot define it on behalf of the organisation.
Elena Debbaut is a strategic execution expert to boards and executive teams. She leads and advises on complex transformations when governance barriers, internal politics, or structural fragmentation prevent organizations from executing critical decisions.
Specialities:
• governance-constrained transformation
• operational restructuring
• strategic recovery & execution