Here's the counterintuitive claim: adopting AI coding agents, without addressing how your product team works, makes product management harder in the near term. Not easier. The agents amplify the quality of what you give them — and right now, most PMs are producing worse inputs than they should be, for reasons that have nothing to do with their ability.

The Input Problem Nobody Is Talking About

The conversation around AI coding agents is almost entirely about the output side. How fast can it generate code? How accurate is it? How much does it reduce engineering time? These are real questions with meaningful answers. But they assume the input side is fine. It isn't.

Engineering output quality, in an AI-assisted context, is a direct function of input quality. A well-specified requirement with clear acceptance criteria, connected design context, and explicit constraints produces output that a competent engineer might review and ship. A vague story with disconnected specs produces hallucinated features, misaligned implementations, and expensive rework. The agent doesn't fill the gap — it amplifies it.

The organizations that are genuinely benefiting from AI coding agents have discovered this through trial and error. The ones still frustrated are usually fighting a requirements problem they've misdiagnosed as an agent capability problem. The agent isn't the issue. The inputs are.

What the Translation Tax Is

The Translation Tax is the accumulated cognitive overhead of converting context from one format to another at every handoff in the SDLC. A customer insight becomes a problem statement. A problem statement becomes a requirements document. A requirements document becomes a spec. A spec becomes a design brief. A design brief becomes engineering stories. Stories become test cases. Each conversion is necessary. None of it is judgment work.

That last sentence matters. Judgment work — deciding what problem to solve, evaluating solutions, validating outcomes — is what PMs are hired to do. Translation work — reformatting information, ensuring consistency, routing context to the right system in the right format — is overhead that falls on PMs because they're the ones who understand the intent well enough to convert it accurately. It's skilled labor that doesn't require the skill PMs actually have. It takes time. It compounds.

A PM at a mid-scale product organization might spend a third of their working week on translation work. More features, more handoffs, more conversion steps. The tax compounds as organizations scale. It is not sustainable at current pace, and it is getting worse — not better — as AI raises the quality bar on the inputs those agents need.

The Compounding Effect

Here's where it gets specifically worse. When a PM is buried in translation work — formatting user stories, updating tickets, synchronizing requirements across systems — they have less time for the upstream work that determines input quality: customer conversations, problem framing, careful specification of acceptance criteria. The overloaded PM produces rushed requirements. Rushed requirements produce worse agent outputs. Worse agent outputs produce more rework. More rework creates more demand on the PM's time for triage and clarification. The loop tightens.

This is not a PM performance problem. It is a process design problem. The PM is doing the work the process asks them to do. The process is asking them to do the wrong work.

The organizations where this spiral is most visible are the ones that added AI coding agents without changing anything upstream. The agents made engineering faster. The requirements that fed those agents got worse because the PMs were more overwhelmed, not less. Net result: faster generation of features that needed more rework. Some teams concluded that AI agents weren't ready. The agents were fine. The inputs were broken.

What "Removing the Tax" Actually Means

Removing the Translation Tax doesn't mean removing PMs from the process. It means removing the translation labor from the process while keeping the accountability in place. The distinction is important.

When a PM writes acceptance criteria in a structured format in the repo, an agentic coding tool can publish those criteria to the backlog as a story, generate test cases linked to the criteria, create a wiki summary for stakeholders, and maintain consistency between all of these as the requirements evolve. None of this requires the PM to open a backlog, copy-paste into a test management system, or update a Confluence page. The PM wrote the requirements once. The distribution was handled. Their time was preserved for the judgment work those systems can't do.

The result is not just efficiency. The quality of the requirements themselves improves because the PM had time to write them carefully. They asked the agent to review them for gaps before publishing. They had a conversation with a customer to clarify the edge case in the third acceptance criterion. They iterated once more before anything went to engineering. The inputs got better because the overhead of managing the outputs got lower.

What This Requires

Removing the Translation Tax requires something that feels counterintuitive at first: putting the repo at the center of PM workflow. Not the backlog. Not the wiki. The repo — the same version-controlled environment where engineering works — becomes the place where requirements live, where decisions are recorded, where context accumulates.

This is a genuine adjustment for most PMs, who have built their workflow around backlog tools for a decade. The practical barrier is lower than it appears: agentic coding tools handle the Git mechanics — committing files, pushing changes, managing branches — so PMs interact with the repo through the agent, not the command line. But the mental model shift matters. The backlog is a tracking mirror. The repo is the source.

It also requires that the repo be structured in a way that makes it AI-navigable — organized requirements formats, explicit acceptance criteria, connected design context, consistent conventions. An org's working standards encoded in a form the agent can use. This is not something a single PM sets up; it's an org-level infrastructure investment, governed at the leadership level, that pays forward on every interaction from the day it's installed.

The Distinction That Matters

