A client asks for a fixed price. The vendor writes a spec, quotes a number, and both sides sign it feeling like they’ve eliminated risk. Six weeks in, the client wants a feature that wasn’t in the spec, the vendor calls it a change order, and the relationship that started as a handshake is now a negotiation over what “originally scoped” meant. That’s not a fixed price project gone wrong. That’s what most fixed price projects actually look like once real requirements meet a document written before anyone had built anything.

The fixed-price contract is built on a specific assumption: that the scope of the work can be defined in advance with enough precision to price it accurately. The agile development model is built on a specific observation: that software requirements are not fully knowable in advance, and that attempting to define them completely before development begins produces worse outcomes than defining them incrementally in response to what is learned during development.

For most of software’s history, vague requirements were expensive but survivable. A developer who received an underspecified ticket could ask a question, make a reasonable inference, or build a small prototype and get feedback. The cost of ambiguity was absorbed in back-and-forth, rework, and the gradual clarification that happened naturally when humans were iterating together. AI-assisted development has changed the economics of ambiguity in a way that most teams have not fully reckoned with.

The user story format — as a user, I want, so that — was not designed to specify behavior. It was designed to prompt a conversation about behavior. The distinction matters because teams that treat the card as the requirement skip the conversation, and the conversation is where the value lives. Ron Jeffries described the three Cs: card, conversation, confirmation. The card is a placeholder for a conversation that has not yet happened.