Rules for coding agents in a production codebase

The loop

Business requirements become tests. The agent writes code against the tests. The tests run. Fix, repeat, until green. The tests define what correct means, not the agent and not my reading of the diff at midnight. Writing the tests is where I spend my own attention, because that is where the requirement gets pinned down.

Rules live in the repository

Before the agent writes a line it reads the rules that live next to the code: naming, the layering of the codebase (domain, application, infrastructure, presentation), and what must never be imported where. A rule that lives in a chat message is forgotten by the next session. A rule in the repo is read by every session and by every human too.

Rules that fail the build beat rules that need a reviewer

• An embeddable widget has a build-time check that fails if a server module leaks into the bundle. The agent cannot ship a secret to the browser by accident.
• The set of AI transforms is typed as a complete record, so adding a transform without its server strategy does not compile. See every AI step falls back to its input.
• The end-to-end suite runs on Playwright against an in-memory database with a role matrix of expectations, and a custom reporter shows each test’s screenshots and API calls. When an agent breaks a permission rule, the failure comes with pictures.

Keep it practical

The simplest approach that works wins. Agents are good at producing more code; the job is to want less of it. A client put it this way after a year of working together:

“He put real thought into working with AI coding tools, setting up rules and structure in the codebase so the generated code actually fit. But he stayed practical about it, going for the simplest approach that works and flagging things like licensing questions early instead of after the fact.”