A few of us work on what we're stuck on, Wednesdays at 5:30pm

Designing the system

Designing the system comes down to one habit: matching the system to the need. At each decision you fit the choice to what the work actually requires, rather than reaching for a default. It is the system side of working with AI, the structure the work runs inside.

Here is the shape of a system like this one: a handful of separate parts, each with one job, wired together. This is only a suggested high-level blueprint, not the one right answer. Notice that Claude shows up twice, in two different jobs: it builds the static front end before launch, and the running system asks it for answers once it is live.

visits [HTTPS]reads content [Content API]calls [JSON / HTTPS]asks [API]builds the front end[build time]Visitor[Person]uses the siteFront end[Container: static site]what people seeContent[Container: CMS]headless: content via an APICode[Container: serverless platform]your logic, behind an APIClaude[Claude]builds it and runs inside itClaude shows up in two different jobs here. At build time it builds the static front end(the dashed arrow). At run time the code asks it for an answer (the solid arrow), the sameway the front end asks the CMS for content. Using AI to build the system and using AI insidethe running system are different decisions; the prompting craft is similar across both.
A container view in the C4 style: separate containers wired together by APIs. The visitor uses the front end, which reads content from a CMS over its headless content API and calls your code, which asks Claude at run time. Separately, at build time, Claude builds the static front end. Same model, two different jobs.

Each part has one job, and you match it to what the work needs:

  • How the AI works — Claude, the intelligence: how to structure the work it does, from a single call to agents, tools and safeguards. These are prompt-engineering decisions, covered on their own page.
  • Where the code runs — for example Cloudflare Workers.
  • Where the content lives — a CMS, for example Ghost.

Headless and wired with APIs

These pieces are not one block of code. Headless and wired with APIs →

Where the code runs

Where your code runs is a design decision, not an afterthought. Where the code runs →

Where the content lives

Where your content lives is a separate decision from where the app runs. Where the content lives →

How the AI works

Claude is the intelligence in the system. How the AI works →

Part of Working with AI. These are Shape decisions, made before and around the build, organised by the shape+build+launch framework.

The craft side of working with Claude is Working with Claude.