For the past while I have been responsible for the coding standards and agent rules of a production monorepo, and I have built pipelines in which an agent takes a bug report and delivers a reviewed pull request without a human typing any code. Whenever I describe this to other engineers, the questions are about the model. Which one, is it clever enough, does it hallucinate. In my experience the model is rarely the constraint. The constraint is context, and the uncomfortable truth is that most teams have never written theirs down.
An agent starts every session knowing nothing about your codebase beyond what you tell it. It does not know that your dataframes must stay in one library end to end, that your API responses get parsed into typed structures at the boundary, or that the last person who suppressed a type error to get a green build caused a production incident. A capable new hire absorbs these things over months of review comments and corridor conversations. An agent has no corridor. Everything it will ever know about how your team works has to exist in a file.
Rules are distilled failure
The first rules file I wrote was a wish list. Write clean code, add tests, follow the style guide. It achieved nothing, because nothing in it was specific enough to change a decision. The version that works reads more like an accident investigation report. When a session goes wrong, I ask what single piece of context would have prevented it, reduce the answer to one enforceable sentence, and add it to the file. Parse external data into typed structures at the boundary. Never suppress a type error to make CI pass. Do not refactor half a file and stop. None of these are aspirations; every one of them is a scar with a date on it.
"Done" is a claim, not a feeling
The most dangerous thing an agent produces is not wrong code, it is the word "done". A green build is not done. The rule I enforce hardest, on agents and on myself, is that a completion claim must state what was verified and what was not. "Added X and Y, deferred Z" is worth far more than "fully implemented", because the second version costs you a debugging day three weeks later, once you have forgotten there was anything left to doubt.
Skills, not longer prompts
A single rules file cannot hold everything, and stuffing it bloats every session with context that is irrelevant to the task at hand. The structure that has scaled for me is a small core of behavioural rules plus a library of skills: self-contained procedures for one kind of task, loaded only when that task comes up. Bootstrapping a dashboard app is a skill. Writing a pipeline is a skill. Fixing type errors properly is, pointedly, a skill. It is the same instinct as modularising a codebase, and the trigger is the same too: if I catch myself explaining the same procedure in a second session, that procedure becomes a skill.
None of this is glamorous work, and that is rather the point. Written well, the rules convert an agent from a slot machine into a colleague with a consistent floor, and the file itself becomes the team's institutional memory. The newest humans on the team read it for exactly the same reason the agents do. My benchmark is whether an agent can turn a real bug report into a pull request I would accept from a junior engineer. Increasingly it can, and every rule that got it there was paid for by a session that went wrong.