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 tellerCopywriterContent moderatorCustomer 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 pageEndpoints and the plumbing between themKeeping it correct when things happen at onceThe data model, and changing it while it is in useWho is allowed to see whatWhat it costs and how fast it isBeing the one the pager wakes
Occupations›Backend developer›Tasks, one by one

Backend developer — 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
2/6
Assessed
2026-09-12
Automating×1Being augmented×1Still human-led×4

Every task on this page#

Endpoints and the plumbing between them

Automating✓ Evidence-backed

CRUD, validation, serialisation, calling one service from another, and the tests for all of it.

AI / software
Why

Well-specified, heavily represented in training data, and verifiable by running it — the same three properties that make any task a strong case for generation. It is also a large share of what backend work looks like from outside.

What this does NOT mean

Generating an endpoint is not the same as deciding it should exist, what it must guarantee, or what happens when it is called twice. The typing was rarely the expensive part of this work.

Keeping it correct when things happen at once

Still human-led≈ Platform inference

Transactions, idempotency, retries, ordering — deciding what must never be true and making sure it never is.

AI / software
Why

These bugs do not appear in tests and often do not appear for months. Reasoning about them requires holding a model of what else is running and what a partial failure leaves behind, and the correct answer depends on guarantees the business has made rather than on the code in front of you.

What this does NOT mean

A judgement about the nature of the work rather than a measured one. Incidents are almost never attributed publicly to generated concurrency code, and that silence is not evidence that it does not happen — a post-incident review naming a cause that specific is unusual in any company.

The data model, and changing it while it is in use

Still human-led≈ Platform inference

Designing what is stored, and migrating it later without stopping the service or losing anything.

AI / software
Why

Early schema decisions become expensive years later in ways no tool can see from the current code, because the cost lives in what was already written into the data. A migration is also irreversible in practice, which puts it in the category where somebody must be accountable rather than assisted.

What this does NOT mean

Says nothing about how often tools now draft migrations, which they do routinely. The claim is about who decides and answers for it, not about who types it.

Who is allowed to see what

Still human-led≈ Platform inference

Authorisation, tenancy boundaries, what leaks through an error message, and what an internal endpoint exposes if someone finds it.

AI / softwareRPA / self-service
Why

Generation optimises for the request that was described, and an authorisation bug is precisely the case nobody described. This is also the area where a confident, plausible, wrong answer is most dangerous, because it looks exactly like a correct one until someone exploits it.

What this does NOT mean

This rests on the structure of the problem rather than on a measurement, and what would settle it is a defect study that separates generated code from hand-written code in the same codebase. Regulated environments already require human sign-off here, which may be doing more of the work than the difficulty is.

What it costs and how fast it is

Being augmented✓ Evidence-backed

Query plans, caching, the bill, and the request that got slow because something upstream changed.

AI / software
Why

Tools are genuinely strong at spotting the pathological query and suggesting the index. They are weak at the trade-off — spending money to be faster is a business decision, and knowing which request matters requires knowing what the product is for.

What this does NOT mean

Nothing here measures how much of this is now tool-driven in practice, and the answer differs enormously between a team with an observability budget and one without.

Being the one the pager wakes

Still human-led≈ Platform inference

On-call: deciding under time pressure what to roll back, what to degrade, and what to tell people while it is still broken.

AI / softwareRPA / self-service
Why

Diagnosis is increasingly assisted and that genuinely helps. The decision is not: choosing to accept a known loss in order to restore service is a judgement with consequences somebody has to own, and it is made with incomplete information by design.

What this does NOT mean

This says nothing about whether on-call load is rising or falling, which is the question most engineers actually care about and the one nobody publishes.

← Back to Backend developer