The Work We Hand Over and the Work We Keep

I have been spending a lot of time working with coding agents lately, and I enjoy what they let me build. Things that would have taken much longer before are now easier to explore, and I have found that exciting.

But I have also been thinking about what happens to the parts of engineering we enjoy doing ourselves.

Writing code, investigating a difficult bug, or gradually figuring out the right shape for a solution can be satisfying in ways that have little to do with how quickly we get to the result. And I wonder how that changes when more of those activities become something we can delegate.

Two kinds of satisfaction

There is a difference between being pleased that a problem is solved and enjoying the process of solving it. Software has always offered both, often in the same afternoon. You can care about the person who can finally use a feature and also enjoy the small moment when a failing test makes sense. The last time that happened to me it was a timezone bug, and the moment it clicked was worth more than the fix.

Stack Overflow's 2026 task-satisfaction results resist a simple story of lost enjoyment. Among 12,125 respondents to that question, 60.1% reported improved satisfaction with implementation when using AI, while 19.9% reported a decrease. It is a self-selected survey: it captures how developers describe their experience, but it cannot establish what caused those differences.

I find that split interesting because we often talk about repetitive or tedious work as though everyone agreed on what belongs in that category. A split in satisfaction does not show that people disagree about which work is tedious, but it leaves plenty of room for it. The debugging session one person gladly hands over might be the part another looks forward to, and calling it toil often says more about who got to name the task than about the task itself.

And the people reporting more satisfaction deserve to be taken seriously. The numbers do not come with faces, so picture someone who used to dread untangling an unfamiliar build system, now spending the day shaping a product they care about. They have gained something they wanted, and we would be wrong to call that a less meaningful relationship with engineering because there is less typing involved.

I am not sure we always notice which part of the old work was the rewarding one, or that we ever had reason to. The work never made anyone choose. An agent that takes over part of it makes that a question someone has to answer.

The name on the pull request

In engineering teams, ownership usually means responsibility. Your name is on the change. You understand what it does, and you will help when it fails. Feeling that something is yours is another matter, and it is rarely what anyone asks about when a change is reviewed. You can approve a solution responsibly and feel almost nothing for it. How much of the code came from your own hands was never a good measure of either.

We miss this most easily when we are reassuring someone that their role still matters. Explaining that they remain accountable answers a real engineering question. It may leave their personal one untouched: whether they recognise their own contribution in what they are now responsible for.

A 2026 experiment by Elena Hayoung Lee and colleagues looked at ownership in writing tasks with 269 participants. People instructed to copy AI output reported less ownership than those who drafted first and refined with AI, or worked without it. The latter two groups did not differ significantly. Yet the copy-output group reported greater immediate enjoyment and satisfaction with the result.

A short writing task is nothing like a year of maintaining software with agents, and I would not build a rule about engineers on it. What stays with me is that the two did not move together: the people who copied reported enjoying the result more and feeling it was less their own.

An implementation can be correct and understandable without feeling like something you helped bring into being. Perhaps you can explain every decision in it, but you cannot remember forming any of them. For someone else, having shaped the behaviour and kept changing the result until it matched what they wanted may be enough to feel closely involved. Both can happen with a green test suite.

Missing the making

Writing code can be a craft as much as a means of delivery, something a person wants to become good at and enjoys becoming good at. Finding the small reproduction for a bug, changing the shape of a function until the problem became easier to see: there was satisfaction inside those acts.

Competence is not what is at stake here. You might keep all the judgment needed to evaluate a change, the kind hands-on work tends to build, and still miss making it. Missing an activity does not require evidence that losing it will make you worse at your job.

Adam Alami and colleagues heard a version of this in a September 2026 preprint: interviews with 21 software practitioners at one company, a year into its AI adoption. Some missed the connection between their daily work and the craftsmanship that had given it its point. It is a small window — one company, and no way to separate the tools from how they were introduced. But some of the people in it kept using the tools and missed the craft anyway.

There is no contradiction in appreciating what an agent did and wishing you had been more involved in doing it. I would rather find out which part someone misses than explain why they should be glad to have moved beyond it.

The code that stood in the way

