

This kind of specification applies to the agent behavior or the agent behavior in a project. You don’t write it on every conversation, you write/review it once for the project or agent and let the harness include it on every conversation. You can even ask the agent to scan the codebase and pull desirable patterns out of it for future sessions.
The entire point of using an agent is to not have to write everything yourself, so that when you write “implement feature X”, the feature gets implemented in a way that makes sense in that project, is reviewed, refactored, and tested by agents, and it’s good enough to bring in a human reviewer.















I don’t know you, but it doesn’t sound like a high standards issue to me, sounds like a lack of process. I’ve been a thorough reviewer before AI, at least thorough in the ways that mattered, not nitpicking formatting. And I’ll tell you an automated reviewer today can catch more things before I have time to confirm the first item I find. There are still false positives, but it’s still more thorough than I have time to be. Bc of that it really helps including a round of automated review before looping in a human, regardless of who/what wrote the code.
The main kind of review problems AI still struggles with are the project direction ones: “does it make sense to implement this/like this?”, “should this be a new package instead?”, and things involving tacit knowledge that often goes undocumented “last time we did this, someone had to access prod on a Sunday” - so that’s what I focus my reviews on. And the other area is if you’re writing UI code, whether it’s a web app or a game, it’ll also struggle to determine what “feels” good to use, so it’ll need a human earlier in the loop.