The product engineer
One person owns the feature. All of it.
From the customer signal that starts it to the usage data a week after release. Insight, spec, design judgment, code, tests, security, launch, docs. This is a new job, and it changes more in your HR system than it does in your repo.
The agent does the work. The engineer makes the call.
Ten stages. Read the left column to see why one person can hold it, and the right one to see why it still needs a person.
Stage
The agent does
The product engineer decides
-
Insight
Agent Transcribes every call, clusters reviews, watches telemetry and flags what changed.
Engineer Decides which signal is worth a product change, and which is noise from one loud account.
-
Priority
Agent Ranks opportunities against outcome data and starts work inside the agreed goals.
Engineer Sets the goals, and says no to the thing that ranked well but does not belong.
-
Spec
Agent Writes the executable spec and the acceptance criteria from shared context.
Engineer Resolves the ambiguity the agent escalated. Owns what the feature is actually for.
-
Design
Agent Generates flows, states and device variants from the design system.
Engineer Judges whether it is a good experience. This one never fully delegates.
-
Build
Agent Implements and integrates the change across repos.
Engineer Makes the architecture call, and defines what the agent is allowed to decide alone.
-
Quality
Agent Runs regression, security and device checks on every change, and blocks failures.
Engineer Sets the bar. Decides what a blocking check is, and what an accepted risk looks like.
-
Security
Agent Scans dependencies, flags exposure, applies the known fixes.
Engineer Owns the threat model, the data boundary and anything that touches customer trust.
-
Release
Agent Ships behind flags, watches the rollout, restores the known-good version on failure.
Engineer Decides the moment, the blast radius and the customers who see it first.
-
Docs
Agent Writes and publishes guides, API docs and release notes with the change.
Engineer Resolves the behavior the agent could not describe, which is usually behavior worth fixing.
-
Adoption
Agent Measures usage, surfaces where people drop out, drafts the follow-up.
Engineer Reads it a week later and decides whether the feature actually worked.
We think this is better work. Here is the argument.
Not a morale slide. Four specific things that change about the day.
You see the whole problem
The reason engineers ask to talk to customers is that specs arrive stripped of the thing that made them worth building. When you hold the chain from the signal onward, that information is simply yours. Most of the frustration of the job was never the code.
You see the consequence
You ship, and a week later you read whether anyone used it. In a handoff model that feedback lands on the PM, and the person who built the thing finds out by accident. Closing that loop is the single change engineers react to most.
The coordination tax is gone
No refinement ceremony to translate a spec you could have read. No waiting three days on a review. No status update whose only purpose is telling someone else what a system already knows. This is the recovered time, and it is most of the gain.
The work left is the work worth doing
What agents take is the repetitive, mechanical and procedural part. What stays is judgment: what to build, what good looks like, what risk is acceptable, what to tell the customer. Harder job, and a far more interesting one.
We are stating a belief here, not a benchmark. It matches what we see in the squads we have run, and it is the part of the model you should test against your own people before you commit to it.
Six things this breaks in your HR system
A new production line needs a new people system. These are the parts that stop working first, in the order they usually surface.
01
Job architecture
Six families become one ladder.
Product manager, product owner, frontend, backend, QA and part of the writer role converge into a single job family. You keep a product lead and a designer per squad, and you move QA, documentation and marketing expertise to a shared pool that serves several squads. Expect your job catalogue to get shorter and your levelling framework to get harder.
02
Hiring
You stop screening for output and start screening for judgment.
A coding test where the candidate cannot use agents now measures a skill the job does not require. Screen instead for written clarity, for the ability to decompose an ambiguous problem, for taste in a product decision, and for how someone reviews work they did not write. The last one is the single best predictor we have found.
03
Seniority
Levels stop meaning scope of code and start meaning scope of consequence.
When an agent writes the implementation, years of experience no longer separate a mid from a senior. What separates them is blast radius: how much ambiguity they absorb without escalating, how large a surface they can be trusted to change, and how good their judgment is on the calls that cannot be automated. Rewrite the ladder before you promote anyone against the old one.
04
Performance
Tickets closed and lines written become actively misleading.
Both go up when agents arrive and neither tells you anything. Measure the outcome the engineer owned: did the feature ship, did it work, did it need a rollback, did customers adopt it. Measure it per feature, per named owner, and make it visible. This is more honest than the system it replaces, and some people will find that uncomfortable.
05
Compensation
One role spanning three former families breaks your bands.
A product engineer does work that used to sit in a PM band and an engineering band at once. If you map the new role onto the old engineering band, the strong people leave within a year. Plan the re-banding as part of the transition, not as a cleanup exercise eighteen months later.
06
The transition
Nobody gets reassigned by an algorithm.
Most developers become product engineers, and most of them want to. Some POs become product leads, some become product engineers, and some will not want either, which is a legitimate answer that deserves a real conversation. The capacity the model frees goes to the squad that has been waiting a year for it. We do not touch staffing conclusions until the numbers are in.
What your people will ask
These come up in the first week, every time. The answers below are the ones we give in the room.
Is this not just three jobs on one salary?
It would be, if the volume stayed. It does not. Agents absorb the implementation, the tests, the first review, the release mechanics and the documentation. What lands on the engineer is the decision layer of each stage, which is a fraction of the hours and most of the interest. If a squad reaches Level 4 and people are working longer, the workflow is wrong and we will say so.
What happens to the people who loved writing code?
They still write code, on the parts that matter: the architecture, the hard bug, the thing the agent got subtly wrong. What they stop doing is the third CRUD endpoint of the week. In every squad we have run this with, that trade is welcomed. The engineers who struggle are the ones who liked the predictability of a ticket queue, and that is worth naming early rather than discovering in month three.
Do we lose deep specialists?
No, you relocate them. QA, security, documentation and product marketing expertise moves out of the squad and into a shared pool that sets the standards the agents enforce and handles the cases the standards do not cover. Their leverage goes up, because a standard they write is now applied automatically on every change in every squad.
What about junior engineers?
This is the hardest honest question in the model. The traditional junior path was learning by writing the easy tickets, and agents now write those. The path that works instead is ownership of a small, low blast radius surface from day one, with review of agent output as the core training. It requires more senior attention, not less, and you should budget for that.
Who is accountable when an agent breaks production?
The product engineer named on the feature. That is the point of naming one. The agent is a tool with a scope you defined, the same way a CI pipeline is. Accountability does not move to the vendor, the model or the platform team.
Does this mean layoffs?
That is your call, not ours, and we will not make it for you by publishing a headcount target. What we produce is a measurement: the same scope held with fewer people, or more scope held at the same headcount. Most of the CTOs we work with choose the second, because they have a backlog of work they have never had capacity for.
The people work is half the engagement.
Two workstreams run in parallel for the full 30 days. One is the tooling: an agent-ready repo, connected signals, reusable agents, scoped access, tested rollback. The other is this page, applied to your squad. We work alongside your PM, your designer and your engineers, answer doubts with evidence from their own repo, and coach the squad until it operates the workflow without us.
We are not an HR consultancy and we do not rewrite your levelling framework for you. What we do is put the new role in front of real people on real work, so that the conversation your HR team has to have is about something they have seen, rather than something they have been told.
Find out how far your squad already is.
Twelve questions, four minutes. You get your level, a score per phase, and the three steps holding you back.