A hard truth in product: Your spec could be the bug.
PMs have done the AI-risk homework. The spec problem is the part nobody assigned.
Stack Overflow asked roughly 49,000 developers what frustrates them most about AI coding tools. The top answer, from 66 percent, was code that is almost right but not quite.
It compiles, runs, and looks correct, then does the wrong thing in a way you catch three weeks later.
You can name how AI fails. You probably can’t name how your spec invited the failure.
Product managers have done the reading on AI risk. Hallucination, bias, data leakage, and model drift. Everyone can recite the list.
That list is part of the curriculum that everyone studied. The spec problem is the part nobody assigned.
A controlled study this year put sixteen experienced developers on their own codebases, with and without AI. The work took 19 percent longer with AI.
The same developers were sure it had made them 20 percent faster. The slowdown is not the point. None of them could feel it.
This lands on product people for a reason that has nothing to do with the model.
Researchers studied how developers specify work for humans versus AI agents. For humans, they wrote a compass. The intent, the goal, and trust in the person to handle whatever nobody wrote down.
For AI, they wrote railway tracks. Every path laid is followed because the agent follows the letter of the instruction and ignores the intent behind it.
For fifteen years, the compass worked. You wrote “let users filter by date range,” and an engineer who knew the product asked what happens with an open-ended range, which time zone it uses, and what the empty state says.
Those gaps got closed by someone who cared how they closed. You were never the only person thinking about the product. It only felt that way.
The agent does not ask. It builds the open-ended range as a crash, picks UTC because it was first in the library, ships an empty state that reads “undefined,” and reports the task done.
It built exactly what you wrote. That is the problem.
A wrong build used to be cheap to catch because you had time. NASA’s old data put the cost of fixing a requirements error at the spec stage at 1 unit and, after release, at up to 1,500.
The gap between a written spec and running code used to be weeks of reviews and QA. With an agent, it is an afternoon, so the error lands in something deployable before anyone has looked at it.
Strip the tooling away. The product manager’s value was always some version of “I know what to build.”
That knowledge could live partly in your head, because the people building it interrogated it on the way down. The interrogation is gone.
What you know is now worth exactly as much as you can write precisely enough that a literal executor cannot get it wrong. The PMs with real clarity and loose documentation habits are about to learn which one was carrying them.
AI removed the people who were quietly covering for the gaps in your product thinking. The gaps were always there. You just never had to see them.
You spent a career learning to write compasses. Track is a different skill, and it is the most fixable problem in this entire piece.
What follows is just the questions a good engineer used to ask you, written down before anyone has to ask them.
Five places to start this week:
Take your last spec to someone with zero product context and ask them to list every decision they’d have to make to build it. That list is what your agent is guessing at. Close the three biggest gaps now.
Add an out-of-scope section to your next spec. Write what you are deliberately not building. Every line you leave out is a line the agent fills for you.
Write the edge cases before the happy path. Empty state, the limit, the open-ended input, zero, and ten thousand. If you can’t name them, you don’t understand the feature yet, and neither will the agent.
For anything behind a flag or a gate, describe the off state in full sentences. Off is where agents improvise the worst. Spell it out, and you delete a class of bugs before it exists.
Keep a one-line log of every decision your agents got wrong. Read it before you write the next spec. Your habits are the pattern, not the model’s.
Final Thoughts
Almost right but not quite is not a model problem. It is the sound of a spec that trusted someone to fill a gap, running on a system where nobody fills it anymore.
Those developers could not feel themselves slowing down. Most PMs cannot feel the holes in their specs because, for 15 years, someone downstream closed them first.
That person is gone. The job is split into two.
On one side, the PMs who can put what they know on the page precisely enough that a literal executor cannot get it wrong. On the other hand, the ones still waiting for someone to ask them the right question.
The spec is the bug. It has your name on it. The next one does not have to.
Mike Watson @ Product Party
P.S. Want to connect? Send me a message on LinkedIn, Bluesky, Threads, or Instagram.