LO
Experienced software engineer
Changes systems they did not write, decides what may go out, and is answerable for how it fails — the part of software work that is mostly judgement about a specific codebase rather than typing.
This is not a probability of losing your job. It combines how much of the role's task load is exposed to automation with how far adoption has actually gone — useful for comparing occupations on one consistent basis, and for nothing else.
Written for engineers with several years in a maintained production codebase — the people who review, design and decide what ships. It cuts by seniority; frontend, backend and data engineering cut by layer and have their own pages, so a senior frontend engineer sits on two and they answer different questions. Entry-level work is assessed separately; dedicated test engineering has its own page. Machine-learning and site-reliability engineering are real and genuinely different, and this site does not cover them yet — that is a gap, not a judgement that they belong here.
What is actually changing#
The unit of analysis is the task, not the job title. A role is not replaced — its task mix shifts.
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≈ Platform inferenceReading 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: we hold no record of design decisions being automated or resisted, and the absence of evidence here is the ordinary kind — nobody publishes their architecture reviews.
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≈ Platform inferenceSetting 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.
Which technologies matter here#
Four separate signals. They are deliberately not added together — a job exposed to two technologies is not twice as exposed.
How it got here#
The index is not a static number. This is where it would have sat at each capability checkpoint since ChatGPT — reconstructed, and labelled as such.
● 1 verified event for this occupation, plotted at the date it happened — the parts of the line near a marker are anchored to something checkable.
A higher baseline than most pages here, because code completion and refactoring tools were already ordinary before 2022 — this occupation started the period partly automated and knew it. The 2023-2025 climb is generation reaching the point where a whole change can be drafted rather than a line completed. It flattens early and low compared with the junior curve, and the flattening is the interesting part: the remaining tasks are judgement about one specific system and accountability for what goes out, neither of which a more capable model reaches. Read the gap between this line and the junior one as the shape of the problem rather than as reassurance — the same forces that hold this curve down are the ones pushing that one up, and they are connected by the route between them.
A flat line is not a forecast of safety. It says which tasks automation has reached so far — the occupations that moved least here are the ones where the constraint is physical or regulatory, and both of those can change.
Recent changes#
Experienced maintainers on large, mature repositories they know well (about 5 years each); tools were mainly Cursor Pro with Claude 3.5/3.7 Sonnet. The authors explicitly do not claim the result generalises to most developers or to greenfield or junior work.
Failure, rollback, regulation or cost is suppressing adoption. Can lower an assessment or widen its uncertainty.
What this means for you#
You are not this page yet, and the route to it is the thing under pressure — read the junior page first. What matters most here is that the capability this occupation sells is judgement about one specific system, and that is acquired by being inside one, not by using better tools.
The measured finding on this page is that the tools did not speed you up on your own codebase, and that you may have believed otherwise. Treat that as a reason to measure your own work rather than as reassurance: the trial is small and a year old, and the part of the job that is growing is not typing — it is reviewing what arrives, and answering for what an agent was allowed to do.
Your options#
Four directions, each with its real constraints and one thing you can test this week. Continuing as you are is a legitimate choice — it just has to be a chosen one.
Become the person who is trusted to say no
As generated changes multiply, the constraint moves to whoever can refuse one with a reason that holds. That authority is earned by being right in public, repeatedly, about a specific system.
Requires staying in one codebase long enough to be right about it, which cuts against moving for a raise every eighteen months.
Take one generated change you approved this month and re-read it looking for what you missed. Write down whether you would still approve it, and why.
Take ownership of what the agents may do
Somebody has to decide what an automated change is allowed to touch and where it enters. In most teams nobody has been given that, which is why it shows up in incident write-ups rather than job descriptions.
It is accountability without a title, at least for now. Take it deliberately and in writing, or it will be assigned to you the first time something breaks.
Write one page on what automated changes may currently do in your repository without a human in the path. Circulate it and see who disagrees about what is already permitted.
Move to where correctness is expensive by law
Payments, safety-critical systems, regulated data — places where an unattended change is not permitted, so the reviewing and the accountability are funded rather than assumed.
Slower work, more process, and the depth takes years. It is a different kind of engineering, not the same engineering in a safer room.
Find one regulated requirement that applies to a system near you and read what it actually forbids. Most engineers have never read one directly.
Move to the side of the problem
Solutions engineering, technical product, developer experience — roles where the value is understanding both a system and what someone needs from it, and where the writing was never the scarce part.
Requires treating communication as a first-class skill, and accepting that you will stop being the person who knows the code best.
Sit with someone using a system you built and say nothing for twenty minutes. Write down every place they hesitated.
Common questions#
The one randomised trial this site holds found the opposite, and the detail worth carrying is the gap between measurement and perception: sixteen experienced open-source maintainers working on real issues in repositories they knew took 19% longer with 2025-era tools, while estimating they had been 20% faster. The authors do not claim this describes most developers or new projects, and it is a year old. What it does establish is that the speed-up is not automatic on a mature codebase, and that asking yourself does not settle it.
Nobody can answer that with a number, and the confident answers on both sides are selling something. A more useful question is which part of the job, because the parts are moving at different speeds: writing routine code is already largely done by machine, reviewing what it produced has grown into a job of its own, and deciding what ships with a known risk has not moved because it is accountability rather than capability. Watch a signal you can check yourself instead — how much of your week is now reading code you did not write.
It is differently exposed, not safer, and the two are connected in a way worth seeing. Employment among the most AI-exposed 22-to-25-year-olds fell about 11% between late 2022 and mid-2026, and several organisations that cut junior intake said publicly that they had removed the path by which people become senior. A profession that stops making seniors has a supply problem later, not a safety guarantee now — and in the meantime the teaching work that used to be spread across a team lands on fewer people.
This site cannot answer that yet, and saying so is more useful than guessing. Those three have genuinely different exposure, but we hold no evidence that separates them — the records here distinguish by seniority, not by stack, because that is how the studies were designed. Treat any confident ranking of frontend against backend as someone's impression. What the evidence does support is choosing by how expensive being wrong is in your domain, which cuts across all three.
Reviewing code you did not write, and being able to say why you rejected something. That skill was always present in the job and was never the thing anyone was hired or assessed on; it is now the bottleneck, because generation moved the work from producing to judging. It is also the capability that makes you the person who can be trusted to say no, which is the part of this job with no substitute in sight.
Method and sources#
- Assessment date
- 2026-09-12
- Basis of the task judgements
- 1 evidence-backed · 5 platform inference · 0 not enough evidence
- Verified events
- 1