Built by agents, read by us

Agents do the implementation on this site: templates, styles, scripts and database changes. What gets built, and whether it’s right, stays with us.

Every change starts as something written. A design says what we’re making and why. A plan breaks it into numbered tasks, and each task goes to a fresh agent. Then the work is read three times: against the spec, as code, and by one of us. The plan also lists, in advance, the cases a reviewer has to check, under the heading “Review Focus”: an old link with a trailing slash, a navigation bar that might wrap onto two lines at 1,024 pixels wide.

This note is an example. An agent drafted it from a brief that said which files and commits each claim had to come from, and listed a source for every claim so one of us could check it. It was added to the site switched off, and it goes live only once one of us has read it.

Reviews are only worth having if they sometimes say no. Two examples from August, both still in the history.

A page on this site replayed our build history as a terminal session, and one line read “eslint: 0 problems”. The spec review checked it. ESLint 9 was installed with only an old-style config file, so the lint command died on startup. The linter had never run on this repository at all. We fixed both halves: the config moved to the new format, and the page stopped claiming a result it didn’t have. Once the linter worked, it reported 76 problems, one of them a real bug in a carousel.

Reading the case studies as code turned up a band of figures that rendered empty on every one of them. Craft’s table field starts with one blank row, and the template only asked whether the table had any rows. The same commit took an invented story out of one draft case study, about a surprise on a bill, because the research behind it didn’t record one.

Both are the same failure: a confident sentence nobody had checked. One of them was about our own discipline, on a page about discipline.

Reviews read one change at a time. Some mistakes only show across changes.

On 27 September the first mock of the homepage’s services came back far too dense. Each section carried an eyebrow, a heading, an intro, “sounds like you”, three chips, an honest bit and a call to action, and each demo had five or more controls and readouts. Dave’s verdict: “too much… everything feels quite squeezed in”. The lesson we wrote down: parallel agents each maximise their own section, and nobody owns the total. The next round overcorrected. Every section became heading, line, card, and the page went flat: “the user could get bored as everything looks similar”.

On 1 October it happened at the scale of the site. Ten pages were built in a day on one shared kit, by agents working from one shared brief, and each page was good on its own. Together they read the same: every page opened with the same header, every service page had the same row of example conversations, and six pages ended on the same process line, FAQ and pink close. Dave: “this creativity dies out the deeper you drop into the website”.

The same day, a step designed to change nothing you could see came back as a dozen “done” items. Dave opened the site, found almost nothing new, and asked whether this was the result of all the design work. The step had done exactly what it was meant to. The report just never said so.

The density limits became hard rules, written into every brief rather than left to taste: one idea per section, one main interaction per demo, at most two readouts. They live in a kit contract that is handed to every agent verbatim. It also says to vary the layouts down a page, and to give each type of page its own linking idea instead of cloning the homepage’s.

The lessons from 1 October are written down too. A kit needs several looks for each repeated part, and when parallel builders share a brief, each page is assigned its own looks before anyone starts. A step that will show nothing is announced as one, up front, and reports lead with what someone can see on the page. The design this note came from opens its first step with exactly that warning.

The contract also keeps a list of CSS traps, under a heading that says each one has bitten this project.

Everything the agents write for the public arrives switched off. The eleven case studies were seeded disabled, and so were these notes. One of us reads each one and switches it on.

It isn’t that agents are careless. They’re fast and thorough, and given the chance they’ll write a confident sentence about their own quality that isn’t true. The reviews are there to catch that. The person at the end is there for what no single review can see: whether the whole thing is right.