01
02
03
04
05Sections
Most company websites age the same way. The launch version is sharp, then every change waits for the one person who knows the system, and the site drifts away from what the company now does. AI assistants can now write, edit and publish web pages. They can only do that safely on a site built to be changed by them.
This piece sets out how we build those sites, using the rebuild of our own studio site as the worked example. The method applies to any company whose story moves faster than its web budget.
Why most sites resist safe change
A typical site keeps its words, layout and rules in different places. Copy sits inside a page builder, design decisions live in a designer's head, and nobody has written down which claims the company is allowed to make. An assistant asked to "update the case study" has to guess at all three. It will usually produce something that reads well and breaks something else, a heading style, a link or a claim the evidence does not support.
The fix is structural. Everything the assistant needs to make a good change has to exist as something it can read.
The four parts of a site AI can maintain
Content in plain files. Every page, article and case study lives as a text file with a fixed shape, a title, a description, the body and its sources. The site is generated from those files, so an edit is a change to one file and the design stays the same everywhere.
A written design system. Colours, type, spacing and every component the site uses are defined once and named. The assistant uses an existing component and never invents a new one, so a new page looks like the rest of the site on its first day.
A written house style. Our own rules cover spelling, sentence length, banned constructions and how evidence is attributed. The same file tells a person and an assistant what good copy looks like for this company. It also lists what must never appear, such as unsourced figures or a client claim the client has not made.
Checks before publishing. Every build runs a link check, flags banned words and confirms each page has its title, description and structured data. A change that fails a check does not go live. A private preview link shows the change before it reaches the public site.
What this looked like on our own site
We rebuilt brighterfuture.studio in September and October 2026 this way. The Library holds more than 180 articles and interviews as files. Three free courses arrive from separate builds and are imported with one command each, keeping their email gates and forms. When a course changes, the import replaces it and the build reports any copy fix that no longer matches.
The checks earned their place. During the rebuild they caught six articles linking a course at an old address, a robots rule that let two AI crawlers read gated lessons, and lesson titles repeated across parts. Each was fixed in the source and the fix held on every later build.
Where the limits sit
An assistant can draft, restructure and publish within the rules. It cannot decide what the company believes, which client results it may claim or which audience matters most. Those stay with the people who own the story. We write that boundary into the house style, and the people who own the story approve anything that changes a claim.
A site built this way also needs one person who owns it. The assistant does the work, and that person decides what ships.
How to tell if your site is ready
Ask four questions about the site you have now.
- Could someone outside the team find every word on a page in one place?
- Is there a written list of the components a new page may use?
- Is the company's house style written down where a tool could read it?
- Does anything check a change before it goes live?
Each no is a place where an assistant will guess. A redesign is the cheapest moment to turn those answers into yes, because the structure is being decided anyway.
Sources and further reading
Tell us what needs to move.
Bring the brief if it is clear. If it is unclear, tell us where the work is stuck.
Bring us the problem