A senior engineer opens a pull request containing 2,400 lines of plausible code, twelve passing tests and a confident summary from an agent. The change touches a customer workflow she did not design, a service she has not worked on recently and an integration maintained by another team. Her organisation calls this leverage. At that moment, it feels more like a new kind of liability.
The awkward truth is that coding agents do not remove the need for senior engineering. They make senior judgement more consequential. As implementation becomes cheaper, the scarce work shifts towards deciding what should be built, setting the boundaries within which it may be built, assessing whether the evidence is enough, and carrying responsibility when the change meets production.
That is a job redesign, not a productivity add-on. Leaders who treat agents as a way to replace senior effort with output will create an approval queue staffed by exhausted people. Leaders who redesign the role can give experienced engineers more leverage while keeping technical accountability close to the work.
DORA’s 2025 research describes AI as an amplifier of an organisation’s existing strengths and weaknesses. That conclusion matters for career design. A team with clear interfaces, reliable tests and healthy production feedback gives senior engineers a system they can shape. A team with ambiguous work and fragile releases gives them an expanding pile of generated uncertainty. DORA
Seniority now begins before the prompt
The least valuable use of a senior engineer is asking them to type faster than an agent. Their value is in making the work legible before implementation begins.
A good agent task is a compact engineering contract. It states the user or operational outcome, the boundary of the change, the constraints that must hold, the systems and data it may touch, the tests that demonstrate the result, and the person who will accept it in production. An agent can then work within a defined problem. A reviewer can assess a stated intention rather than infer one from a diff.
This sounds procedural until one sees the alternative. “Add an export button” can conceal tenancy rules, retention obligations, rate limits, accessibility expectations, permissions, audit events and a customer support burden. An agent may produce a sensible local implementation while missing one of those obligations. The senior engineer’s contribution is to surface those decisions early, when changing direction is cheap.
That makes design artefacts more important, not less. Architectural decision records, API contracts, threat models, ownership maps, service-level objectives and examples of expected behaviour become working context for people and agents alike. They should be versioned, discoverable and current. A wiki full of old opinions is not an engineering memory; it is a source of confident mistakes.
Anthropic’s work on long-running coding agents reaches a similar conclusion in a different setting. Its engineering team found that agents need an initial environment, an explicit feature list, incremental tasks and clear progress artefacts to work reliably across sessions. The lesson for an enterprise team is straightforward: structure is not overhead when it prevents an autonomous worker from guessing. Anthropic
Move from reviewer of code to designer of assurance
Review is changing shape. A senior engineer cannot responsibly read every generated line with the same depth that was practical when changes were smaller and authors carried the implementation in their heads. Nor should they accept a green build as a substitute for understanding.
The answer is not to lower the bar. It is to redesign assurance around evidence and risk.
For a bounded, low-risk change, an engineer may review the task contract, changed files, tests, static-analysis result and rollback path. For an identity rule, payment path, data export or production configuration change, that evidence is insufficient. The review needs a domain owner, security and privacy controls where appropriate, integration evidence, a deployment plan and a clear decision on who can stop the release.
The senior engineer should define that graduated standard with the team. They decide which risks demand human-authored tests, which changes need independent review, which policy checks belong in continuous integration, and which classes of work an agent must never execute without named approval. This is engineering judgement made repeatable, rather than a personal act of heroism at the end of a sprint.
NIST’s Secure Software Development Framework is useful here because it treats secure delivery as practices embedded across the lifecycle, rather than a final security inspection. Agent-assisted work should enter the same lifecycle: defined requirements, protected environments, automated checks, review and response to vulnerabilities. An “AI-generated” label is not a new delivery lane. NIST SSDF
A well-designed pull request makes the remaining human judgement visible. It should answer five questions: what outcome was intended; what boundaries and internal sources shaped the implementation; what was changed; what evidence was run; and what uncertainty remains. Full prompt transcripts rarely help. A concise, accountable explanation does.
This also changes what teams measure. Lines generated, agent sessions and pull requests opened are activity measures. Senior engineers should watch the quality of the system they are supervising: review latency, change size, rework after merge, defects escaped into production, rollback time, policy exceptions and the share of work that reaches a stable customer outcome. If volume rises while any of those deteriorates, the agent has exposed a constraint rather than created capacity.
Keep ownership with the person who can act
There is a dangerous story emerging around AI work: the agent wrote the code, so the human merely approved it. That story dissolves accountability at exactly the point an enterprise needs more of it.
Every production change needs a human technical owner who can explain its intent, its assumptions and its operational consequences. That does not mean the owner must have hand-written every line. It means they have accepted the evidence, understand the relevant failure modes and can participate in recovery. The product owner remains accountable for the outcome and risk tolerance. The platform team remains accountable for the paved road, access controls and reliable tooling. Security sets and tests control expectations. Responsibility is shared, but it is never anonymous.
GitHub’s documentation describes its cloud coding agent as able to research a repository, create a plan, make changes on a branch and support a pull-request workflow. It also exposes lifecycle metrics such as pull requests created, merged and time to merge. Those are useful operating signals. They are not proof that a feature meets a business rule or can be safely operated after release. GitHub
The ownership model must survive an incident. If an agent-assisted release causes incorrect notifications, corrupts a workflow or creates an access-control gap, the team needs a known route to contain it: disable the feature, revoke the agent’s credentials if necessary, roll back a small change and inspect the evidence. Senior engineers should rehearse this for the highest-risk paths, just as they would any other production change.
I have seen teams turn their most trusted engineers into permanent interpreters of machine-produced work. It feels prudent initially. It is not sustainable. The senior people become the queue, junior engineers lose the chance to develop judgement, and every unfamiliar change demands a rescue mission. A better organisation uses senior expertise to design guardrails, coach reviewers and improve the feedback system so that more people can make sound decisions.
Redesign the team, not just the individual role
The development path for junior and mid-level engineers must change as well. They still need to learn to read code, reason about failure, understand domains and debug systems. Giving them an agent without that foundation can hide the very learning that produces capable engineers. Banning agents is equally unhelpful. The answer is deliberate practice with bounded responsibility.
Pair an engineer with an agent on a small, observable change. Ask the engineer to write or refine the acceptance criteria, identify the relevant contract, challenge the agent’s assumptions, run the evidence and explain the result in review. Rotate the senior engineer through coaching and design sessions rather than assigning them every difficult pull request. Over time, expand authority only when the engineer and the delivery system have earned it.
Platform teams have a role too. They should offer the trusted context, approved tools, least-privilege identities, policy checks and telemetry that make responsible work the easiest route. But they should avoid turning agent use into a central ticket queue. The product team is closest to the business decision; it must retain ownership of its evaluation criteria, release outcome and production behaviour.
Start with one workflow where the failure path is understood and feedback is fast: adding test coverage to a bounded service, repairing a known static-analysis finding, or implementing a well-specified internal integration. Establish a baseline. Then compare the agent-assisted route with ordinary delivery: did the team reduce lead time without worse review delay, rework or change failure? What evidence caught mistakes? Which judgement still required a senior engineer?
Use the answers to change the system. Reduce task scope where reviews are too hard. Improve source context where agents make repeatable mistakes. Add an automated policy check where human reviewers keep catching the same defect. Assign a domain owner where semantic errors recur. This is how an organisation turns individual expertise into a safer delivery capability.
The leadership test is blunt. Before celebrating more code from an agent, ask whether a senior engineer can point to the design contract, the assurance evidence and the person who will own the result at 02:00. If all three are clear, AI is increasing engineering leverage. If they are vague, the organisation has simply accelerated work it does not yet know how to own.
Sources
- DORA, State of AI-assisted Software Development 2025, 2025.
- Anthropic, Effective harnesses for long-running agents, 2025.
- National Institute of Standards and Technology, SP 800-218: Secure Software Development Framework, 2022.
- GitHub Docs, About GitHub Copilot cloud agent, accessed before the scheduled publication date.