When a coding agent makes a bad edit, I want to know what it had access to. Did it find the call sites? Read the repository instructions? Run the test that would have caught the mistake?
A stronger model can still waste a session guessing the test command or rewriting a generated file. The harness should make that information easy to find. A few maintained project notes and reliable commands are often more useful than a huge introductory prompt.
My preferred sequence is fairly ordinary: inspect the working tree, search, read the relevant files, make a scoped change, run checks, inspect the diff. Preserve changes that were already there. If a check cannot run, say so rather than quietly treating it as passed.
Retrieval needs some care too. For a function change, give the agent its callers and tests. For a dependency issue, give it the installed version and the matching documentation. Loading the whole repository is a poor substitute for finding the right part.
I think of the harness as part of my development environment. Its value should survive a model switch. If changing providers means losing all the useful project knowledge and checks, too much of the setup was living in the conversation.