Why Some Standards Survive and Others Don’t

In my article about CMS consistency I admitted that I failed. While I led five or six people, I kept our standards alive. When I had three teams, I lost. “Natural chaos won.”

That is true, but it is not the whole story. One standard survived. On almost every build, across the same three teams where everything else drifted, for eight years: every page loads only the CSS and JavaScript of the blocks it actually uses.

This piece is about why that one survived, and the others did not.

Key takeaways

A convention depends on everyone remembering it. A standard survives when skipping it costs the developer more than following it.
Standards die quietly: a new person, a deadline, a shortcut, and nobody notices the day it stops.
What lasted was whatever put the cost of skipping it on the developer: a score every build had to hit, or the next person opening the project.
Architecture enforces only what it covers. Leave a side door, and someone will use it.
A system that needs extra work every time dies like a convention, and it cost more to build.
Structure costs once, when you build it. Discipline costs every single day.
Not everything can be made structural. Taste and judgement stay with people, and stay fragile.

The standards that died

We tried to hold many things. Three of them, and what each was supposed to prevent:

Where settings live. One place for every option, so nobody hunts for a button. It lasted until the first new person put a setting where it felt natural to them.
Tabs, not rows. Our theme options had a structure: what belongs in the header options, what in the footer, what is global. That split survived. The rule inside it did not: every group of settings gets its own tab, never stacked in rows. Sometimes rows really were the reasonable choice, and a rule with reasonable exceptions stops being a rule. Everyone reads it in their own way.
CSS built per option. Block styles written in a PHP file that checked which options a block actually used and printed only the CSS lines for those options. It lasted until the team, quite reasonably, stopped writing it.

The first two did not fail because the idea was wrong. They failed because each one depended on people: remembering it, or reading it the same way, every day, on every project.

There are only two ways to put a standard into a team. You convince people it matters, or you review their work and fix it afterwards. We used both. Both are most expensive at the start, when the standard changes how everyone works. And even when the whole team has accepted it, the cost does not end: every new person needs it explained again. That is the real cost of a convention, and it is paid forever.

The third one was mine, and it taught me something the others did not. It was not a rule people forgot. It was a system, and it still died. It asked for extra work on every block to save a few lines of CSS: too complex a solution for too tiny a goal. I understand why the team let it go. A system that asks for extra effort every time is still a convention, only a more expensive one.

The one that lived

Loading only the CSS and JavaScript a page uses was a rule too, and every new developer was told it: each block has its own CSS file and its own JS file, and the page loads only the files of the blocks on it. Nothing goes into one site-wide file. The difference was what stood behind the rule. A PageSpeed score of 90 or higher was a required feature of every build, the same as a working contact form. And the developer who wrote the code was the one who had to optimise it if the score fell short.

So nobody needed convincing. Follow the rule from the start, or spend a day at the end of the project finding what to cut. Everyone did that maths once, on their first build, and then did it from the beginning. The two ways were still there, but a number did the work: the review was automatic, and the convincing was done by the result.

Compare it with CSS built per option. Per block, the rule paid the developer back on the same project. Per option, the saving was tiny, the effort was on every block, and no score noticed the difference.

It was not free. It came out of my research into how Google’s speed test worked back then, before it ran on Lighthouse. There were easy tricks to get a good score, but I wanted a stable solution that made pages really fast. The accepted advice at the time was one CSS file for the whole site, and the W3C validator flagged a style tag inside the page as an error. It still does. So for several clients I had to spend time explaining the logic, and once I even had to rebuild a site back into a single .css file.

But that cost ended, and WordPress itself proved the point twice. First, in 2021, core started doing what we did: loading block styles only for the blocks on the page. Then, in 2022, it went one step further and began printing some of those styles inside the page body, exactly what the W3C validator had been flagging on our sites for years. WordPress got the same validator error and kept the approach anyway. Google’s test now tells you to remove unused CSS. Every standard that died, we kept paying for until we stopped.

So I did not win that one by being more disciplined than with the others. I won it because the result was measured, and the cheapest way to the result was the rule.

Even that one leaked

It did not hold everywhere, and the place where it broke is the best proof of the point.

Our blocks’ own CSS and JavaScript loaded only where the block was used. Third-party libraries were a different story. Again and again I found the slider library, Swiper, loaded globally through a WordPress function in the theme’s PHP, instead of being attached to the block that needed it. Every page downloaded it, including the pages with no slider at all.

