When Coding Agents Go Wild, Git Is Not Enough
We need to stop kicking this can down the road
The large software platforms are no longer selling autocomplete.
They are building managed agent execution systems.
GitHub has Copilot agents.
OpenAI has Codex.
Anthropic has Claude Code.
Google has Antigravity 2.0 and Managed Agents.
The direction is clear.
Agents are being assigned work. Agents are running in the background. Agents are changing files. Agents are opening pull requests. Agents are starting to operate as parallel software workers.
That is a major shift.
It also creates a management problem that most organizations are not ready for.
The Current Vendor Pattern
The leading platforms are converging on the same operating model:
• Isolate the agent
• Give it repository context
• Let it plan the work
• Let it change files
• Let it run tools
• Produce a diff or pull request
• Let a human review before merge
Google’s May 2026 I/O announcements make the shift more visible.
Antigravity 2.0 is no longer framed as one assistant helping one developer. It is moving toward agent orchestration, subagents, hooks, scheduled work, sandboxed execution, and managed agents.
That matters.
The market is moving from developer assistance to managed parallel development capacity.
That is the good news.
The bad news is that most organizations still think the control point is the pull request.
It is not.
The pull request is downstream.
By the time the pull request exists, the agent has already made decisions. It has selected files. It has crossed boundaries. It has interpreted scope. It has changed code. It has created merge risk.
Review catches some of that.
It does not govern the work before the damage exists.
Git Records the Collision. It Does Not Prevent It.
Git is excellent at source control.
It records history. It tracks branches. It detects merge conflicts. It supports rollback. It supports pull requests.
But Git is not an architect.
Git does not know which agent should own Program.cs. Git does not know whether one agent is changing onboarding while another changes authentication. Git does not know whether two agents are changing different files that depend on the same interface. Git does not know whether a small view change depends on a service change in another worktree.
Git tells you about the collision later.
For a human team, that is painful but survivable.
Humans move at human speed.
An agent does not.
One unmanaged agent is a risk. Ten unmanaged agents are a delivery hazard. Fifty unmanaged agents are not a team. They are uncontrolled concurrency.
Worktrees Are Isolation, Not Coordination
Git worktrees are useful.
They let multiple branches exist beside each other without constant checkout switching. That is useful for agent work because each agent gets its own folder, branch, and task.
But isolation is not coordination.
A worktree says:
This branch has its own working directory.
It does not say:
This agent owns these files. This agent must not touch those files. This file is already leased. This task overlaps another task. This change crosses an architectural boundary. This branch is drifting from the integration branch. This merge conflict is predictable now.
That missing layer is the real problem.
The Big Players Are Building the Runtime
The big players are building the runtime.
That includes:
• Agent workspaces
• Cloud sandboxes
• Repository access
• Tool execution
• Branch creation
• Pull request generation
• Background task execution
• Multi-agent orchestration
• Hooks and agent configuration files
• Permission models
• Review workflows
This is necessary.
It is not sufficient.
The runtime answers:
How does the agent do the work?
The enterprise still needs to answer:
Should this agent be allowed to do this work right now?
That is where the AI Harness belongs.
The AI Harness Is the Missing Control Layer
The AI Harness is not another chatbot.
It is not a prompt library.
It is the control system around agentic software delivery.
The AI Harness should know:
• Which agents are active
• Which tasks they own
• Which worktrees they are using
• Which branches they created
• Which files they are allowed to change
• Which files are already leased
• Which files are architectural choke points
• Which changes are drifting toward conflict
• Which tasks overlap
• Which pull requests are safe to review
• Which work requires human approval before the agent continues
Without this layer, organizations rely on downstream merge conflicts as their safety system.
That is weak design.
Merge conflict detection is an alarm.
It is not traffic control.
File Leases Should Become Normal
Before an agent edits a file, it should request a lease.
Example:
Agent A requests:
Views/EmployeeMasters/OnBoardingEmployee.cshtml
The AI Harness approves it.
Agent B then requests the same file.
The AI Harness denies it.
That denial is not friction.
It is control.
The same rule should apply to high-risk files:
Program.cs appsettings.json Dependency injection setup Authentication code Authorization code Shared interfaces Database migrations Project files Build scripts Deployment configuration
These files should not be casual agent targets.
They are architectural choke points.
A senior developer or solution architect should decide when those files are in scope.
Scope Is the New Senior Developer Skill
In agentic development, the quality of the task matters as much as the quality of the model.
A bad task creates bad motion.
“Fix onboarding” is too broad.
A safer work order says:
• Change activation link failure handling
• Modify only the onboarding employee view and related controller path
• Do not change authentication
• Do not change configuration
• Do not change shared email services without approval
• Do not change dependency injection
• Run the named tests
• Produce a pull request with a short explanation
That is the difference between delegation and abdication.
Untrained users will not naturally write work orders this way.
They will tell the agent to fix the problem.
The agent will search the codebase, infer scope, change files, and produce code that looks plausible.
That is where the danger starts.
Cloud Adoption Was Hard. Agent Adoption Will Be Harder.
Many companies still have not learned how to use cloud providers well.
They moved servers into the cloud and called it transformation.
They bought services but kept old operating models.
They created cost surprises, security gaps, brittle deployments, and unclear ownership.
Agentic development carries the same risk, but faster.
Companies will buy coding agents and assume productivity follows.
It will not.
Without governance, agents amplify both skill and confusion.
A strong engineering culture will use agents to accelerate bounded work.
A weak engineering culture will use agents to generate larger piles of unmanaged change.
The difference will not be the model.
The difference will be control.
Pull Requests Are Not the Finish Line
A pull request is useful.
But a pull request is downstream.
By the time the PR exists, the agent has already made decisions:
It selected files. It crossed boundaries. It introduced dependencies. It interpreted requirements. It created merge pressure. It consumed review capacity.
Review matters.
Review alone is not enough.
The AI Harness needs earlier signals:
• What files did the agent read?
• What files did the agent plan to change?
• What files did it actually change?
• Did it change files outside approved scope?
• Did another active task touch related files?
• Does the branch still merge cleanly?
• Does the change affect a high-risk architectural path?
• Did the agent modify configuration, security, or build behavior?
• Did the agent create hidden coupling with another branch?
This is how agentic work becomes manageable.
The Safe Operating Model
A safer workflow looks like this:
1. The architect breaks work into bounded tasks.
2. The AI Harness assigns one task to one agent.
3. The AI Harness creates the branch and worktree.
4. The agent receives allowed paths and blocked paths.
5. The agent requests file leases before edits.
6. A watcher tracks actual file changes.
7. The AI Harness compares actual changes against approved leases.
8. The branch is continuously checked against the integration branch.
9. Tests and static checks run before PR creation.
10. High-risk changes require human approval before merge.
This is not bureaucracy.
This is the minimum control layer needed when the workforce includes tireless parallel code writers.
The Real Enterprise Risk
The risk is not that agents write bad code.
That risk already exists with people.
The larger risk is unmanaged speed.
An agent does not need a coffee break. An agent does not wait for the next standup. An agent does not naturally understand team ownership. An agent does not know which files are politically, architecturally, or operationally sensitive unless the system tells it.
That means the organization must supply the boundaries.
If the architecture is weak, agents expose it.
If the work is poorly scoped, agents expand the mess.
If ownership is unclear, agents collide.
If the branch strategy is weak, agents accelerate drift.
If review discipline is weak, agents push more work into a broken gate.
What the Serious Teams Will Do
Serious teams will not let agents roam the repo.
They will create controls:
• Agent task intake
• Path-level ownership
• File leasing
• Worktree assignment
• Branch naming rules
• Merge simulation
• Test gating
• PR templates
• Change-risk scoring
• Human approval for architectural files
• Audit logs of agent activity
They will treat agents like powerful junior developers with speed, memory, and tool access.
That means supervision matters.
The future is not “give every employee an agent and hope Git catches the problems.”
The future is controlled agentic delivery.
The Real Question
The question is not:
How many agents can we run?
The question is:
How many agents can we control?
A solution architect should not celebrate unmanaged parallelism.
More agents do not automatically mean more progress.
Twenty agents changing code without coordination is not a high-performance team. It is a collision engine.
The companies that win with agentic development will not be the companies that let the most agents loose.
They will be the companies that build the best harness around them.
Agents need autonomy.
Software delivery needs control.
The AI Harness is where those two realities meet.