How We Rebuilt the Code23 Website With AI Agents

The current Code23 website is not a concept or a demo. We rebuilt it and launched it in August 2026 using the same agent-assisted engineering model we now use on client work. Senior people owned strategy, architecture, brand, content, QA and release. Coding agents handled much of the implementation, migration and repetitive checking. This is the build log, including the bits that went wrong.

From hand-written HTML to an agent-built website

When we started Code23 in 2005, our first website was hand-written HTML. It looked technical, did the job and needed a developer every time we wanted to change it.

We came from an animation background, so Macromedia Flash was hard to resist. It gave us movement, sound and interaction at a time when ordinary websites felt static. We invested heavily in it and got very good at it. Had we known what we know now, particularly after Apple refused to support Flash on the iPhone and iPad, we might have been a little less enthusiastic. Adobe eventually ended Flash Player support on 31 December 2020. Great technology for its moment; less brilliant as a long-term business bet.

WordPress came next. Its first public release appeared on 27 May 2003, only two years before Code23 started. We adopted it early and built several generations of our own website on it, alongside a lot of client work. It was the right move. Clients could manage content, we could build more capable sites without starting from zero, and the platform kept growing with us.

Over time, our own WordPress site carried more baggage: more plugins, more legacy templates, more security upkeep, slower page loads and too many compromises to keep an old system moving. That is not an argument that every WordPress site is bad. It was a sign that ours no longer matched how we wanted to work.

We started looking at Sanity and Payload, both content platforms we still like. At the same time, the acceleration in generative AI from 2023 changed the bigger question. Instead of simply moving the old website into a cleaner CMS, could we build it around the engineering model we believed was coming?

We waited until coding models, tooling and review systems could handle a complex marketing website under real controls. Then we used our own site as the proving ground. If we were going to tell clients that senior engineers could use agents to move faster without dropping the quality bar, our own website needed to be built that way too.

The project and the brief

We rebuilt the current public Code23 website and launched it on 26 August 2026. The goal was not simply a new design. We wanted a clearer service architecture, useful long-form content, visible proof and a stack we could evolve without fighting an old theme. Because it was our own site, we could publish the workflow without waiting on a client NDA.

Scope that mattered:

• Six service hubs that actually match how we sell
• Blog and content model that can carry long-form articles without turning every edit into a CMS job
• Entity-consistent facts everywhere (est 2005, Reading base, 60+ five-star reviews, the same one-sentence description)
• Performance and accessibility budgets enforced before go-live
• No “AI magic” section that claims speed without showing how delivery works

We are not documenting a toy landing page. The brief carried the same commercial pressure as client work: ship a site that sells, ranks and stays editable. For the numbers behind the speed, read our AI-accelerated delivery build-time data. For the wider explanation, read what is agentic AI.

From three months to seven days

Our previous WordPress website took roughly three months to design and build. Four months would not have been unusual. It followed the agency process we had used for years:

1. Prototype the main journeys.
2. Design the pages in Figma.
3. Turn the approved designs into HTML.
4. Test the front end, then rebuild it inside WordPress.
5. Configure the theme, content model and plugins, then test the whole site again in WordPress.

Every handover added time. A decision made in a prototype had to survive design, front-end development and CMS implementation. Each stage could reinterpret the last one, and the final WordPress build brought its own plugin, security and performance work.

The current Code23 site took seven days from the first design direction to a tested production build.

We began with colour ideas, references and a handful of websites whose pace or art direction we liked. That became a mood board, not a template to copy. Before we designed pages, we built the system: type, spacing, colour, grids, components, motion rules and reusable design tokens. That shared kit mattered more than any individual mock-up because it gave our designers, engineers and every model the same boundaries.

For this build, we worked in Pencil, now pen.dev rather than following the old Figma-to-development handover. Its canvas can work with agents through MCP, which lets a designer ask for six page directions, six versions of one component or ten treatments of a pricing block, then compare them and refine the strongest. The agent increases the number of useful options we can explore. The designer still decides what belongs in the product.

