Self-Driving Codebase: A Governance Guide for Agent PRs

Executive Summary

A self-driving codebase is not a repository that can safely modify itself without supervision. It is a governed delivery system in which AI agents receive bounded work, operate inside restricted environments, produce verifiable evidence, and move changes through risk-based approval and rollback controls.

The practical design question is therefore not "How many pull requests can an agent create?" It is:

Which changes may an agent attempt, what evidence must it return, who may approve the effect, and how will the team detect and reverse a bad outcome?

Four principles anchor the answer:

• Eligibility before autonomy: classify the task before choosing how independently the agent may act.
• Evidence before trust: a plausible diff or polished demo is not proof of correctness.
• Review capacity before parallelism: generating changes faster than people can validate them creates a larger risk queue.
• Recovery before expansion: do not grant a new effect until cancellation, rollback, and ownership are proven.

What "Self-Driving" Should Mean

Self-driving should describe a closed, controlled workflow rather than unlimited model authority. A production loop includes:

The agent may perform much of the middle of this loop. The organization still owns the task definition, permissions, acceptance policy, merge authority, release boundary, and consequences.

This framing avoids two common mistakes:

1. treating a capable coding model as an authorization system;
2. treating a pull request as the end of the task rather than a proposal for an operational effect.

For a deeper view of the runtime around the model, see the agent harness evaluation guide.

Read Adoption Claims with the Correct Boundary

Vendor disclosures show that agent-authored changes are real, but they do not establish a universal productivity or quality rate.

Cursor's February 24, 2026 product post states that more than 30% of the PRs it merged internally were created by agents operating autonomously in cloud sandboxes. Michael Truell's February 26 post gives the figure as 35%. Both describe Cursor's own team; neither establishes an industry-wide rate.

The product post describes isolated virtual machines and artifacts such as videos, screenshots, and logs. These first-party reports do not provide a matched human baseline, task distribution, review-cost breakdown, defect rate, or independent audit. They establish the reported extent of adoption, not a measured productivity gain.

Independent studies add useful but still bounded evidence:

These results are compatible: an agent PR can be mergeable and still require human revision; throughput can improve for one task class while review or maintainability costs rise elsewhere. Treat external numbers as hypotheses for a local evaluation, not adoption targets.

Classify Tasks Before Launching an Agent

Task eligibility is the first safety boundary. A useful classification combines blast radius, observability, reversibility, and specification quality.

Examples are not permanent labels. A dependency update may be low risk in an isolated tool and high risk in an authentication gateway. A documentation change may still leak confidential information. Classify the actual effect, not the ticket title.

Do not delegate end-to-end execution when any of these conditions is true:

• the desired behavior cannot be expressed as observable acceptance criteria;
• the agent needs standing production credentials or unrestricted network access;
• the change crosses an undocumented service, schema, or tenancy boundary;
• rollback is destructive, untested, or slower than the tolerated recovery time;
• CI is flaky enough that a pass cannot distinguish the patch from noise;
• ownership, licensing, privacy, or regulatory obligations are unresolved.

Use an Autonomy Ladder, Not an On/Off Switch

Autonomy should advance independently for each repository and risk class.

Level 5 is not the goal for every task. A mature system may keep security-sensitive work at Level 1 while allowing generated documentation at Level 4. The correct level is the highest one supported by representative evidence and reliable recovery.

Human-in-the-loop also does not mean adding a confirmation dialog to every action. Approval must be attached to an exact revision, parameters, evidence bundle, and effect. A stale approval must not authorize a changed commit.

Write an Executable Acceptance Contract

The agent should receive a contract that makes success and prohibited behavior explicit.

Outcome:
Baseline and reproduction:
Allowed files, services, and commands:
Non-goals and forbidden changes:
Functional and negative acceptance tests:
Security, privacy, performance, and compatibility invariants:
Required evidence:
Budget and stop conditions:
Rollback procedure:
Owner and required approvals:

Good acceptance criteria describe observable behavior. "Improve the authentication module" is not testable. "Reject an expired token without querying the profile service, preserve the public error schema, and pass the replay fixture" is.

Keep the contract separate from implementation hints. Otherwise, an agent can satisfy the proposed method while missing the user outcome.

A Go policy gate

The following standalone Go program shows how a repository can convert verified risk and evidence into a deterministic decision. Save it as main.go and run go run main.go. Medium-risk work still requires a human even when all automated gates pass.

This is a decision function, not an evidence verifier. Its inputs must be assembled by a trusted service from CI results and authenticated review records for the exact commit. The agent must not supply its own risk classification, pass flags, or approval count.

