Prompts Are Code

Lesson 4 of 4 in Prompting as Engineering.

Here is a failure pattern old enough to have gray hair: the prompt lives in a string constant, someone “improves” it on a Friday, nothing is tested because it is just text, and Monday’s incident review discovers that refund summaries have been silently wrong all weekend. The root cause is a category mistake. A prompt is not documentation. It is deployed behavior — as much a part of your system’s logic as any function — and it deserves the same lifecycle.

That lifecycle has three non-negotiables. Version control: the prompt lives in a repository (or a versioned prompt store), with history, blame, and rollback — never inline in application code where changes hide inside unrelated diffs. Review: a prompt diff gets read by a second person, exactly like code, because a one-word change (“concise” → “brief”; adding “always”) is a behavior change. Regression testing: before any change ships, old and new prompts run against a fixed evaluation set — a curated collection of real inputs with expected properties of the outputs — and the metrics are compared. No eval set, no merge. How to build eval sets that deserve this trust is the Evaluation domain’s subject; here, the rule is simply that one exists and gates the deploy.

The eval set is what converts prompt work from anecdote to engineering. Without it, “the new prompt feels better” is the entire QA process, and every lesson in this module — format consistency, ordering sensitivity, CoT trade-offs — becomes unmeasurable folklore again.

The prompt-change lifecycle

  1. Change proposed

    A prompt edit in version control: new template text, changed examples, or new placeholder wiring — with a stated reason.

  2. Diff reviewed like code

    A second person reads the diff. Wording changes are behavior changes; example changes are specification changes.

  3. Run the fixed eval set

    Old and new prompts run on the same held-out inputs; outputs are scored the same way. Same model, same decoding settings — isolate the variable.

  4. Metrics regress?

    Compare against the current prompt’s baseline. Look at per-slice results, not just the average — regressions hide in subgroups.

  5. Revise or reject

    A regression sends the change back with data attached — the failing cases become candidates for the eval set of the future.

  6. Ship as a versioned release

    The prompt deploys with a version identifier, logged with every request it serves, so any output can be traced to the exact prompt that produced it.

  7. Monitor, with rollback ready

    Production monitoring watches for drift the eval set missed; rollback is a config change, not a code release.

Production prompts are templates plus variables, and the variables deserve their own hygiene rules. Give placeholders explicit names ({{DOCUMENT}}, {{USER_MESSAGE}}) and a single source of truth for what fills them. Delimit every untrusted variable — user text, retrieved documents — with clear markers, so the boundary between your instructions and inserted content is explicit in the token stream. Validate before insertion: length limits protect your Context window budget, and a template that silently truncates a 40-page document explains many “the model ignored the input” bugs. And keep the System prompt for durable role and policy, per-request variables in the user turn — the Chat template gives these positions different weight in post-training, and mixing them muddies both.

One boundary line for this site: patterns where a model iterates — plans, calls tools, reads results, retries, the ReAct family of scaffolds — are agent engineering, and our sister AI Agent Academy teaches them properly; everything on this page still applies to every prompt inside such a loop. And when instructions and untrusted content share one context, an adversarial document can try to be instructions — prompt injection, the signature risk of this whole technique, gets its full treatment in the Security & Risk domain.

In production

On every platform, the prompt is deployed configuration: it changes model behavior in production without any code path changing. The evergreen discipline is identical everywhere — version it, gate it with evals, log which version served each request, and make rollback instant.

AWS

The Bedrock-centric pattern keeps prompt templates as versioned artifacts outside application code — Bedrock offers managed prompt versioning, and teams equally use their own config or repository — so a prompt change rides the same review-and-release path as any config deploy. Because Bedrock fronts many model families, the eval gate earns its keep twice: the same template can behave differently per model, so a prompt release is validated against the specific model it targets, and the serving logs record prompt version alongside model ID.

Azure

In Azure AI Foundry, prompts slot into the platform’s evaluation tooling: prompt variants are compared on shared test data before deployment, and prompt assets are managed and versioned alongside the deployments that use them. The mechanism to internalize is the pairing — a prompt store plus an evaluation harness — so that “edit the prompt” is structurally inseparable from “re-run the evals,” and a regression blocks the release rather than reaching users.

Google Cloud

Vertex AI exposes the same shape: prompt templates saved and versioned in the platform, evaluation services that score prompt variants against datasets, and deployment separated from authoring. The durable takeaway is architectural, not product-specific: keep the prompt out of the container image, so shipping a prompt fix never waits on a code release — and gate that fast path with the same eval discipline you would demand of a slow one.

Interactive checkpoint quiz (1 questions) — open this page in a browser to take it.