The same design system followed the work into implementation. We used frontier models including Codex, Claude and Gemini for different jobs, but none was allowed to invent its own visual language. Components, tokens and review rules kept the output coherent while the agents handled more of the production work.

Astro is the framework underneath the site. It suits a content-rich website because it can ship very little browser JavaScript by default while still giving us room for the animation and interaction that make the site feel like Code23. Blog posts and service pages live as structured content in the repository. We do not need a conventional CMS, a stack of plugins or a second implementation step simply to publish an edit.

We can describe a content change in natural language and route it through an MCP-connected workflow. The change still arrives as a visible diff, goes through tests and review, and is released by a person. Natural language replaces the admin screen, not the controls around publishing.

Seven days covered design exploration, the tokenised system, page building, animation, content migration, refinement and testing. The result has more movement, deeper blog and service content, and massively increased speed compared with the previous site.

The prompt-to-production trail

A typical implementation loop looked like this:

1. Human sets the frame. Architecture note, acceptance criteria, forbidden shortcuts (no unsupervised schema changes, no silent dependency upgrades, no inventing product claims).
2. Agent drafts inside the remit. Component variants, route scaffolding, content transforms, test stubs, refactor diffs against the design system.
3. Human reviews every change like production code. Naming, edge cases, accessibility, whether the change matches the brief or quietly expanded it.
4. Agent revises against the review notes. Specific instructions beat “make it better”.
5. Harden before merge. Lint, tests, visual check, performance budget, then a human release decision.

That trail is boring on purpose. The value is not a demo reel of prompts. It is a senior-directed pipeline with the same accountability we had before agents existed. The difference is how much implementation a senior hour can cover when the system is tightly controlled.

What we kept visible on the board:

• Branch and PR titles that named the human owner
• Review comments that rejected “helpful” extras outside the brief
• Screenshots of broken states we refused to ship
• A short note on every merge: what the agent produced vs what a human rewrote

Clients who want this transparency on their builds can ask for the same artefacts. The log is the product differentiator; the chat transcript alone is not.

What the humans did vs what the agents did

Humans owned:

• Information architecture and which services earn a hub vs a spoke
• Brand and design-system decisions that affect trust
• Claims discipline (corpus facts only; no invented case-study numbers)
• Integration choices and release authority
• Accessibility and performance approval
• The call to scrap an approach when the agent kept papering over a bad model

Agents owned (under direction):

• First-pass components and page sections against existing tokens
• Bulk migrations of content fields and internal link patterns
• Test scaffolding and repetitive refactors across similar routes
• Draft copy variants for humans to cut hard
• Inventory of inconsistencies (duplicate descriptions, missing alt text, orphan templates)

The split matters. Agents are fast at volume work inside a coherent system. They are weak at deciding what the business is selling. On a multi-brand programme we once shipped 100+ sites from a shared kit - that pattern only works when humans lock the kit and agents multiply the instances. The same rule applies to one flagship site: lock the system, then accelerate.

We do not let agents “own” production. Diff review is mandatory. The person who merges is accountable when something breaks at 3am.

Where it went wrong

Three failure modes showed up often enough to name them.

1. Confident wrongness on brand facts. Agents happily invented tidy statistics that were not in the brief. We caught them because every claim went through a human check against verified facts, including the 350+ projects we have delivered since 2005. Without that gate, a polished paragraph can ship a lie.

2. Scope creep dressed as helpfulness. “While I was here I also refactored X” is how reviews balloon. We started rejecting unsolicited extras unless they were required for the change. Speed without scope control turns a focused build into a mess.

3. Tests that assert the bug. Agents sometimes wrote tests that encoded the broken behaviour. Human review of test intent mattered as much as review of the feature code. Our AI agent QA notes go deeper on that pipeline.

We also hit the ordinary stuff: flaky previews, content freezes while marketing rewrote a service pitch, and one integration path that looked fine in isolation and failed when two agents touched adjacent modules without a human merge plan. None of that is exotic. Hiding it would make this log marketing. Publishing it is the point.

