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.
Every task on this page#
Endpoints and the plumbing between them
Automating✓ Evidence-backedCRUD, 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. 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 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.
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-backedQuery 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 the one nobody publishes.