Specifying an AI Feature Takes a Process You Don’t Have

The rule that product owns the what and engineering owns the how has held for the whole history of software. An AI-dependent feature is the first thing to break it, and hiring alone won’t put it back together; the process itself has to change.

The first two articles in this series each pointed at someone missing from the room. Part 1 was about whether anyone on the team can tell a routine feature from an open research problem. Part 2 was about proving an AI feature is good enough to ship, and the data-science work that takes, which most product teams have nobody to do. Both ended in the same reassuring place: name the gap, put the right person on it, and the plan comes back together.

So you could close the series here and call it a hiring problem. Get a feasibility-minded engineer and a data scientist in the room, and the normal process absorbs the rest. That helps, and you should do it. But it does not reach the real problem, because the process you would drop them into was built for conventional software, and a rule it has always rested on stops being true the moment there is a model in the feature. No org chart fixes a process built for the wrong kind of work.

The rule is the one every product person works under: product owns what the software should do, and engineering owns how. It was never product deciding in a vacuum, but the line held up well enough to organize the work around, and it held for a reason, the one part 1 called buildability and part 2 called implementation certainty. Whatever product defined, engineering could build; the only open questions were people, time, and cost, never whether it was possible. That a feature was achievable at all got assumed so completely that nobody named it.

The behavior is now the thing you discover

Put an LLM in the feature and that assumption falls away. What an AI-dependent feature can reliably do is a property of the model, discovered by running it against real inputs, not a property of the description you write beforehand. Product cannot write a complete what and hand it across the line, because the what is now the unproven. The behavior the feature will exhibit is contingent on what the model turns out to be capable of, so the boundary between the intended behavior and its implementation is no longer a line you draw. It is the thing you have to go prove out.

The boundary between the intended behavior and the implementation is exactly what you have to discover.

In part 2’s terms, achievable stops being implied. It becomes a fourth question, ahead of people, time, and cost, and the only one you actually have to prove.

If that feels foreign, it is because it is not software thinking. It is hardware thinking, and I say that as someone who spent my early career in hardware engineering, where you never trust a component until you have characterized it yourself. A model is like an off-the-shelf sensor you are considering designing into a product, except a model ships with no datasheet at all. A hardware engineer will not take even a spec’d, off-the-shelf sensor as ready to use; you characterize it in the real environment, across the inputs it will actually see, and you check part-to-part variation, because two units of the same part can differ enough to sink the design. Only then do you commit. A model is akin to a hardware sensor that ships with no spec sheet, which is why the testing cannot wait until after your requirements are written.

What actually changes in the process

So here is the change. Before anyone writes the requirements, you run experimentation loops against the real model, or several candidates, and real data: define a little, build a little, evaluate what comes back, repeat, until you can commit to what is achievable. Those dependable requirements are the result of that loop. It is not a single sprint or a one-time gate; it is a period of iterative work whose product is the numbers and constraints the requirements will then state.

Experiment first, specify second. The requirements are what the loop produces, not what starts it.

That one reordering is the whole change, and it is the workflow that traditional software processes have no slot for.

What you can still specify

None of this leaves you with nothing to write down. It means the requirements the loop produces do not look like the ones you are used to. You are specifying a stochastic model, not deterministic logic, so they take a different shape: an acceptance rate, say ninety-five percent on real inputs, instead of a single correct answer; a distribution of twenty or more messy, real cases instead of happy-path examples; and defined low-confidence behavior, what the feature does when it falls back, hands off, or stays quiet. All three are product’s to decide. If your AI PRD has no acceptance-threshold section, as one practitioner put it, it is not yet an AI PRD.

Specify a rate and you have said something with teeth. At a ninety-five percent bar, the other five percent is not an edge case you might hit; it is part of the feature you shipped. It is a standing condition to design for versus a surprise to patch later, and handling it is shared: engineering catches the failure, product and UX decide what the user sees, so a wrong or low-confidence answer degrades gracefully rather than lands as fact. Part of the spec is deciding when a human enters the loop, and how the user is alerted without being buried in confirmations until they click past every one. We have written before about that overload trap, and about human-in-the-loop treated as an afterthought; both are the seed of a point the next article takes up.

