The rise and fall of UML prompt engineering

My site's design mimics UML diagrams, nostalgia for the 2000s. For those who missed it: UML is a modeling language invented so developers would stop writing code by hand and start drawing it in something resembling PowerPoint. The promise went like this: the model becomes the primary artifact, the code is generated from it, and the programmer as a transcriber disappears.

Remind you of prompt engineering at all?

Why did UML fall short? The law of conservation of complexity. To generate working code from a model, you had to pack more and more detail into it: signatures, constraints, action semantics. Until it turned out you were just writing code, only in an ugly graphical syntax, twice as slow, and with no debugger. A specification precise enough to produce a system is that system.

The same thing happens with prompts (or, in the modern paradigm, CLAUDE.md, "memory", "spec trees", and the rest of that circus). While the task is vague, the prompt stays short and pretty. The moment you need a specific result, it swells with clarifications, exceptions, formats, and examples, until it becomes the very spec that would have been shorter as code.

A specification is not what you feed in. It is what you get out. Which is why, as the great Kent Beck decreed, my CLAUDE.md files carry this:

## Strict TDD Protocol
1. Write a failing test
2. Verify the test fails
3. Implement the fix
4. Verify all tests pass

Tests are your real specification. Shipping without them used to earn you a disapproving frown. In the LLM era, when a day's work can produce tens of thousands of lines of code, it means outright professional unfitness, right up there with not knowing how to use git.

As for the diagrams, I'll keep them around as a reminder. Memento mori.