Contracts: declarative style, types and capabilities

A prompt that scripts every step encodes assumptions about one specific model and becomes obsolete the moment that model changes. A specification that declares the required outcome, the constraints and the acceptance criteria survives the change, because switching models turns into a re-verification exercise rather than a rebuild. Given how often models are replaced now, this difference decides whether each upgrade costs your team days or a quarter.

When prose is passed unchanged from one internal stage to the next, small differences in wording cascade into different behaviour further down, and nobody can point at where the result went wrong. Extracting the request once into a validated structure converts that fuzzy handoff into an inspectable one: you can log it, diff it, replay it, and route on facts instead of phrasing. It also lets stages be tested independently, which is what makes incremental improvement possible.

Preconditions, postconditions and invariants turn a vague quality discussion into an automatic decision. Without them, whether a module is finished is settled in review meetings, which is slow, inconsistent and easy to relitigate. With them, the system itself refuses to hand on a result that violates the contract. This also draws clean lines of responsibility between your teams and any external partner, because the contract states what each side owes the other.

Serious AI incidents are rarely a badly worded answer. They are a plausible-looking result combined with an action the component was never meant to take: publishing, spending, deleting, changing permissions, or writing to customers. Permission must therefore be part of the program, never something the model infers about itself. An explicit capability matrix per component makes the blast radius of any component visible before it ships, and reviewable when it changes.