Experienced software engineer — tasks, one by one
The unit of analysis is the task, not the job title. Each one below carries its direction, whether the judgement rests on evidence or on platform inference, the reasoning, and what it does not establish.
Every task on this page#
Changing a system you did not write
Still human-led✓ Evidence-backedMaking a change inside a large, long-lived codebase where the constraints are undocumented and live in what previous decisions already committed to.
This is the task the strongest evidence on this page is about, and the evidence points the unexpected way: in a randomised trial on real issues in repositories the participants maintained, experienced developers using 2025-era AI tools took 19% longer, while believing they had been 20% faster. The context a change needs is held in a person's model of that specific system, and supplying it to a tool costs more than it saves.
One trial, sixteen developers, mature repositories they knew well — the authors say plainly it does not describe most developers or new projects. It says nothing about how the same tools perform a year later, and a slowdown measured once is not a permanent property of the tools.
Reviewing what the machine wrote
New task✓ Evidence-backedReading code you did not write and were not there for, and deciding whether it is right — at a volume that rises as generation gets cheaper.
Generation shifts the bottleneck rather than removing it: more code arrives, and the reading of it lands on whoever is accountable for the branch. Alphabet has said more than a quarter of new code at Google is AI-generated and then reviewed and accepted by engineers, which is a description of where the work moved rather than of work disappearing.
A share of code generated says nothing about how long the reviewing takes, whether it is done well, or whether the total number of engineers changed. Reviewing volume rising is also not automatically good work — it is the part of the job most easily done badly under time pressure.
Designing for how it fails
Still human-led≈ Platform inferenceChoosing a structure, and choosing which failure modes to accept — knowing what happens at 3am when a dependency is down and half the requests are already in flight.
A model can propose an architecture and argue for it fluently. What it cannot do is carry the consequence of the trade-off, and the trade-offs here are not technical preferences — they are bets about which failure the organisation can survive, which depends on facts about the organisation rather than the code.
This is a judgement about the work, not a measurement, and the absence of evidence is the ordinary kind rather than a finding: architecture reviews are not published, so whether design decisions are being handed to a machine or held back from one is not observable from outside the company where it happens.
Deciding what ships
Still human-led≈ Platform inferenceBeing the person who says this goes out now, with this known risk, and answers for it afterwards.
The evidence on the testing side of this boundary is that automated checks are not catching enough: a survey of two hundred senior engineers reports 43% of AI-generated changes still needing manual debugging in production after passing QA and staging. Whether or not the percentage holds — the survey was published by a company selling debugging tools — the shape of the claim matches the incidents that are independently reported.
A self-reported survey from an interested party is weak evidence for a number and better evidence for a direction. It does not establish that release decisions are becoming harder overall, and it is about large enterprise software rather than all software.
Making someone else able to do it
Still human-led≈ Platform inferenceReview that teaches, pairing, and the deliberate handing over of context — the mechanism by which a team keeps having people who can judge.
This task is becoming load-bearing for a reason outside the task itself. Employment among 22-to-25-year-olds in the most AI-exposed roles fell about 11% from late 2022 to mid-2026 while less-exposed groups did not; several organisations that cut junior intake said publicly that they had removed the path by which people become senior. If fewer people arrive at the bottom, the transfer of judgement stops being a nice habit and becomes the supply line.
Payroll microdata shows an employment decline; it does not show that mentoring increased, or that anyone chose to invest in it. The link between a thinner junior intake and more teaching work falling on seniors is a reading of two facts, not a measured one.
Owning the agents that write and change code
New task✓ Evidence-backedSetting what an automated coding agent may do unattended, what it must ask about, and where its output enters the branch — then being the name attached to that setting.
This work did not exist in 2022 and nobody is assigned to it by default. It appears wherever generation is allowed to touch a repository, and the incidents that follow tend to be traced not to the model but to who was allowed to merge what — the Amazon outages of March 2026 were attributed to an unapproved AI-assisted code change and followed by a ninety-day code-safety remediation across 335 systems.
One company's incident and remediation is not a description of the industry, and a remediation programme is evidence that something went wrong rather than evidence about how common it is. Nothing here says this ownership is a role anyone is paid for yet.