Agents Write the Code Now. Here Is What the Developer's Job Became.

The question comes up at every dinner table where somebody has a developer in the family: if the machine writes the code, what is left?

The honest answer is that the question is aimed at the wrong part of the job. Writing code was never the whole job. It was the visible part, the part that looked like work to anyone walking past the desk. It was also, on most weeks, the smallest part.

The part that got automated was never the whole job

Anything that ships passes through six links:

1. Someone wants something, and says so badly.
2. Someone decides it is worth doing, and when.
3. Someone turns it into a description precise enough to act on.
4. Someone builds it.
5. Someone checks it did not break something else.
6. Someone ships it and tells the person who asked.

Agents took link four. They took it convincingly, and they will keep getting better at it. What almost nobody says out loud is what that does to the other five: it makes them heavier, not lighter.

The reason is throughput. When building took a fortnight, the five surrounding links had a fortnight to happen. They were slow because the middle was slow, and nobody noticed they were slow. When building takes an afternoon, everything else becomes the bottleneck, all at once.

One link collapsed. The other five now carry the weight that link used to hide.

That is the whole story, and the rest of this article is what each of the five looks like when you actually have to do it every day.

Link 1: hearing what to build, without losing half of it

The new failure mode is specific and it is expensive: you can build anything, so you build the wrong thing faster.

Requests arrive from everywhere. A message in a support thread. A sentence at the end of a call. A complaint on social media. A bug report that is really a feature request wearing a disguise. Historically that did not matter much, because you could only build one thing a fortnight anyway, and the obvious one was usually right. Now that you can build five things a week, the difference between the right five and the wrong five is most of your year.

Two things have to happen, and they are different things.

First, capture has to be cheap for the person asking. If a user has to open an account, find a form and describe the problem twice, most of them will not bother, and the ones who do are not a representative sample. A public feedback board where anyone can file a request, attach a screenshot, and follow what happens to it removes that friction. The people who use the product write the requests themselves, in their own words, with the context attached.

Second, sorting has to be automatic, because raw feedback does not stay useful for long. Twenty messages saying roughly the same thing look like twenty problems until somebody reads all twenty and notices they are one. That is precisely the work nobody has time for. Idea Radar is our answer to it: raw signals land untouched, cluster themselves into themes, duplicates are matched before they become two builds, and every idea carries the number of distinct people who asked for it. The verbatim is never rewritten, because the exact words someone used are the data.

The output of this link is not a backlog. It is a corpus you can read.

Link 2: deciding, which is now the scarce resource

An idea board is not a plan. Turning one into the other is the judgement call that used to be spread thinly across a quarter and now has to happen every week.

Two moves matter here.

Promotion is deliberate. An idea becomes a backlog ticket when someone decides it is worth building, not when it is filed. Everything else stays visible on the radar with its count of askers, which is the honest state of affairs: heard, not scheduled. Backlogs where eighty per cent of the lines will never be built are not plans, they are archives with a deceptive layout.

Scoping happens before the build, not during it. Fuzzy feedback becomes a validated mockup that the person who asked can look at and confirm. Five minutes of confirmation beats an afternoon of building the wrong screen, and that trade got dramatically better when the afternoon of building became an afternoon of agent time you could have spent on something else.

Link 3: briefing, which is the craft that replaced typing

This is where the actual skill went.

An agent will not push back on an ambiguous instruction the way a colleague does. It will not say "wait, which of the two payment flows do you mean". It fills the gap with a plausible guess and hands you something coherent and wrong. The cost of ambiguity used to be a conversation. Now it is a diff.

What separates people who get good output from people who fight their agents all day is not prompt cleverness. It is reusable context. Four kinds, in descending order of how much they pay back.

Context the agents read before they explore. Committed convention files (CLAUDE.md, AGENTS.md) and a project memory that holds architecture decisions, past traps and the reason things are the way they are. Written once, read by every agent on every machine, forever. It is the highest-leverage writing a developer does now, and almost nobody budgets time for it.

Procedures, saved as procedures. The tenth time you explain your release checklist, you are not briefing, you are retyping. A skills library turns a recurring procedure into something an agent loads when the task matches, and a prompt library does the same for the briefs themselves.

Showing instead of describing. A paragraph describing a misaligned button is worse than a picture of the misaligned button. Send a screen region directly, or draw on it to point at the thing you mean. For a web page, handing the agent the live DOM beats describing it, every time.

Speaking instead of typing. A three-sentence spoken brief carries more nuance than the one sentence you would have bothered to type. Voice dictation for a quick instruction, voice mode when you want the back-and-forth without touching the keyboard. This sounds like a comfort feature. In practice it is a bandwidth feature: people say more than they type, and agents are limited by what you tell them.

The first three are paid per task. The fourth is paid once and collected forever.

Link 4: running the work, on the right machine

One agent is a tool. Several agents are a system, and systems need an operator.

The practical questions are not glamorous, and they are the job. What can run in parallel without two agents editing the same module? Which task deserves your attention while it runs and which one does not? What should be running while you sleep?

That last one determines where the work executes. Anything you might need to interrupt, correct or steer mid-flight belongs on the machine in front of you. Long, well-specified, low-ambiguity work belongs somewhere else: another computer you own or a server over SSH, so a two-hour job is not holding your laptop hostage. Recurring work belongs on a schedule. The deciding question is never raw power, it is how likely you are to need to intervene.

