Breaking Change

A breaking change is a change to an API, library, model, or platform that causes existing integrations to fail unless they are updated. It can be as obvious as a removed endpoint or as subtle as a renamed parameter, a different response shape, a retired model identifier, or a new SDK call pattern. In AI systems, the risk reaches beyond conventional software compatibility. A change can affect prompts, tool calls, evaluation results, latency, cost assumptions, safety checks, and downstream workflows that were tuned against the old behavior. Good teams therefore treat breaking changes as planned engineering events, not as release-note trivia. They track deprecation notices, pin critical dependencies, test replacement versions against real production cases, and define rollback paths before switching traffic. The key distinction is between availability and adoption: a new version may be available, but production should move only after the team has verified quality, observability, and operational readiness. Handled this way, a breaking change becomes a controlled migration instead of a surprise outage.