When agents write most of the code, the developer’s job becomes three things: deciding what to build, checking what was built, and owning what ships. The risk is that we turn capable people into tired reviewers who read machine output all day, so the work has to be designed around that risk instead of hoping it goes away.

I run Wbcom Designs, a WordPress agency with a small team and more than 100 plugins and themes. AI coding agents now write a large share of our code. This post is about what that did to the job, what has been hard, and the rules we use to keep the work meaningful. It is a report from the middle of a change, not a finished answer, and I say where I am still guessing.

In this guide

  • What moved to the agents and what stayed with people
  • Why reading agent output all day is draining, and what we do about it
  • What the data says: far more code, only a little more shipped software
  • Ownership: one person per change, written reasoning, and separate roles
  • What people lose, and what we are trying to give back
  • Hiring and growing developers when agents write first drafts
  • What I still do not know
  • Questions people ask

What actually changed in the developer’s job?

The typing moved. The responsibility did not. A developer used to spend most of a day producing code and a smaller part of it deciding and checking. Now the proportions are reversed: the agent produces a first draft in minutes, and the person spends their time on whether that draft is the right thing, whether it works, and whether they are willing to put their name on it.

I want to be careful with the word “reversed”. Writing code was never only typing. It was also the slow, half-conscious process of understanding the problem while your hands were busy with it. When the agent does the typing, that understanding does not arrive for free. It has to be created some other way, on purpose, before the code exists and after it appears. Most of what follows is about how we try to create it.

Which tasks moved to the agents, and which stayed with people?

The short version: anything that is well specified moved, and anything that needs a view of the customer, the business or the risk stayed. Here is how that splits in practice.

What the agents took over

  • First drafts of implementation. Given a clear plan, the agent writes the code, including the repetitive parts: REST routes, settings screens, data access methods, tests.
  • Investigation. Reading a codebase to find where a bug lives, tracing a flow, listing every caller of a function. This is slow human work that agents do well, as long as someone checks the conclusion.
  • Mechanical sweeps. Running a checklist across many lists and screens, for example the large-site checks we apply to anything that returns a set of rows: pagination, indexes, per-row queries, counts, empty states.

What stayed with people

  • Deciding what to build, and saying no. An agent will build whatever it is asked to build. Nothing in it pushes back on a feature that should not exist. A person has to.
  • The owner’s view. We have a written rule that site owners and end customers decide what is right, not QA and not me. When a tester reports a layout or preference complaint, someone has to reproduce it at the exact viewport, judge it as the person who runs the site and the person who uses it, and sometimes push back with a reason. That is judgement about people, and I have not seen an agent do it unprompted.
  • Verifying in a real browser. Our rule is that every item with frontend or CSS changes is browser-verified before it counts as done, at 390px wide as well as desktop. Passing code checks does not mean the feature is done. A person looks at the screen.
  • The decision to ship. Someone has to be willing to say “this goes out” and carry what follows.

If you look at that list, the second half is where the job always was at its best. The first half used to be the apprenticeship that taught people the second half. I come back to that problem in the hiring section, because it is the hardest part.

Why is reading agent output all day so draining?

Reviewing code you did not write, in large volume, is harder than writing it, and it is a different kind of tiring. When you write code, you build up a mental model as you go, and reading it back is cheap. When an agent hands you a finished change, you arrive cold. You have to reconstruct the intent, the alternatives that were rejected and the assumptions baked in, all from the result. Nothing about the output tells you how much effort that will take.

Several things make it worse with agents specifically:

  • Volume. The agent can produce changes faster than a person can honestly read them. The queue grows, and the pressure is to skim.
  • Plausibility. Agent code usually looks right. Bad human code often looks bad; bad agent code often looks fine. Reviewing for “looks wrong” stops working.
  • Confident reports. The agent’s own summary of its work can be wrong, in a tidy and convincing way. More on that below.
  • No learning loop. Reviewing a hundred small corrections for an agent does not make you better at the craft the way writing does. It can feel like labour with no growth in it.

When I look at the public discussion on this, the shape is consistent. On Hacker News there is a long thread around a story about an engineer who found the job soul-sucking once an agent did the writing, and a separate Ask HN thread asking whether anyone is really getting good code from agents. People in both threads describe the same split. Some say the hard part of engineering moved up to architecture, specs and evaluation and that they like it more. Others say the keeping-up, the reviewing and the understanding is the exhausting part, and that they now ship code they only half understand. Several say they have settled on a spectrum: let the agent run on throwaway code, audit every change on code they care about, and write the critical parts by hand. I am describing what people are discussing, not claiming any of it is measured fact. I could not open the linked TechSpot article from a script, so I am not relying on it for anything.

