When AI Agents Write the Code, What Do Developers Actually Do?

It's a reasonable question. Agents can now gather information from requirements, prepare implementation plans, write code, run tests and review changes before an engineer ever sees a pull request. Much of the activity that once involved moving between tools, writing prompts and managing each stage can happen within a coordinated workflow.

The developer's role is becoming less about manually managing every stage of development and more about directing the work, evaluating the results and making the decisions that matter.

From Operating the Process to Supervising It

In a traditional development workflow, engineers are responsible for both carrying out the work and managing how it progresses. They interpret requirements, decide how to approach a problem, write code, test changes and respond to reviews. AI-assisted coding made parts of this faster, but developers still had to direct each activity.

As we outlined in From AI-Assisted Coding to Agentic Software Development, our testing of agentic workflows has shown around three to five times less hands-on developer time per ticket. That's an encouraging early result, rather than a measure of overall delivery speed. But it raises an important question: if agents are taking on more of the execution and coordination, where can engineers contribute the most value?

The opportunity isn't simply to reduce developer involvement. It's to redirect that time towards evaluating plans, challenging assumptions and making the decisions that determine whether the software is right.

The Importance of Engineering Judgement

In our workflow, agents investigate the requirements and existing codebase before preparing alternative implementation plans. An agent evaluates those options and recommends an approach, but an engineer must approve the plan before development begins.

A technically valid solution might introduce unnecessary complexity, create maintenance problems or overlook a dependency elsewhere in the product. Engineers review the proposed implementation with the ability to approve the plan, request changes or stop the work entirely.

That review involves questions an automated plan cannot settle on its own. Is this the right solution for the product? Does it introduce unnecessary risk? Are there dependencies or business requirements the proposed approach hasn't adequately addressed? Agents can investigate these considerations and recommend an approach, but the engineer remains responsible for deciding whether to proceed.

As implementation becomes easier, the ability to recognise a poor decision before it becomes working software becomes more valuable.

Better Requirements Become More Important

There's another consequence of letting agents carry out more of the process. The quality of the information they receive has a greater influence on what gets built.

Agents can read tickets, retrieve specifications, examine related code and follow established development rules. But this information only tells them so much about what a product needs to achieve. They don't necessarily have the context that comes from speaking to stakeholders, understanding user needs or recognising a problem that hasn't been properly defined.

If the original requirement is unclear, even strong capabilities don't guarantee the right outcome. An agent might produce code that passes its tests while missing what the user actually needs. If the acceptance criteria are incomplete, the tests may simply confirm that the wrong interpretation has been implemented correctly.

That makes the work before development begins more important. Clear requirements, well-defined acceptance criteria and an understanding of the wider product become essential inputs. It also means developers need to challenge requirements rather than simply accept them. Sometimes the most valuable thing an engineer can do is identify what's missing from a ticket before any code is written.

As we explored in When AI Has the Answers, Are We Asking Enough Questions?, speed makes it easy to answer a question nobody checked was the right one.

Where Does Judgement Come From?

There's an obvious challenge to all of this. If engineers increasingly supervise the work rather than carry out every task themselves, how do they develop the judgement that supervision depends on?

It's a real risk. Experience has traditionally come from doing the work: writing the code, finding why it broke and learning which approaches hold up. If more of that is handled by agents, teams can't assume judgement will simply appear.

Our view is that judgement has to be developed deliberately. Reviewing and questioning plans, understanding why a recommendation was chosen and investigating failures can all contribute to that development. But teams also need to ensure engineers continue gaining practical experience of the systems they're responsible for. Supervision needs to be an active discipline, not simply approving whatever an agent produces.

Accountability Doesn't Move to the Agents

Automated reviews, testing and validation provide additional assurance, but they don't transfer responsibility from the team to the technology. An agent can identify a problem, suggest a correction or report that checks have passed. Engineers still need to understand what those findings mean and whether the software is suitable for its purpose. We'll look at how that assurance works in more detail in the next article.

That's why we've deliberately kept human approval at two points: before implementation and before changes are merged. These aren't simply checkpoints added to an automated process. They're where engineering judgement determines whether the work should proceed.

This reflects our wider approach to AI-native product development. Technology can change how work is carried out, but successful products still depend on understanding the problem and taking responsibility for the outcome.

Agentic development doesn't remove the need for experienced developers. It changes where their experience matters most.