The structure is the same
Traditional programming uses formal syntax to specify behavior: given these inputs, produce this output. With language models, the program is written in plain English, and the expected output acts as a test assertion — not an exact match, but a semantic contract.
That prompt is a function definition. The model interprets intent rather than strict syntax. The precision is probabilistic and semantic rather than formal — but it’s still precision. You’re specifying what you want, and you’re wrong when the output doesn’t satisfy it.
Test messages as unit tests
Input: “Translate ‘Hello’ to Spanish.” Expected output: “Hola.” This is structurally identical to a unit test — except instead of asserting exact equality, you’re allowing for acceptable variation: synonyms, formatting differences, paraphrase. Your “program” becomes three things: a set of prompts, a set of test cases, and a tolerance for fuzziness. That’s behavior-driven development, written in English.
The output is part of the loop
What makes this different from traditional software is that the output itself shapes the program. You’re not just checking correctness — you’re shaping the model’s behavior by iterating on wording, structure, and edge cases. When a test fails, you don’t fix a syntax error. You debug language.
Traditional code is deterministic: same input, same output. Language models are probabilistic: same input, slightly different outputs. So your tests are less about exact matches and more about semantic correctness — constraint satisfaction, pattern alignment, soft contracts rather than strict pass/fail conditions.
Why this matters for anyone building on AI
Framing prompts as programs and expected outputs as test assertions helps explain why prompt engineering feels like coding, why evaluation datasets look like test suites, and why iteration is essential. You’re debugging language, not syntax errors.
It also points at a broader shift: programming is moving from formal instruction writing toward intent specification and example curation. The practitioners who will do this well are the ones who already think clearly about inputs, outputs, and the behavior that connects them — which is to say, the ones who already think like engineers.