Two additional dimensions belong in the spec, which are ones teams often forget:

• How dependent the task is on the model’s own training. There is a real difference between natural-language matching against a reference you supply (say, routing support tickets to the right queue by comparing them to your queue definitions, which a smaller model and some retrieval can handle), and asking the model to decide from its own training what the queues should even be. The more the task leans on what the model happened to learn, the more exposed you are to drift and to swapping models later, so the spec should say which kind it is.
• Governance, policy, and contractual limits. What your AI policy allows, what your contracts bind you to, and what your governance people require, named during requirements rather than discovered when a review reopens the finished feature.

What you’ve built is a different kind of POC

Step back and that whole loop, the rate and the distribution and the fallback behavior and the dimensions most people miss, adds up to one thing worth naming: a proof of capability. Not a proof of concept, which asks whether the idea can work at all, but a proof of capability, which asks whether this model can deliver the intended behavior reliably enough, within your constraints, to build on. It is the AI-era form of the de-risking good design has always done, and it is not optional, because the failure mode moved. A usability problem makes a feature hard to use: a calculator with its plus and times keys swapped is annoying, and people will grudgingly adapt. A quality problem makes a feature impossible to adopt: a calculator that sometimes returns wrong answers is broken, and no one keeps using it.

You can’t spec an AI feature you haven’t evaluated.

The proof doesn’t hold still

And a proof of capability is not earned once, because the model does not hold still, and how exposed you are depends on whether you control it. Lean on a commercial LLM and you have a dependency whose version you cannot pin; it can shift under you with no notice, and the frontier is moving fast. One index that tracks major model releases has the cadence tightening from roughly six months in 2024, to three months through 2025, to about four weeks by the second quarter of this year. A commercial model drifts under you like a dependency you can’t version-pin; a model you host stays put until you change it. But control is not the end of it, because you should not evaluate the model alone. You evaluate it with the harness around it, the prompts, retrieval, filters, and routing that decide what reaches it and what comes back, and that harness is software, so it changes. A model whose weights never moved can start answering differently because the software around it did. So you need a standing set of evaluations that runs on a schedule and trips when the system fails checks it used to pass, the way a qualified part gets re-tested periodically before anyone keeps trusting it. Quality asks whether it was good enough; reliability asks whether it still is, a discipline conventional software rarely forced.

What this asks of your process

This reorders the work, and organizations meet it differently. A team that today runs discovery ahead of delivery has the muscle memory; they just incorporate model feasibility. But many teams that call themselves “agile” are really running what Forrester once labeled water-scrum-fall: waterfall requirements at the front, a waterfall release at the back, sprints in the middle. Plenty of shops that call themselves agile still run waterfall at both ends. For them this is a change of mind, not of tooling, which is the challenging part. It can be done. A practical on-ramp is a small validation or innovation function that runs the proof of capability up front. The caution is that detached from product it becomes a request queue, work in and generic features out, so it only works close to product context. And it has to be resourced as a stretch of iterative experimentation, not a sprint slotted into the delivery calendar. The process has to make room for the activity, which is the plain version of what this article’s title claims.

There is a cost asymmetry in all of this, and it is what makes the upfront experiment worth the trouble. A spec that turns out impossible is the cheap outcome: you find out early and stop, having lost a little time. The expensive one is the spec that is merely very hard, because a competent team will take it, build it, and bill you, and you will not learn it was the wrong feature until it is running. Run the proof of capability during requirements and the choice stays yours; skip it and there may be no one positioned to make the call at all.

And notice what the work asks for. Proving what is possible, defining what good means, and finding where the behavior boundary sits all happen before the requirements. They all sit with neither product (as most teams staff it today), nor engineering. It points at a function most org charts do not have yet.

This is the third of four articles on the work an AI feature demands before anyone can write its requirements. The last one names the role all of this has been circling, and asks what it takes to put someone in it.