package main

import (
	"fmt"
	"strings"
)

type Proposal struct {
	Risk               string
	BaselineCaptured   bool
	TestsPassed        bool
	SecurityPassed     bool
	RollbackVerified   bool
	ProvenanceComplete bool
	HumanApprovals     int
}

type Decision struct {
	Action  string
	Reasons []string
}

func evaluate(proposal Proposal) Decision {
	reasons := make([]string, 0)
	if !proposal.BaselineCaptured {
		reasons = append(reasons, "baseline is missing")
	}
	if !proposal.TestsPassed {
		reasons = append(reasons, "required tests failed")
	}
	if !proposal.SecurityPassed {
		reasons = append(reasons, "security gate failed")
	}
	if !proposal.RollbackVerified {
		reasons = append(reasons, "rollback is unverified")
	}
	if !proposal.ProvenanceComplete {
		reasons = append(reasons, "provenance is incomplete")
	}
	if len(reasons) > 0 {
		return Decision{Action: "block", Reasons: reasons}
	}

	switch proposal.Risk {
	case "low":
		return Decision{Action: "eligible-for-policy-merge"}
	case "medium":
		if proposal.HumanApprovals < 1 {
			return Decision{
				Action:  "require-human-review",
				Reasons: []string{"medium-risk change needs an accountable owner"},
			}
		}
		return Decision{Action: "merge-after-owner-approval"}
	default:
		return Decision{
			Action:  "require-specialist-review",
			Reasons: []string{"high or unknown risk cannot auto-merge"},
		}
	}
}

func main() {
	decision := evaluate(Proposal{
		Risk:               "medium",
		BaselineCaptured:   true,
		TestsPassed:        true,
		SecurityPassed:     true,
		RollbackVerified:   true,
		ProvenanceComplete: true,
	})
	fmt.Printf("%s: %s\n", decision.Action, strings.Join(decision.Reasons, "; "))
	// Output: require-human-review: medium-risk change needs an accountable owner
}

Real policy must bind the decision to the commit SHA, repository, actor identity, policy version, test artifact hashes, and approval expiry. Count distinct authorized reviewers, reject dismissed or stale approvals, and enforce the decision at the protected merge boundary. Returning an action string does not perform or authorize a merge on its own.

Require an Evidence-Bearing Pull Request

A trustworthy agent PR explains what was proven, not merely what the agent did.

The evidence bundle should contain:

• task identity: issue, contract version, target branch, and exact commit;
• baseline: reproduction steps or a known-good comparison;
• change map: affected interfaces, schemas, dependencies, flags, and owners;
• verification: commands, environment, exit status, relevant logs, and artifact hashes;
• negative evidence: failure paths, authorization checks, malformed input, and rollback test;
• residual uncertainty: checks not run, assumptions, flaky results, and unsupported environments;
• release plan: rollout scope, observation signals, abort condition, and rollback owner.

Screenshots and videos are useful for visual behavior, but they cannot prove authorization, concurrency safety, data integrity, or absence of hidden regressions. Generated tests are also not independent evidence when they repeat the implementation's mistaken assumption.

Record tool calls, commands, changed resources, policy decisions, approvals, and outcomes. Do not require or retain hidden chain-of-thought. Operational evidence is more auditable and less sensitive than an unverifiable narrative about internal reasoning.

Protect Reviewer Capacity

Parallel agents increase proposal throughput before they increase verified delivery. If review is the bottleneck, more agents can lengthen queues, encourage shallow review, and create conflicting changes.

Control work in progress with:

• a per-owner limit on unreviewed agent PRs;
• maximum change size or mandatory decomposition for broad diffs;
• automatic closure or refresh of stale proposals;
• ownership routing based on affected interfaces;
• duplicate-task and overlapping-file detection;
• a review service-level objective by risk class;
• a kill switch when rollback, defect, or queue thresholds are breached.

The economic unit is not "PR created." A more useful unit is accepted goodput: changes that are reviewed, merged, operated for the observation window, and not immediately reverted or repaired, divided by constrained human and system resources.

Measure Outcomes by Task and Risk Class

A self-driving codebase needs a versioned scorecard. Aggregate averages hide which work is safe and valuable.

Keep model, harness, policy, repository, and test-suite versions with every observation. Compare similar tasks and report uncertainty. The AI coding ROI guide explains how to avoid turning activity metrics into productivity claims.

Build Security into the Execution Environment

An agent that can read a repository, run commands, browse the web, install dependencies, and open PRs is a privileged software principal. Its controls should be technical rather than prompt-only:

