The New Role of the Senior Engineer in an Autonomous Development Workflow

Part II - Governing Codebase-Wide Change: When agents can refactor an entire system, the pull request stops being the unit of control. Senior engineers govern the transformation as a program.

TL;DR - Agent capability is improving faster than the ability to verify agent output, and the gap becomes consequential when agents stop completing tickets and start changing entire systems. At repository scale, the unit of control becomes the transformation program, governed through one reusable model: transformation brief, system baseline, work plan, agent workstreams, program dashboard, cutover gate. A program can contain hundreds of individually valid pull requests and still fail as a whole, which is why the controls sit at the program level rather than inside any single diff.

Capability rose faster than confidence

Coding agents are getting much better at producing working code. A 2026 survey of agentic software development reports SWE-bench Verified performance rising from 1.96 percent to 78.4 percent between October 2023 and April 2026.

Producing code that works and producing code that can be trusted are different achievements, and they improved at different rates. Veracode reports that syntax pass rates in its generated-code benchmark rose from roughly 50 percent to more than 95 percent between 2023 and 2026, while security pass rates remained mostly between 45 and 55 percent. Results varied considerably by programming language. Veracode sells application-security tooling, so its findings should be read with that commercial context in mind.

These benchmarks measure different things. SWE-bench evaluates whether systems can resolve repository issues. Veracode evaluates whether smaller generated functions avoid specific vulnerability classes. The comparison still exposes an important gap:

Agent capability is improving faster than the ability to verify agent output.

That gap becomes much more consequential when agents stop completing individual tickets and begin changing entire systems: refactoring a monorepo, upgrading every service to a new framework, replacing a vulnerable internal library, migrating between programming languages, decomposing a monolith, standardizing authentication across applications, or removing a deprecated API from hundreds of consumers.

At that scale, reviewing one pull request at a time falls short. The unit of control becomes the transformation program.

The pull request is only one checkpoint

Traditional code review assumes a reasonably small batch of work. A human understands the requirement, writes the implementation, runs tests, and explains the change. Another human reads the diff and decides whether the code is correct, maintainable, and safe to merge.

That process becomes strained when an agent modifies dozens of files, refactors adjacent components, changes dependencies, generates its own tests, repairs compilation failures, updates configuration, and repeats the work across hundreds of modules.

The diff still answers what changed. It may not answer why this design was selected, what behavior must remain unchanged, which dependencies were examined, what assumptions the agent made, whether the acceptance tests were defined independently, what remains untested, whether the change can be rolled back, or whether the system still satisfies its global invariants.

Recent studies reinforce the need for human involvement. An analysis of 278,790 code-review conversations found that human reviewers provided contextual feedback about system behavior, testing, and knowledge transfer that agent reviewers often lacked. Agent suggestions were adopted less frequently, and many rejected suggestions were either incorrect or replaced with a different developer fix.

A separate July 2026 preprint examining 1.02 million reviewed pull requests found that some forms of agent-assisted review reduced review time. Those gains did not produce a corresponding improvement in review quality.

The practical conclusion: faster review and better review are separate outcomes, and automated review delivers the first more reliably than the second.

Avoid reviewer monoculture

The million-pull-request study surfaced another important risk: reviewer monoculture.

When one default AI reviewer is installed across a large organization, the same perspective, rules, blind spots, and failure patterns apply to almost every change. The study found that the review smell associated with repeatedly relying on the same reviewer increased substantially once LLM and agent reviewers became involved.

This recreates an old organizational problem at machine scale. Assigning one human reviewer to everything narrows perspective. Assigning one AI reviewer to everything narrows it the same way, at higher speed and with more consistency.

A stronger review model uses several narrow reviewers: security, architecture, dependencies, performance, behavior, data and privacy. Each reviewer gets its own purpose, instructions, context, and qualification process.

The objective: independent opportunities for one reviewer to catch another reviewer’s miss.

The reviewable artifact becomes an evidence pack