For some engineers the interesting part was always deciding which version of a product to build, and the implementation was what stood between them and finding out. Delegation can make their day feel closer to what drew them into the profession.

Anthropic is an unusual place to study this, given that it builds the tools its employees are using. Still, its December 2025 study of its own engineers and researchers included both responses: people who missed coding and people who enjoyed collaborating with Claude or realised they cared more about what code enabled. Its October 2026 report describes more work going into tools for directing agents, which suggests where some of its engineers' days now go, though not whether they like it.

Having worked on building an AI harness around my team's workflow, I can relate to some of that excitement. Designing how agents work together, defining their boundaries, and figuring out how to make the process reliable are interesting engineering problems in their own right. But enjoying the process of building those workflows does not necessarily tell me how another engineer feels about spending most of their day working inside them.

The choice to delegate

The experience changes again when handing work over becomes an expectation. Choosing to let an agent handle a task because you would rather work on something else is one thing. Wanting to do it yourself and feeling obliged to delegate leaves you with a different relationship to the same afternoon.

In self-determination theory's account of work motivation, autonomy is the feeling that you choose how you act. Competence is the feeling of being effective, and neither asks you to do everything unaided.

Applying it to coding agents is my reading, not the authors'.

An agent could help you feel more capable while the rules around its use leave you with less choice. Or it could expand both: you can tackle more of the problem and decide which parts deserve your own attention. In conversations about agents, the word autonomy slides between two meanings: how freely the agent can act, and how freely you decide what to do with your own day. Only the second is the autonomy the theory is talking about.

In Atlassian's State of Developer Experience 2026, 41% of developers said they sometimes use AI more than necessary because they feel expected to. The first article in this series treated that figure as a measurement problem; the question here is how much choice sits behind the usage. Even without knowing whether that pressure costs anyone their satisfaction — and the survey cannot tell us — it is hard to read every act of delegation as a preference after a number like that.

The pressure rarely needs to be stated. Once delegation becomes the default, keeping a task starts to look like something that needs a reason. It shows up in the small pause in a planning meeting when someone says they want to implement an awkward part themselves. Or in the expectation that they will explain why an agent could not do it.

Nor should we assume that someone who keeps one task for themselves wants to work that way on everything. You might happily delegate a migration on Monday and want to work through a similar one on Friday because this time the problem catches your interest.

Room for more than one answer

A single question about whether someone likes using AI was never going to capture this. In a July 2026 preprint surveying 448 developers at Microsoft, willingness to give AI control depended on the task and on the person. Developers who identified more with a task wanted to keep more of its decisions. Those with more AI experience were readier to hand them over — though from a single snapshot there is no telling which came first, the experience or the readiness.

Preferences like these make poor permanent labels. Enjoyment may change with familiarity, although someone can become highly skilled with agents and continue to prefer doing some work directly. And the same person might feel differently depending on the problem, the context or what they find interesting that week.

For people leading teams, much of this comes down to noticing which parts of the work someone reaches for when they have a choice, and treating that as information about the work rather than a verdict on how well they have adapted. One person might want to own the investigation before asking for an implementation; another, more room to explore product behaviour while agents handle the code. Neither fits on a scale of who has embraced the new way of working.

There are limits to how much a team can accommodate. Software has to be reliable, work has to be shared, and there will be responsibilities nobody particularly enjoys. Sometimes a delivery constraint prevents an arrangement someone would prefer. Saying that plainly leaves more room for an honest conversation than recasting their preference as reluctance to adapt. What I would like to avoid is making people defend their enjoyment of the work as though it were a technical objection. They still need to understand and stand behind what they ship. Within that responsibility, there is usually more than one way to take part, and I do not see why everyone has to pick the same one.

Final thoughts

Whether what people miss will fade as working with agents becomes ordinary, or last because the activity itself has changed, is not something anyone can tell yet. The research gives us reasons to take both possibilities seriously. It does not give us an agreed destination for what an engineer ought to enjoy.

You may feel more connected to your work now because you can finally build the things you had in mind. You may miss the part where your own understanding gradually became working code. Or both, in the same project, depending on the week.

I would like us to be able to acknowledge those different experiences without having to defend our place in the profession first.