Nobody did it out of carelessness. The build controlled the block’s own files, but nothing stopped a developer from adding a library the usual WordPress way. On a project with many sliders, loading Swiper once for the whole site was simply easier for the developers, and moving it back into the blocks later was not always a quick fix. To be honest, several times we left it as it was, because there was no time to fix it. And the score did not catch it: one extra library rarely moved a page below 90, so nothing forced the fix.

That is the other cost of a convention. When it breaks, fixing it later costs more than following it would have.

An architecture enforces only what it covers. Leave a side door, and someone will use it.

One more that mostly held

There was a second one, and it held for a different reason. Our theme had a fixed structure: where blocks live, where components live, where templates live, where function extensions go. It survived, with some variation, across every team.

Nothing measured it. What enforced it was maintenance. A live site is rarely touched only by the developer who built it. Someone else adds a feature, someone else again fixes a bug a year later, and none of them wants to dig through a whole project to find where a thing begins and where it ends. On a team that rotates developers across sites, the person who pays for a broken structure is the next developer, and next month the next developer is you.

So the cost of skipping it landed on the same people who would have skipped it. That is the same mechanism as the score, without the number. It held less perfectly, because nothing checked it, but it held.

The standard nobody could read

There is a third kind, and it is the most common in agencies.

Oleg, our designer, has a rule for banners: 1440 by 600, with the composition centred and padded so any social network can crop it without cutting anything important. It is correct and deliberate.

It is also invisible to everyone outside his head. Every time someone else made a banner, the rule had to be retrieved from Oleg first. A standard that only one person can read is not a team standard. It is a single point of failure that happens to be well designed.

That is the reason we started writing our rules where both people and AI agents read them, which I described in Documentation for AI agents.

Three levels of control

In a discussion this month, someone summed up my argument better than I had. They described control at three levels: the input (what goes in), the destination (the structure it has to fit), and the decisions (what is allowed and what is improvised).

An AI agent is the new team member taken to the extreme. The model itself remembers nothing between sessions. What carries over is only what someone wrote down: memory files, AGENTS.md, a summary of the last conversation. And even then, it is a note the agent reads and interprets, the same way a person reads a guide. So the rules that matter cannot live in a note. They have to live in the system, where there is nothing to interpret.

That is exactly how we built Fabrement for working with AI agents, and it is the same principle as the CSS build:

The destination is a design system. An agent does not choose colours or spacing; every block takes them from one system, so the site cannot drift the way our old projects did.
The rules are part of the tools. Each operation an agent can use comes with its own rules, so it does not depend on the agent remembering a long guide. For sliders, for example, there is one allowed library, not whatever the agent finds first.
The decisions stay separate. Saving and publishing are different steps, so the agent cannot put something live as a side effect of saving it.

None of this makes the agent smarter. It makes the wrong result harder to produce, which is what worked for our CSS long before anyone used AI.

What stays fragile

The honest limit: only rules that can be expressed mechanically can be built into a system.

Taste. Judgement about what a specific client needs. The quality of a code review. The decision about what to build next. These stay conventions, which means they stay fragile, and they stay the part of the job worth paying people for.

So the real work is sorting. Everything that can be a wall, make it a wall. Everything that cannot, protect with people, and stop pretending a document will hold it.

The short version

A standard written in a document lasts as long as someone guards it. A standard built into the system lasts as long as the system does. I spent years trying the first way. Now I only trust the second.

With an AI agent, the second way gets sharper. A rule written for people gets interpreted. A rule built into the tools the agent uses gets followed every time, on every page, on every site, because the agent has no other way to do the job. Of all the standards I have tried to keep, these have the best survival rate I have seen.

There will still be that one developer who tells the agent to do it another way. There always is. But now the other way costs an extra move. They have to stop and ask for it in a prompt, while the default already works. And people behave like any physical system: nobody spends energy for nothing while everything works as it is. Call it developer thermodynamics.

That is the whole essay in one line. A standard survives when following it is the laziest option.

Why Some Standards Survive and Others Don’t

Key takeaways

The standards that died

The one that lived

Even that one leaked

One more that mostly held

The standard nobody could read

Three levels of control

What stays fragile

The short version

Related articles

The Best CMS Is the One You Don’t Need to Know

Website Builders Were Made for People. What Happens When AI Is the User?

WordPress MCP Adapter vs Fabrement

Start building custom Gutenberg sections with AI