Nobody reads a wiki page before writing code. The tool can be made to, and that is the difference between a coding standard that exists and one that is followed.
Two people on the same team, both building with AI tools, produce two different codebases. One writes an instructions file the tool reads at the start of every session; one does not. One keeps a decision log; one relitigates the same choice a month later. One’s tool follows the patterns already in the code; the other’s invents a parallel way of doing the same thing on every new file.
None of this shows up in a demo. All of it shows up eighteen months later, when someone has to work across both.
What actually gets read
An AI coding session starts fresh every time, with no memory of the last one unless something puts it there. The fix is a small set of files in the repository itself, because those are the one thing every session can be pointed at automatically.
An instructions file, kept under two hundred lines. Conventions, not documentation: how errors are handled, where business rules live, what never goes in a commit. Short enough that it gets followed. A file that has grown past a few hundred lines gets skimmed, not read.
An architecture note. What the system is made of and why, so a session does not have to reverse-engineer the shape of the codebase from the code every single time.
A decision log. Choices with their reasoning, so the next session does not reopen a decision that was already made for a reason nobody wrote down.
The ritual. Read at the start of a session. Updated before it ends, and the moment something important is settled mid-session, because a long session’s context gets summarized and the thing decided an hour ago is exactly what gets lost.
The standard has to travel with new work
The other failure mode is the standard existing somewhere and nobody remembering it exists. Every new project should start with these files already in place, stamped in as part of setting the project up, not written from memory three weeks in when someone notices the drift. The company decides once what the instructions file looks like; every new repository gets a copy automatically.
This is the same shape as any other automated onboarding step, and it should be treated as one: not a document someone is trusted to go and read, but a default that is simply there.
What this buys that a policy document does not
A policy document says how code should be written. These files are how it actually gets written, because the tool reads them before it writes anything.
It also compounds. A gotcha discovered on one project, written into the shared layer these files point to, is available to every project after it without anyone remembering to mention it in a meeting. That shared layer, and how a company runs it with more than one person contributing, is the learning loop.