Why AI Agent PRs Get Rejected And How Repo Contracts Help

A recent study of agent-generated pull-request fixes reported that 46.41% of fixes proposed by Copilot, Devin, Cursor, and Claude were rejected.

That number matters, but the more useful question is why.

Some rejected PRs are simple model failures: the implementation is wrong, incomplete, or low priority.

Ota addresses a separate, avoidable class of failure:

• the agent ran the wrong verification path
• the repo needed a service or env var that was never declared clearly
• the change passed one local command but failed the real CI lane
• the repo never made safe boundaries explicit
• the agent stopped at "the code compiles" instead of "the repo's declared acceptance path passed"

That is not only an intelligence problem.

It is also a repo-governance problem.

No contract can make an incorrect or low-priority implementation worth merging. It can remove the avoidable execution uncertainty around it: whether the repo was ready, the right lane ran, the required services existed, and the completion claim matched the repo's declared acceptance path.

When an agent opens a PR, maintainers are not only reviewing the code diff.

They are also reviewing whether the agent understood the repo well enough to:

• prepare the repo correctly
• choose the right workflow
• run the right checks
• avoid unsafe changes
• prove that the change is actually complete

That is where a lot of agent PRs fall apart.

The repo may have the truth, but the truth is scattered:

• setup instructions in one README
• real verification logic in CI
• service assumptions in Docker files
• extra post-change steps in shell scripts
• path sensitivity in maintainer memory

An agent sees all of that and still has to decide:

What does done mean here?

If the repo does not answer that clearly, the PR is already risky before the code review starts.

The useful framing is not:

"Agents need better prompts."

The useful framing is:

"Repos need better execution truth."

A maintainer should be able to declare:

• how the repo becomes ready
• which tasks are canonical
• which workflow should be used after a change
• which services and env are required
• which tasks are safe for an agent
• which paths are protected
• which verification lane proves completion

Without that, every agent run is partly reconstruction work.

That reconstruction cost shows up later as:

• CI failures
• incomplete implementations
• wrong runtime assumptions
• reviewer fatigue
• rejected PRs that were never fully grounded in repo truth

Ota is not trying to make agents magically smarter.

Ota gives the repo an execution contract so the agent has less to guess.

That contract can declare:

• toolchains and runtime requirements
• dependency hydration and setup
• services and readiness
• tasks and workflows
• safe task boundaries
• protected and writable paths
• verification paths after changes

Instead of asking an agent to infer "probably run tests," a repo can say what the acceptance path actually is.

For example:

agent:  entrypoint: verify  default_task: verify  safe_tasks:    - lint    - test  verify_after_changes:    - verify  protected_paths:    - .github/workflows    - production/**    - secrets/**

And:

workflows:  default: app  app:    intent: local_development    prepare:      task: setup

And:

tasks:  verify:    aggregate:      tasks:        - lint        - test

Now the repo is saying something operationally useful:

• start from this task
• these are the safe tasks
• this is the post-change verification lane
• these paths are not for autonomous editing

That does not guarantee the agent will write the right code.

But it does remove a large class of avoidable failure.

There are four concrete ways this helps.

1. The agent runs the repo's real verification path

The agent no longer has to guess whether pytest, npm test, go test, or one CI script is the real acceptance lane.

The repo can declare the exact task or workflow that must pass.

That reduces PRs that fail because the agent validated the wrong thing.

2. The agent prepares the repo correctly before editing

A lot of wasted agent work starts before the code change:

• dependencies were not hydrated correctly
• a service was missing
• env files were never prepared
• the runtime was not actually ready

If readiness and setup are declared structurally, the agent has a better chance of operating on a real working repo instead of a half-prepared one.

3. The agent stays inside explicit safety boundaries

Some changes should not happen autonomously.

That may include:

• workflow files
• deployment config
• secrets surfaces
• destructive tasks
• data-reset lanes

If those boundaries are explicit, the agent can stop, escalate, or stay on the safe path instead of wandering into a high-review or high-risk change set. A consuming runner or CI gate can then enforce the same declared boundary where that enforcement is configured.

4. Reviewers get evidence, not reconstruction work

A reviewer should not have to reverse-engineer:

• what the agent should have run
• whether it used the right workflow
• whether a failure came from code, setup drift, or missing services
• whether the repo even exposed the right operational truth

Ota moves that toward explicit evidence:

• contract validation
• doctor output
• task dry-run
• workflow proof
• execution receipts

That makes rejected PRs easier to understand and good PRs easier to trust.

The real wedge is execution governance.

If AI agents are going to work across unfamiliar repos, those repos need a way to say:

• what is required
• what is safe
• what should run
• what success looks like

That is why this matters beyond agents.

The same contract truth helps:

• new contributors
• CI systems
• remote sandboxes
• internal automation
• future maintainers

The agent use case just makes the pain impossible to ignore.

A stronger flow is simple:

ota doctorota validate .ota tasks --useota up --workflow appota run verify

That is materially different from:

"Look around, pick some commands, and hope the repo agrees."

The first flow is governed. The second is guesswork.

If nearly half of agent-generated PR fixes are being rejected, the response should not only be to measure model quality harder.

We should also ask whether repos are giving agents a trustworthy path to completion.

The stronger question is not:

"Can the agent write code?"

It is:

"Can the repo tell the agent what a correct, safe, complete change looks like?"

That is the layer Ota is built for.

Install Ota:

curl -fsSL https://dist.ota.run/install.sh | sh

Windows:

irm https://dist.ota.run/install.ps1 | iex

Then start with:

ota doctorota init