AI Didn’t Make Developers Obsolete. It Turned Them Into Supervisors.

Non members can read here

You know the kind of pull request that makes you suspicious because it looks a little too complete.

Fourteen files changed. A migration. Three tests. Updated documentation. Even the naming is

tidy. The agent did in ten minutes what would have taken a solid afternoon a year ago.

At first glance, it is excellent. Then one line gives the whole thing away: the agent stored a

calculated value instead of the original value the business needed to preserve.

Nothing is obviously broken. The tests pass because they were written around the same

misunderstanding. The code is competent. The decision behind it is wrong.

That is the part most AI demos skip.

Coding agents are getting very good at producing plausible implementations. They are not

accountable for how those implementations behave in a real company, inside a codebase with

history, customers, compliance rules, and odd constraints that never made it into the ticket.

The developer is still accountable. The work has simply moved.

The Part of the Job That Moved

For a long time, implementation was the visible bottleneck. A requirement entered the team,

and somebody had to translate it line by line into working software. Senior engineers were

faster because they had seen more failure modes and carried more patterns in their heads.

Agents compress a large part of that middle step. They can inspect a repository, make

coordinated edits, run commands, write tests, and revise their own work after a failure.

Anthropic's 2026 analysis of roughly 400,000 Claude Code sessions found a useful split: people

tended to make more of the planning decisions — what should be built — while the agent

handled more of the execution decisions — how to build it.

That sounds like a small distinction. It is not.

When implementation gets cheaper, attention shifts to the decisions on either side of it.

Before the code exists, someone has to define the actual outcome and put sensible boundaries

around the task. After the code exists, someone has to prove that it is correct, safe,

maintainable, and worth merging.

We used to spend most of our energy turning decisions into code. Increasingly, the hard part

is making decisions that deserve to become code.

Code is becoming abundant. Judgment is not.

The Speed Is Real. So Is the Drag.

There is no point pretending these tools are not useful. They are. A good agent can remove

hours of repetitive work, especially when the task is well-bounded and the repository is easy

to navigate.

The trouble starts when we turn that experience into a universal productivity claim.

Stack Overflow's 2025 Developer Survey found that 46% of respondents distrusted the

accuracy of AI tools, compared with 33% who trusted them. Experienced developers were

among the more cautious groups. That caution makes sense: they have spent years learning

how often clean-looking code hides a bad assumption.

DORA's 2025 research described AI as an amplifier. Teams with good engineering systems can

convert faster generation into faster delivery. Teams with weak review, testing, or product

discipline often get a different result: more code entering the system faster than the

organization can safely absorb it.

METR's studies make the picture even less tidy. Its early-2025 controlled experiment found

experienced open-source developers took 19% longer with the tools available at the time,

despite feeling faster. By February 2026, newer tools appeared more capable, but METR also

explained why the size of the benefit had become difficult to measure cleanly.

None of that fits neatly into a viral headline. That is probably the point.

On one task, an agent can save an hour. On the next, it can send you down a polished detour

that takes forty minutes to unwind. It may make prototyping dramatically faster while adding

review pressure to mature systems. It may reduce the tiring parts of coding without

improving every delivery metric.

So the useful question is not whether AI writes code quickly. Obviously it does.

The useful question is whether the human-and-agent workflow produces a better result at an

acceptable level of risk.

What Supervision Looks Like in Practice

The word supervisor sounds managerial, which is slightly misleading. This is still deeply

technical work. It just happens around the implementation instead of inside every keystroke.

The engineer defines the task, gives the agent a safe amount of context, reviews what

changed, tests the assumptions, and decides whether the result belongs in the system. The

agent can do a large share of the typing. It cannot take ownership of the consequences.

Good Engineers Make the Task Smaller Than the Temptation

A weak instruction says, 'Add user notifications.' It gives the agent a feature name and leaves

the important decisions unstated.

A useful task explains which events should trigger a notification, who should receive it, how

duplicates are avoided, what happens when the provider is down, which user preferences

override the default, and how the finished behavior will be tested.

This is not prompt engineering theatre. It is specification work — the same discipline strong

teams needed before AI, only now poor specifications can generate a surprising amount of

wrong code very quickly.

They Know Strange Code Usually Has a History

Agents optimize for the code they can see. Production systems are full of things they cannot

infer from the repository alone: old customer promises, regulatory boundaries, deployment

quirks, support processes, cost limits, and the reason an awkward abstraction was introduced

three years ago.

An agent may see three similar classes and suggest combining them. A senior engineer may

know those classes deliberately isolate customers with different compliance requirements.

The agent sees duplication. The engineer sees a boundary.

They Test the Assumption, Not Only the Implementation

Generated tests are useful, but they often inherit the same interpretation as the generated

code.

Suppose an agent decides that an 'active subscription' means any subscription record that has

not been deleted. It implements that rule and writes tests around it. Everything is green.

Expired customers still receive access.

The test suite did its job. It verified the implementation. Nobody verified the meaning of

active.

The stronger review question is: what independent evidence would expose the most likely

misunderstanding here?

They Treat Permissions as Part of the Design

A coding agent is no longer just autocomplete. Depending on the setup, it can read files,

execute commands, install packages, call external services, edit infrastructure, run

