This is Part 3 of a three-part series on what changes when agents, not just people, become your product’s clients: The New Front Door · The Governing PM · The Same Discipline, One Layer Deeper

Engineering blogs are currently rediscovering a discipline product managers have practiced imperfectly for two decades: write down what “done” and “correct” mean before work starts, or ambiguity gets resolved badly and expensively later. They’re calling it spec-driven development. Part of what they’re describing, I’ve been calling Tuesday.

Only part, though. The contract a product makes with whoever calls it, a person or an agent, including what it’s allowed to decide on its own, has always been product’s job, and still is. What’s actually new sits one layer further down: the internal architecture and implementation choices that fulfill that contract, the layer that used to tolerate ambiguity because an engineer would resolve it with a hallway question. That layer is now under the same zero-ambiguity pressure the contract has always carried, and it’s a genuinely new problem for engineering, not a rebrand of product’s.

The Discipline With a New Name

Addy Osmani’s January 2026 piece on writing specs for AI agents, backed by GitHub’s analysis of more than 2,500 agent configuration files, walks through GitHub’s own Spec Kit workflow: Specify, then Plan, then Tasks, then Implement. Specify is the PRD-like layer: intent, outcomes, acceptance criteria. Plan is the layer underneath, and Osmani puts architecture, interfaces, and operational constraints all in that one bucket, engineering’s job in his framing. Osmani is clear elsewhere in the same piece that teams often collapse Specify and Plan into a single document in practice, so the stack is real structure that gets flattened for convenience, not always two separate files.

I’d draw the line inside Plan differently, and I already have. Interface behavior, what a system promises whoever calls it and what it’s allowed to decide alone, is product’s job now. What’s left once interfaces move to the contract side is narrower than Osmani’s Plan phase: the architecture and data-structure choices that never surface to any caller at all. That narrower layer is where the oldest failure mode in product management, an ambiguous requirement discovered downstream at the worst possible time, is now showing up for the first time. My own read of Osmani’s broader argument, not a claim he states outright, is that AI coding quality usually fails at the specification layer before it fails at the model layer. That holds whether Specify and Plan stay separate documents or get flattened into one. Vague inputs produce confident, wrong outputs, and the model often doesn’t flag which part it’s guessing at — how much it hides that guess depends on how the agent is configured, more on that below.

Why the Agent Is Less Forgiving

A human engineer handed an ambiguous requirement either asks a clarifying question in the hallway or quietly makes a reasonable call and mentions it in review. An agent left to its own defaults often fills the same gap with a confident guess and no visible flag that a guess happened, though agents built with plan modes or instructed to surface assumptions before implementing can and do expose that gap instead of hiding it. Where an agent isn’t set up to do that, the difference in degree, silence by default instead of a hallway conversation, is still real leverage, not just a rebrand.

Addy Osmani’s own framing of that shift, quoted and curated on LeadDev’s AI engineering curriculum page (first published April 2025, still the clearest version of this argument I’ve found), casts it for engineering leaders as moving from direct code monitoring to strategic guidance, making sure the upstream instructions are precise enough that the output doesn’t need line-by-line supervision. A separate February 2026 study out of ETH Zurich found that repository-level context files like AGENTS.md increased reasoning-token usage in the measured GPT-5.2 and GPT-5.1 Mini runs, with increases ranging from 2% to 22% depending on model, dataset, and whether the context file was LLM-generated or developer-provided, without generally improving task success. The agents did more file traversal and ran more tests, not necessarily better work. That’s a narrower and more specific finding than “bloated specs waste computation”: it’s about repository configuration files specifically, not product specs in general, but the mechanism (unfocused instructions costing real compute without buying better outcomes) rhymes with the spec discipline point above.

The Chore That Became the Leverage

Most product orgs still file spec-writing under documentation, the thing you finish so engineering can start the real work. That framing was always a little wrong. It’s gotten expensive to be wrong about it now, because the cost of an ambiguous spec used to be a Slack thread and now it’s an agent shipping the wrong feature at agent speed.

The New Front Door covered the contract. This is what happens one layer past it, once the contract is solid. Precision stops being a nice-to-have at either point: for the PM specifying intent and interface, and for the engineer specifying the architecture underneath it, each now accountable for a half of the seam that used to have a person absorbing the gaps on both sides.

The Comprehension Cost Underneath

None of this replaces the concern I raised in The Code Nobody Understands, that teams can ship code they don’t fully understand. Tighter specs don’t fix comprehension. They just move the point of failure earlier, from a confused engineer staring at generated code to a PM who never had to make the ambiguous call explicit in the first place. Written down badly, the ambiguity used to surface in code review. Written down badly for an agent, it surfaces in production.

Where I’m Less Certain

I don’t think every PM should start writing specs like engineers do, and I’d be skeptical of anyone selling a course that says so. What I’ll say plainly is that the PMs who already treat requirements as a precision discipline, not a formality to clear before the real work starts, are the ones whose features are surviving contact with an agent. That was true before AI showed up. It’s just no longer optional to pretend otherwise.

What’s the last spec you wrote that you’d trust an agent, not a person, to execute exactly as written?