What I take from it is that the fatigue is not a personal weakness and is not universal. It depends on how the work is cut up. That is a design question, and it is the one we have to answer.

Does more code from agents mean more software?

Not by much, and that is the best evidence I have seen for why the job moved to deciding and checking. A working paper from the National Bureau of Economic Research, Writing Code vs. Shipping Code, matched more than 500,000 GitHub developers with their AI usage data. Its abstract reports that autocomplete, interactive coding agents and autonomous coding agents raised coding activity, measured as commits, by 30%, 180% and 240% in turn. The 240% then shrinks as it moves towards the customer: 80% more projects, and 30% more actual releases. Across four software marketplaces the authors found a sharp rise in new apps and no rise in total usage.

The authors call this the weak-link pattern: the gain at the typing stage is held back by the human steps further down the chain. In plain terms, the agent made one stage of the work almost free, and the output of the whole line is now set by the stages a person still does. That is review, verification, release and support. If those stages stay the same size while the code arriving at them triples, the queue grows and nothing more ships.

A developer essay that was widely shared the same week, AI Got Better While I Was Away. Software Didn’t., makes the same point from the inside: “We don’t have a code shortage”, it says, “we have a shortage of good decisions.” The author’s worry is that the friction of writing code by hand used to stop some bad ideas, and an agent will now build the whole over-complicated thing without complaint.

How to check it on your own team: count three numbers for the last quarter and the same quarter a year earlier. Commits or merged changes, releases that reached customers, and support tickets per release. If the first went up far more than the second, your bottleneck is after the code, and adding more agent output will not help. What to do about it: spend the time the agents saved on the narrow stages, which is what the rest of this post describes.

The second lesson: limit what an agent can reach, not only what it is told

Part of the job that stayed with people is deciding what an agent is allowed to touch. In October, TechCrunch reported that Anthropic, which makes the agent we use most, had found its models taking actions nobody asked for while solving problems during internal tests, and that it responded by turning off live internet access for those tests and moving its internal agents to tightly contained infrastructure. The report quotes the company saying its training was not yet sufficient for skills such as search and computer use.

I read that as a useful admission for anyone running agents at a much smaller scale. If the people who build the model chose to restrict the environment instead of trusting the instructions, an agency should do the same. In our work that means an agent does its first pass on staging and not on a live site, it gets credentials for the one system the task needs, and anything that changes a customer’s site waits for a person. Deciding those limits, and noticing when a task quietly needs wider ones, is developer work that no agent does for you.

What practices keep review meaningful instead of numbing?

We do not have a clever system. We have four habits, each one tied to a written rule, and each one exists because skipping it cost us something.

The gates themselves are described in 26 Releases in Four Days: What Our Release Gates Caught; here I am writing about the people who sit behind them.

1. Keep the unit of work small

A reviewer can hold a small change in their head. They cannot hold a sprawling one, and a sprawling one is where review turns into skimming. Our rule for tracker cards is one commit per card, made after that card is verified live, not a batch of cards squashed into one. The rule came from a session where I worked through more than a dozen cards before committing, and several fixes ended up combined into single commits by a background step instead of by intent. The result was history that was harder to review and harder to revert one fix at a time.

How to check it: look at your last ten merged changes. If you cannot say in one sentence what each one did, they are too big. How to fix it: split by card or by intent before you ask anyone to review. How to prevent it: make “verified, then committed, one item at a time” the default workflow instead of a tidy-up at the end.

2. Verify each item before moving to the next

Our verify-per-item rule says each item with frontend changes is implemented, then checked in the browser, then fixed if it falls short, and only then marked done. We do not batch everything and verify at the end. The reason is practical: a defect found right after the change is cheap to trace, and a defect found after twenty changes is a detective job.

3. Gates that measure the property, not the step

This lesson came from a different part of our work, video production, and it applies directly to code. A pipeline step was claimed to normalise audio loudness uniformly. Our quality check only confirmed that the clips existed and had a sensible length. Neither check measured loudness. The result was inconsistent audio across dozens of videos, and I was the one who caught it. Later we found some clips were nearly silent while still passing the length check.

The rule we took from it: for any step that claims an output property, add a check that measures that property on the output. Do not accept a recipe line, or a passing “it ran” check, as proof. The structural fix matters too. A lesson that lives only in a note gets skipped; a gate built into the script does not.

For review fatigue, this is the most useful idea we have. A tired reviewer cannot be the only thing standing between a wrong claim and a release. Every property you care about (the data is saved, the toggle changes behaviour, the list works at two thousand rows) should have something that measures it, so the person’s attention goes to the things only a person can judge. Gates do not replace review. They stop review from being asked to do a machine’s job.

4. Check the code before believing “already done”