migrations, and open or merge pull requests.

That makes least privilege an engineering requirement, not an optional security hardening

exercise. Use bounded credentials, isolated environments, explicit allowed paths, reversible

operations, and human approval before destructive or high-impact actions.

Giving an agent broad access because it makes the demo smoother is the modern version of

running everything as root. Convenient, right up to the moment it is not.

They Refuse to Merge What Nobody Understands

There is another debt appearing in AI-heavy teams: the codebase grows faster than the team's

mental model.

Call it comprehension debt. The feature works, but nobody can clearly explain its boundaries,

the assumptions inside it, or how it fails. Six months later, every change around it becomes

slower because the team has to rediscover what was merged in a hurry.

The fix is not to manually rewrite agent-generated code. It is to make understanding part of

done. Ask the agent to explain what changed, what it assumed, which invariants might be

affected, how it validated the result, and how to roll it back. Then check that explanation

against the code.

The explanation is not proof. It is a map of where proof is still needed.

The Most Dangerous Diff Is the One That Looks Finished

Bad code eventually makes noise. Tests fail. Logs spike. Customers complain.

The harder problem is the distance between the person approving a change and the system

being changed.

AI makes that distance easy to miss because the output often looks professional. The names

are reasonable. The comments are polished. The tests are present. A large diff can feel

reviewable before the reviewer has actually reconstructed the logic behind it.

A tidy diff can still be wrong at the product level.

So do not stop at, 'Is this readable?' Ask whether the requirement was interpreted correctly.

Do not stop at, 'Do the tests pass?' Ask whether those tests could pass while the customer

outcome is still wrong. Do not stop at, 'Does it follow our pattern?' Ask whether that pattern

should be repeated in this case.

The new failure mode is not ignorance. It is borrowed confidence.

A Workflow I Would Trust on a Real Team

Before the agent starts, write a short task contract. It does not need to be a twenty-page

specification. It should state the outcome, the relevant context, the files or modules that may

change, the things that must not change, the important edge cases, and what evidence will

count as done.

During execution, keep the scope small enough that a human can still review it properly.

Separate unrelated work. Use branches or worktrees. Put an approval checkpoint in front of

schema changes, new dependencies, destructive commands, authentication changes,

production access, and anything involving billing or personal data.

After execution, resist the urge to read the diff from top to bottom immediately. First restate

the requirement in your own words. Then inspect the plan and the boundaries that moved.

Only then review the implementation, run the checks, and add at least one adversarial test

the agent did not suggest.

Before merging, ask the boring operational questions. Did this introduce another

dependency? Is the failure observable? Can it be rolled back? Will support understand it?

Could another engineer maintain it after the original context has disappeared?

This can feel slower than accepting the first plausible answer. It is still cheaper than

discovering in production that the agent solved the wrong problem beautifully.

Junior Developers Still Need the Boring Parts

There is a genuine training problem hiding inside all of this.

Junior developers used to learn by doing work that was slow and occasionally painful: tracing

unfamiliar code, reading documentation, writing a clumsy first version, receiving blunt

review comments, and fixing the same misconception twice before it finally stuck.

If an agent removes every difficult step, it can also remove the feedback that creates expertise.

Banning the tools is not the answer. Pretending the problem does not exist is not an answer

either.

A junior developer can use an agent and still be expected to explain the architecture, predict

where the change might fail, write one independent test, and defend the final diff. Teams can

reserve some debugging exercises for manual work. Reviews can include questions about

understanding, not only whether the ticket moved to done.

The boring parts are not a flaw in engineering education. Some of them are how judgment is

built.

The future senior engineer will not be the person who avoided AI. It will be the person who

used it without outsourcing the learning required to supervise it.

Keystrokes Were Never the Profession

There will be disruption. Some implementation work will shrink. Teams will attempt larger

scopes with fewer people. Entry-level pathways will need deliberate redesign instead of

wishful thinking.

But software was never valuable because someone typed it. It is valuable because it changes a

system in a way that serves a real human or business goal — reliably enough that people are

willing to depend on it.

AI can produce more and more of the implementation. It cannot own the consequences when

that implementation is wrong.

A developer whose only value is converting tickets into syntax is exposed. A developer who

understands users, architecture, operations, security, constraints, and proof is becoming more

important, because the amount of code needing judgment is growing faster than the supply of

judgment.

The next generation of strong engineers will still know how software works. They will also

know how to direct machines, restrict their access, challenge their assumptions, and turn

their output into systems people can trust.

The future does not belong to the developer who rejects every agent. It does not belong to the

developer who merges whatever the agent produces.

It belongs to the developer who can use machine speed without borrowing machine confidence.

Before You Click Merge

Can I describe the business requirement without looking at the generated implementation?

Which assumption in this change is most likely to be wrong?

What test would fail if the agent misunderstood the requirement?

What permissions, data, or infrastructure did the agent touch?

Could another engineer explain and operate this change six months from now?

Research Notes

This article combines current industry research with an editorial argument. The cited studies use different tools, populations, methodologies, and time periods, so their results should not be treated as directly comparable or as a promise that every team will see the sameproductivity effect.

Consider buying me a cup of coffee if i added value to your learning.