Agentic coding tools and what they actually change about being a technical PM
Tom W Dixon · Senior Product Manager and Digital Platform Lead
There's a claim doing the rounds: agentic coding tools have closed the gap between technical and non-technical product managers. If an AI agent can write the pull request, so the argument goes, coding literacy stops being a differentiator. Anyone can be a "technical PM" now.
I think that gets it backwards. Agentic tools haven't lowered the bar for technical PMs. They've moved it.
For years, "technical" meant something narrow: can you read a bit of code, understand an API contract, hold your own in a sprint planning session with engineers. That bar was already low enough that a determined PM could clear it with a few months of exposure to a codebase.
Agentic coding tools change the job, not the difficulty. When a tool like Claude Code can scaffold a feature, write the tests, and open the PR in minutes, the scarce skill isn't writing code any more. It's judging code you didn't write, at speed, and knowing when to trust it.
That's a different discipline. It means:
- Reading a diff and spotting the decision the agent made silently, the edge case it didn't consider, the assumption buried in a variable name.
- Knowing which parts of the system are safe to let an agent touch unsupervised, and which need a human in the loop before anything merges.
- Understanding architecture well enough to ask "why did it do it that way" rather than just "does it work".
- Being able to explain, to a stakeholder or an auditor, why a piece of AI-generated logic is correct, not just that it passed a test.
None of that requires a PM to write production code. It requires a PM to be comfortable interrogating output they didn't produce, which is a harder and less comfortable skill than writing code from scratch. Writing code, you build understanding as you go. Reviewing someone else's output, human or agent, you have to build that understanding backwards, from the result to the reasoning.
I've spent most of my career sitting between engineering teams and the business, translating one to the other. That job hasn't gone away. It's got harder, because now one side of the conversation is an agent that will confidently produce something plausible-looking whether or not it's right. A junior developer at least knows what they don't know. An agent, prompted badly, doesn't.
So the technical PMs who matter most in this shift aren't the ones who can write a script. They're the ones who can look at a pile of AI-generated changes, ask the right five questions, and know within a few minutes whether the answer holds up. That's not a coding skill. It's a scepticism skill, applied to a new kind of output.
The gap between technical and non-technical PMs hasn't closed. It's moved from "can you code" to "can you tell when the code is wrong", and the second one was always the harder test.