For agent-executed work, the primary review artifact should contain more than the code diff. It should include an evidence pack.

Intent. Original requirement, expected business or system outcome, behavior that must remain unchanged, explicit non-goals, risk classification.

Plan. Proposed design, components affected, dependency order, work that may run in parallel, migration strategy, rollback strategy.

Impact. Files and modules changed, public contracts affected, downstream consumers, data dependencies, infrastructure dependencies, security-sensitive paths.

Verification. Existing regression results, independent acceptance tests, contract and schema checks, static analysis, security scans, performance comparisons, invariant checks.

Remaining risk. Untested behavior, missing environments, unresolved assumptions, production-only dependencies, areas requiring human inspection.

The purpose of the pack is testability rather than length.

“The refactor preserves behavior” is a claim. A behavioral baseline, regression suite, contract tests, and output comparison provide evidence. “The migration does not affect downstream systems” is a claim. A dependency inventory and compatibility tests across actual consumers provide evidence.

A small 2026 pilot on software delegation contracts found that structured evidence did not improve correctness on its limited tasks. The evidence did, however, improve reviewability by producing clearer changed-file lists, known limitations, residual risks, and reviewer guidance.

The distinction matters:

Correctness asks whether the software works. Reviewability asks whether a responsible person can determine why it should be trusted.

Autonomous development needs both.

What an AI-native development lifecycle looks like

Anthropic published an operational account in July 2026 describing an internal development lifecycle in which Claude authors roughly 80 percent of merged code.

Risk-based automation. Different areas of the codebase receive different levels of automation. Some codebases continue to require strict human approval.

Multiple focused reviewers. Separate agents review different concerns rather than asking one agent to inspect everything.

Proof requirements. Automated reviewers must provide evidence for their findings rather than only assigning a severity label.

Invariant testing. The system evaluates properties such as ensuring that one user can never access another user’s data.

Shadow mode. New automated reviewers initially submit findings for human approval, and get tested against deliberately inserted defects before being trusted.

Approval sampling. Humans inspect a risk-weighted sample of automated approvals.

Auditable agent activity. Agent actions, tool calls, approvals, and agent-to-agent messages are logged.

Limited identities. An incident-response agent may read production logs and write documentation but cannot deploy a fix. Deployment requires a separate path.

The broader lesson:

Autonomous development requires controls around the entire execution loop, not only around the final code.

Repository-scale work is a transformation program

Most coding-agent workflows still assume the unit of work is a ticket. That assumption breaks during a codebase-wide refactor, migration, or rewrite. These are transformation programs, and calling them very large tasks understates what governs their success.

A transformation program is a governed sequence of agent-executed workstreams that share one target system state, a common set of invariants, an explicit dependency order, bounded permissions, evidence requirements, and a final cutover decision.

A program can contain hundreds of individually valid pull requests and still fail as a whole. Every workstream might pass its local tests while the system gradually drifts away from the intended architecture.

The program therefore needs six controls.

1. Transformation brief

The transformation brief defines the program before agents begin: target end state, scope and exclusions, behavior that must remain unchanged, architectural constraints, allowed intermediate states, completion criteria, rollback requirements, and the conditions that pause the program.

Consider a fictional enterprise modernizing a 750,000-line Java monorepo. Its transformation brief might say:

End state:
All persistence access uses the approved repository interfaces.

Must preserve:
Public APIs
Database schemas
Transaction semantics
Authorization behavior
Audit events
Deployment topology

Allowed intermediate state:
Old and new persistence paths may coexist
behind compatibility adapters.

Not allowed:
Direct schema changes
Cross-domain ownership changes
Removal of old paths before every consumer migrates

Complete when:
No production code imports the legacy persistence package.
Behavioral and performance baselines pass.
Compatibility adapters are removed.
Rollback has been rehearsed.

The brief works as the contract shared by every agent, engineer, and reviewer participating in the transformation, rather than as a prompt for any single agent.

2. System baseline

