I have not written a ticket in months. I have not sat in a status meeting either. I still run product every day.
That is not a boast about tools. It is a report from the other side of a change most product people are still debating in the abstract.
I run product through AI agents. I set the direction. The agents do the execution. Verification decides what ships.
The role did not die. The job description got rewritten underneath it. I want to describe the rewrite as plainly as I can, because I have been living it.
The job I stopped doing
The traditional PM is a translator. Business goals into design briefs, designs into engineering tickets, engineering constraints back into stakeholder language.
Most of the classic PM week exists to solve one problem. The standups, the grooming sessions, the status meetings. Humans on a team cannot hold shared context, so someone has to carry it between them.
When execution moves to AI agents, that problem mostly disappears. The system that builds the feature has read the same context I have, in full, every time.
There is nobody to chase for an update, because the update is a log I can read.
The translation layer was most of what I used to do all day. It is not needed any more.
What is needed instead surprised me. It is harder work. It is also better work.
The job that replaced it
Three artefacts now carry the weight that meetings and tickets used to carry.
Vision anchors
A vision anchor is a written, versioned statement of what the product is, who it serves, and what it refuses to become.
Not a pitch deck. A file in the repository that every AI system reads before it touches anything.
When execution is expensive, drift is slow and you can correct it in a fortnightly review. When execution is cheap and constant, drift is the primary failure mode. A hundred small, individually competent decisions can add up to the wrong product in a week.
The anchor is what stops that. It has to be written tightly enough that a machine acting on it makes the choices you would have made.
That is harder than writing any spec I produced in my coordination years.
Machine-checkable done-conditions
This is the deepest change to how I think.
In the old world, done was a judgement call at a review. Does this look right. Does it feel finished.
Now done is a condition a machine can check. A test that passes. A build that compiles. A gate that scans for the specific failure I care about and blocks the merge if it finds one.
Defining a feature now means defining the check that proves it works. If I cannot express done as something that can fail, I have not finished thinking about the feature.
That discipline sounds bureaucratic. It is the opposite. It forces the fuzzy part of product thinking to happen up front, where it is cheap. Not at review time, where it is expensive.
Verification gates instead of status meetings
I do not ask how the work is going. I read what passed.
Every piece of work lands against gates: test suites, type checks, content rules, build health. The question "is it done?" has a boring, wonderful answer. Run the command.
There is no status to report, because status is not an opinion any more. It is a result.
One night in July
Here is what this looks like when it compounds. The business involved stays unnamed, because we keep our case studies confidential. The numbers are public and re-derivable.
One night in early July 2026, on a platform we run, 101 commits landed while I slept.
I had done the direction work beforehand. The vision anchor was written. The done-conditions were defined. The gates were in place. The overnight system built, checked its own work against the gates, and kept going.
In the morning I did not read the code first. I read the verification, saw what had passed, and made keep-or-kill calls on the rest.
That platform's test suite stands at 1,400 tests green today. Not "at last count". Today, re-run, because a number you cannot re-derive is a memory, not a fact. Both figures sit in our claims registry alongside the commands that reproduce them.
The commits were not the achievement. Any system can generate commits. Volume is the least interesting metric in this whole story.
The achievement was that the gates decided which work survived, and I had defined the gates.
That is the new PM job in one sentence. The value moved from doing the work to specifying what counts as done.
What stays human
I want to be straight about the limits, because the breathless version of this story is wrong.
Taste stays human. A test suite catches broken. It does not catch bland. AI systems will cheerfully ship something mediocre that passes every check you wrote. The gap between passing and good is exactly where product judgement lives. Somebody has to look at the thing and say "this is not it", and no gate I know how to write replaces that.
Scope calls stay human. The hardest product decisions are refusals. What not to build. Which idea to kill. When a feature is finished rather than merely improvable. Cheap execution makes these calls more important, not less. The cost of building the wrong thing has dropped below the cost of noticing you built it.
Accountability stays human. A system cannot own a mistake. When something wrong ships, and it does, the responsibility is mine. The person a customer talks to is me, not a model. That is not a soft point about ethics. It is structural. Verification gates exist because someone accountable decided what needed verifying, and deciding what to verify is itself a product decision.
The checks are human work all the way down.
Long live the product manager
The coordination PM is gone from my week and I do not miss the role. The direction PM shapes more of the outcome than any product job I have held.
Define the vision precisely enough for machines to execute against it. Define done precisely enough for machines to check it. Keep the judgement that machines cannot supply.
If you are a PM reading this with some dread, I would redirect it. The parts of the job that are disappearing are the parts most PMs complain about. The parts that remain are the reason most of us took the job in the first place.
If you run a product or a team, you can see what this looks like on your own work. The entry point is the free 15-minute call. Book 15 minutes. We will show you what we can prove, including the failures.