Backend developer

Guidance from the UK's national cyber security agency, written by one of its principal security architects, placing AI-assisted development on a spectrum from fully generated to manual. It advises sliding towards manual when building authentication or authorisation logic, processing sensitive personal data, handling secrets, tokens or credentials, or where the consequences of a security flaw would be significant. It is advice, not a binding rule, and it does not forbid using AI for security code; it gives no figures on how developers actually work.

Failure, rollback, regulation or cost is suppressing adoption. Can lower an assessment or widen its uncertainty.

The same census: 20 fixed questions put to every reporting agency under a statutory duty, each answered Y or N with the product named and the licences given as a band. Generating code using AI is Y at 31 of 45, seventh of the 20. What makes this row worth more than its count is the product column, because the tools named are ones that did not exist three years ago: GitHub Copilot at Agriculture, Veterans Affairs, the SEC and a dozen more, Claude Code at the Interior, Poolside at Homeland Security and Labor, Codex at the Office of Personnel Management, Amazon Q Developer at Health and Human Services. Compare the travel-booking row in the same file, where most of the Y answers name SAP Concur: on that question agencies were largely pointing at a platform they already had, and on this one they were not. Three limits. A band of 10,000-50,000 at Energy or the Environmental Protection Agency is an enterprise licence that also answers other rows in this file, so it is not a count of people writing code with it. A Y is the employer reporting that it has the tool, not a measurement of how much code the tool writes or how much of that code is kept. And the question says code without distinguishing backend from frontend, or an engineer of ten years from one of ten months; this record attaches here because writing routine service code is what this task is, not because the inventory says so.

An employer has put it into production. Can move the baseline — weighted by scale and how similar the setting is.

A peer-reviewed benchmark of 392 backend tasks, each a set of endpoints to implement from a specification, with functional tests and end-to-end security exploits, including improper access control and incorrect authorisation. The best model on correctness reached 62%; on average around half of the correct programs each model produced could be exploited; and the best model on correct-and-secure code reached 35%. These are 2025 models writing whole backends from a specification, not changes inside an existing codebase, and some authors work for a company building AI code agents.

Failure, rollback, regulation or cost is suppressing adoption. Can lower an assessment or widen its uncertainty.

A peer-reviewed paper by Uber engineers about a tool running in Uber's own developer workflow. Over 18 months it identified 404 reproducible data races in Uber's Go codebase, produced fixes for 224 (55%), and developers approved 193 of those (86%) in code review; rejected fixes included ones judged incorrect despite passing initial tests. Uber does not sell the tool. It covers low-level data races in one language and one codebase, not transactions, idempotency, retries or ordering across services, and every fix went through a person's review.

An employer has put it into production. Can move the baseline — weighted by scale and how similar the setting is.

Google engineers describing their own use of language models for large internal code migrations. In one case study, IDs in the Ads code base (500+ million lines) had to move from 32 to 64 bits to avoid negative rollover scenarios that could cause outages; 80% of the code modifications in the landed changes were fully AI-authored, in most cases a person had to revert at least some of the model's changes, and engineers estimated the total time was cut by 50%. The paper says code reviews and change rollouts still require a human operator. Google sells the models it used. This is a type change in code across a codebase, not a live database schema migration.

An employer has put it into production. Can move the baseline — weighted by scale and how similar the setting is.

One large technology company, company-reported, with no definition of how 'generated' is measured (autocomplete versus whole functions). The figure covers all new code at Google without saying what kind; it attaches to this task because writing routine service code — handlers, validation, calls between services and their tests — is what this task is, not because the statement singles out backend work. It says nothing about hiring, and the review step stayed with engineers.

An employer has put it into production. Can move the baseline — weighted by scale and how similar the setting is.

Amazon's own internal estimate about Amazon's own engineering, published by the company that sells the tool - the party doing the work, the party measuring it and the party selling it are the same, which is stated here because it cannot be checked from outside. The company also publishes its method: time saved was estimated from the number of Java dependencies migrated, assuming a day or more of developer time per dependency manually. Note what the migration is: a language-version upgrade has a compiler and an existing test suite as its oracle, so success is machine-checkable at every step - the most favourable possible shape for this kind of automation and not a general result about backend work. And note what is claimed and what is not: 4,500 years is work not done, over a thousand developers, with no statement anywhere that any of them left or that a role was removed.

An employer has put it into production. Can move the baseline — weighted by scale and how similar the setting is.

A peer-reviewed paper, mostly by Microsoft authors, on a tool for on-call engineers handling cloud incidents. Its diagnostic information collection component has been deployed across over 30 teams within Microsoft for over four years; a root-cause prediction component using a language model, after a successful preliminary phase, has been actively deployed by one incident management team for several months. It helps with diagnosis; it does not decide what to roll back or accept, and Microsoft sells the models involved.

An employer has put it into production. Can move the baseline — weighted by scale and how similar the setting is.

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.

Stay and strengthen

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.

Reshape the role

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.

Adjacent move

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.

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.