When a piece of work has stages that genuinely differ, a single agent is the wrong shape for it. A build that has to be tested and then reviewed is three jobs with three different skill sets, and agent teams let you draw that handoff explicitly rather than re-explaining the context at each step.

And because none of this requires you to be sitting there, driving it from a phone stops being a novelty. Reading an agent's question and answering it in twenty seconds from a train is the difference between a task that finished and a task that waited four hours for you.

Link 5: reviewing, which is where accountability lives

This is the link that cannot be delegated, and the reason is not technical.

Agents already replaced most of the line reading. What they cannot take is the signature. Accountability does not transfer to a model. When a migration drops a column in production, "the agent wrote it" is not a sentence anyone accepts, and it should not be.

What changes is the shape of review, not its existence. Reading every line does not survive contact with five agents running in parallel, and a human skimming a nine-hundred-line diff at six in the evening produces a signature without producing knowledge. The policy that holds is review in proportion to blast radius: copy and styling get a skim, while auth, payments, permissions, personal data and migrations get read line by line, every time, by someone who could have written them.

Two things make that practical. Being able to see a diff per agent rather than one merged pile tells you who changed what when three of them worked in the same repo. And attaching the conversation to the commit answers the question that actually costs time six months later, which is never "what changed" but "why".

For anything with a user interface, the check does not stop at the diff. An agent driving a real browser can walk through the flow it just built and report what it saw, which catches the class of bug that reads perfectly well in source.

We wrote a whole article on where to spend that attention: should you still review your AI agent's code.

Link 6: shipping, and closing the loop

Shipping is the easy half of this link. The half that gets skipped is telling the person who asked.

It is also the half with the highest return. A user who reports something and later hears that it shipped reports the next thing. A user who reports something into silence stops reporting, and you lose the input that fed link one. When a ticket that came from a public request is closed, the person who filed it should hear about it without anyone remembering to send an email.

Before that, there is usually someone who needs to see it working and does not have your development environment: a client, a designer, a colleague on another continent. A public HTTPS URL pointing at your local machine turns that from a deployment into a link, and the feedback that comes back goes straight into link one.

The chain closes. That is what makes it a job rather than a queue.

What actually shrank, and what actually grew

Read that table honestly and the anxiety changes shape. The parts that shrank are the parts that were easiest to hire for. The parts that grew are the parts that need someone who understands the system, the users and the consequences. That is a harder job, not a smaller one, and it is a good deal less lonely than the version where you typed all day.

Where AgentsRoom sits in all this

We build the tool that holds the whole chain, because the alternative is six tools that do not know about each other.

That means the requests land in a board, sort themselves into ideas, get promoted into tickets, get scoped into something an agent cannot misread, get executed by one agent or a team of them on your machine or a remote one, get reviewed per agent with the conversation attached, and get closed with the person who asked being told. One window, one place where the state of the work is true.

The individual pieces exist elsewhere. The connections between them are what nobody was shipping, and the connections are where the work leaks.

Questions people actually ask

Will AI replace software developers?

It replaced the typing, not the job. Writing code is one link in a chain that also contains hearing what users need, deciding what is worth building, specifying it precisely, running the work, checking it, and shipping it. Agents collapsed the cost of one link, which made the other five the bottleneck. Fewer people will be paid to produce lines. More people are being paid to decide which lines should exist and to answer for them once they are live.

What does a developer actually do when agents write the code?

Six things, and only one of them used to be visible on a screen full of code. You collect what people are asking for, you decide what is worth building and in which order, you brief the work precisely enough that an agent cannot misread it, you run several pieces of work at once without losing track, you review in proportion to what each change can break, and you ship and tell the person who asked. The craft moved from producing the change to specifying and owning it.

Do you still need to know how to code?

Yes, and more than before for reading. You no longer need to remember the syntax of a language you touch twice a year, because the agent writes it. You do need to open a diff and know within seconds whether a migration is reversible, whether an auth check moved, whether a query will hold at ten times the traffic. Someone who cannot read code cannot review an agent, and someone who cannot review an agent is not steering it, only hoping.

What breaks first when you hand coding to agents?

Prioritisation. When building takes an afternoon instead of a fortnight, the cost of building the wrong thing drops out of sight, so it gets built. Teams end up with more shipped features and no more solved problems. The second thing to break is the feedback loop: user requests arrive faster than anyone can sort them, so they pile up in chat threads and are lost, and the same request gets built twice because nobody noticed it was the same one.

What is the hardest skill in this new workflow?

Writing a brief an agent cannot misread. An agent will not push back on an ambiguous instruction the way a colleague does, so it fills the gaps with a plausible guess and delivers something coherent and wrong. The people who get good output are not the ones with clever prompts, they are the ones who keep reusable context in place: committed convention files, a saved procedure per recurring task, a project memory the agents read before exploring, and screenshots or sketches instead of paragraphs describing a screen.

Should coding agents run on your machine or on a remote one?

Both, chosen per task. Anything you want to watch, interrupt or correct mid-flight belongs on the machine in front of you. Long, well-specified, low-ambiguity work belongs on another machine you own or a server over SSH, so a two-hour job is not holding your laptop hostage. The deciding question is not power, it is how likely you are to need to intervene.

The short version

The job did not disappear. It moved out of the editor and into the chain around it.

If you want a single thing to change this month, pick link one. Everything downstream of it is wasted effort when it is pointed at the wrong problem, and it is the only link where an hour of your attention still beats an hour of agent time by a factor nobody can measure.