The prompt as an artifact

Nine courses established that you will be changing prompts, not weights. This course shows what a prompt looks like once you accept that and engineer it properly.

What usually happens is different. A prompt starts as one clear sentence. Someone adds a rule after an incident. Someone adds an example. Someone adds "IMPORTANT: never do X" in capitals, because the model did X. Eighteen months later it is four hundred lines of accumulated scar tissue. Nobody knows which lines still matter, and everyone is afraid to delete anything.

Any artifact with no structure, no ownership and no test ends up like this, however disciplined the team. A prompt is an artifact, however much it looks like a paragraph.

Why a prompt is unlike the code around it

Four properties make it an awkward thing to maintain, and each one has an engineering answer:

The fourth is the dangerous one. Code that breaks stops working. A prompt that breaks keeps producing confident, well-formatted, slightly worse output, and there is no exception to page anyone.

Layers, not a paragraph

An architected prompt is composed of parts with distinct jobs and distinct rates of change:

flowchart TB
  A["Identity and rules — changes rarely"] --> B["Task definition — changes with the feature"]
  B --> C["Examples — changes with the data"]
  C --> D["Retrieved context — changes every request"]
  D --> E["The user's input — changes every request"]
  E --> F["Output contract — changes with the consumer"]

Two things follow from separating them, and both matter more than they look.

Different rates of change mean different homes. Identity and rules belong in code and change through review. Examples belong in a table and change through an interface, as the few-shot course argued. Retrieved context is assembled per request. Collapsing all of it into one string means the stable parts are edited as often as the volatile ones.

The order is a cost decision. Put the stable layers first and the volatile ones last, and every repeat request reads everything above the last cache breakpoint from the cache, at a fraction of the input price. A prompt whose layers are interleaved cannot be cached, and you see that on the bill.

What "architecture" buys

Compare two teams with the same task.

The first has one prompt string. Improving it means editing prose and hoping. Testing it means trying a few inputs. Nobody can say which of its four hundred lines is doing the work, and the honest answer is that some of them are doing nothing and one of them is doing harm.

The second has an identity layer in code, a task definition per route, examples as rows, a context assembler with a budget, and an output schema. They can change one layer and measure it, delete a rule and see whether anything moves, and answer "why did the model do that" by pointing at a component.

Neither team has a better model. The second team has a system they can reason about.

What this course covers

1. The prompt as an artifact (you are here).
2. Anatomy: what belongs in which layer, and in what order.
3. Composition without coupling.
4. Reasoning scaffolds, and what adaptive thinking made obsolete.
5. Context assembly under a budget.
6. Multi-turn prompts and state.
7. Putting it together: a prompt registry in Rails.

This is the last of the pure prompt-side courses. It comes after agents, Claude Code, schemas and fine-tuning on purpose: the right structure for a prompt depends on the system it is part of, and you now know that system.

Key takeaways

• A prompt is an artifact with no compiler, non-local effects, unclear ownership and silent degradation.
• It degrades without breaking, which is why an evaluation set and regression metrics are the substitute for a compiler.
• Architect it as layers with distinct jobs: identity, task, examples, context, input and output contract.
• Layers change at different rates, so they belong in different places: code, tables, per-request assembly.
• Order the layers stable-first so the part that never changes is read from the cache.