The New Role of the Senior Engineer in an Autonomous Development Workflow
Part I: The Senior Engineer Stops Being the Fastest Coder
As agents take on more implementation work, seniority moves upstream, from writing every change to defining intent, context, and authority.
For most of software history, seniority was partly visible in the code.
The senior engineer could enter an unfamiliar system, find the real source of a problem, anticipate the consequences of a change, choose an appropriate abstraction, and debug the failure nobody else understood.
AI coding agents do not make those abilities irrelevant. They change where those abilities are applied.
When an agent can inspect a repository, propose a plan, modify multiple files, run tests, and repair failures, the senior engineer no longer needs to personally produce every implementation.
But someone still has to decide:
What should be built?
What must not change?
Which assumptions are safe?
What is the agent allowed to do?
What evidence will be required before the result is accepted?
The senior engineer’s role moves from producing every line to designing the conditions under which software can be produced safely.
That is not the end of senior engineering.
It is an evolution of it.
The old workflow centered on implementation
A simplified development workflow once looked like this:
Requirement
↓
Engineer understands the system
↓
Engineer designs the change
↓
Engineer writes the code
↓
Engineer tests the code
↓
Another engineer reviews the diff
↓
The change is mergedThe engineer writing the code accumulated context as they worked.
They discovered hidden dependencies. They clarified requirements. They noticed misleading abstractions. They adjusted the design when the repository contradicted their original assumptions.
By the time the code reached review, at least one human had followed the path that produced it.
An autonomous workflow looks different:
Intent
↓
Repository context
↓
Generated plan
↓
Task decomposition
↓
Agent execution
↓
Automated validation
↓
Human acceptanceThis workflow can produce code much faster.
It can also separate the person accountable for the change from the process that created it.
The senior engineer may receive a plan, a large diff, test results, and a generated explanation without having observed every decision made along the way.
That creates a new engineering question:
How can a human remain meaningfully accountable for work they did not personally produce?
Answering that question becomes one of the senior engineer’s most important responsibilities.
Autonomy changes the bottleneck
AI reduces the cost of producing plausible code.
It does not reduce the cost of determining whether that code expresses the correct intent.
Faster generation can expose bottlenecks elsewhere:
Requirements remain ambiguous.
Architectural constraints remain undocumented.
Tests do not capture important behavior.
Internal APIs have unclear ownership.
Production risks are poorly understood.
Reviewers cannot absorb the volume of generated changes.
Deployment systems provide slow feedback.
The 2025 DORA report on AI-assisted software development describes AI as an amplifier of an organization’s existing strengths and weaknesses.
The surrounding engineering system still matters. Gains in coding speed can be consumed by what DORA calls downstream disorder: bottlenecks in testing, security review, deployment, and organizational coordination. The report’s related guidance on platform engineering argues that organizations need reliable internal platforms and fast feedback loops if individual productivity gains are to translate into delivery performance.
The scarce resource shifts from implementation capacity to trustworthy judgment.
This first part focuses on the first three.
1. The senior engineer becomes an intent architect
Traditional tickets often leave important decisions to the person implementing them.
“Add partial refunds.”
“Modernize this service.”
“Move authentication to the shared platform.”
“Improve checkout performance.”
A human engineer usually encounters ambiguity while coding and asks questions as needed. An autonomous agent may resolve the ambiguity itself. Its decision may be technically reasonable and operationally wrong.
The senior engineer’s first responsibility is therefore to convert a request into an explicit model of intent.
That model should describe:
The desired business outcome
The boundaries of the change
Existing behavior that must remain unchanged
Architectural constraints
Security and compliance requirements
Known exceptions
Acceptable trade-offs
Success and failure criteria
The objective is not to produce a hundred-page specification. It is to remove the ambiguity that could cause a system to confidently build the wrong thing.
Consider a request to add partial refunds. A more useful intent definition would say:
Goal:
Allow an operator to refund part of a captured payment.
Must preserve:
Existing full-refund behavior and API compatibility.
Constraints:
The total refunded amount cannot exceed the captured amount.
Refund operations must remain idempotent.
Payment-provider and internal-ledger states must remain reconcilable.
Evidence required:
Refund-calculation tests.
Payment-provider integration tests.
Full-refund regression tests.
Audit-event verification.The senior engineer is not merely prompting an agent.
They are defining the contract under which implementation may proceed.
This is intent engineering.
Prompt engineering asks:
How do I get the model to produce a better response?
Intent engineering asks:
What must the system understand before it is allowed to act?
As code generation becomes cheaper, the ability to express intent precisely becomes more valuable.
2. The senior engineer becomes a context curator
Senior engineers carry a large amount of institutional knowledge.
They know:
Which module really owns a business rule
Which abstraction is misleadingly named
Which service appears independent but shares a database
Which test is unreliable
Which migration must remain backward compatible
Which team must approve a contract change
Which production behavior differs from the documentation
A coding agent can search source code and documentation. Access to information, however, is not the same as understanding its significance. The senior engineer increasingly becomes responsible for making institutional knowledge legible to machines.
That can mean improving:
Service ownership metadata
Interface and event contracts
Repository-level agent instructions
Dependency declarations
Test documentation
Operational runbooks
Development-environment setup
Examples of approved patterns
Explicitly prohibited patterns
This is already becoming a concrete part of modern coding-agent workflows. GitHub, for example, supports repository-specific custom instructions that explain how an agent should understand, build, test, and validate a project.
The specific file format will vary by tool. The broader principle will not:
Repositories increasingly need a machine-readable operating manual.
A repository that depends on oral history is difficult for autonomous agents for the same reason it is difficult for newly hired engineers.
But the consequences can occur at greater speed.
A human newcomer can ask why something is unusual. An agent may encounter the pattern repeatedly and infer the wrong rule each time.
Senior engineers must begin asking:
What important knowledge currently exists only inside the heads of experienced people?
Not all of that knowledge belongs in one giant document.
It should be placed close to where it matters:
Business rules in executable tests
Ownership in repository metadata
Architectural decisions in ADRs
Constraints in schemas and policies
Approved patterns in reference implementations
Operational expectations in runbooks
Exceptions in acceptance criteria
Code shows what was built. It rarely explains what was rejected, which constraints shaped the decision, or which trade-offs were accepted. That is why lightweight artifacts such as ADRs become more valuable in an agentic workflow. They preserve the reasoning that source code alone cannot reveal. The best-prepared codebase is not the one with the most documentation.
It is the one where important decisions are recoverable from evidence.
3. The senior engineer becomes a delegation designer
Delegating work to another engineer relies on shared professional norms.
A human engineer generally knows not to:
Delete production data
Introduce a new framework casually
Expose credentials
Rewrite unrelated modules
Bypass failing tests
Change a public contract without discussion
Agents require a more explicit model. (At least for now)
A strong delegation contract defines four things:
Task
What outcome should be produced?
Authority
What may the agent read, modify, execute, or access?
Boundaries
What must remain untouched or require approval?
Return package
What code, tests, evidence, risks, and explanations must be returned?For example:
Task:
Add retry behavior to outbound notification delivery.
Authority:
Modify the notification service and its tests.
Run the local test suite.
Update internal configuration documentation.
Boundaries:
Do not change the public API.
Do not change the database schema.
Do not add dependencies without approval.
Do not modify unrelated delivery providers.
Return package:
Implementation summary.
Changed-file list.
Retry-policy explanation.
Test evidence.
Known limitations.
Rollback instructions.This is more than a detailed prompt.
It is a control surface.
A 2026 research preprint, Human oversight of agentic systems in practice, interviewed 17 experienced developers using software agents. It identified four forms of oversight already emerging in practice:
A priori control: boundaries established before execution
Co-planning: shaping the proposed approach with the agent
Real-time monitoring: observing execution and intervening
Post hoc review: evaluating the completed work
The important finding is that oversight does not begin after the code is generated.
It begins before the agent acts. Senior engineers must decide where each form of oversight belongs. Not every task needs continuous observation. Not every agent should receive the same permissions. Not every repository is ready for asynchronous execution. Not every operation should be reversible only after deployment.
The NIST Secure Software Development Framework provides a useful baseline here. It is not written specifically as a coding-agent framework, but its emphasis on protecting software, producing well-secured releases, responding to vulnerabilities, and integrating security into the development lifecycle remains directly relevant.
Autonomy does not replace secure development controls.
It makes clear delegation, bounded permissions, traceability, and repeatable validation more important.
Seniority becomes upstream work
In this workflow, the senior engineer may write less of the final implementation. But their decisions shape more of it. They define the intent the system should preserve. They expose the context the system cannot infer reliably. They establish the limits within which the system may act. This is easy to mistake for “managing/Orchestrating the agents.”
It is more technical than that. Every boundary encodes an understanding of the architecture. Every requirement captures a business invariant. Every permission reflects a risk decision. Every escalation point expresses where automation stops being trustworthy.
The senior engineer is no longer valuable because they can type the implementation faster than everyone else. They are valuable because they can prevent the system from efficiently producing the wrong result.
In Part II: Why reviewing generated diffs will not scale, how senior engineers design evidence, and why the most important skill becomes knowing when to intervene.