From author to manager: how a developer's work changes with agents

Agents have made writing code a lot cheaper. They haven't made it any cheaper to understand what exactly to build, or to check what came out. That's why the most interesting part of working with agents happens before and after the code gets written: who sets the task, who decides the result is good, and how to choose how much work to hand to the agent in the first place.

Below we'll look at how research and reports from the last two years describe this: four ways to work with an agent, picking the way that fits the task, and what's called "intent and a quality bar". In the second half, a bit about why a developer's role is getting broader than just writing code. The data is as of September 2026. Numbers sit in separate blocks with a link to the source. Where I'm retelling the authors' position, I name them, and I label my own conclusions as mine.

Four ways to work with an agent

The clearest framework came from Jared Spataro of Microsoft in May 2026. He describes four ways a human and AI split the work. The framework is easy to follow, and any developer will recognize in it their own path with these tools.

The higher the step, the less you write by hand and the more you decide up front and check afterwards. An author keeps quality in their head while writing. A director no longer sees how the code came together, so everything that matters to them has to be said before the work starts and checked after it's done. The orchestrator only gets a name here. It's a big topic of its own, with its own tools (worth getting to once the first three ways feel solid).

A way for each task, not a ladder

It's easy to read the framework as a ladder: first you're an author, then you work your way up to orchestrator, and the higher the better. Spataro says the opposite outright. The goal isn't to move every task to the fourth way, it's to pick the right one for each workstream.

In practice it usually boils down to four questions:

• how clear is the goal. If you don't yet know yourself what the result should be, it's too early to hand over the whole task;
• can the result be checked automatically. Good tests let you give the agent more slack, because a mistake gets caught by the check, not by you staying alert;
• what does a mistake cost. A typo in a tooltip is easy to fix, a wrong money calculation is expensive;
• does the task repeat. For a one-off task it doesn't pay to build a separate process, for a weekly one it may well pay off.

Here's how that plays out on specific tasks:

I think these numbers are worth keeping in mind. Most people being cautious doesn't mean they're falling behind. People pick the way based on what a mistake costs, and honestly, that's the right call. If you work as an editor on a task where mistakes are expensive, you're not "underusing" the agent.

In Claude Code you set this choice directly. Plan mode and permission rules work like a dial you adjust yourself. For an expensive task you turn on planning before edits and confirmation for risky actions, for a routine one you give the agent more slack.

Intent and a quality bar

The more work you hand over, the more it matters what you say before you start. The Microsoft study puts it like this: the most effective AI users won't be the ones who do more, faster, but the ones who build their value around what only a human can do. Setting a clear intent, meaning describing the desired outcome and the quality bar, and thinking through how work is split between people and AI.

In development this idea has long had familiar names. Intent is basically the spec - what to do and why. The quality bar is the acceptance criteria and what Scrum calls the Definition of Done: a list of conditions under which the work counts as finished. From here on we'll just call it the bar for done.

Daniel Epstein of Microsoft, who builds agents using Agile, put it very concisely in the first article of the Agentic-Agile series (May 19, 2026): "Every capability is an issue. Every issue has acceptance criteria." In other words, every feature becomes a ticket, and every ticket comes with acceptance criteria.

It helps to write a task in two registers at once (sounds fancier than it is). For people, you explain why it's needed and for whom. For the agent, you write what to do, how to check it and what not to touch. Here's a made-up example of how the same request looks before and after. In the second version the first paragraph is for people, the rest is for the agent.

Before:

Add a CSV export for expenses, and make it work properly.

After:

Why: every month the accountant copies the team's expenses into their own
spreadsheet by hand. That's an hour of work plus mistakes in the totals.

Task: add an "Export to CSV" button to the monthly expenses page.

Done when:
- the file opens with a double click in a spreadsheet app, and names with
  accented characters display correctly without setting the encoding by hand;
- one row is one expense, column names in the first row;
- the amounts can be added up with a formula without editing any cells.

Don't touch: the expense storage format and the existing list screen.
Show me the plan first, and how you'll check each item.

In the second version the agent has almost nothing left to guess. More importantly, you have something to compare the result against: the three items can be checked by hand in a couple of minutes. The word "properly" from the first version can't be checked. You can only take it on faith.

The agent doesn't know what good looks like

From here on it's mostly my conclusions from the data, not the data itself. I'm saying so up front so I don't pass off opinion as a research finding.

An agent can do a great deal. Read an unfamiliar project, find the cause of a bug, write an implementation, run the tests, explain what it did. There's one thing it can't do: decide on its own what "doing it well" means for these users and this business. Without criteria it picks a plausible middle-of-the-road option and confidently reports it as done. The code can be neat, and the solution still the wrong one.

