Building the Same Product With AI Changes the Product Contract
Adding AI to an existing workflow changes more than the implementation. It changes what the product can promise.
Consider a product that turns a meeting into a list of follow-up actions. The non-AI version asks a person to type each action, select an owner and choose a due date. The AI version listens, infers commitments and prepares the list automatically.
The screen may look almost identical. The product underneath is not.
I call this the Product Contract Shift. When judgment moves from the user into the system, correctness, testing, interaction design, release proof and operations all acquire new jobs.
Deterministic software asks the user to supply judgment
Traditional software can still contain complicated logic, predictions and failure. The boundary is usually legible. The user enters a value. The system applies rules. A stored record means the user or a deterministic process created that record.
In the manual meeting product, the person decides that a commitment exists. The form ensures an owner is valid and a date has the expected shape. If the task is wrong, the error usually entered through a visible action.
AI changes the source of the record. The system now decides whether the conversation contained a commitment, whether it was final, who owns it and whether “next Friday” means a particular date. The interface receives an object with the shape of a task before a person has agreed that the task exists.
That is the shift: model judgment arrives wearing application data’s clothes.
The same feature now has a different contract
| Product concern | Without AI judgment | With AI judgment |
|---|---|---|
| Input | User supplies structured fields | System interprets unstructured evidence |
| Correctness | Rules produce the defined result | Output has a quality distribution |
| Edge case | Unexpected state or invalid value | Plausible but unsupported interpretation |
| Testing | Inputs map to expected outputs | A changing set of cases needs graded outcomes |
| Interface | Enter, edit, save | Inspect, correct, approve, reject |
| Release | Code and journey behave as specified | Behaviour also holds across a representative set |
| Operations | Errors, latency, availability | Drift, evidence gaps, review load, provider change |
| Stored data | Record is presumed intentional | Observation, inference and approval need separation |
The AI feature may save the user several steps. The product team inherits those steps as system responsibilities.
Requirements become distributions
A deterministic requirement might say: “When the user assigns an owner and saves, create one task.”
The AI version needs a different specification. Which phrases count as commitments? How should the system handle disagreement, tentative language, several possible owners or a date mentioned as an example? Which errors are tolerable? Which errors are costly enough to require review?
One acceptance example cannot represent that space. The team needs a set containing ordinary cases, hard cases, refusals and cases where doing nothing is correct. Each important change is evaluated against that distribution.
This is why agent evaluation cannot stop at one answer string. Anthropic describes agent evaluation as a task, repeated trials, environment state, transcripts, outcomes and graders. The approach reflects the real shape of an AI product: behaviour unfolds across actions and variation.
The product manager’s work changes too. Writing the happy path is insufficient. They have to decide what kind of wrongness matters.
The interface becomes part of the safety architecture
If the system can be wrong while sounding coherent, the interface must help a person detect and correct it.
The manual product needs good entry controls. The AI product also needs provenance, uncertainty, correction and permission. The user should see which words produced the proposed task, whether the speaker was clear, what the system inferred and what saving will do.
That does not mean covering every screen in confidence badges. It means placing the right evidence at the point where an inference becomes a durable fact or external action.
This is the role of the Evidence Layer and the Approval Surface. The first keeps source and interpretation connected. The second makes the consequence reviewable.
Without those layers, “AI-assisted” often means the product saves typing by creating verification work somewhere less visible.
Versioning expands beyond code
In conventional software, a commit and its configuration usually identify the behaviour being released. In an AI system, behaviour may also depend on:
- model and provider version;
- system instructions;
- retrieved context;
- available tools and permissions;
- source freshness;
- evaluation and routing policy;
- prior state or memory.
A code rollback may not restore previous behaviour if one of those dependencies changed independently.
The release identity therefore needs to bind the relevant behavioural configuration. The team must know which combination passed the evaluation and which combination a user encountered. This does not require freezing every model forever. It requires enough identity to investigate a change rather than arguing from memory.
The Release Proof Ladder becomes stricter for exactly this reason. “The deployment succeeded” says nothing about whether the evaluated behaviour is the behaviour now serving the customer.
Operations move from uptime to continuing fitness
A traditional service can remain correct while its traffic changes. An AI feature may degrade because its inputs, source material, language mix, user behaviour or provider response changed.
Availability monitoring still matters. The team also needs signals for continuing fitness:
| Operational signal | Product question |
|---|---|
| Evidence coverage | Did the system have enough source material? |
| Correction rate | How often do people materially change the proposal? |
| Refusal rate | Is the system stopping appropriately or becoming unusable? |
| Review concentration | Which cases consume human judgment? |
| Action reversal | Which approved actions later prove wrong? |
| Source health | Is the information supply fresh and complete? |
These metrics are not universal scores. They locate where the product contract is breaking.
An increase in refusal may mean the model degraded. It may also mean the team introduced a good safety boundary. A lower correction rate may mean quality improved, or that reviewers stopped paying attention. Product interpretation remains necessary.
AI can reduce user work while increasing product work
This is the economic tension behind the Product Contract Shift.
The manual version makes the user perform interpretation. The AI version takes that burden into the product and must perform it repeatedly, cheaply and safely. Some of the saved effort reappears as evaluation, evidence storage, review design, exception handling and operational monitoring.
That exchange can still be extremely valuable. Turning an hour of conversation into five reviewable commitments is better than asking a person to reconstruct the meeting from memory. But the value comes from moving work into a dependable system, not from making the work disappear.
The same pattern appears in research, coding, customer support and learning. AI collapses visible creation time. The product must absorb the verification and recovery time that users previously carried themselves.
What I got wrong
I initially treated AI capabilities as unusually flexible services inside otherwise normal products. Define an interface, call the model, validate the response and continue.
That architecture can produce a feature. It does not fully account for the change in responsibility. Once model judgment creates product state, every downstream surface needs to know what kind of state it received.
The Product Contract Shift is therefore an organizational change as much as a technical one. Product, design, engineering and operations must agree on evidence, acceptable error, refusal, correction and authority.
The unresolved question is pricing. If an AI product genuinely absorbs interpretation, verification and recovery work that the customer used to perform, should it still be priced like the software screen it replaced? Or should price follow the responsibility the system has taken on?