Promoted to pull request reviewer?
When agents write code, the work shifts toward defining tasks, reviewing changes and taking responsibility for the result.
Describe a ticket, send an agent to work and review a pull request later: software development can now follow this pattern. GitHub explicitly describes this workflow for its cloud agent. The resulting changes still need review and validation.
The joke about being “promoted to PR reviewer” carries a serious point. Delegating implementation means spending more time clarifying tasks, challenging assumptions and judging results. This is one possible shift in the work, rather than a description of every developer’s job.
Defining the task becomes development work
“Build a login” leaves plenty undecided. Who needs access? Which existing flows must keep working? What would demonstrate that the change is finished?
A useful brief describes behaviour, boundaries and acceptance criteria. Product understanding increasingly shows up in this preparation. Unclear requirements do not disappear with an agent; they may simply become code faster.
More code makes judgement more important
A review goes beyond a passing test suite. Does the change fit the architecture? Do the tests check the intended behaviour? Are new dependencies or side effects justified? Answering those questions still requires technical understanding.
A second agent can help review a change. The decision about whether that result belongs in the product should retain a clear owner.
Coordinating agents is work in its own right
Multiple agents can tackle separate tasks. As a working model, this needs defined responsibilities, clear handovers and a shared understanding of the current state. Otherwise, time saved in implementation can become integration work.
The interesting question is how more generated code becomes better software. Leading agents means shaping tasks and quality standards so that their results fit together and can be understood.