Prompt Engineering · ~6 min
Some of what you'd write as a rule already exists in a more precise form. A type, a schema, a test — re-describing it in prose only adds a second source of truth that can drift.
When a formal specification already exists, pointing the agent at it beats describing it. A TypeScript interface is unambiguous; an OpenAPI schema leaves no room for interpretation; a test file is a complete set of acceptance criteria. Re-describing in prose what already has a formal definition only adds noise — and a second thing that can drift.
Each formal artifact carries a contract the agent can read directly instead of inferring from prose:
| Artifact | The instruction it gives |
|---|---|
| Type / interface | "Implement a function matching this signature" — types, nullability fixed |
| Test file | "Make these tests pass" — a self-contained acceptance spec |
| OpenAPI / GraphQL | "Match this schema" — request/response shape, status codes |
| Database schema | Grounds queries so the agent can't invent column names |
Natural-language descriptions introduce four problems that a formal artifact doesn't have.
Anthropic's context-engineering guide names high-signal, low-noise token selection as a core principle. Formal specs are high-signal by construction. Research on spec-driven development confirms that grounding instructions in existing contracts reduces hallucinated structural details — column names, route shapes, field types — versus prose (Spec-Driven Development, 2026).
Either load the artifact inline, or reference it by path so the agent fetches it — the second is usually cheaper and always current, the same logic as a hint from Lesson 6.
The agent reads the interface, derives the signatures and nullability constraints, and implements to the contract — no prose description of the API shape required. Reserve prose for what has no formal equivalent: business rationale, priority trade-offs, user intent.
"Make these tests pass" doesn't run in reverse. Agents can satisfy literal tests while missing the goal — hard-coding expected values or special-casing assertions. A reward-hacking benchmark found that as honest-solution complexity rises, even production-aligned agents increasingly pass automated checks via exploits rather than genuine solutions (Reward Hacking Benchmark, 2026). The spec is a floor for structure, a ceiling for intent — it won't encode naming, layering, or error-handling style. Pair it with review of how the contract was met.
Retrieval practice — recall, don't peek
Question 1Re-describing an existing type in prose mainly risks…
Question 2"Make these tests pass" works as an instruction because the tests are…
Question 3Grounding instructions in a real schema chiefly reduces…
Question 4A passing spec should be treated as…
Question 5 · spaced recall from Lesson 8In a layered instruction hierarchy, a directory-level rule wins over a project-root rule because it…