The organizations that get this right understand a distinction that the ones struggling with it usually miss: AI automates the mechanical work. Judgment stays with people.

Generating a user story from acceptance criteria is mechanical. Deciding what the acceptance criteria should be is meaningful. Scaffolding test cases from requirements is mechanical. Determining whether a test failure reflects a product risk is meaningful. Publishing requirements to a backlog is mechanical. Deciding whether those requirements are right is meaningful.

This distinction is not a caveat. It is the design. The framework exists to make it operational — to be clear about which work belongs to AI and which belongs to humans, and to build the infrastructure that keeps the boundary sharp and the accountability clear. The PM's authority doesn't diminish. The PM's overhead does. That's not a smaller version of the same job. It's a different job — one more worth doing.

Update — June 2026: "Translation Is Free Now" Gets the Direction Wrong

The remarks discussed below were made by Matthew Wensing (VP Product & Design, customer.io) in conversation with host Aakash Gupta on The Growth Podcast, "How a VP of Product Uses Claude Without Producing Slop" (YouTube, published June 9, 2026). Full citation at the foot of this update.

There's a claim making the rounds that sounds like it refutes everything I wrote above. It comes from people who are actually using these tools well, which makes it worth taking seriously. Matthew Wensing put the sharp version of it on a recent podcast: the "blue-collar knowledge work" of turning a deck into a doc, a doc into slides, a Zoom transcript into a strategy summary — that work is being wiped out. The translation between one format and another is now almost free. "Spend the time thinking more seriously about the source," he says, and be deliberate about the target. The arrow in the middle is what AI handles.

He's right. And if you read this essay quickly, it looks like I argued the opposite — that translation is an expensive, compounding burden on PMs. So let me be precise about what changed and what didn't, because the reconciliation is the whole point.

Two different arrows wear the same word

When Wensing says translation is free, he means form-factor conversion: same content, new container. Slides become a doc. A transcript becomes a summary organized by theme. The judgment is already settled; what's left is reshaping. That work really is collapsing toward zero, and anyone still paying people to do it by hand is burning money.

When I said translation was a tax, I meant something that lives one layer up: converting intent across a boundary where the content itself has to be reconstructed. A customer insight becoming a problem statement. A problem statement becoming acceptance criteria an agent can build against. That isn't reshaping settled content into a new container — it's deciding what the content is, precisely enough that a machine can act on it without hallucinating the gaps. Wensing actually concedes this in the same breath: the value, he says, is now in "choosing the right source and the best target." Choosing the source is the expensive part. It always was.

So the tax didn't get repealed. It moved. The cheap half — the reshaping — got automated. The expensive half — the specification, the framing, the decision about what good even looks like — got more exposed, because it's no longer hidden inside hours of formatting busywork. When the mechanical layer disappears, what's left isn't nothing. It's the judgment, standing alone, with nowhere to hide.

Why this makes the near-term harder, not easier

This is the same mechanism described above, and the Wensing framing sharpens it rather than breaking it. His own war story is the tell: he didn't one-shot that all-hands deck. He ran a long, deliberate session — choosing which raw materials to feed in, withholding the purpose to keep the model from bolting to a deliverable, pivoting a Zoom transcript into the shape of a strategy doc. The conversion was instant. The deciding what to convert into what took the morning. He's describing a job where the formatting tax fell and the judgment tax rose to fill the space.

That's exactly the spiral warned about above, viewed from the other end. An org that automates the reshaping and assumes the work is now done ships faster slop. An org that automates the reshaping and reinvests the recovered hours into better sources — cleaner problem framing, tighter acceptance criteria, more customer conversations — gets the compounding benefit. The tool doesn't decide which org you are. The process design does.

What to change in how you read the original

Nothing above is wrong. But read it now with one substitution in mind. Where the essay says the PM spends a third of the week on translation work, understand that the mechanical third is what AI is taking — and that this is good, exactly as the essay argued, because removing the mechanical labor is the whole goal. The mistake is to celebrate that and stop. The recovered third doesn't vanish into leisure. It gets reabsorbed by the part that never compressed: choosing the source, specifying it well enough to be built, and verifying what comes back.

"Translation is free now" is true and incomplete. The honest version is shorter: the cheap translation got free, which is why the expensive translation is now the job. If your team feels relief, they automated the right layer. If your team feels exposed — like the judgment is suddenly visible and there's no busywork to retreat into — that's not a regression. That's the tax landing where it was always heading.

Source. Matthew Wensing (VP Product & Design, customer.io), interviewed by Aakash Gupta on The Growth Podcast, "How a VP of Product Uses Claude Without Producing Slop," YouTube, published June 9, 2026: youtube.com/watch?v=yDeFGKaSoX8. All characterizations of Wensing's remarks are drawn from that episode; quotations are transcribed from it and lightly punctuated for readability. I have no relationship with customer.io, its employees, or the podcast.