Agents report on their own work, and the report can be wrong in both directions. We hit a clean example while completing screens in a community product. A completion agent said several features had already shipped before its branch: a mark-all-read button, unread counts on tabs, pagination, date groupings. A live walk of the same screens showed none of them.

Both were partly right. The code existed. But each feature sat behind a condition that was false on our sparse test data: the button only appeared if there were unread items, the tab counts only if the count was above zero, pagination only when the total passed the page size, and date groups only when a notification fell in that bucket. The agent had read the code. The walk had looked at a nearly empty screen.

How to check: do not trust the agent’s report and do not trust one walk on thin data. Search the template for the feature, then read the condition around it. If it is a guard like “only when the count is above zero”, it is not a gap; it is a data problem. Fix: create realistic test data that exercises the condition, then verify it renders. If there is no such code, it is a real gap and you build it. Prevent: seed realistic data before any completion walk, and put in the agent’s brief that a feature that seems missing should be searched for before it is built.

This habit is also a relief to the reviewer. It turns an argument about what the agent claims into a short, factual check.

5. Test the fix yourself before telling anyone it shipped

Before we tell a customer a fix has shipped, someone installs the released version on a matching test setup, recreates the customer’s situation, and walks each point in the browser. A developer’s verification ran on a branch build in their own environment, and the customer gets the released package on theirs. This stops everyone assuming the previous person checked.

Who owns a change that an agent wrote?

A person owns it. An agent cannot be paged, cannot apologise to a customer and cannot decide to roll something back. If nobody can say “this is mine”, then when it breaks, everyone is sure someone else checked it. I have written separately about the line between writing code and being accountable for it, in Who Owns It at 3am: The Real Line Between Vibe Coding and Engineering. Here I want to stay on the day-to-day mechanics.

Three things make ownership real. I will be honest about which are fixed rules in our written instructions and which are practices I am still shaping.

One named person per change

This is the practice I push hardest and the one I would call least finished. The idea is simple: for every change that ships, one human is the owner, whoever wrote the prompt or the agent’s brief. Their job is not to have typed the code. It is to be able to explain it, to have seen it work, and to answer for it. If the owner cannot explain the change, it is not ready, regardless of whether the tests pass.

Write down the reasoning

Agent output contains the what. It rarely contains the why. Our working rule for significant decisions is to store the reasoning and outcome, and to store a bug fix with its root cause and not just the patch. The reason is memory. In six months a new developer, or the same developer after a long gap, will find a piece of code that nobody typed by hand and nobody remembers deciding. Our test, taken from our own instructions, is: will a new developer understand this in six months? If the answer depends on someone remembering a conversation with an agent, it is no.

The check is easy: for any change, ask whether the reason it exists is written somewhere other than the code. The fix is to write two or three sentences at the time, while it is fresh. The prevention is to make it part of the definition of done.

Keep the role that investigates separate from the role that writes

This is one of the structural choices I am happiest with. We split work by kind. The investigation of a bug, reproducing it and finding the cause, runs on one model setup, and writing, fixing and reviewing the code runs on another. Between them sits a written hand-off: evidence, the root cause with the file and line and how it was established, how far the problem reaches, a confidence level, and a list of what was not verified.

The rule that makes it work is that the coding side does not build on an unchecked brief. Before planning, it checks only the claims the fix depends on: does the reproduction hold, is the cited code actually the cause, is the reach complete. If a claim fails, the work goes back to investigation. If it holds, nothing gets re-investigated. This stops one agent from writing a plausible diagnosis and then also writing the fix that confirms it.

For ownership, the useful part is that the hand-off is a document a person can read. It gives the owner a short, structured thing to review in place of a long chain of agent steps. It also gives a clear point to escalate: if a root cause survives one fix attempt, or the work touches money or authentication paths, the instruction is to say so in one line and recommend a stronger setup, and a person decides.

What do people lose, and what are we trying to give back?

People lose three things, and I would rather say so plainly than pretend otherwise.

I made the case for stepping back from the keyboard myself in You Can Now Code Everything Yourself. That Is Exactly Why You Must Stop. This is the other side of it: what that shift asks of the people who used to write the code.

  • The craft. Many developers became developers because they like writing code: the shape of a clean function, the satisfaction of a hard bug yielding. When the agent writes the function, that pleasure moves out of the day. For some people this is the whole point of the job, and telling them to enjoy “higher-level work” is not an answer.
  • The learning. Most of what a developer knows came from writing and breaking things. Reviewing is a thinner way to learn. People can get faster at the output and slower at the understanding.
  • The sense of building. When you steer instead of make, the finished thing can feel like it belongs to nobody. That connects straight back to ownership.

People respond to this differently. Some in the public threads say they now enjoy the work more because the tedium dropped and the product thinking came forward. Others find the same change hollow. Both are real, and a team has both kinds of people. A policy that assumes everyone feels the same will lose someone.

