VOLOVLOAutomation risk & transition, task by task
AskOccupationsMajorsBusinessFoundersChangesNotesMethod
Search occupations, majors…
EN
  • English
  • 简体中文
  • 日本語
  • Español
  • Português
  • Français
VLO
VOLO

Understanding how automation changes work — task by task, with the evidence shown and the uncertainty admitted.

AskOccupationsMajorsBusinessFoundersChangesNotesMethodAboutRole diagnosisPrivacyTerms
© 2026 VOLO
Occupations
All occupations
AI / software
Translator / InterpreterBank tellerCopywriterCustomer service representativeAdministrative assistantSoftware tester / QA engineerGraphic designerParalegalVideo editorAccountant / BookkeeperMarketing specialistFrontend developerData analystInsurance claims handlerTechnical writer / documentation engineerJunior software developerHR / recruiterLoan officer / credit officerFinancial analystProcurement / supply chain specialistJournalistSales / account managerReal estate agentIT support specialist / helpdeskAuditorManagement consultantBackend developerAI researcherProduct / UX designerBusiness systems ownerE-commerce operations specialistRadiologistData engineerLawyerMedical assistant / clinic assistantMachine learning engineerExperienced software engineerDevOps / platform / SRE engineerProduct managerPharmacistPartnerships / channel managerSecurity analyst (SOC)Compliance officerArchitectFirst-line manager / team supervisorCounsellor / therapistRetail salesperson / shop assistantSecurity guardSchool teacherGeneral practitioner / primary care doctorWaiter / restaurant serverAuto mechanic / vehicle technicianPhysiotherapist / rehabilitation therapistConstruction workerRegistered nurseCare worker / nursing assistantAI implementation lead
RPA / self-service
Government service clerkOperations coordinatorMetro train driverReceptionist / front desk
Robotics
Retail cashier / shop assistantContainer port workerWarehouse workerAssembly line workerMedical laboratory technicianChef / cookCleaner / janitorElectrician
Autonomous driving
Ride-hail / taxi driverTruck driverDelivery rider / courier
Majors
All majorsEnglish / Foreign languagesComputer scienceAccountingPsychologyJournalism / CommunicationFinanceLawVisual communication designMarketingNursingBusiness administrationEducation and teacher trainingArchitecturePublic administrationMedicineHospitality and tourism managementEconomicsInformation systems
Guides
Ask VOLOFor businessFor foundersRecent changesNotesRole diagnosisMethod & evidenceAboutFollow an occupationSearch
You are reading as:I have a jobI am studyingI run a companyI am building something
On this pageChanging a system you did not writeReviewing what the machine wroteDesigning for how it failsDeciding what shipsMaking someone else able to do itOwning the agents that write and change code
Occupations›Experienced software engineer›Tasks, one by one

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.

Tasks
6
With evidence
3/6
Assessed
2026-09-12
Still human-led×4New task×2

Every task on this page#

Changing a system you did not write

Still human-led✓ Evidence-backed

Making a change inside a large, long-lived codebase where the constraints are undocumented and live in what previous decisions already committed to.

AI / software
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 mean

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-backed

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

AI / software
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. 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.

What this does NOT mean

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 inference

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

AI / software
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 mean

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 inference

Being the person who says this goes out now, with this known risk, and answers for it afterwards.

AI / softwareRPA / self-service
Why

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.

What this does NOT mean

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 inference

Review that teaches, pairing, and the deliberate handing over of context — the mechanism by which a team keeps having people who can judge.

AI / software
Why

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.

What this does NOT mean

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-backed

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

AI / softwareRPA / self-service
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, 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.

What this does NOT mean

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.

← Back to Experienced software engineer