Table of contents
Open Table of contents
What AI is doing, and what it isn’t
A fair amount of my recent delivery runs through AI-assisted workflows — Claude and MCP-based tooling handle a lot of the repetitive parts of building and maintaining sites. That’s a separate claim from “AI builds the site.” The architecture, the technical decisions, and the QA stay mine. What the tooling speeds up is the typing — scaffolding a component, drafting copy from a brief, writing the first pass of a test — not the judgement about whether any of it is right.
That distinction matters more than it sounds. It’s easy to describe an AI-assisted workflow in a way that makes it sound like the AI is doing the thinking. In practice, the thinking — what to build, why, and whether it’s done — is still a human job. The tooling just removes a lot of the mechanical distance between a decision and the code that reflects it.
The shape of it: plan, then ticket, then build
The workflow has a fairly plain shape, and the plainness is the point.
Nothing gets built before there’s a plan to build it against. A project starts with research and a structured brief, not a prompt and a blank editor. Once a plan exists, work breaks down into tickets — one focused piece of scope each, worked one at a time rather than several in parallel and reconciled later.
Each ticket moves through the same review passes before it’s considered finished: a check that the content is accurate and matches what was actually agreed, a check that it’s reasonably discoverable, and a QA pass that runs the build and checks it against what the ticket said it should do. None of those passes are optional, and none of them get skipped because a ticket looks small.
Why the discipline matters more than the tool
The specific tooling — Claude, MCP-based integrations — will change over time; it already has, a few times over. What doesn’t change is the discipline around it: plan before code, one ticket at a time, nothing ships until it passes a QA gate. That structure is what keeps an AI-assisted workflow from drifting into “whatever came out of the last prompt.” Without it, speed just means getting to a worse outcome faster.
This site is the example
This site is itself a worked example of that process. It was planned, built, and QA’d through exactly this kind of workflow — Astro, with Markdown as the content model, no database, no admin login, no monthly fee behind any of it. The content you’re reading now went through the same ticket-and-review cycle as the code that renders it.
If you want the fuller version of how I describe this day to day, it’s on the About page.