When 70% of Pull Requests Come From Agents, Who Decides What They’re Allowed to Change?

At a recent AI Engineer talk, Uber described an engineering environment that would have sounded futuristic only a short time ago.

More than 70% of its pull requests now originate from local or cloud agents. Lines of code per engineer have doubled year over year. Automated migrations have changed millions of lines of code.

But the interesting part of Uber’s story isn’t the code-generation number.

It is the infrastructure they had to build around it.

Uber described a model gateway handling identity, PII redaction, safety controls, and attribution. An MCP gateway exposes internal tools efficiently to agents. Pre-provisioned development environments give autonomous agents isolated places to work. A managed skills marketplace provides reusable capabilities. A large context graph connects code, ownership, documentation, incidents, and dependencies.

Then those pieces come together in an agentic software development lifecycle.

An idea can begin in Slack, move through business research and product requirements, connect to design, pass to a coding agent, produce a draft pull request, validate itself, go through CI and review, and eventually enter managed maintenance loops.

This is much more interesting than “AI writes code.”

It looks like the beginning of a software factory for agents.

And once software development starts operating this way, another problem becomes important.

Validation answers “did it work?”

One detail in Uber’s workflow is particularly important.

Their cloud coding agent, Minion, can deliberately stop at a draft pull request before sending work into CI.

Why?

Because pushing every generated attempt into an expensive shared CI system does not scale.

Instead, Uber is moving more validation into the agent’s inner loop.

Static analysis can happen earlier. A mobile simulator can be launched. Screenshots can be compared with Figma designs. Frontend and backend behaviour can be tested together. Parts of code review can happen before the outer CI loop.

By the time an autonomous change reaches a human reviewer, the pull request can include evidence showing which checks the agent has already performed.

That makes sense.

If agents generate increasing amounts of software, humans cannot compensate simply by reviewing more generated code manually.

Agents must increasingly prove their work before asking for human attention.

But validation answers only part of the problem.

It can tell us:

Did the tests pass?

Does the interface match the design?

Did static analysis succeed?

Does the implementation behave correctly?

There is another question.

Was the agent authorised to make this change in the first place?

Those are different questions.

Correct code can still be an unauthorised change

Imagine an agent receives a task to modify session-refresh behaviour.

It discovers that the easiest implementation also requires changing authentication middleware, modifying a shared database model, and updating a deployment configuration.

The agent may be completely correct.

Every test may pass.

The implementation may even be better than the originally anticipated solution.

But something important happened along the way:

the scope of the change expanded.

Today, we often expect a human reviewer to notice this.

That assumption becomes harder to sustain when agent-generated changes become the majority of changes rather than the exception.

Context doesn’t completely solve the problem either.

Giving an agent access to architecture documents, dependency graphs, source code, Jira tickets, incident history, and internal knowledge can dramatically improve its decisions.

But knowing about something is not the same as having authority to change it.

This distinction will matter increasingly in agentic software development.

Context and authority are different primitives

Uber’s context graph is a good example of the emerging context layer.

An agent may need to know:

Who owns this service?

Where is the implementation?

What depends on it?

Which internal patterns should be followed?

Which incidents involved this component?

Which design documents are relevant?

That is enormously valuable.

But consider a slightly different set of questions:

Which files may this agent modify?

Which files must it not modify?

Which constraints must remain true?

Which repository-owned checks provide evidence?

Who approved this scope?

Which trusted version of that approval applies to this implementation?

Did the final Git diff remain inside that approved scope?

Those aren’t primarily context-retrieval questions.

They are change-authority questions.

This is the problem EngineeringSpec is exploring.

Grant authority before the agent spends it

EngineeringSpec is an open experiment in change authority for AI coding agents.

Its basic idea is deliberately simple:

Review what an agent may change before it writes code. Verify the final Git diff against that authority.

Instead of allowing an agent to create a specification and immediately treat its own specification as permission, the authority comes from a reviewed contract already present on the trusted Git base.

Conceptually, the lifecycle is:

propose bounded authority
        ↓
human review
        ↓
merge authority to trusted base
        ↓
agent implements
        ↓
