What remains when AI can write the code

An agent can finish a reasonable-looking patch before the team has agreed what the feature should do.

Then someone asks whether the old mobile client can still read the new response. Another person asks who owns the data migration. The support lead wants to know what happens to accounts that were already in the middle of the workflow.

“Coding is solved” is an understandable reaction to current agents, and a poor literal description of their reliability. Difficult implementation tasks remain. Suppose an agent can produce the required code. Someone still has to decide whether the requirement is right and whether the change should ship.

I expect decisions about behavior and system boundaries to take a larger share of engineering time as implementation gets cheaper.

Capability is real; completion depends on the task#

There is no need to argue away the improvement. On October 14, OpenAI described its Core Experimentation team's use of the GPT-6 family for maintenance, including more than 1,400 merged pull requests that began as model proposals. The same account notes that some proposals introduced more complexity than their likely benefit justified. It is a company report about one team's workflow, not a controlled estimate of developer productivity. OpenAI's maintenance account

Benchmarks answer narrower questions. SWE-Bench Pro, for example, targets demanding repository changes across multiple files. Even that is a different scope from owning a system's ongoing behavior.

Productivity evidence also needs its date and context. METR's early-2025 study found a 19% slowdown among experienced open-source developers using the tools available then. Its February 2026 follow-up found selection and time-accounting problems that made the newer productivity estimate unreliable. The old slowdown should not be recycled as a verdict on today's agents. The original study, the follow-up

I would measure the time from request to a reliable change, including review and rework.

The requirement is still a decision#

Consider a hypothetical subscription service asked to support “pause my account.” The phrase sounds implementable. It is also incomplete.

Does pausing stop billing immediately or at the end of the current period? What happens to reserved resources? Can a paused account receive notifications? Does the customer keep access to existing records? What happens if a payment is already in flight?

An agent can help discover these questions, trace the existing behavior, and implement an agreed policy. Someone still has to reconcile the business commitments and decide which behavior is intended.

When the implementation was expensive, some of these ambiguities surfaced slowly during development. Faster code generation can compress that discovery period. If nobody makes room for it elsewhere, the ambiguity reaches production sooner.

The response is to put more effort into concrete examples, state transitions, and exceptions at the start. A short acceptance case can be more valuable than a long description that leaves the consequential decision implicit.

Architecture is the cost of future change#

An implementation can satisfy today's task while making tomorrow's task harder. It may add another source of truth, duplicate a permission rule, or hide a dependency behind an apparently convenient abstraction.

For the subscription service, imagine adding a pause flag to the application while the billing system keeps its own subscription state. Both changes can look reasonable in isolation. The engineering question is which system owns the decision, how the other learns about it, and what customers see while they disagree. That boundary will affect every later change to renewal, cancellation, and account access.

Those costs are difficult to see from a local diff. They depend on which system boundaries matter, what other teams rely on, and how the product is likely to change. Agents can investigate those relationships, but the organization must make them discoverable and review the resulting assumptions.

More code proposals can also create a capacity problem. If generating another approach is cheap, reviewing every approach is not automatically worthwhile. Teams need a reason to accept a change: a measured bottleneck, an actual user need, a simpler ownership boundary, or a recurring failure it removes.

The decision to leave a working component alone remains an engineering decision. So does deleting code rather than extending it.

Compatibility belongs in the requirement#

For the pause feature, a new-client test may pass while an old mobile client treats the unfamiliar account state as an error. A successful database update may leave a previously submitted charge untouched.

Those are decisions about supported behavior. The team needs to settle them and include the relevant cases in its acceptance checks. I cover how to construct those checks in Give the agent a definition of done. Here, the point is that generating the patch does not resolve the commitments around it.

Someone has to own the failed pause request#

Production introduces incomplete information and irreversible history. Jobs run twice. Connections fail after an upstream service has committed a change. Users return to old sessions. Credentials expire. Someone needs to find the affected records and explain what happened.

Suppose the pause request times out after the billing provider accepts it. Retrying without checking the earlier action can create a second change; assuming failure can leave the application showing an active subscription that billing has paused. The workflow needs a stable request identifier, a way to reconcile the two states, and enough recorded evidence for support to explain the outcome. Someone must own the unresolved cases.

A model's ability to write the happy path does not supply operational ownership. A team still needs observable state, bounded retries, deployment discipline, and a person responsible for responding when the system violates its promises.

Agents can perform significant parts of this work as well. The point is that these responsibilities remain part of the task. They do not disappear when the first implementation becomes easier.

An effective request to an agent should therefore include the work needed to make a change usable: inspect callers, identify migration effects, demonstrate the failure case, and show how the result will be monitored. Completion should be checked against the running system where appropriate, rather than inferred from the agent's account of it.

Organize around accepted outcomes#

The managerial temptation is to count what becomes plentiful: commits, generated lines, pull requests, and tasks opened. Those measures can increase while the organization accumulates more uncertainty.

I would look at how long useful changes take to reach users, how much reviewer effort they require, which regressions escape, and how quickly the team can recover. Interpret those measures together; reducing review time by skipping review is not an improvement in the same sense as making evidence easier to inspect.

I would ask the agent to investigate dependencies, reproduce failures, implement alternatives, and prepare the evidence for review. The people who own the product and its operation must agree on behavior, tradeoffs, and release conditions.

That division will change as agents demonstrate reliability on more of the work. Until then, somebody needs to be able to answer the support lead when the pause request has failed halfway through.

Research checked on October 15, 2026. The subscription examples are illustrative. Reported studies and company experience have different scopes and should not be combined into a single productivity estimate.