Prompt optimization is compilation — prompts deserve version control

Prompt optimization frameworks are compilers. OPRO, ProTeGi, DSPy, and GEPA all take the same inputs — a task specification, an eval set, a seed instruction — and emit prompt text that scores better than what a human wrote. Once you see the pipeline that way, "prompts deserve version control" stops being hygiene advice and becomes a build-system requirement: you don't version binaries and discard the source.

The compiler already works. OPRO's optimizer-LLM loop lifted GSM8K accuracy from 79% to 85% and Big-Bench Hard by eight points, by generating candidates against a scored trajectory of previous attempts. ProTeGi computes "textual gradients" — natural-language critiques of failure patterns — and beam-searches over edits. DSPy goes furthest: the prompt is explicitly a learnable parameter, and its optimizers bootstrap few-shot examples and search instruction space against your metric. The common structure is exact: source (intent plus evals) in, artifact (prompt text) out, with a scorer standing where the type checker used to be.

Take the analogy seriously and the engineering consequences fall out. Hand-editing an optimized prompt is patching a binary — your fix evaporates on the next optimization run, so the things under version control must be the sources: the eval set, the seed instructions, the optimizer configuration, and the emitted prompt as a build artifact with provenance. A prompt change can break a production system as thoroughly as a code change, so prompts get semantic versions — major when the behavioral contract changes — and go through pull-request review like everything else that can take the system down. Storage follows one of three patterns: co-located with code, a separate prompt repo, or a runtime registry; the registry earns its complexity when you need A/B traffic splits, staged dev-to-prod promotion, and rollback without a redeploy.

Testing is where most teams are furthest behind. A prompt release needs what a code release needs: a regression suite of tricky historical examples that every new version must pass, paired significance tests comparing old and new prompts on the same inputs — because single-run comparisons lie when output variance is this high — and canary rollout before full traffic. The teams I see get burned are the ones who "improved" a prompt on five eyeballed examples and silently regressed a case the old prompt handled; a curated regression suite is precisely the institutional memory that prevents relearning failures you already paid for.

One concession: the analogy breaks in a place that matters. A compiler targets a stable instruction set; a prompt targets a model that shifts underneath you — provider updates, quantization changes, deprecations. Byte-identical prompt, different behavior. Which means a versioned prompt without a pinned model identifier is half a lockfile: the unit you actually version is the triple of prompt, model version, and eval scores, and a model upgrade is a rebuild that must re-run the full suite, not a config tweak.

The uncomfortable implication is that artisanal prompt engineering is a transitional practice. The durable skills sit on either side of the compiler: specifying what good looks like — the eval set is the real program — and building the pipeline that compiles, tests, and ships prompt versions safely. Teams still hand-tuning strings in a playground are hand-assembling code in an age of compilers; charming, occasionally brilliant, and impossible to maintain.