The site is meant to show two things rather than claim them: design systems and AI. The theme picker in the header is a plain web component driven by a real token pipeline. The breadcrumb prompt is a bit of fun. Both would have taken me weeks by hand.

Most of the effort was up front

I already had a dark, developer-style blog. The first thing I did was brainstorm with the agent about what I actually wanted, and as soon as I saw a terminal-based option I loved it. I love the terminal and I love themes, so the site has nine. You don't need hundreds.

I also cut things that added nothing. There was a lab page in the plan; it is built but not in the navigation. There was a "now" page; it went. The agent then went off and found almost everything I had ever made, talks, courses and workshops, with working links. That alone would have taken me forever.

A spec, a plan, and one outside review

The agent wrote a spec from the brainstorm, I approved it, and it wrote an implementation plan: sixteen tasks, each with the exact values to use and a list of tests. Before any code existed I had a second model, Codex, review the plan. It found 34 issues.

I did not read all 34. I let it roll, and the plan came back as version two with every one resolved. The rule I hold to is one review cycle, then move. If you let agents review each other indefinitely they loop forever.

What I care about instead is deterministic checks. The design tokens live in JSON and a build step refuses any theme where body text falls under the contrast ratio. A Lighthouse run gates the end of the build. When I ran Lighthouse myself and pasted the results back, the agent fixed the findings: a logo link whose accessible name did not match its visible text, and breadcrumb links distinguished by colour alone.

One task, one brief, one report

Each task ran the same way. A controlling agent wrote a brief with the exact requirements, a fresh implementer worked in a git worktree and wrote a report, and a reviewer read the code rather than the report. When a brief and reality disagreed, the controller made a ruling and wrote it in a log with the cost if it was wrong.

One real ruling: the plan had a 3:1 contrast rule for borders, which failed in all nine themes. The controller removed it, because borders are decorative and the accessibility rule is about text, and logged "low-contrast borders, reversible" as the cost. I found out at the next checkpoint and agreed.

What the agents got wrong

The build log is honest, so this can be too.

• A brief said a function keeps an alias field. After alias resolution the field was gone. The very first test failed on it.
• A brief marked several colours as known contrast failures. Against the real palette, none failed. The marks had been copied from a test fixture.
• The headline typing effect was built with clip-path on an inline element, which hid every wrapped line after the first in Chrome.
• The first image run dropped the EXIF orientation, so photos of me shipped sideways and upside down.

The pattern: the agents did exactly what the brief said. A wrong brief produces confident wrong code, and the fix each time was a test that pins the real value, not a better prompt.

Where I overruled them

The checkpoints are where I earned my keep. In one batch I sent ten corrections: I live in the Blue Mountains, not Melbourne; the product is called Foodzone, with no version number; the prompt had an @ in it that made it read like an email address; the lede said "I spent a decade", which was wrong, because I still do the work. The agents could not have known any of that. Facts, taste and naming are mine. Syntax is theirs.

The pipeline that wrote this post

Every post on this site, this one included, is made the same way the code was.

1. Claude Code writes an interview brief: the purpose, the audience, numbered evidence pulled from the build log or a session transcript, and ten questions that cite it.
2. I paste the brief into the Claude app, switch to voice, and talk for fifteen to twenty minutes with a slightly sceptical interviewer.
3. I paste the conversation back. Claude Code drafts the post in my voice. Anything only I can fill is left as a comment that the renderer strips, so a placeholder can never ship.
4. I edit and approve.

For this post I talked for about twenty minutes and pasted back the closing summary. The draft came from that summary and the build log. You can read the brief that produced it on GitHub.

The point is fun

AI does not have to mean purple slop. A terminal breadcrumb, a token-driven theme picker and a site that sounds like me came out of a day of directing, checking and saying no.

My advice, if you want one of your own: think about what you are passionate about, then just ask the agent. You can even ask it to help you work out what you want.

Working outline

This is the plan for the post, published early so the series is visible. The full write-up follows a voice interview, the way part 1 was written.

Why a custom element

• One file, public/js/theme-picker.js, ES modules, no library and no build step, tying back to the Web Components Foundations course.
• Progressive enhancement: with JavaScript off the control is simply absent and the page renders in the default theme.

