Building This Site with AI Agents, a Design System, and a Backlog

There’s a version of AI-assisted development where you sit at the prompt, describe what you want, the agent produces something, you give feedback, and you iterate in real time. That version works. But it doesn’t scale — not even to a personal website.

This site was built differently. It started with a design system, a structured backlog of user stories, and a Claude Code agent harness that worked through those stories systematically across multiple sessions. What I learned was less about AI capabilities and more about what it takes to make AI work as a real development partner rather than a smarter autocomplete.

Start with a design system, not a scaffold

The first decision was to define a visual identity before writing a single component. I called it Digital Frontier: a Southwestern desert meets AI architecture aesthetic, grounded in a specific set of color tokens.

--color-frontier:   #101820;  /* near-black page background */
--color-signal:     #FF5E0E;  /* signal orange — primary accent */
--color-sky:        #6FB7D6;  /* sky blue — AI Frontier category */
--color-gold:       #E7C66B;  /* gold — Architecture Notes category */
--color-clay:       #BF8055;  /* clay — Field Journal category */

Three fonts: Space Grotesk for headings, Inter for body, IBM Plex Mono for labels and code. Three blog categories, each with a dedicated accent color. A hero concept — desert landscape, constellation SVGs — defined before any page existed.

The payoff came later. When the agent needed to build the blog listing page, the PostCard component, the mobile navigation, the light/dark theme toggle — it had a source of truth to work from. Token names like --color-ink and --color-muted now travel consistently across ten source files. Story 022 (Design Token Adoption) was able to replace all nine raw hex values with their CSS custom properties in a single session because the system had been defined upfront.

Without the design system, every component would have been a negotiation about color values. With it, the agent inherited a shared vocabulary and stayed inside it.

The backlog as a contract

The more important structural decision was the backlog. Thirty user stories so far, each written in a consistent format:

As a [reader / developer]
I want [specific behavior]
So that [concrete outcome]

Acceptance criteria:
- ...
- Build passes npm run build with no errors

Each story lived in .claude/backlog/ as its own markdown file. When a story was completed, it was renamed to DONE-XXX-...md and appended with completion notes: what changed, which files, why.

This format did something important: it gave the agent a verifiable definition of done. “Implement blog category filtering” is ambiguous. Story 007 specifies that filter tabs must use aria-selected, that URL state must persist on browser back/forward, and that the empty-state message must be announced to screen readers. The agent can work against that. It can check that. It can mark it complete.

The commit log tells the story: Implement story 008: Contact page. Complete stories 011, 012, 014: RSS feed, mobile audit, PostCard thumbnails. Complete story 023: remove dead Atkinson font preload. Twenty-six stories shipped across a couple dozen sessions. Four accessibility and design-system stories remain in the backlog — a known, managed state, not accumulated debt hiding in the corners of the codebase.

How the agent harness worked

Claude Code’s subagent harness was the operational layer that made multi-session development practical. The key capability is decomposition: a story involving multiple components could be broken into parallel research tasks before any code was written. One agent scans existing component patterns, another checks what the design system defines, another reads the backlog for related work. Code comes after context, not before.

The CLAUDE.md file served as the persistent context layer: project status, planned stack, commands, conventions. At the start of each session, the agent had enough context to continue without re-explaining the project. A sibling Notebook repository held deeper project notes — deployment configuration, design decisions, the story of the DNS setup. The agent was instructed to read those before starting, grounding decisions in documented context rather than inference.

The feedback loop was session-persistent but not cross-session. Each session started fresh from CLAUDE.md and the backlog. That meant the backlog had to be the authoritative source of state — not memory, not chat history. A story either has ## Completion notes or it doesn’t. That binary is what made multi-session development tractable without drift.

What actually shipped

The site runs on Astro 7 with static output, deployed to Bluehost shared hosting via GitHub Actions SSH/rsync on every push to master. The build completes in under 3 seconds. The design system is fully tokenized. The blog started with a single listing page and client-side category tabs; it later grew into three dedicated landing pages — AI Notes, Architecture, Field Journal — each with its own hero and its own filtered set of posts, because a real route beats a query-string filter once there’s enough content to justify it. There’s a light/dark theme toggle, an RSS feed, a custom 404, Open Graph meta tags, and code syntax highlighting with copy buttons — all of it built through conversation, guided by stories, grounded in a design system defined before the first component existed.

The structure is the product

The pattern that made this work wasn’t the AI’s capability. It was the structure around the AI. A design system creates shared vocabulary. A backlog creates verifiable contracts. A persistent knowledge base creates continuity across sessions. The agent’s job was to execute against that structure, not to invent it.

If you’re building something with AI that’s more than a one-shot experiment, the investment in structure pays back immediately. Define your tokens, write your stories, keep your context tight. The agent handles the rest.