A passing build tells you the code compiled. That's all it tells you. It is not evidence that the page works, that anyone can read it, or that a search engine can make sense of it — and treating it as evidence is how a site quietly degrades while every light stays green.

We learned this the direct way. Over the past month our own site shipped invisible headings, text wrapping in the middle of words, broken internal links, duplicate H1s, and pages too thin to justify existing. Not one of those was caught by anything. Every single one passed a clean build and deployed.

That's an uncomfortable list to publish. It's also the useful part, because the pattern in it is obvious once you write it down: none of those failures are compile errors. They're rendering failures, structural failures, judgement failures. The build system was never looking for them, and it never claimed to be. We were the ones treating a successful exit code as a quality signal.

So we wrote the check we actually needed. It's a shell script that runs against the built output and asserts the specific things that went wrong: headings that render invisible, words that break mid-string, links that go nowhere, more than one H1 on a page, pages under a content threshold. It runs before deploy and fails the run. There's a second mode that reads Search Console, and that one deliberately never fails — search data is evidence to interpret, not a gate to pass, and conflating the two produces a check nobody trusts.

The important detail is that it isn't a generic best-practice linter. Every assertion in it is a scar. It exists because that exact thing broke on that exact site, which means it's short enough to read in one sitting and specific enough that a failure always means something. Generic rule sets fail the opposite way: they're long, they're noisy, people learn to skim past them, and the one real failure gets lost among forty warnings about alt text on decorative images.

The same instinct drove the other half of the month's work. We spent it writing down brand rules, voice, colour logic, typography and design tokens as structured references rather than as things a few people happen to know. That's the part people miss about working AI-first. The advantage isn't a model generating your copy. It's that judgement which used to live in someone's head — what our headings should look like, what our brand does and doesn't say — becomes something a machine can check on every change, at three in the morning, without getting tired or being polite about it.

None of it is glamorous, and it costs real time you'd rather spend on the work itself. We'd argue it's the cheaper option. The alternative is finding out from a client, or from a ranking drop two months later, at which point you're paying for the fix and the credibility at the same time.

So the question isn't whether your build passes. It's what your build has never once looked for. Go and read your CI config and ask what it would let through — then write down the last five things that broke in production and see how many of them appear anywhere in it.

Ours was zero. That's why the script exists.