Contract-Driven Development

When contracts are clearly defined at each layer, change propagates safely, low-code becomes possible, and AI and agentic systems suddenly have real leverage. The contract is the product; the code either side of it is replaceable.

A platform built around the contract

Convex is a good example. It bundles the database, server functions, client libraries, end-to-end type safety, observability and integrations, and removes most of the backend maintenance around database integration. It’s model and interface first: you define the shape, and the plumbing follows. Less means more. The underlying driver is low-code: less developer overhead, easier for the people using it.

Schema-driven payloads

Picture a domain with many variants: different product types, each with different inputs and outputs. Rather than hand-building a form per variant, let a single source of truth in the backend define which fields each variant needs, and have the UI render from that schema.

{
  "variant": "subscription",
  "fields": [
    { "name": "interval", "type": "enum", "options": ["monthly", "annual"], "required": true },
    { "name": "trialDays", "type": "integer", "min": 0, "max": 30 }
  ]
}

Add a field in the backend and it appears in the UI without a front-end code change. It’s the same idea as JSON Schema forms, and the same instinct as TypeScript as a Team Contract one layer down.

Three contracts between platform and consumers

In a layered platform, consuming teams talk to providers only through contracts, and there are three kinds:

1. API contract: a formal spec for every service (OpenAPI for REST, Protocol Buffers for gRPC) covering shapes, auth, rate limits, versioning and error conventions. Consumer-driven contract tests (Pact, Spring Cloud Contract) enforce it: consumers declare what they rely on, and a provider change must keep every consumer’s tests green.
2. SLA contract: operational promises, which differ by layer. A core layer might promise 99.95 % availability and 24/7 support with quarterly change; an extension layer 99.5 %, best-effort support and continuous change (SLA vs SLO vs SLI).
3. Evolution contract: how a service will change: deprecation notice, migration support, breaking-change windows, how long old versions live. Without it, consumers program defensively, adopt less and stop trusting the platform. It can live in code, with longer notice for the core (say 90 days) than for extensions (two weeks).

On the front end, contract-first mocking is the consumer’s half of the same idea: mock the agreed network contract, not your own code.

Why it matters for AI

• Agents work best against explicit interfaces and constraints: tool schemas, typed APIs, validated outputs (Agentic System Design Checklist).
• Platforms that encode constraints once let teams adopt new technology faster (Platforms as the Enterprise Operating Model).

The trap

Low-code built on contracts is powerful; low-code built on opaque configuration is a maintenance nightmare. Keep contracts versioned and reviewable, like any other code (Low-Code Platforms), and model them deliberately (API Modelling).