The Work Moved Upstream

I've spent the last seven months helping product teams ship faster using AI coding agents. Claude Code, Codex, Kimi Code and similar tools. The code arrives fast. That part works. The problem is everything around it.

Here's what we keep seeing.

The bottleneck isn't writing code anymore. It's writing intent.

When a developer asks an AI to "build a notification system," the code it produces works in testing. Clean tests, green build, looks good. Then it ships, and sends 50,000 emails in four minutes. No rate limiting. Not because the AI is bad at coding. Because nobody told it rate limiting mattered.

Engineering quality didn't disappear. It moved upstream. Into specifications, requirements and the decisions made before a single line of code is generated. The teams that are shipping well are the ones that figured this out early. They're writing structured requirements again. State machines. Decision tables. The formal documentation that agile was supposed to kill.

Except now it's not overhead. It's the product. The code is disposable. If your specs and tests are precise enough, you can rewrite your entire backend in a different language by feeding the tests to an agent and saying, "make these pass." The specification became the product. The code became an implementation detail.

Vague requirements don't fail immediately. They fail later and expensively.

I came across a case where days were lost to a single unclear definition. Three concepts sounded similar but meant different things. The documentation wasn't explicit enough to disambiguate them. Agents working on separate parts of the system, interpreted the same terms in different ways and built inconsistent behavior. By the time anyone noticed, the cost of untangling it was significant.

Another scenario had a size specified as "up to 14" instead of "must be 14." The agent built variations at every size up to 14. The tests passed because they validated the implementation against the spec as written, and the spec allowed the range. The code was correct for the wrong requirement. One word, "up to" instead of "exactly," and the entire output diverged from intent.

These aren't edge cases. They're the default outcome when specifications leave room for interpretation.

Verification is the real skill now.

AI agents aren't magic. They're deterministic. They solve what you give them to solve, with the information you provide. One team we worked with had an engineer paste the same error into an AI tool six times and restart a server six times. Each time, the AI gave the same answer. Each time, the server crashed again. The AI wasn't wrong. It had one data point and gave the textbook response. The engineer never pivoted, never provided logs, never added context. After the second failure, the right move was to step back and say "I'm probably looking at the wrong thing." Instead, he repeated the same input and expected a different result. The AI wasn't the problem. The supervision was.

The teams doing this well share a pattern. They don't repeat failing inputs. They pivot after the second failure, not the sixth, and they bring more context to the problem each time. They don't trust agent output at face value. They verify with a second agent, a human or both. They write prompts that leave zero room for interpretation.

The skill shift is real and it favors product thinking.

The skills that matter now, writing unambiguous specs, verifying intent against implementation, and catching drift before it compounds, aren't new skills. They're product management skills.

Product managers have always translated ambiguous human intent into precise requirements. They've always caught the gap between what someone asked for and what they actually needed. They've always thought about edge cases, failure modes and what happens when assumptions are wrong.

The difference is that now, those skills are directly executable. You write a precise spec, hand it to an agent, and working code comes out the other end. The translation layer between thinking and shipping just got removed.

Being a product manager has always been about making teams effective. Now that the bottleneck is specification, not execution, that skill set isn't just useful. It's the lever.

The teams that figure this out first aren't going to be the ones with the best engineers. They're going to be the ones with the clearest thinkers.