Launch started the next loop

The old workflow ended when the new WordPress site went live. This one keeps feeding evidence back into the product.

We use PostHog to understand what real journeys do, not only what we hoped they would do. Privacy-safe, aggregated signals can surface errors, dead clicks, contact-funnel failures and material changes in behaviour. When a signal passes the required confidence and sample thresholds, our monitor can create an evidence-backed task in Linear. Lower-confidence observations stay in a digest until there is enough evidence to act.

That is the continuous loop: observe, investigate, prioritise, improve and measure again. The agent helps monitor the evidence and remove repetitive analysis. It does not watch one unusual recording, guess at a fix and quietly rewrite the live site. People decide what matters, engineers review the change, tests run and a person controls the release.

We are now building the same kind of feedback loop into client platforms. A website should not sit untouched between redesigns while useful evidence piles up. It should become a product that the team can improve continuously, with the same design system and delivery controls protecting every change.

Near-perfect speed scores, on desktop and mobile

Speed was a hard requirement, not a nice-to-have. We set performance budgets at the start and the agents had to build inside them. Here is where the live homepage landed when we ran it through Google’s PageSpeed Insights on 11 September 2026.

On desktop the first content appears in half a second and the largest element is painted in 0.6 seconds. On mobile, which PageSpeed tests on a throttled connection and a slower phone, the largest element is painted in 2.3 seconds. Both sit inside Google’s “good” thresholds for every Core Web Vital, and the layout shift score of 0.002 means nothing jumps around while the page loads. Lab scores move a little from run to run, so treat these as a snapshot rather than a fixed number.

The old WordPress site had never been near these figures. The difference is not a caching plugin. It is a static build with no page builder, no render-blocking scripts, images sized and compressed at build time, fonts loaded once and a budget that fails the build if a page gets heavier than it should. That last part matters most: speed is a gate the agents have to pass, not a clean-up job somebody remembers to do before launch.

Why this matters for SEO

Google has used page speed as a ranking factor for years and Core Web Vitals are part of how it judges page experience. Speed on its own rarely moves a page from position 20 to position 1, but it decides who wins when two pages are otherwise close, and a slow site gives Google a reason to prefer the competitor. It also affects how much of your site Google bothers to crawl. A fast site is cheaper to crawl, so new pages and changes are picked up sooner.

The same applies to AI answer engines. When ChatGPT, Claude or Google’s AI Overviews fetch a page to check a fact or cite a source, a page that returns quickly and cleanly is easier to read and more likely to be used. Being fast is part of being recommended by AI, not just ranked by Google.

Why this matters for users

Rankings only bring people to the door. Speed decides whether they come in. Half a second to first paint means a visitor never sees a blank screen, and no layout shift means the button they were about to tap does not move under their thumb. On mobile, where most first visits now happen, every extra second of load time costs enquiries, and the people on the slowest phones and connections are the ones who leave first.

Fast pages also feel trustworthy. A site that snaps into place reads as well built, and a site that stutters reads as neglected, before anyone has read a word. For a business that sells design and development, the website is the first sample of the work. Ours needed to be quick because we ask clients to expect the same.

What shipped and how we verified it

What we shipped:

• Service hubs live and internally linked to the spokes that support them
• Blog collection frontmatter aligned so pillars and supporting posts share one schema
• Entity description consistent across footer, about, and key landing surfaces
• Accessibility and performance budgets checked before launch, not after a complaint, with the speed scores above as the result
• A review trail that can answer “who decided this shipped?”

Verification was not a vibe check. We used diff review, automated tests where they earned their keep, manual passes on conversion paths and a human go-live. It is the same bar we apply to client work through our AI development service.

If you want the quantitative companion - what compressed and what still takes calendar time - read the build-time data. If you want the plain definition behind the workflow, start with agentic AI.

The delivery model is simple: humans lead, agents execute and the review trail stays visible. If you want the same approach on your next website, app or platform, tell us what you are building.