LO
Backend developer
Owns the part where being wrong is expensive and invisible — the data that must stay consistent, the money that must not move twice, and the service that has to be up at 3am.
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 building services, APIs and data layers. It cuts by layer, not by seniority — the junior and experienced pages cut the other way and a senior backend engineer sits on both. Platform and site-reliability work overlaps but is answerable for different things; data pipelines have their own page.
The evidence base holds verified records for other occupations, but not one for this one yet. Until it does, the analysis below is reasoning about task structure and known technical capability — for this job in particular it is not backed by traceable sources, and we would rather say so than cite things we have not verified. An empty section here is a gap in our coverage, not a finding about the work.
What is actually changing#
The unit of analysis is the task, not the job title. A role is not replaced — its task mix shifts.
Is this your job? Say so and this page narrows to your share of it.
A job title is a bundle of tasks bought together, and no two people hold the same bundle. Nothing is sent anywhere — it stays in this browser.
Endpoints and the plumbing between them
Automating≈ Platform inferenceCRUD, validation, serialisation, calling one service from another, and the tests for all of it.
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.
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 inferenceTransactions, idempotency, retries, ordering — deciding what must never be true and making sure it never is.
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.
A judgement about the nature of the work rather than a measured one. We hold no record of teams attributing incidents to generated concurrency code, and the absence of that record is not evidence that it does not happen.
The data model, and changing it while it is in use
Still human-led≈ Platform inferenceDesigning what is stored, and migrating it later without stopping the service or losing anything.
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.
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 inferenceAuthorisation, tenancy boundaries, what leaks through an error message, and what an internal endpoint exposes if someone finds it.
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.
We hold no verified record about generated code and security defects specifically, so this rests on the structure of the problem rather than on a measurement. 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≈ Platform inferenceQuery plans, caching, the bill, and the request that got slow because something upstream changed.
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.
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 inferenceOn-call: deciding under time pressure what to roll back, what to degrade, and what to tell people while it is still broken.
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.
This says nothing about whether on-call load is rising or falling, which is the question most engineers actually care about and which we have no evidence on.
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.
It starts slightly above the frontend line — code completion and query tooling were already ordinary before 2022 — and ends well below it, and the gap between the two is the point of having both pages. The climb through 2024 is whole-service drafting becoming real. The early flattening is not difficulty: it is that being wrong here is expensive and often invisible for months, so more of the work is accountability — what must never happen when two requests arrive together, what an error message may reveal, what a migration does to data already written. A more capable model does not reach a position of accountability.
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#
No verified events recorded yet.
This section will fill from the monitoring pipeline as events are collected, de-duplicated, graded and linked to the tasks above. An empty list here means we have not verified anything — it does not mean nothing is happening.
"We found no news" is not the same as "you are safe."
What this means for you#
The visible half of this job — endpoints and plumbing — is the exposed half, and it is what you would have been hired to do. The parts that hold are about what must never happen, and you learn those by being present when something did happen. Get near an on-call rotation earlier than feels comfortable.
Your position is stronger than the frontend page's on the most exposed task, and the reason is not that the work is harder — it is that being wrong is expensive and invisible, so accountability is concentrated. Watch for the failure mode that creates: reviewing generated changes to systems where a mistake is silent for months.
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.
Go where a mistake is expensive
Payments, ledgers, identity, anything with a regulator — domains where an unattended change is not allowed, so review and accountability are funded rather than assumed.
Slower, more process, and depth takes years. It is a different kind of engineering, not the same work in a safer room.
Find one invariant in your system that must never be violated, and check whether anything actually enforces it or whether everyone just avoids breaking it.
Own the boundary the agents may cross
Somebody has to decide what an automated change may touch in a service where a mistake is silent. In most teams nobody has been given that, which is why it appears in incident reviews rather than job descriptions.
Accountability without a title, for now. Take it in writing or it will be assigned to you the first time something breaks.
Write down what an automated change can currently merge and deploy in your service with no human in the path. Circulate it and see who is surprised.
Move to data or platform work
The reasoning about consistency, failure and cost transfers directly, and both are places where the same judgement is applied to a wider surface.
Both pull you further from the product and from the people who use it, which some engineers find is the cost that matters.
Trace one number on a company dashboard back to the table it comes from, and count how many transformations it passed through.
Common questions#
The parts are moving at different speeds, so a single number would hide the thing you need. Writing endpoints is already largely machine work. Deciding what must never happen when two requests arrive together, or what an error message is allowed to reveal, has not moved, because those are answerable positions rather than typing. A signal you can check: when something broke last quarter, was the hard part finding it or deciding what to do about it.
On its most visible task it is less exposed, and the reason is worth understanding rather than taking as comfort: backend correctness is often invisible and expensive to get wrong, so more of the work is accountability. That is a structural difference, not a difficulty ranking, and it can change — the endpoints half of this job is exposed on exactly the same terms as the frontend half.
For interviews, that has not changed yet. For the work, the honest split is that recalling an algorithm matters less than it did, while reasoning about failure matters more — knowing what a retry does to a system that is already struggling is the same skill system-design questions are trying to test, applied to something real. Learn it from your own incidents rather than from a list.
It can already draft one, and that is not the constraint. The constraint is that somebody has to guarantee what it must never do, migrate its data years later without losing anything, and be awake when it fails. Those are positions of accountability, and accountability has not become cheaper — in regulated domains it has become more explicitly required.
Method and sources#
- Assessment date
- 2026-09-12
- Basis of the task judgements
- 0 evidence-backed · 6 platform inference · 0 not enough evidence
- Verified events
- 0