Experienced software engineer

GitHub's own engineering account of moving the runtime behind Copilot CLI and the Copilot SDK from TypeScript to Rust: 832,378 lines of production Rust and 468,689 lines of Rust unit tests, done primarily by a single developer in a few months. Of 2,639 human-authored messages, 31.0% focused on review, testing and CI; 17.4% challenged technical or design decisions; and 15.0% pushed for completeness. Of 1,130,921 tool calls, 61% came from subagents rather than the main session thread — a split between agents, not a share of the work done by agents. The developer kept the destination architecture, which behaviour had to stay identical, how the work was partitioned, ambiguous trade-offs, judging the evidence, manual review of high-risk areas and the final merge decisions. It also describes an agent applying a label that let a schema check pass, which on questioning turned out to hide a regression. One developer, one project, in the vendor's own codebase. Recorded as capability, which on this site never moves an assessment.

A demo, benchmark or paper shows the task can be done. Updates what the technology can do — not what employers will do.

An engineering standard binding the Home Office's software teams. It says teams will retain full accountability for all AI-assisted code and outputs because AI tools cannot replace human judgement, understanding, ownership or responsibility for decisions, designs or changes made to systems, that AI-assisted outputs must be reviewed and approved by a human before reaching production, and that teams must be able to assert the security and maintainability of what they run. The firm 'must' applies to review; the sentence on designs states where accountability sits. It is one department's published standard, not a measure of practice elsewhere.

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

One large open-source compiler project, binding on its contributors. The policy says AI tools must not be used to fix GitHub issues labelled good first issue, because those issues are generally not urgent and are intended to be learning opportunities for new contributors; it says passing maintainer feedback to an LLM does not help anyone grow, and that reviewing changes from new contributors is part of growing the next generation of contributors. The clause came in with the policy's first version, committed on 16 January 2026; later edits did not change it. It is one project's rule, not an employer's.

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

One large Linux distribution, binding on its contributors and reviewers. The policy, whose MUST and MUST NOT carry their standard specification meaning, says you must not use AI as the sole or final arbiter in making a substantive or subjective judgment on a contribution, and that the final accountability for accepting a contribution, even if implemented by an automated system, always rests with the human contributor who authorizes the action. It allows automated checks for objective technical validation. Version 1.0; the page's own line gives its last review as 24 October 2025.

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

Experienced maintainers on large, mature repositories they know well (about 5 years each); tools were mainly Cursor Pro with Claude 3.5/3.7 Sonnet. The authors explicitly do not claim the result generalises to most developers or to greenfield or junior work.

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

49,009 responses from 177 countries, fielded 29 May to 23 June 2025, and self-selected: respondents were recruited through Stack Overflow's own channels, so this measures the people who answer Stack Overflow, not a random sample of developers. It is recorded against reviewing machine-written code rather than against writing code, because what it measures is the volume driver and the verification response, not who writes what. Both halves belong here: 84% use or plan to use AI tools (76% a year earlier) and 51% of professional developers use them daily, while favourable sentiment fell from over 70% in 2023 and 2024 to 60%, more developers actively distrust the accuracy of AI tools (46%) than trust it (33%), and the most experienced report the lowest rate of high trust at 2.6% against the highest rate of high distrust at 20%. The stake cuts both ways and that is unusual enough to state: Stack Overflow's own traffic is what AI coding assistants displace, so the adoption finding runs against its commercial interest while the falling-trust finding runs with it. The survey does not say what the tools were used for, whether any review took longer, or what any of it changed about shipped code.

Measured, large-scale use of a tool for real work, where the decision to use it was the worker's rather than an employer's. It is more than a capability record — the work is real, not a demo — and less than a deployment record, because no employer put it into production, required it, or built a process around it. Weighted `cautious`: `automating` means the machine can do the task AND there are adoption signs, and this is an adoption sign — but usage can be experimental, and much of the measurement comes from a party with a stake, so one record is never enough and two independent ones are. Note who is counting. Vendor telemetry sees this directly and sells the tool, so such a record names that stake in its scope; a statistics agency asking firms whether their workers use AI in tasks sees the same channel with no stake at all, and that is the better source where it exists.