"Good" doesn't live in the code. It depends on who will use the result, what that person cares about and which mistakes are unacceptable. In the export example the agent could easily have produced a technically correct CSV that opens as garbled characters on the accountant's machine. From the code's point of view, everything is fine. For the task, not so much.

The takeaway is simple. Setting a criterion and checking the result against it is the part of the work you can't delegate. The agent can help you phrase the criteria, ask clarifying questions, suggest checks. The decision that the criteria are right stays with you.

Understand the process first

Where do criteria come from? Almost never from the code. They come from the business process: who will open the file, what they'll do with it next, what happens if a row goes missing or an amount gets rounded the wrong way.

The requirement "accented names display correctly without manual setup" didn't appear because that's the right way to write a CSV. It appeared because someone asked the accountant how they open files and saw that they do it with a double click, without the import wizard. A developer who knows the process writes this criterion right away. One who doesn't finds out a month later, from a complaint.

Companies are already noticing this and reshaping roles.

There's an opposing view on this too, and it's worth knowing. For example, the consulting firm Converteo, on its blog, describes the product manager, designer and AI product builder roles as complementary rather than competing: the first owns the "why", the second owns the user, the third quickly turns an idea into a working prototype. Converteo itself sells services in this area. Personally, I wouldn't bet on either version. For you the practical takeaway is the same either way: a developer who understands the client's process is worth more than one who waits for a perfectly written ticket.

Conversation as a working tool

Soft skills used to be presented as a nice add-on to technical skills. With agents that's changing. Quality criteria live in people's heads, not in the repository, and the only way to get them out is to talk.

Here's what actually turns out to be part of the job:

• ask. Not "what should I do" but "what will you do with the result" - people answer that one more precisely;
• clarify. Ask about the edge case before it turns into a bug: what do we do with an expense that has no category?
• write it down. If an agreement only lives in a conversation, the agent can't read it and a colleague will forget it;
• agree on boundaries. What's in the task and what isn't, and saying "that's a separate task" when someone asks you to "fix this while you're at it";
• explain the trade-off. "We can do it in a day without choosing a period, or in three days with it" - the decision is the client's, but you're the one offering the options.

None of these skills is about code, and each one directly affects what the agent will do. i.e. the quality of your conversations with people turns into the quality of the task you give the agent.

Everyone's a bit of a CEO

Put it all together and you get a familiar picture. Setting a goal, defining criteria, dividing up the work, checking the result and owning it - that's a manager's job. A developer working with agents does it every day, even if on a small scale.

The CEO metaphor gets one thing right: where the responsibility lies. A CEO can delegate almost everything except responsibility for the outcome. Same with agents. If an agent built an export that breaks the accountant's spreadsheet, it won't be the agent answering for it (you can guess who will).

It's also worth saying what the metaphor doesn't mean. It's not a promotion, and nobody becomes a manager because they launched three agents. Rather, you'll need manager skills earlier than people used to, as early as your first job. And there's a risk: developers have long grown their skills by writing code by hand, and that path is changing. Understanding the code you accept from an agent is still a must. Without it, review turns into "seems to work".

How to read this data

All the numbers above were published by companies that sell AI or products built around it. That doesn't make them false, but it's something to factor in. Here's the short version:

All the percentages here are people's self-assessment at a single point in time. They show what people think and expect, not what actually happened. The authors of the Work Trend Index 2026 state outright that the relationships in their analysis are statistical associations, not cause and effect.

It's useful to ask three questions about any number on AI and work. Who paid for the study? What exactly was measured: an opinion, an expectation or an actual outcome? Who was asked, and are those people like you? If the answers work for you, you can use the number. If not, it can still be interesting, it just carries less weight.

What it all comes down to

Everything above that sounds like report-speak turns into concrete habits when you work with Claude Code:

• a plan before the edit - that's your intent. ask the agent to first show what it's going to change and how, and compare it with what you wanted;
• acceptance criteria in the request - your bar for done. Two or three checkable items instead of "make it work properly";
• permission mode and permission rules - choosing the way. The more expensive a mistake, the more often the agent stops and asks;
• reviewing the diff and checking honestly - judging the result by your criteria, not by the agent's report;
• a short wrap-up: what was done, how it was checked, what wasn't checked - responsibility for the result, which you can't hand over to the agent.

Data as of September 2026. Research in this area comes out often, and the numbers go stale faster than the conclusions.