Prompting agents for Rust

General prompting advice applies (be specific, give examples, name the contract). Rust adds a few special requirements that, if you bake into your prompts, save you from the most common failure modes before they happen.

This page is a tactical reference. Categories, then prompts.

Asking for new code

The single highest-leverage prompt addition is naming the error type and the ownership boundary before the agent writes a single line.

This prompt does five things at once: defines the signature, the error model, the ownership boundary, the test coverage, and the gates. The agent has fewer decisions to get wrong.

Asking the agent to read before writing

Agents over-index on writing. They will happily write code that duplicates something already in the repo. For changes to an existing module:

Asking the agent to justify decisions

Decisions are where agents drift. Force them to defend non-obvious choices.

Asking to fix compiler errors

The lazy fix is almost always the wrong fix. Specify what you want.

Asking for refactors

Rust refactors should be smaller than agents naturally make them.

Asking the agent to explain

Some of the best leverage is asking the agent to summarize what it wrote so you can review the summary.

A prompt template I keep handy

## Goal
{one-sentence outcome}
 
## Contract
- Function signature: {explicit, including lifetimes and bounds}
- Error type: {enum name, variants, `thiserror` or manual}
- Ownership: {who owns what, who borrows what}
- Side effects: {IO, network, time, randomness, file paths}
 
## Tests
- Happy: {input, expected output}
- Each error variant: at least one test that produces it
 
## Gates (must pass before reporting done)
- cargo fmt --check
- cargo clippy --all-targets --all-features -- -D warnings
- cargo test --workspace
 
## Constraints
- No new `unwrap()`, `expect()`, `panic!` in non-test code.
- No new `unsafe` without an inline justification comment.
- No `Box<dyn Error>` in library APIs; use a concrete error enum.
- No `.clone()` you cannot defend.

Copy this, fill it in for each task, paste it as the prompt. The agent gets a clear contract. You get a deterministic review surface.

Stop using these phrases

• "Make it work." Too vague. Make what work, against what contract?
• "Fix the warnings." The agent will #[allow(...)] them. Say which lint to actually fix and how.
• "Add error handling." Define the error type and the recovery strategy. Otherwise you get Box<dyn Error> and silent swallowing.
• "Refactor for readability." Readability for whom, against what target? Specify the structural change.
• "Make it idiomatic." Idiomatic in whose dialect? Clippy already has opinions; defer to it.

The thing that actually moves the needle

The agent will follow the cargo gates. The agent will follow the contract you specify. The agent will not, on its own, decide between two valid designs in a way that matches your repo's style.

You decide design. The agent implements. Keep that division of labor explicit in every prompt.