Prompt design is really interface design.

The instinct most engineers have when they first design a prompt is to treat it like an API call: define inputs, define outputs, glue it to the rest of the system. That’s a useful instinct, but it’s incomplete. A prompt isn’t just a function — it’s an interface. Two parties read it: the model, and the human who has to maintain it.

Two readers

Optimize a prompt only for the model and you’ll end up with something nobody can change without breaking. Optimize only for the human and you’ll end up with prose that performs worse than a smaller, more disciplined version. The trick is treating both as primary readers and refusing to choose.

Three habits that help

• Name your inputs. A prompt that takes ambiguous strings is a prompt nobody trusts.
• Name your outputs. If you can describe the output as a schema, do — even if you don’t enforce it. Naming forces clarity.
• Comment the why. Future-you needs to know why a sentence was added, not just that it exists.

Where this breaks

It breaks when the prompt is treated as a piece of magic — a string that works, that nobody understands, that nobody is allowed to touch. That’s the worst possible interface: opaque, fragile, and central. The cure is the same as for any other piece of software — names, contracts, and discipline.