The team records current system behavior before agents begin changing it: API responses, database behavior, events emitted, critical user journeys, performance profiles, security properties, failure and recovery behavior, production exceptions, and dependency relationships.

For a rewrite or language migration, representative inputs and outputs become a golden behavior corpus. For a data migration, the baseline includes row counts, checksums, reconciliation totals, referential integrity, and recovery times. For an architectural refactor, it includes public contracts, dependency boundaries, module coupling, performance, and deployment behavior.

A 2026 C-to-Rust migration preprint describes a related approach. The system first generates architecture-aware documentation describing modules, data flow, APIs, and design rationale, then uses that model as a migration blueprint and compares the migrated system against it. The results remain early, but the transferable idea is useful:

Whole-system changes require an architectural target and a behavioral baseline. Access to source files alone leaves the agent guessing at intent.

3. Work plan

Divide a large transformation by dependencies and integration risk rather than file count.

Stage 0
Build baseline tests and compatibility interfaces.

Stage 1
Migrate independent leaf modules.

Stage 2
Migrate shared domain services.

Stage 3
Migrate high-traffic workflows.

Stage 4
Remove compatibility paths.

Stage 5
Run system-wide validation.

Each workstream defines modules owned, inputs and outputs, dependencies, files it may change, files it must not change, required tests, integration prerequisites, rollback point, evidence requirements, and a named human owner.

The result is a dependency graph rather than a flat task list.

4. Agent workstreams

Large transformations create a temptation to launch as many agents as possible. Parallelism helps only when the work is genuinely independent.

GitHub’s /fleet command describes an orchestrator that breaks an objective into work items with dependencies, runs independent work in parallel, and delays later stages until prerequisites finish.

A production transformation should also give each agent an isolated branch or worktree, assign exclusive file ownership where possible, treat shared interfaces as read-only, prevent concurrent work across the same dependency boundary, merge according to the dependency graph, rerun evidence after upstream changes, and stop a stage when integration failures exceed a threshold.

The program should optimize for safe convergence rather than maximum agent activity.

5. Evidence pack per workstream

Every workstream must return evidence before integration.

Workstream
Migrate order-processing persistence access.

Scope
12 files changed
3 legacy imports removed
1 compatibility adapter retained

Behavior
Existing order tests pass
Golden order scenarios match
Transaction rollback matches baseline

Architecture
No new direct database access
Module dependencies reduced from 14 to 9
No public API changes

Operations
P95 latency changed by +1.8%
Memory use changed by -3.1%
No new high-severity security findings

Remaining risk
One batch-processing path cannot be reproduced locally

Human decision
Approve production shadow testing for the batch path

A workstream integrates when its evidence satisfies the transformation brief. An agent reporting completion carries no weight on its own.

6. Program dashboard

Passing every workstream locally does not prove the overall transformation is succeeding. The program needs system-level measurements: percentage of modules migrated, legacy references remaining, compatibility adapters still active, dependency cycles introduced or removed, global invariant status, performance drift, security findings, integration-test health, production differences, rollbacks, human overrides, and unresolved exceptions.

This catches a failure that individual pull-request checks cannot:

Every local change appears valid while the system moves away from the intended end state.

The cutover gate

The final agent finishing its last workstream settles nothing. The transformation completes when the system reaches the target state and the accumulated evidence supports replacing the old path.

The cutover gate verifies that every required workstream is integrated, no forbidden legacy references remain, temporary compatibility layers are removed or formally retained, global invariants pass, full regression suites pass, performance remains within the approved range, security review is complete, rollback remains possible, ownership and documentation reflect the new system, and the old path can be disabled safely.

Runtime migrations may also require shadow traffic, dual reads or writes, output comparison, canary deployment, progressive traffic shifting, reconciliation windows, and delayed cleanup.

The final human decision weighs whether the total evidence supports cutover. Nobody inspects one enormous diff.

Use risk-based autonomy

Uniform review does not scale. Uniform autonomy is unsafe.

