An AI coding agent can now carry a change from plan to production in an afternoon. The lifecycle around that work has been redrawn to match, most thoroughly in Anthropic's AI-native SDLC playbook: six stages, an artifact committed at each one, and a gate that declares a condition and records whether it was met.
Read it and you will notice where product judgment enters. The Plan stage begins once an idea, a ticket, or an incident has already been selected for attention, and turns that input into a file. The Maintain stage closes the operational loop, turning breached control bands into new intent. What stays outside the frame is the loop that decides which signals deserve attention in the first place, and whether the user outcome you promised, not just system health, actually materialized.
That gap is not a flaw in the playbook. It is a different loop.
An AI-native product company runs two. One turns evidence into a decision. The other turns a decision into working software. The second one is close to solved. The first one is where most teams have nothing at all, which is why they can build continuously without being able to continuously decide, verify, and learn.
The execution loop is not the problem any more
Give the agent-run loop its due, because the gains are real and they are the reason the other loop now matters.
Plan mode reads a codebase without editing until someone approves a strategy. Hooks allow, ask, or block. Tests and screenshots run before an engineer reads a diff. Branch protection records code-owner approval. Production deploys need a named release authorization. Some of those are automated and some still need a person, but each one declares a condition and leaves a record of whether it held.
That is a well-governed loop, and it now completes in hours. Which relocates the constraint rather than removing it. When building takes an afternoon and deciding takes three weeks of meetings, the bottleneck is the meetings. We wrote about that shift in The Bottleneck Moved.
The uncomfortable part is that an execution loop this fast will faithfully build the wrong thing at unprecedented speed, and every gate in it will pass.
The product intent loop has four stages
The second loop runs on a different clock. Days, not hours, because judgment does not parallelize the way code generation does. It has four stages, and unlike the execution loop it is mostly people.
Sense
What changes. Signals arrive continuously and get thrown away continuously. A support ticket answered is a signal consumed; a sales call is a signal that lived in one person's memory for an hour. When building was slow this waste was invisible, because you could only act on a few signals per quarter anyway. At current build speed the loss is the constraint.
Who does what. People capture. Agents cluster, deduplicate, and surface what recurs. The order matters: an agent that generates signals rather than organizing them is manufacturing evidence.
The artifact. A durable, addressable record of the observation with its source attached. A quote with a ticket number. A drop-off with the segment and the date. Something a colleague can check in six months.
The gate. Does the observation have a source someone else could go and verify? An assumption is allowed in the record, but it has to be labelled as one.
How you know it worked. Signals from more than one channel reach the record, and the decisions downstream cite records rather than recollections.
Decide
What changes. This is the stage the industry keeps trying to skip, because it is the only one no tool can do for you. Deciding is choosing which problem to spend attention on, in the presence of evidence pointing several directions, with dependencies and constraints that are all real.
Who does what. People decide. Agents argue: assemble the evidence on each side, name what the decision contradicts, surface the strategy rule it bumps into, propose the alternative you did not consider. An agent that decides for you has not removed the accountability, only hidden it. Product Judgment is the longer version of this argument.
The artifact. The decision, plus what it ruled out and why. The ruled-out branch is the part everyone omits and the part future-you needs, because a decision without its alternatives cannot be revisited, only relitigated.
The gate. Can you point to the evidence behind the choice, and name what you decided against? If the honest answer is a hunch, that is permitted. Write "hunch" in the record.
How you know it worked. Decisions get revisited when contradicting evidence arrives, instead of being defended.
Specify
What changes. A decision in someone's head cannot be handed to an agent. It has to become text with an actor, an observable outcome, a boundary that can actually be violated, a failure mode with expected behavior, and a way to check the result. Not because agents are fragile, but because those five things are what "done" means, and if they are absent the agent will invent them.
Who does what. Agents draft well and interrogate better. People own every claim in the result. The productive shape is an agent asking the fifteen questions a reviewer would have asked next week.
The artifact. A specification carrying the decision, its evidence, and its verification. In practice a markdown file, because that is what agents read.
The gate. This is the one stage where a machine can give you a real verdict rather than an opinion, because the five properties above are present or absent in the text. It is worth having that check be deterministic and boring, so it runs on every save instead of once at review. The intent.md profile is our attempt at writing down what the check should require.
How you know it worked. The agent implements without asking what an outcome meant, and the reviewer does not have to reconstruct the reasoning.
Learn
What changes. The execution loop tells you the code works. It cannot tell you the problem went away. Those are different questions, and only the second one closes the loop.
Who does what. Agents watch the signals and flag the ones that contradict what you predicted. People decide what the contradiction means, which is the same judgment call as Decide, arriving from the other direction.
The artifact. A verdict on the original intent, not on the diff. Did the outcome you named actually happen, in production, for the users you meant?
The gate. Every outcome has a check that can fail. A shipped feature with no falsifiable outcome has not been verified, it has been announced. Verification Is a Feedback Loop covers the four kinds of check worth having.
How you know it worked. Findings from production become new records in Sense, and some of them overturn an earlier decision. A loop that never overturns anything is not a loop.
The loops meet at exactly two points
Two connections, and both of them leak in most teams.
Handing off intent. The decision has to reach the tools doing the work, in a form they read without a person in the room. Today that means a file in the repository or a tool call over MCP. This is the join Anthropic's playbook already describes well, and the reason intent.md is becoming a common filename.
Signals coming back. Implementation discovers things the decision got wrong. Production reveals whether the outcome happened. Both belong in the evidence record, and in most teams both evaporate: the discovery lives in a pull request comment, the outcome lives in a dashboard nobody links to the decision that predicted it.
The return path is the weaker of the two and the more valuable. Without it you have a pipeline that ships, not a loop that learns.
Annotating the execution loop honestly
Here is the whole thing in one table, including the three rows where the product loop has no business.
The playbook makes a rule worth repeating: for every artifact the process produces, name one system as the authoritative record and let everything else hold a copy or a link. That is the "source of truth" column, and it is the column where the first row is awkward.
| Execution stage | Committed artifact | Source of truth | Product loop's role |
|---|---|---|---|
| Plan | The intent file | The record the decision lives in | Produces it, and stands behind it |
| Design | The spec | The repo | Supplies the constraints and the ruled-out options |
| Build | The diff | The repo | Nothing |
| Test | Test results | CI | Nothing |
| Deploy | Release authorization | The deploy system | Nothing |
| Maintain | Production signals | Observability | Consumes them, as outcome evidence |
Three rows say nothing, and that is the point. Building, testing, and deploying are well served by tools built for them, and a product layer that claims those rows is selling a diagram rather than a capability.
The first row is the awkward one. The playbook names candidate homes for the authoritative record: the repository, an existing requirements tool such as Jira or ServiceNow, or links between the two as the minimum bar. A repository scopes intent to a codebase. A ticket scopes it to a delivery item. Both can preserve a record. Neither naturally connects the decision, its evidence, the alternatives it ruled out, and the outcome that came back after shipping as one durable object.
That is the argument for a product layer. Not that agents cannot write specs, they write them well. Someone has to be answerable for which problem the team spent its attention on, and that answer has to stay connected to what came back after the ship.
How Pathmode operationalizes it
Everything above is a model of how the work happens, and it holds whether or not you use any particular tool. Two of the four stages can be run with a text editor and discipline. Here is what we build, so you can judge the fit.
Evidence and decisions live as durable records with their sources and ruled-out alternatives attached, so Sense and Decide have somewhere to accumulate. Specify produces an IntentSpec that carries the decision, its evidence anchors, and its verification, and a deterministic preflight checks six readiness gates on every save; The First Artifact Has No Readiness Gate is the full story of that check. The handoff writes intent.md into your repository, or answers over MCP, with the readiness verdict stamped in the file's frontmatter and a pointer back to the record it came from. Agents return implementation findings as recorded corrections, and teams attach production signals as evidence against the intent that predicted them, which is what makes Learn a stage rather than a hope.
The claim is narrow on purpose. intent.md is the interface. The judgment behind it needs a home that outlives the file.
Where to start
You do not need the whole loop on day one, and building it in order is slower than building the join first.
Pick one shipped feature from last quarter. Write down the decision it embodied, the evidence you had, and what you ruled out. Then answer whether the outcome you expected actually happened. Most teams cannot answer the last question, and finding that out is worth more than any process diagram.
If you want the smaller version, Support Ticket to Shipped Feature runs the whole loop once, on one real signal, in about an hour.