Code standards that made AI-generated code cheap to accept

A convention with no owner is a suggestion: it holds while someone has time to review carefully, and it stops the first week nobody does.

Conventions fade on disciplined teams too, because nothing enforces the agreement. On a system of nineteen repositories, with four developers in a team of twelve, "we agreed to do it this way" has a half-life of about a quarter. I had already seen where that leads: the same queue helper copied into seven repositories, because nothing stopped it.

With AI in the workflow, a soft standard gets weaker still: generated code arrives faster than a person can carefully read it, and the standard becomes decoration.

The requirement was to make the standards mechanical, checked by tools, so that accepting code would cost less than writing it.

Rules written as code

We wrote the standards as checks that the tooling runs, so none of them depended on anyone remembering a style guide. They included:

• No any, with a prescribed way of declaring types
• A component may not exceed 200 lines
• Every API call must have a request type and a response type

A different set per codebase

The web app, the backend and the component library each had their own set of rules. One set for both a backend and a design system would be loose enough to be useless for one or strict enough to be routinely bypassed in the other.

Deciding which rules mattered in which codebase was part of my job as Technical Lead.

Three severity levels, by stage

The same rule had a different severity at each stage:

Escalating the severity by stage keeps a rule present the whole way through and makes it block only where blocking is cheap. Most teams pick one severity and get one of two failures: if it is too strict, people fight the tooling or switch it off, and if it is too soft, the rule gradually stops being followed. This is the part of the setup I would recommend to any team.

Which checks run where follows the same logic. Formatting and linting run in the hook because they are fast and local, and types and tests run in CI because they are slow and definitive. A hook that takes thirty seconds gets bypassed within a week.

AI in daily use

With the checks in place, Claude Code went into daily use for components, tests and integrations, and design was connected to Figma.

The order mattered because generated code is cheap only when accepting it is cheap, and that requires something other than a person to check the boring half.

• Team throughput up roughly 50%, estimated from ticket cycle time
• Tests stopped being written by hand: the team generated them with Claude Code, and that matters because tests are the first thing dropped under deadline pressure
• The standards were enforced the same way no matter who reviewed the code, or whether anyone did

In hindsight, the most valuable rule was the 200-line limit on components, more than the type rules or the API contracts. It pays back over years, because it forces decomposition the moment something starts to sprawl, while splitting it is still easy.

The 50% figure is an estimate from ticket cycle times, not a controlled measurement.

In July 2025, METR ran a randomized controlled trial with 16 experienced developers working on 246 real tasks in repositories they had worked in for years. The developers predicted that AI would make them 24% faster, and afterwards they reported being 20% faster. Measured, they were 19% slower, a gap of 39 percentage points between how fast they felt and how fast they were.

METR has since revised the study's design and treats the result as historical, partly because in a follow-up many developers declined to take part if they had to work without AI. The main finding still stands as a warning: speed that people report themselves is unreliable, including when the report is flattering.

The team's setup differed from the study's in ways that plausibly matter. METR measured individual developers in codebases they had known for five years, using AI ad hoc in an editor with early-2025 tools. This team was building a product in active development, with rules enforced automatically and 2026 tooling. Those differences are reasons to think the 50% might be real, but they do not prove it.

I would measure cycle time properly: three months before and three months after, from data the team already had. It was available, and I estimated instead.