# 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.

Page: https://flyvolo.ai/en/careers/experienced-software-engineer
Impact index: 46/100 · confidence Low confidence · assessed 2026-09-12
This is not a probability of losing a job.

## Scope

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 engineering and AI research have their own pages now; site-reliability engineering is real, genuinely different, and not covered here yet — that is a gap, not a judgement that it belongs here.

## Tasks

### Changing a system you did not write

- Direction: Still human-led
- Basis: evidenced (verified records attached)
- Why: 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.
- What this does NOT establish: 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.
- Records:
  - 2025-07-10 · Constraint · A METR randomised trial of 16 experienced open-source developers on 246 real issues found they took 19% longer with early-2025 AI tools, while believing they had been 20% faster — https://flyvolo.ai/en/changes/ev-20250710-junior-software-developer-2 (source: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)

### Reviewing what the machine wrote

- Direction: New task
- Basis: evidenced (verified records attached)
- Why: Generation shifts the bottleneck rather than removing it: more code arrives, and the reading of it lands on whoever is accountable for the branch. When GitHub moved its Copilot runtime to Rust largely with its own agents, 31.0% of the developer's 2,639 messages went to review, testing and CI; a US agency that deployed AI developer tools recorded that their output must be reviewed and approved before it enters the codebase; and in Stack Overflow's survey of 49,009 developers the most experienced report the highest distrust of what the tools produce.
- What this does NOT establish: 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.
- Records:
  - 2026-09-16 · Capability · GitHub reported that one developer, working with its Copilot agents, moved the Copilot runtime to 832,378 lines of Rust, and that 31.0% of the developer's 2,639 messages went to review, testing and CI — https://flyvolo.ai/en/changes/ev-20260916-experienced-software-engineer-4 (source: https://github.blog/ai-and-ml/generative-ai/migrating-the-github-copilot-runtime-to-rust-using-copilot/)
  - 2025-06-23 · Worker adoption · Stack Overflow's survey of 49,009 developers finds 84% using or planning to use AI tools, and the most experienced reporting the highest distrust of what it produces — https://flyvolo.ai/en/changes/ev-20250623-experienced-software-engineer-2 (source: https://survey.stackoverflow.co/2025/ai)
  - 2025-04-15 · Deployment · US Immigration and Customs Enforcement reported deploying AI developer tools on 15 April 2025, and recorded that their output must be reviewed and approved before it enters the codebase — https://flyvolo.ai/en/changes/ev-20250415-experienced-software-engineer-3 (source: https://github.com/ombegov/2025-Federal-Agency-AI-Use-Case-Inventory)

### Designing for how it fails

- Direction: Still human-led
- Basis: evidenced (verified records attached)
- Why: 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.
- What this does NOT establish: This is a judgement about the work, not a measurement. Architecture reviews are rarely published; one government department's engineering standard is an exception that states design responsibility stays with the team, but whether design decisions are handed to a machine elsewhere is mostly not observable from outside the company where it happens.
- Records:
  - 2026-03-20 · Constraint · A UK government department's engineering standard says AI cannot replace human responsibility for designs, and requires a person to approve every AI-assisted output before production — https://flyvolo.ai/en/changes/ev-20260320-experienced-software-engineer-5 (source: https://engineering.homeoffice.gov.uk/standards/use-ai)

### Deciding what ships

- Direction: Still human-led
- Basis: evidenced (verified records attached)
- Why: Machines can now carry a change much further before anyone looks: in GitHub's migration of its Copilot runtime, one developer working with its agents produced 832,378 lines of Rust in a few months, and kept deciding what was acceptable. Where the decision is written down, it is a person's: Fedora's council says AI must not be the sole or final arbiter on a contribution, and that the final accountability for accepting it rests with the human who authorizes the action, even when automation carries it out.
- What this does NOT establish: One company's account of its own project and one open-source project's rule on accepting contributions; neither shows how release decisions are made at companies generally, or how often things that passed every check still fail.
- Records:
  - 2026-09-16 · Capability · GitHub reported that one developer, working with its Copilot agents, moved the Copilot runtime to 832,378 lines of Rust, and that 31.0% of the developer's 2,639 messages went to review, testing and CI — https://flyvolo.ai/en/changes/ev-20260916-experienced-software-engineer-4 (source: https://github.blog/ai-and-ml/generative-ai/migrating-the-github-copilot-runtime-to-rust-using-copilot/)
  - 2025-10-24 · Constraint · Fedora's council forbids using AI as the sole or final arbiter on a contribution and puts the final accountability for accepting it on a person — https://flyvolo.ai/en/changes/ev-20251024-experienced-software-engineer-7 (source: https://docs.fedoraproject.org/en-US/council/policy/ai-contribution-policy/)

### Making someone else able to do it

- Direction: Still human-led
- Basis: evidenced (verified records attached)
- Why: This task becomes load-bearing for a reason outside the task itself: if fewer people arrive at the bottom, the transfer of judgement stops being a nice habit and becomes the supply line. Some engineering communities now write this down: LLVM forbids AI tools on issues labelled good first issue, keeping them as learning opportunities for new contributors, and says reviewing newcomers' changes is how the project grows its next contributors.
- What this does NOT establish: One open-source project's rule keeps work for newcomers; it says nothing about mentoring inside companies, and nothing here measures whether junior intake is falling or whether more teaching work lands on seniors.
- Records:
  - 2026-01-16 · Constraint · LLVM forbids AI tools on issues labelled "good first issue", keeping them as learning opportunities for new contributors — https://flyvolo.ai/en/changes/ev-20260116-experienced-software-engineer-6 (source: https://llvm.org/docs/AIToolPolicy.html)

### Owning the agents that write and change code

- Direction: New task
- Basis: evidenced (verified records attached)
- Why: 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: a US agency that deployed AI developer tools recorded that their output must be reviewed and approved before it enters the codebase, and in GitHub's own migration of its Copilot runtime one developer directed the agents, kept the destination architecture and spent most messages on review, testing and design challenges.
- What this does NOT establish: One agency's inventory entry and one company's account of its own project; neither shows how common this ownership is, and nothing here says it is a role anyone is paid for yet.
- Records:
  - 2026-09-16 · Capability · GitHub reported that one developer, working with its Copilot agents, moved the Copilot runtime to 832,378 lines of Rust, and that 31.0% of the developer's 2,639 messages went to review, testing and CI — https://flyvolo.ai/en/changes/ev-20260916-experienced-software-engineer-4 (source: https://github.blog/ai-and-ml/generative-ai/migrating-the-github-copilot-runtime-to-rust-using-copilot/)
  - 2025-04-15 · Deployment · US Immigration and Customs Enforcement reported deploying AI developer tools on 15 April 2025, and recorded that their output must be reviewed and approved before it enters the codebase — https://flyvolo.ai/en/changes/ev-20250415-experienced-software-engineer-3 (source: https://github.com/ombegov/2025-Federal-Agency-AI-Use-Case-Inventory)

## How to cite this

- The unit is the task, not the job title: say which tasks are changing and which are not.
- Carry each task's basis and its limits with it; an inferred judgement is not a finding.
- This page gives no number of years. Do not derive one from it.
- More: https://flyvolo.ai/llms.txt