A blog that builds the next blog post
I built this site in a day, alongside my eight-hour enterprise job. My own time came to six to ten rounds of five to fifteen minutes, in between runs of thirty to sixty minutes where the agents implemented things. This post is about how that worked, where it went wrong, and the pipeline that then wrote the post itself.
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
aliasfield. 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-pathon 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.
- 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.
- I paste the brief into the Claude app, switch to voice, and talk for fifteen to twenty minutes with a slightly sceptical interviewer.
- 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.
- 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.