One controller, many pickers

• A module-level singleton from createController(): every dispatch runs reduce, save, the data-* attributes on <html>, then data-switching for the motion.
• The theme-change event, bubbling and composed, fired from every connected instance so the popup and the /tokens/ page stay in sync.

No flash: the inline init script

• An ES5 script under 700 characters in <head> that applies the stored attributes before first paint, generated from the same constants as the element.
• The parity test that runs it under node:vm across 480 combinations, and the 12.25rem by 2.25rem box reserved so the nav does not move when the element upgrades.

Shadow DOM, tokens and the focus trap

• Custom properties inherit across the shadow boundary, which is why a token system and web components fit together; adoptedStyleSheets only, which sets the browser floor (Safari 16.4+, Firefox 119+); older browsers keep the default theme and never upgrade the element.
• The non-modal dialog: focus to the checked theme on open, Tab and Shift+Tab wrap with each radio group as one stop, Escape closes and refocuses, a composedPath check closes on outside clicks.

The panel that trailed the page

• The bug: a transition on every shadow element made the panel settle about 600ms after a switch while the page settled at about 270ms.
• The fix: registered --color-* properties already animate and inherit, so the extra transition now applies only where CSS.registerProperty is missing.

The 12,288-byte budget

• The spec guessed about 250 lines; the element landed at 12,207 bytes and 216 lines, then 12,276 bytes after the carry-overs.
• What was cut to stay inside it, including the mono face option removed end to end.

Directing the agents

• What was prompted, what came back wrong (the CSS constant that shadowed the global, the panel running off screen at 360px), and what was corrected.
• What Duncan would not accept, and why.

Working outline

This is the plan for the post, published early so the series is visible. The full write-up follows a voice interview, the way part 1 was written.

Why myGov made me care about tokens

• The motivation: one set of components at Services Australia serving many teams and frameworks, and what happens to all of them when a single value changes.
• Public-level war stories only: naming, governance, versioning, and the change that broke something downstream.

Three tiers: primitive, semantic, component

• Primitives are raw palette values per theme, semantics are theme-independent meaning (17 paths, including five named hues), and components alias semantics only.
• The colour rule the whole site follows: CSS and the picker reference semantic or component tokens, never a primitive or a hex literal, and a test enforces it.

One source in DTCG format, four outputs

• tokens/*.json in the Design Tokens Community Group 2025.10 format, and the dependency-free build-tokens.mjs that emits tokens.css, tokens.json, a manifest and the table in this post.
• Why everything renders in memory first, so a contrast failure leaves the last good output untouched.

The contrast gate

• Every text-on-surface pair in every theme checked at full precision, because #647a86 on white is 4.49686 and would pass at 4.5 if rounded.
• What failed and how it was fixed: only foregrounds moved, by HSL lightness in steps of 0.001, so Monokai Pro pink went from 4.30 to 4.53 and Solarized pink from 3.80 to 4.50.

Themes and modes

• Eight dark themes plus Paper, data-theme and data-mode defined so that a first visit with no JavaScript gets Gruvbox dark on any operating system.
• Why choosing a dark theme always sets dark mode, and how system mode follows the OS only when asked.

Section tints: three layers, no pixel coloured twice

• The tint contract: the theme layer, the section layer and the content layer each own different pixels, and exactly four places use the section tint.
• The CSS test that counts those four rules, and the Talks heading that briefly made a fifth.

When a token changes

• On this site: the line colour that failed 3:1 in all nine themes, and the ruling that borders are decorative.
• Back at myGov: how a change like that is versioned and rolled out across teams.

In 2014 I did FireBootCamp, SSW's developer bootcamp, and in November 2014 I started at SSW as a software architect.

In March 2015 Pluralsight turned that story into a short video.

If you are thinking about the same move: the field you come from is not wasted. Knowing what the software is for is half the job.

Reading this in 2026

This post is dated to the video, but I wrote it in 2026, looking back. In 2017 I became a Pluralsight author myself, on the platform the video is about. The nutrition side never left either: I still build Foodzone, a nutrition analysis platform for Australian nutritionists.