Everyone is measuring throughput and how much their developers are using AI. Then something comes out of the agent pipeline wrong, and somebody fixes it. They fix the bug. They don't fix whatever produced the bug.
Several people on your team already deal with pieces of this. A tech lead who is just doing a good job. A developer concerned about token costs, with little visibility into the bill. Somebody who notices how often work fails on the way through.
None of them own it. Nobody's filing bugs against the pipeline itself. It gets handled ad hoc, in the margins of other jobs, usually by people who don't have the authority to change the process that caused the problem.
Then the monthly token report comes in. And things are still moving too slow.
Last issue I argued for people building the requirements, people validating the work product, and the part in between running without them. So who builds and maintains that part.
Every time something comes out wrong you have two options. Put a person in the middle to catch it next time, or change the pipeline so it stops coming out wrong. This job is the second one, made over and over. I've been calling the person who does it an AI-native pipeline engineer.
A feature came back from acceptance with the UX wrong. It wasn't that an agent did a bad job. The spec never said in detail what the UX should be.
I could have put a reviewer on UX before merge. I could have handed the missing UX to another agent. Neither one fixes anything, because the next feature arrives with the same gap in the spec. That's what most teams are doing right now. They fix it on the fly, and the next one costs them the same as the last one. Nothing compounds.
The correction went into the prompt that gathers requirements, and the next feature arrived with that question already asked.
It feels like training a model. You look at the result, then go back and adjust the thing that produced it.
Nobody owns cost either, and that one's harder because nothing looks wrong. It usually sits with somebody outside engineering, far away from where it gets created.
My agent prompts grew, nobody was watching them grow, and by the time I went back in to optimize they were burning around three times the tokens they needed to. Some of that was tightening the prompts. Some was moving work out of the context entirely and into skills that load only when they are needed. The rest was fixing how the agents talk to each other.
When the work's coming out fine, nobody's looking. You find out when the bill shows up.
You'll also have people still standing in the middle, because nobody goes from zero to sixty at the start. Maybe your security review isn't there yet, or front end testing is thin, so somebody's covering those stretches manually, or with vibe coding. Every one of those is a work item for this job, not something you live with.
So what does this person measure. Tokens per engineer answers a question about individuals. What you want to know is how much work cleared without a person having to step in. Keep it next to escaped defects and rollbacks, because on its own it can be gamed by reviewing less.
People always ask about production, so let me be exact. An agent does my production deploys. It doesn't decide to. I validate and accept the work first, and then the deploy runs itself. I still make the call. I just don't run it.
I kept working on that pipeline until it could be trusted with that step.
That's where speed actually comes from. A change to the pipeline makes everything after it faster. A change to the code fixes one thing. If nobody owns the pipeline, you pay full price for every feature you build.
What I keep seeing is orgs depending on people who already have a day job to do this. It's not a designated responsibility. It's absorbed by whoever noticed the problem first.
If you've made the AI-native pipeline engineer a real job, I want to hear how you scoped it and where it sits.