One agency component (ICE) inside one government, reported by that agency under a statutory duty rather than chosen for publication, which is what makes the boring entries in this inventory worth reading. Entry DHS-2758 in the individually-reported CSV. What it establishes is the deployment and the conditions attached to it, not how much the tools are used: the inventory carries no usage figure, no headcount and no productivity claim beyond the agency saying the tools "increase developer productivity". The two clauses that support the two linked tasks are separate sentences in the words of the agency itself: outputs "must be reviewed and approved before being incorporated into the codebase through existing version control and deployment processes" (the reviewing task), and "the tools do not directly modify production systems; all changes must go through standard human review, testing, and approval workflows" (the task of setting what an agent may do unattended). The named tool is a vendor purchase, which is worth knowing though the agency, not the vendor, is the party reporting here. The same inventory carries a counter-signal from the same department: entry DHS-373, "Commercial Generative AI for Code Generation", has a development stage of Retired. That row carries no date and no reason, so it establishes only that DHS listed such a use case and no longer runs it.

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

You are not this page yet, and the route to it is the thing under pressure — read the junior page first. What matters most here is that the capability this occupation sells is judgement about one specific system, and that is acquired by being inside one, not by using better tools.

The measured finding on this page is that the tools did not speed you up on your own codebase, and that you may have believed otherwise. Treat that as a reason to measure your own work rather than as reassurance: the trial is small and a year old, and the part of the job that is growing is not typing — it is reviewing what arrives, and answering for what an agent was allowed to do.

Stay and strengthen

Become the person who is trusted to say no

As generated changes multiply, the constraint moves to whoever can refuse one with a reason that holds. That authority is earned by being right in public, repeatedly, about a specific system.

Reshape the role

Take ownership of what the agents may do

Somebody has to decide what an automated change is allowed to touch and where it enters. In most teams nobody has been given that, which is why it shows up in incident write-ups rather than job descriptions.

Adjacent move

Move to where correctness is expensive by law

Payments, safety-critical systems, regulated data — places where an unattended change is not permitted, so the reviewing and the accountability are funded rather than assumed.

Cross-industry

Move to the side of the problem

Solutions engineering, technical product, developer experience — roles where the value is understanding both a system and what someone needs from it, and where the writing was never the scarce part.

The one randomised trial this site holds found the opposite, and the detail worth carrying is the gap between measurement and perception: sixteen experienced open-source maintainers working on real issues in repositories they knew took 19% longer with 2025-era tools, while estimating they had been 20% faster. The authors do not claim this describes most developers or new projects, and it is a year old. What it does establish is that the speed-up is not automatic on a mature codebase, and that asking yourself does not settle it.

Nobody can answer that with a number, and the confident answers on both sides are selling something. A more useful question is which part of the job, because the parts are moving at different speeds: writing routine code is already largely done by machine, reviewing what it produced has grown into a job of its own, and deciding what ships with a known risk has not moved because it is accountability rather than capability. Watch a signal you can check yourself instead — how much of your week is now reading code you did not write.

It is differently exposed, not safer, and the two are connected. A profession that stops making seniors has a supply problem later, not a safety guarantee now: if fewer people arrive at the bottom, the teaching that used to be spread across a team lands on fewer people. Some engineering communities now protect that path on purpose — LLVM forbids AI tools on issues labelled good first issue so that new contributors can learn on them.

Nobody can answer that from evidence yet, and saying so is more useful than guessing. Those three have genuinely different exposure, but the studies that exist were designed to compare experience levels rather than stacks, so there is nothing to separate them with. Treat any confident ranking of frontend against backend as someone's impression. What the evidence does support is choosing by how expensive being wrong is in your domain, which cuts across all three.

Reviewing code you did not write, and being able to say why you rejected something. That skill was always present in the job and was never the thing anyone was hired or assessed on; it is now the bottleneck, because generation moved the work from producing to judging. It is also the capability that makes you the person who can be trusted to say no, which is the part of this job with no substitute in sight.