The repo decides the speed, not the prompt

You do not make the agent faster with a better prompt. You make it faster with what is already in the repo before it writes a line.

Prompt engineering gets the attention because it is the part you can see. You type, the agent answers, you tweak the wording, the answer changes. It feels like the lever. It is the weakest one you have.

Same model, same prompt, different output

Give the same agent the same prompt in two repos. One has the conventions written down, guardrails on what it can touch, and a fast test it runs against its own work. The other has none of that. Same model, same request, completely different output. One needs a tidy-up, the other needs a rewrite. Almost nothing in the prompt closes that gap. It was set before you typed anything.

What actually compounds

So the work that compounds is the standing setup, not the wording. The repo instructions the agent reads first. The boundaries that stop it touching code it should not. The checks that catch a bad change in seconds, not in review. Tune the prompt and you fix one answer. Get the setup right and every answer after it gets better.

One caveat worth saying out loud: the setup is judgment, not volume. The instructions that help are the why and the when-to-follow, the senior tribal knowledge, not an auto-generated dump of the file tree. More context is not better. High-signal, current context is, so delete more than you add. A stale convention file is worse than none, because the agent trusts it.