When I joined Cobrainer, my title was Cloud Platform Engineer. In 2024 that title made sense: design the AWS architecture, maintain backend systems, keep the platform running. In 2026 it no longer describes the work. I do not think of myself as a platform engineer any more, but as part of Product & Engineering: someone who contributes to the whole product, not one layer of the stack.
There was no big announcement. The work changed one task at a time, until the title stopped describing my day.
I still own the platform. But I also translate product requirements into architecture, ship frontend and backend features, and build services where agents act under human approval. Writing the instructions those agents follow is now part of the job itself.
That opens up a lot of possibilities. It also raises an uncomfortable question: when an agent takes over work you spent years learning to do, where does your contribution begin and end?
My answer is taking shape in the work: deciding what matters, giving agents enough context, and knowing when their output is safe to use. The execution is increasingly shared. The responsibility is still mine.
That is why I think the useful starting point for AI transformation is the work inside a role: its tasks, its handoffs, and the decisions someone still has to own.
What changed in my day
This is one person's experience, not a forecast for every engineer. But putting the tasks side by side makes the shift visible.
| Task | A year ago | Today |
|---|---|---|
| Shape product and roadmap decisions | Rarely | Regularly, with product |
| Translate product requirements into architecture and acceptance criteria | Occasionally | Core of the job |
| Design tenant-isolated cloud architectures | Me | Me, with agents exploring options and drafting decision records |
| Provision infrastructure as code | Me and agents | Agents draft; I verify the plan and blast radius |
| Build frontend and backend capabilities | Me and agents, mostly backend | Mostly agents; I review based on risk |
| Build agent execution services with human approval and audit trails | Did not exist | New, and growing |
| Validate security and resilience | Me, partly manual | Agents write and run tests; I approve the release |
| Operate observability and incident recovery | Me | Agents investigate; I decide |
| Write specs and agent instructions | Regularly | Core of the job |
The responsibilities in the old description are still here, but much of my effort has moved towards defining and checking the work. Alongside that, new tasks have appeared: designing approval boundaries, making agent actions traceable, and writing instructions precise enough to act on.
“Agents write the code” sounds simple. Deciding whether that code solves the right problem, respects tenant boundaries, and can be operated at three in the morning is still engineering.
Anthropic describes a similar shift in its own workforce. Work on agent instructions, reviews and monitoring grew from 10% of the average employee's interactive Claude sessions in fall 2025 to 22% in spring 2026. Its report also describes human attention becoming a bottleneck as agents produce more output. This is evidence from one unusually AI-intensive company, not a prediction for every workplace. But the growing effort required to direct and review agents is a useful signal. 1
A job title hides too much
Two engineers can have the same title and spend their weeks doing very different things. One might maintain a stable service; another might spend most of their time untangling requirements across teams. Their exposure to automation will differ too.
This distinction predates today's agents. In 2016, Arntz, Gregory and Zierahn estimated that about 9% of jobs across 21 OECD countries were automatable under their task-based approach, substantially below earlier occupation-based estimates. They accounted for differences in what people actually do within the same occupation. That number is not a forecast for today's AI. The lasting lesson is that the unit of analysis matters. 2
For engineers, this should feel familiar. You would not estimate a system's performance from its name in the service catalogue. You would look at what it does and where it spends its time.
We need that same curiosity about our work.
Follow the handoffs
Even a task can hide a whole workflow. “Provision infrastructure” might include clarifying requirements, drafting a change, checking permissions, reviewing the plan, applying it, and verifying the result.
Demirer and colleagues model work as chains of interdependent steps. In their model, the cost of handing work between humans and AI can make it worthwhile to automate a whole sequence, even when a human would perform one isolated step better. Where a step sits in the chain matters. 3
Consider an agent that drafts an infrastructure change and runs its checks. If I have to reconstruct its reasoning before I can approve the plan, generating the code faster may save less time than expected. If it gives me a clear diff, relevant test results and a credible rollback path, the review becomes easier.
The approval still serves a purpose. The engineering challenge is to give the person approving the change enough evidence to make a good decision.
“Six out of ten steps are automatable” tells me very little until I know how those steps connect.
Ask what people want to keep
There is a human question here that a capability benchmark cannot answer.
Shao and colleagues gathered preferences from 1,500 workers across 104 occupations and compared them with AI experts' assessments of technical capability. The correlation between workers' desire for automation and assessed capability was weak: Spearman ρ = 0.17. Feasible automation and wanted automation often pointed to different tasks. 4
That matters because work is also a source of pride, identity and learning. A task someone wants to hand off may be the task a colleague enjoys most. And work an experienced engineer can safely delegate may be how a junior engineer learns to recognise a bad solution.
I think we owe people a better conversation than “this percentage of your job can be automated.” Start with what frustrates them, what they value, and what they need to learn. Then work through what should change together.
Start with one role and a real week of work
For engineering and HR leaders, I would start small:
- Map the work with the people doing it. Take one role, list its tasks, and break a few into steps. Include the interruptions and judgement calls that never made it into the job description.
- Trace one workflow end to end. Mark where AI can assist, where it can complete a step, and where a person must decide. Look closely at the handoffs and the evidence needed for review.
- Separate capability from preference. Ask both what AI can do reliably today and what people want help with. Record uncertainty and revisit the assessment as tools and workflows change.
- Make room for the new work. Instructions, review, monitoring and recovery take time. Put them into role descriptions and development plans, including how less experienced colleagues will learn.
- Agree how the map will be used. Use it to redesign work with the team. It should not become a ranking of whose job is easiest to remove. Involve employee representatives early where relevant.
The first map will be incomplete. It only needs to be concrete enough for someone to say, “That is not how this task actually works,” and help you improve it.
Why we are working on this at Cobrainer
At Cobrainer, we are building on this idea across our Work Architecture, Talent Intelligence and AI Transformation capabilities: making the tasks inside roles visible, so organisations and their people can understand and shape how the work changes.
We will share more in our Fall Release, followed by posts about the engineering behind it.
For me, this is already personal. The title I joined with describes a 2024 job. In 2026 the line between product and engineering has blurred: I contribute across the whole product, while the decisions I make still carry consequences for the platform and the people using it.
A useful task map gives us somewhere to start that conversation. It lets us talk about what is changing while there is still time to shape it.
Which part of your work has changed most this year, and how do you feel about that change?
References
- Wilmers, N., Catipon, R., Massenkoff, M., & McCrory, P. (2026). How employment is changing at Anthropic. Anthropic.
- Arntz, M., Gregory, T., & Zierahn, U. (2016). The Risk of Automation for Jobs in OECD Countries: A Comparative Analysis. OECD Social, Employment and Migration Working Papers No. 189.
- Demirer, M., Horton, J. J., Immorlica, N., Lucier, B., & Shahidi, P. (2026). Chaining Tasks, Redefining Work: A Theory of AI Automation. NBER Working Paper 34859.
- Shao, Y., Zope, H., Jiang, Y., Pei, J., Nguyen, D., Brynjolfsson, E., & Yang, D. (2026). Future of Work with AI Agents: Auditing Automation and Augmentation Potential across the U.S. Workforce. arXiv:2506.06576v3.
Top comments (1)
Thank you for sharing! To answer your question: The core part of my role - designing user flows for our product - has changed dramatically. And I was very afraid of that change when I started with AI.
I loved working in figma and taking the time to refine every little detail. Now, I have not opened figma in 5 months and I love it even more.
But - these new capabilities also come with new responsibilities - you need to spend a bit of time understanding the technical details behind what you are doing - so you don't create unwanted damage. And you need to design systems that help your teammates close their own skill gap so they can use AI in the best way.
So there is a lot of back and forth between mastering a skill yourself and then immediately designing the system afterwards that helps your team to do the same.
Exciting times!