In the Stack Overflow Developer Survey 2025, 84% of respondents use or plan to use AI tools in their development process — up from 76% the year before — and 51% of professional developers use them daily. When machines write most of the code, the remaining question is not “are engineers still needed” but “which part of the engineer’s job survives.” The short answer: the hardest part — formulating intent, decomposing problems, and verifying results. This article covers the mechanism, the best public data available, and its limits. What it does not do: promise speedups, or give hiring advice.
What has actually changed in engineering work?
What changed is the work’s center of gravity: from typing implementations to the four things surrounding it — formulating intent, decomposing problems, verifying results, and deciding what an agent is allowed to touch. Writing code has not disappeared, but it has stopped being the bottleneck.
The mechanism works like this. First, formulating intent: an agent fills every gap in an instruction with a guess, and a wrong guess is paid for at verification time — so an unambiguous specification turns from a formality into the primary source of truth. Second, decomposing problems: agents work best on narrow tasks with clear acceptance criteria, and breaking a feature into tasks of that size is an engineering decision, not an administrative one. Third, verifying: the cost of writing code drops, but the cost of reading it does not — every diff still has to be understood by someone who can be accountable for it. Fourth, tool and permission boundaries: deciding which repositories, networks, and credentials an agent may access is a security decision that moves to the engineer rather than being removed by the tool.
All four loads existed before AI; what changed is the proportion. Work that used to be 80% writing and 20% judging now approaches the inverse on tasks that suit agents.
What does the data say?
The two best public sources paint a more complicated picture than the “ten times faster” narrative: one controlled study that found a slowdown, and one large survey that found high adoption with declining trust.
The controlled study is METR’s RCT published on July 10, 2025. Sixteen experienced open-source developers — from large repositories averaging over 22,000 stars and one million lines of code, which they had maintained for years — worked on 246 real issues from their own projects. Each issue was randomized: AI allowed (primarily Cursor Pro with Claude 3.5/3.7 Sonnet, the frontier models at the time) or AI disallowed entirely. The result: with AI, developers were 19% slower at completing issues (confidence interval +2% to +39%). What made the result famous is not the number but the perception gap: before working, the developers expected AI to speed them up by 24%; after experiencing the slowdown themselves, they still believed they had been 20% faster. Their screen recordings show where the time went: composing prompts, waiting, reading, and correcting output that was almost right. METR itself published a list of claims its study does not support — among them, the study does not prove that AI fails to speed up the majority of developers, because its sample was experienced developers on mature repositories they knew inside out.
The second source is a survey. The Stack Overflow Developer Survey 2025 found that positive sentiment toward AI tools actually declined: from above 70% in 2023 and 2024 to 60% in 2025 (very favorable 22.9%, very unfavorable 9.6%). Trust in output accuracy is lower still: 46% of respondents actively distrust it, only 33% trust it, and only about 3% trust it highly. The most cautious group is experienced developers — with the lowest “highly trust” rate (2.6%) and the highest “highly distrust” rate (20%). The most cited frustration (66%) is “AI solutions that are almost right, but not quite,” followed (45%) by “debugging AI-generated code is more time-consuming.” And asked when they would still turn to a person, the top answer (75%) was “when I don’t trust AI’s answers.”
Our reading — and this is a reading, not a survey finding — is that these numbers describe an industry adopting a tool whose output it does not fully trust. That is consistent with a role shifting toward verification, not with a role disappearing.
Does the follow-up study change the conclusion?
Not definitively — the data is moving, and measuring it is getting harder. METR’s February 24, 2026 update reports a second experiment that began in August 2025 with newer tools: 10 developers from the original study plus 47 newly recruited ones (57 developers, 143 repositories, over 800 tasks in total). For the subset of returning developers, the estimate flips to roughly 18% faster — but with a very wide confidence interval (-38% to +9%), while newly recruited developers are estimated at about 4% faster (interval -15% to +9%). The authors themselves call this data “very weak evidence” for the size of the effect.
The reason is selection effects they acknowledge openly. Some developers declined to participate because they did not want to work without AI; 30% to 50% admitted withholding some tasks from randomization for the same reason; pay dropped from $150 to $50 per hour, which further filtered participants; and time measurement becomes unreliable for developers running several agents concurrently while working on something else. In other words: the more useful AI becomes, the harder it is to keep a “no AI” control group, so the estimate is biased downward in a way that cannot be corrected from the data. Add the first study’s finding that developers’ self-estimates can miss reality by 40 percentage points, and the practical lesson is: measure your own work, do not borrow a point estimate from someone else’s study.
What does orchestration work look like in practice?
Its shape is a document: a specification written by a human, a decomposition into agent tasks that each carry acceptance criteria, and verification gates in between. The illustrative example below — not a client project and not a measured result — shows what an orchestrator writes before a single agent runs, for the feature “add a refund flow”:
Feature: refund flow for orders cancelled by the customer (illustrative example)
Specification (written and reviewed by a human before any agent runs):
- Refunds only for orders in "cancelled" status that have never been refunded
- Funds return to the original payment method; confirmation within 3-7 business days
- Every refund recorded in the audit log with a unique idempotency key
Agent task breakdown:
1. Schema migration: refunds table + unique constraint on the idempotency key
Gate: migration runs forward and backward on staging
2. POST /orders/{id}/refund endpoint with order-status validation
Gate: contract tests pass, including the double-submit case
3. Payment gateway integration + refund-status webhook handling
Gate: webhook replay in the sandbox; retries never produce a double refund
4. Email notification + audit log entry
Gate: template snapshot tests; no refund without an audit entry
Tool boundaries: the agent may write code and run tests; it may not access
production credentials; migrations are run manually after human review.Notice where the engineer’s hours move: almost entirely into the specification and the gates. The rule that makes a gate real is writing the acceptance criteria before looking at the agent’s output — a gate that cannot fail is not a gate, it is a rubber stamp.
How does the shift differ across contexts?
The mechanism is the same everywhere; what differs is where the verification tax falls and who pays it.
Solo founder. One person is specification writer, orchestrator, and reviewer at once. The main risk is not agent quality but the absence of a second pair of eyes — the compensation is strict tests, small change scopes, and honesty about which parts of the system you do not actually understand.
Small product team. A division of labor starts to appear: one engineer writes the specification, agents and colleagues execute, and review becomes the real bottleneck — not code writing. A backed-up pull request queue is a symptom of this shift, not a coincidence.
Regulated enterprise. Tool and permission boundaries move to the center of the work: every agent needs an audit trail, “whose code is this” is a compliance question, and evaluation and observability become prerequisites before an agent may touch a real system. This is why we built our LLM evaluation harness as a foundation, and why our AI agents service always starts from gates and permission boundaries rather than prompts.
Who benefits more, seniors or juniors?
In the data that exists, seniors — and the reason is mechanical: the verification tax scales with how much you know. A senior engineer knows where mistakes usually hide, so they can recognize output that is almost right but subtly wrong before it gets expensive. A junior engineer receives output just as fluent, without the mental model of the system to test it against. The survey data aligns: in Stack Overflow 2025, experienced developers are the group most skeptical of AI accuracy (20% “highly distrust,” the highest of any group), and METR’s study deliberately examined the most senior developers on repositories they had known for years — the people best positioned to verify — and still found the tax to be real. This is our reading of that data, not a hiring recommendation: this data does not answer who should be hired.
What about the opposing views?
Two popular views are both half right. The view that “agents will fully replace coding” holds for narrow tasks with algorithmic scoring — benchmarks, throwaway prototypes — and METR’s own comparison table notes that agents succeed at benchmark tasks that are difficult for humans; it breaks precisely at the field study’s definition of success: a human satisfied that the code will pass review, including style, tests, and documentation. The opposite view, “this is just autocomplete,” is broken by the adoption data — 51% of professional developers use AI daily and agents are in real workflows — but holds on one important point: the accountability boundary has not moved, and code that no human has read remains code no one can answer for. The disagreement between the two, in our reading, is mostly about timescale and task type, not about whether verification remains human work.
Which skills gain value?
Judgment, not typing. When writing code becomes cheap, what becomes expensive is: writing unambiguous specifications; review — recognizing output that is almost right; designing evaluations, meaning acceptance criteria and harnesses that can fail honestly; systems debugging, answering “why” when something breaks in production; and designing tool and permission boundaries for agents. All five are the skills that have long marked a senior engineer; the difference is that they are now the main job description, not an add-on.
What remains unanswered?
Plenty, and it is best admitted. Productivity data is moving fast — the same research group produced a slowdown in early 2025 and a tentative speedup in early 2026 — with selection effects that make the newest numbers hard to fully trust. The controlled study’s sample is small and specific: experienced open-source developers on mature repositories, not enterprise teams with internal codebases. Self-estimates have proven unreliable. None of the sources above establishes effects for domains outside software development, for models that do not exist yet, or for hiring policy — this article deliberately does not cover team structures or individual career advice. Sources were checked on October 1, 2026; if you are reading this long after, treat the numbers as a starting point to re-verify, not a conclusion.
The engineer’s role changes shape; the accountability does not. If your organization is remapping engineering roles or designing verification gates for agentic systems, talk to us.
