This site

How AI agents built this site

05 · July 2026 · 3 min read

The footer of every page here makes a claim: built with AI coding agents, reviewed by hand. This essay is the receipt. It walks through the constraint system that made it safe to let agents write most of the code, and the review loop that decides what ships.

A budget, a policy, and a registry #

Before any agent wrote a line, the site got rules that do not bend. A Content Security Policy that allows no inline styles and no third-party scripts beyond the two Cloudflare services the site actually uses. A JavaScript budget: everything the site ships, gzipped, stays under six kilobytes, with no frameworks. Zero layout shift. And a fact registry: a file that lists every claim the site is allowed to make and where it came from, next to a do-not-publish list for the things that stay private, like client names and pipeline internals.

The registry is what makes agent-written copy safe. A sentence that cannot be traced to it does not ship, no matter how good it sounds. Language models like to be generous with praise and numbers; the registry makes that generosity a build failure.

What the agents actually do #

Most of the code here was written by coding agents, the same Claude Code and Codex workflow listed on my resume, operating inside those constraints. They scaffolded the build, wrote the CSS system and the WebGL shader, drew the architecture diagrams, and implemented every feature on this page, including the one you are reading about.

They also audit. When the site needed a full review, a fleet of read-only agents swept it in parallel: one lens on search, one on accessibility, one on performance, one reading the copy through a recruiter's eyes. Every finding that mattered then went to a second agent with exactly one job: try to prove the first agent wrong. Findings that survived became the work list. Findings that did not, died there.

The review loop #

1. Coding agents draft the change: the code, the copy, or both.
2. The constraint system gates it: the CSP allowlist, the JavaScript budget, and the fact registry every claim must trace to.
3. Auditor agents attack the result, and a second agent tries to refute each finding before it counts.
4. The change ships, the live site is verified from outside, and what the checks find feeds the next round.

Nothing lands on this domain without passing the same battery. The build has to compile clean. Greps sweep the output for banned characters, retired claims, and anything shaped like an email address. The structured data has to parse. The JavaScript gets weighed. Lighthouse has to hold its scores. After deploy, the live site gets checked again from outside, because what matters is what visitors actually receive.

Then comes the part that does not automate: I read it. Every word of copy on this site, including this essay, was reviewed and edited by hand before it shipped. The agents draft. The registry constrains. The battery verifies. I sign.

Check it for yourself #

This is the kind of claim that should not require trust. Open the network tab: everything this site ships in JavaScript weighs about five kilobytes gzipped, and this page loads barely three of them. Check the response headers: the Content Security Policy is right there, allowing nothing the colophon does not admit to. View source: no framework runtime, no tracker soup, and structured data that parses. The diagram above is the loop this very page went through before you could read it.

I build multi-agent systems for a living, and this site is the smallest honest demonstration of the lesson that keeps repeating: the agents are only half the system. The other half is the harness that catches them being confidently wrong. The agents wrote most of this site. The constraints are what made that a good idea.