Level 0: disposable work. Prototypes, internal visualizations, generated fixtures, throwaway analysis. Controls: sandboxed execution, automated checks, no production access.

Level 1: bounded changes. Small refactors, documentation, isolated feature work, low-risk dependency maintenance. Controls: deterministic CI, automated review, independent acceptance criteria, human sampling.

Level 2: consequential work. Shared libraries, cross-service contracts, high-traffic workflows, transformation workstreams. Controls: human-approved plan, dependency analysis, invariant testing, focused human review, explicit rollback, required evidence pack.

Level 3: irreversible or regulated work. Authentication, authorization, money movement, data migrations, public protocols, production cutovers. Controls: architecture approval, independent validation, security and performance testing, staged rollout, mandatory human approval, rehearsed recovery.

The level must be assigned before execution begins.

Guidance for senior engineers

Approve the program before reviewing its code. The highest-value decisions happen before agents run: target state, invariants, work decomposition, dependency order, intermediate states, rollback strategy, evidence requirements. A weak transformation plan cannot be repaired through heroic code review at the end.

Set a blast-radius limit. Every workstream gets limits on files, modules, services, schemas, permissions, runtime, dependencies, and compute. Unexpected scope expansion triggers replanning.

Separate implementation from acceptance. The implementation agent may generate unit tests. Those tests should never be the only acceptance evidence. Combine them with existing regression tests, human-authored invariants, contract tests, golden behavior cases, independent reviewers, and runtime comparison.

Require evidence for review findings. A reviewer should identify the exact code path, the violated rule, reproduction or static evidence, expected impact, proposed correction, and stated confidence. A severity label without evidence creates noise.

Qualify automated reviewers. Before allowing an automated reviewer to approve or block changes, compare it with human decisions, seed known defects, measure precision and recall, test adversarial changes, and define promotion and demotion criteria. Trust in a reviewer is an empirical claim.

Sample automated approvals based on risk, novelty, model version, change size, weak evidence, unusual dependencies, and production impact.

Bound actions rather than relying on instructions. A prompt saying “do not deploy” is weaker than an identity that cannot deploy. Limit repository access, secret access, production access, agent-to-agent calls, merge permissions, deployment permissions, and data-modification privileges.

Pause on system drift. Stop the program when a global invariant fails, performance exceeds an approved threshold, unexpected dependencies appear, rollbacks increase, evidence exceptions accumulate, CI becomes unstable, security findings rise, or human overrides repeatedly contradict agents. A transformation should fail closed when confidence decreases.

Metrics that matter

Lines generated, agent sessions, and tasks completed measure activity. They do not prove that the engineering system improved.

DORA’s software-delivery metrics include change lead time, deployment frequency, failed-deployment recovery time, change-failure rate, and deployment rework rate. Agent-specific measurements should connect to those outcomes.

Workstream metrics. Acceptance without material rework, review time, scope violations, evidence completeness, defects before and after merge, human override rate, rollback frequency, escalation quality.

Program metrics. Percentage of target scope completed, legacy references remaining, invariant pass rate, compatibility layers remaining, behavioral divergence, performance drift, security regression, integration health, workstream rollback rate, cost per accepted workstream, time from brief to cutover.

The dangerous dashboard celebrates:

More generated code
More agent sessions
More tasks completed
Fewer human interventions

Fewer interventions can indicate improved autonomy. They can also indicate superficial review.

The new unit of senior engineering

When an agent changes one function, code review may be enough. When agents change the whole codebase, senior engineers govern intent, architecture, authority, work decomposition, evidence, integration, rollout, and cutover.

The pull request remains important. It becomes one checkpoint inside a larger control system.

The senior engineer’s value shifts from personally making the hardest change to designing the conditions under which hundreds of machine-generated changes become one safe system transformation.

Take the last major refactor or migration your organization completed. Could the team name the invariants that had to remain true, the evidence required for each workstream, the condition that would have paused the transformation, and the evidence that justified final cutover?

If those answers live mainly inside one senior engineer’s head, the control system has not been built yet.