The Decisions Your Spec Never Made

My AI teams meet twice a week to talk about why. Rework fell by half.

The spec settles the big decisions; the hundreds of small ones made after it decide whether the product ships

A signed PRD feels like the end of the negotiating. Kickoff goes well, the spec collects its approvals, and everyone leaves the room agreeing on what to build. Then the build starts, and the document stops making decisions.

The build then generates hundreds of small choices that no spec anticipated, made by data scientists, engineers, and designers working alone at their desks, each one a guess at what the product is supposed to be. My teams stopped leaving those guesses to chance. Twice a week, everyone who builds the product sits down and talks through what they are building, how, and why; since we started, rework has fallen by half and every feature has shipped on its committed date.

The rest of this post is why it works, and how to keep it from turning into one more status meeting.

AI products multiply the decisions no document can make

Conventional software has this problem too, but a deterministic feature can at least be specified to the edge: given this input, produce that output. An AI feature cannot. The spec describes the behavior we intend, the model produces the behavior it produces, and whoever happens to be holding the ticket closes every gap between the two.

Count what one sprint generates. The data scientist decides which records leave the training set, which evaluation metric counts, where the confidence threshold sits, and how the prompt is worded, while the engineer decides what happens when the model times out, whether a cached answer is fresh enough, how many retries the budget allows, and which trade-off between latency and accuracy the user will feel. The designer decides how the interface admits uncertainty, what a "no answer" state looks like, how much of the model's reasoning to expose, and what the user can do when the answer is wrong.

None of these is a big decision. Each takes minutes and is easy to defend, and each one carries an assumption about the user that nobody else on the team ever sees. Multiply by a dozen people and ten working days, and you have far more decisions than the spec ever made, none of them compared against each other.

Made alone, those decisions drift apart, and nobody sees it until integration

Before we had the cadence, my team moved our platform's architecture from Semantic Kernel to the Microsoft Agent Framework, and that move taught me what the drift costs. It had a spec, and the team followed it, but inside the work sat a series of architecture decisions about how the platform would run in production, and whoever hit each one decided it at their desk.

Every one of those decisions was reasonable on its own. Together they changed how the platform operated, nobody saw the combined effect until operations did, and we spent three weeks re-engineering work we had already shipped, work a 30-minute conversation at the right moment would have redirected.

Nothing about that was specific to a migration. No single decision is wrong; each person makes theirs against a different picture of the product, so they disagree with each other in ways that show up only when the pieces meet: data science tunes for recall while the feature needs precision, engineering builds a silent fallback where design assumed an error state, the interface copy promises an accuracy the model was never tuned to deliver, and the evaluation set omits the edge cases the product manager cares about most.

Found at integration or in QA, each of these is rework. Found in production, it is worse: a confidently wrong answer with no hedge, delivered to a user who trusted the product, which is how an enterprise AI product loses that trust in a single session.

Twice a week, we put the why in the room

Every session runs 30 minutes, twice a week, and everyone who touches the product attends: data scientists, engineers, designers, product, and the stakeholders who will live with the result. Eight to fifteen people is large for a working session, and I keep it that size on purpose, because the person who made an assumption and the person it will hurt have to be in the same room.

The agenda has three questions: what are you building, how are you building it, and why that way? The first two take a minute each. The third takes the other 28 minutes, because "why" is the question that drags an assumption into the open, where the rest of the team can test it against the product we agreed to build.

A good session looks like this. An engineer describes a fallback she is about to build for when the model returns nothing; a designer says he assumed the interface would show an error there, not a silent retry; the product manager says the user in that moment needs to know the system tried and failed, and the fallback changes before anyone writes a line of it.

Write each decision down in one line: the choice, the reason, and the date. The why has a way of evaporating by the following sprint, and a one-line log is the cheapest way to keep someone who was not in the room from re-litigating it.

The meeting is not a standup, and it fails the moment it becomes one

Anyone who has watched a retrospective turn into a status report knows the failure mode. The moment people start reading their ticket list aloud, the why disappears, attendance turns into a cost, and the meeting gets cut the first week the sprint runs hot.

Status reporting kills it first: if you already have a standup, keep it, and reserve this meeting for the decisions the standup surfaces but never resolves. A product manager who talks for 25 of the 30 minutes kills it too, because the meeting exists so the builders can test their assumptions against the vision, and a monologue hands them the vision instead of letting them find where their work departs from it.

Skipping it when the team is busy is the temptation I feel most, because the heads-down weeks are precisely the weeks when people make the most decisions on their own. And "how" will crowd out "why" unless someone keeps asking what the choice is for, because engineers enjoy the how.

Rework fell by half and features ship on time, for one hour a week

Since we started the cadence, rework across my teams has dropped by roughly 50%, and every feature has shipped on its committed date. The cost is one hour a week per person, against the weeks one set of misaligned architecture decisions took from us before.

The goal is to eliminate rework entirely, and I don't think that's naive. Most rework is a conversation that happened too late, and a cadence this frequent keeps moving the conversation earlier.

Did the meeting cause the drop? Mostly, I think: the rework that disappeared is specifically the integration-stage kind that comes from misaligned assumptions, so I credit the cadence with most of it, and I'm less sure how much team maturity and better specs contributed over the same period. A team that ran this for a quarter with no change in that kind of rework would change my mind, and an hour a week is a cheap experiment either way.

Start next week with one assumption somebody made alone this sprint

You don't need a new process to try this. Put 30 minutes on the calendar twice a week, invite everyone who builds the product and the stakeholders who depend on it, and open the first session with one question: what did you decide this week that nobody asked you about? Someone will have an answer, and you'll spend the rest of the half hour on it.

Two places this breaks. A team of two or three that already talks all day doesn't need it, and a team that pairs across disciplines every day is already doing a version of it. Everyone else is making the spec's decisions for it, alone, and finding out at integration.

The spec never made those decisions. Somebody on your team is making them right now.