Managing Prompts as Software

Once a prompt is reused, it becomes part of the system. It needs ownership, version history, test cases, and a controlled path for change.

A practical maturity ladder

Prompt systems usually progress through seven levels:

1. Static text for one stable task.
2. Parameterized templates that substitute known values.
3. Conditional prompts that branch on task or environment state.
4. Contextual prompts assembled from current project information.
5. Composed prompts that invoke or include other prompt components.
6. Self-modifying prompts that propose changes from observed results.
7. Meta-cognitive prompts that evaluate or improve other prompts.

Each level adds capability and operational cost. Start at the lowest level that solves the problem.

Move upward when people repeatedly copy the same prompt with small edits, manually correct the same output defect, or need project state to determine the next instruction. Move downward when debugging the prompt system costs more than the work it saves.

Version and test reusable prompts

Store reusable prompts with the code or configuration that assembles them. Record why a change was made, not only what text changed. Maintain a small evaluation set containing representative inputs, known edge cases, and previous failures.

Run that set after every material edit and model upgrade. Compare task success, constraint violations, latency, and cost. A prompt change is an experiment, not an improvement until evidence supports it.

Govern self-modification

Self-modifying prompts require the same disciplines as Skills and the Knowledge Base: provenance, evaluation, approval, and rollback. Preserve instructions that still work. Promote repeated lessons rather than one-off reactions. Remove a rule only when evidence shows it is stale or harmful.

This lifecycle is the smallest version of the Evaluation Harness developed later in the book. The next stage of Part I turns from instructions to the probabilistic model executing them.