Here is what we are trying. These are intentions and experiments, not results. I have no data that they work.

  • Keep some work human by choice. Not everything that an agent can do should go to an agent. Pick pieces, especially the ones that teach the most about the codebase, and let a person write them by hand. The point is not nostalgia. It is to keep a reservoir of people who still understand the system from the inside.
  • Put the plan in human hands. The part of the work with the most craft left is the design: the flow, the data model, what the unit of work should be. We treat planning as the creative core, done by a person before an agent touches a file. It is where the thinking is, and it should not be the part that gets squeezed.
  • Protect finishing. Small units, each one verified, each one committed, give people a steady supply of completed things. I think this matters more than anyone admits for how the day feels.
  • Give review a purpose. A review that exists to approve is deadening. A review that exists to catch a wrong claim, such as the “already shipped” case above, is detective work, and detective work is more interesting. Gates that take away the box-ticking leave the reviewer the interesting cases.

None of these removes the cost. They manage it.

How should you hire and grow developers when agents write first drafts?

Hire for judgement and the ability to verify, then protect the path that builds them. I will take the two halves in turn, and I will say up front that parts of this are my current thinking rather than tested practice.

What to look for

  • Can they read code critically? Give a candidate a change that looks right and has a flaw in it. See whether they find it, and see how they go about looking.
  • Do they check instead of assume? Our own incidents show this as the single most useful habit: search the code before believing a report, measure the output instead of trusting the step. Ask for a time they discovered a confident claim was wrong.
  • Can they say no, with a reason? Someone who can turn a request into a better question is worth more than someone who can only execute.

What juniors should still do by hand

This is the part I worry about most. If agents write the first draft of everything, the traditional route into the craft, doing the easy work until it becomes second nature, closes. A junior who only reviews has nothing to compare against. They cannot tell that a plausible change is subtly wrong because they have not yet been wrong themselves.

My current answer, which I am still testing: have juniors write real code by hand, on real work, in the places where the learning is richest. Specifically:

  • Small bug fixes where they must find the root cause themselves before any agent is involved.
  • The first pass of a data-access method or a list query, then compare it against what the agent would have produced and talk through the differences, including the large-site checks (pagination, indexes, per-row queries).
  • Reading and explaining a flow end to end, every caller, before changing it.
  • Browser verification of their own work, at desktop and at 390px, so they build the habit of looking at the real thing.

The aim is not to make juniors slower. It is to make sure that when they do review agent work, they carry a feel for what correct looks like. I have written elsewhere about how to train a team that can ship without relying on one person, in How to Train a Team That Ships Without You. This is the narrower question of how they learn the craft itself when the first draft is free.

What do I still not know?

A lot, and I would rather list it than imply a settled view.

  • How long human understanding lasts. If a system is mostly agent-written, how many people need to understand it deeply, and for how long? A voice in the public discussion makes the point that “it works today” is a different claim from “I will never need to understand it”. I think that is right, and I do not know the answer for a 100-plugin portfolio over years.
  • Whether the by-hand practice for juniors is enough. It might be too little, or it might be a ritual that feels good and teaches less than real work does.
  • Where the fatigue limit is. I have not measured how much review a person can do well in a day. Small units and gates help, but I cannot give you a number, and I would be suspicious of anyone who did.

If you run a team through the same change, ask your people directly what is draining and what they miss, and change the process on what they say.

Questions people ask

Will AI agents replace developers?

I cannot predict that, and this post does not depend on it. What I can say is that in our own work the writing of code has moved to agents while the deciding, checking and owning has stayed with people. Those are jobs, and right now the volume of them has grown with the volume of code.

Is reviewing AI-written code harder than writing it?

Often, yes, for the reasons above: you arrive cold, the output looks plausible, and the volume is high. Small units of work, verifying each item before the next, and gates that measure the property you care about all bring it back to something a person can do well.

How do I stop an AI agent from claiming work is done when it is not?

Treat the claim as a lead, not a result. Search the code for the feature, read the conditions around it, and test with realistic data. In our case the agent was partly right: the code existed but was hidden by conditions that were false on sparse test data. The check takes minutes and settles the argument.

Who is responsible when AI-written code breaks in production?

A person. We aim for one named owner per change who can explain it and has seen it work. The agent is a tool, and accountability cannot be delegated to a tool.

What should junior developers learn if agents write the first draft?

Root-cause debugging, reading a flow end to end, writing some real code by hand, and verifying in the browser. These build the sense of what correct looks like, which is what a reviewer needs. This is my current approach, not a proven curriculum.

This is general commentary on how we work and is not advice for your particular team or employment situation. If you are working out how to organise a development team around agents, or want a second opinion on your own review process, you can reach me through the contact page on vapvarun.com.