For software to interact with other software, it has to agree on a schema.

Traditional software is hard and precise; both sides of an API have to be finely machined to fit precisely into the gears on the other side.

Agreeing on the schema is a coordination problem.

If the two sides don't coordinate on a precise definition, the gears won't fit.

It's not that hard for one pair used one time.

But as soon as you start introducing more endpoints that all have to agree, or you want to change an established schema, it can create significant overhead.

A schema general purpose enough for anything is too generic to be used for anything.

Schemas require you to reduce fuzzy nuance to precision.

But what if the schema you distill is not correct for the domain?

The wrong schema is like a straight jacket that's missing an arm.

When creating a schema, you have to be precise enough to be useful today… but also be able to generalize to some degree into the future.

A challenging design problem.

What if instead you could let schemas emerge organically instead of being engineered?

In the past I've talked about human-driven patterns using techniques like folksonomies.

What if you could have LLM-assisted JIT schemas?

LLMs interpreting things like OpenAPI specs on two sides and writing bespoke translation code.

A massive number of services today document themselves with OpenAPI schemas.

Even without OpenAPI specs, LLMs are good at free text and vibes.

You could hallucinate the translation code once (at non-zero marginal cost) but then run it cheaply in the future (like other software, effectively zero marginal cost).