1. Ephemeral identity: issue short-lived, task-scoped credentials; never place reusable production secrets in the workspace.
2. Sandbox and egress policy: isolate filesystem, process, network, and cloud permissions; allow only required destinations.
3. Protected effects: keep branch protection, CODEOWNERS, deployment approvals, and database controls outside the agent.
4. Supply-chain controls: pin and verify dependencies, scan licenses and vulnerabilities, and review lockfile changes.
5. Untrusted-input handling: treat issues, source files, retrieved web pages, logs, and tool output as data that may contain prompt injection.
6. Provenance: retain the initiating actor, agent and model versions, policy version, commits, tool events, and external resources used.
7. Authoritative read-back: after any permitted write, query the target system rather than trusting a successful tool response.

The AI agent tool security guide covers the broader authorization and prompt-injection threat model.

Roll Out by Evidence, Not Calendar

Adoption should progress through reversible stages:

1. Baseline: measure current task flow, review, defects, and recovery for the selected lane.
2. Shadow: let the agent analyze work without changing shared state; compare its proposal with actual outcomes.
3. Sandboxed PRs: allow edits and checks, but keep merge and release human-owned.
4. Conditional automation: automate only a named low-risk class after representative evaluations pass.
5. Controlled effects: add canary release and automated rollback only after the team has tested failure and recovery.

Predeclare expansion and pause criteria. A positive pilot for documentation does not authorize dependency upgrades. A newer model does not inherit the previous model's evaluation. A changed harness, policy, test suite, or repository can invalidate the evidence.

Common Failure Modes

Optimizing for PR share

A higher agent-authored PR percentage may reflect task selection, smaller PRs, or weaker gates. Optimize for accepted outcomes and user value.

Letting the agent define and grade its own task

When one system writes the requirement, implementation, and tests, a shared misunderstanding can pass every local check. Keep independent fixtures, policies, or reviewers.

Treating artifacts as proof

A video demonstrates one path. It does not establish tenant isolation, race safety, migration integrity, or accessibility.

Scaling generation before review

Ten concurrent agents can create ten queues of uncertain work. Capacity planning must include expert review and integration.

Granting broad credentials for convenience

Long-lived tokens and unrestricted egress turn a repository instruction or compromised dependency into a larger incident.

Capturing hidden reasoning instead of operational evidence

Internal reasoning is neither a reliable audit trail nor necessary for accountability. Capture inputs, actions, policies, artifacts, and outcomes.

FAQ

Is a self-driving codebase the same as autonomous deployment?

No. Agent-authored implementation, automated merge, and automated production release are separate capabilities with different evidence and risk requirements.

Should agent PRs face stricter gates than human PRs?

Apply gates according to risk and failure profile. Agent changes may justify additional provenance, dependency, and independent-test checks, but human changes should not bypass essential security or quality controls either.

What is the best first workload?

Choose a bounded, reversible lane with clear ownership and deterministic checks. The best candidate depends on the repository; there is no universal list of "safe" tickets.

Does a high merge rate prove good quality?

No. Merge rate depends on sample selection, repository norms, task type, and human revision. Pair it with review effort, post-merge defects, rollback, maintainability, and security outcomes.

When can a team enable auto-merge?

Only for a declared task class after representative evaluations show acceptable quality and recovery, with commit-bound evidence, protected branches, a policy kill switch, and an accountable owner.

Primary Sources

• Cursor: Agents can now control their own computers - first-party architecture and "more than 30%" internal PR disclosure
• Cursor: The third era of AI software development - Michael Truell's February 26, 2026 post reports 35% of internally merged PRs
• Cursor: Scaling long-running autonomous coding - research prototype, coordination failures, planner-worker design, and review caveats
• Watanabe et al.: On the Use of Agentic Coding - 567 Claude Code pull requests across 157 open-source projects
• Agarwal et al.: AI IDEs or Autonomous Agents? - longitudinal matched-repository study and maintainability signals
• METR: Changing the Developer Productivity Experiment Design - selection and time-accounting limits
• NIST Secure Software Development Framework - secure development practices and organizational controls
• OWASP Top 10 for Agentic Applications - agent authorization, tool, and untrusted-input risks

Conclusion

A self-driving codebase is credible when it can say no, prove what happened, preserve accountable review, and recover from failure. The durable advantage is not the fraction of code written by agents. It is the quality of the eligibility rules, acceptance contracts, evidence, permissions, review system, and rollback controls around every change.

This is article 14 in the AI Agent Engineering series. Continue with From Programmer to Agent Orchestrator for the human responsibility model, or Harness Engineering in Practice for the execution layer.