evaluate final Git state
        ↓
implementation review / merge

This creates a separation between granting authority and spending authority.

That separation is important.

An agent can propose that it needs broader access.

It cannot silently grant that broader access to itself.

If implementation discovers that additional surfaces need to change, the authority can be amended and reviewed separately.

The implementation then continues against the newly approved authority.

An agentic SDLC needs several independent controls

It is tempting to think there will eventually be one platform responsible for “AI governance.”

That probably isn’t the right model.

Different controls solve different problems.

These layers complement one another.

A sandbox controls execution boundaries.

A model gateway controls model access.

A context graph improves understanding.

Tests validate behaviour.

EngineeringSpec does not attempt to replace any of them.

Its narrower goal is to make repository change authority explicit and machine-verifiable.

That narrowness is intentional.

Git tells us what changed. We also need to know what was allowed to change.

Git already gives engineering teams an excellent historical record.

We can determine exactly which files changed, who committed them, which branch they came from, and which pull request merged them.

Agent platforms can provide another category of evidence: prompts, tool calls, reasoning traces, generated patches, and execution histories.

Those tell us what happened.

Change authority records something subtly different:

what was authorised to happen.

That enables a deterministic comparison.

Suppose an approved change contract permits modifications under:

src/session/**
tests/session/**

and explicitly denies:

infra/**

If the resulting Git diff modifies:

src/session/refresh.ts
tests/session/refresh.test.ts
infra/production/auth.yaml

the question is no longer whether an LLM reviewer believes that infrastructure change looks suspicious.

The authority check can fail deterministically.

The changed path was outside the granted authority.

Humans can then decide whether the implementation was wrong or whether the authorised scope needs to change.

The machine doesn’t make that product or architecture decision.

It simply prevents the decision from happening invisibly.

The reviewer experience may be where this becomes most valuable

Uber demonstrated another important idea: give reviewers evidence about what an autonomous change has already done.

As agent-generated code increases, the pull request itself may evolve.

Instead of presenting humans with only a diff, future pull requests may carry an evidence package:

the product intent, the approved change boundary, tests executed, visual comparisons, policy checks, affected components, agent provenance, and final authority evaluation.

The human review question can then change from:

“Can I reconstruct everything this agent did and determine whether it looks safe?”

to:

“Here is the intent, here is the authority we approved, here is the implementation, and here is the evidence. Do I approve the result?”

That is a substantially better human-machine boundary.

The goal isn’t to slow agents down

Governance mechanisms often fail because they add ceremony to every change.

That would be particularly damaging for coding agents.

If agents can produce changes in minutes but every change requires filling out a large governance document manually, the control will eventually be bypassed.

The useful version of change authority therefore has to be small, composable, and increasingly generated from information teams already possess.

A task, issue, or product requirement can help propose the authority.

Repository architecture can help identify likely writable surfaces.

Agents can draft the contract.

Humans review the consequential boundary.

The machine handles deterministic enforcement.

The important human action isn’t typing YAML or Markdown.

It is making an explicit decision:

Yes. For this change, these are the boundaries I am willing to authorise.

From coding agents to managed software factories

Uber’s talk suggests that the important shift is already underway.

The industry started by asking whether AI could generate useful code.

Then we asked whether agents could complete entire engineering tasks.

Now companies are building the infrastructure needed to run those agents at scale: gateways, environments, tools, context systems, skills, evaluation loops, and automated maintenance.

As those systems mature, the bottleneck moves again.

Uber ends its presentation with an important observation: when building becomes dramatically easier, the harder question becomes whether something should be built.

There is a parallel engineering question:

When making a change becomes dramatically easier, who authorised the change, and what exactly did they authorise?

That question is unlikely to be answered by a larger context window or a smarter coding model.

It is a control-plane problem.

And if agent-generated software becomes normal, change authority may need to become a first-class primitive of the software development lifecycle.

EngineeringSpec does not claim that Uber uses EngineeringSpec, nor that Uber lacks internal controls not discussed publicly. Uber’s Agentic SDLC presentation is used here as an example of the broader architectural direction emerging as organisations adopt coding agents at scale.