How AI-made work should be made

Execution got cheap. Judgement didn’t.

Building used to be the expensive part, so we decided everything before anyone wrote a line of code. Now I build the options and decide from the real thing, and the deciding is what costs.

Wireframes and mockups are dead.

They were a workaround for expensive code.

DISCOVERDEFINEDEVELOPDELIVERwireframesmockupssketches

A wireframe is a cheap picture of an expensive thing. That is the only reason it exists. Code used to be too expensive to be your first draft, so you drew a fake page and argued about that instead.

Code is cheap now. Arguing about a picture of a page, when you could be arguing about the page, is just slower.

So I made building cheap.

I industrialised it. A plugin marketplace runs the build: a strong model plans and holds the gates, cheaper models do the typing. It shipped roughly forty pages of a live client site. The interesting part is the two places it isn’t allowed to continue without me.

plugins
agents
skills
human gates
orchestratorFable / Opus · owns every shared file

The main session. Plans the queue, runs the human gates, integrates each part, and makes every shared-file edit itself.

foundations

once per project

Establishes what the project looks like before anything is built against it.

  1. design-system-extractorOpusproposes

    Pulls the design system out of brand material, a live site, or concept imagery. Enumerate everything, invent nothing: every value is provenance-tagged and anything inferred is flagged for approval.

  2. ui-patterns-extractorOpusproposes

    Reads the components already built and drafts the patterns doc from them, so new pages match the existing ones rather than only the brand.

  3. foundations-auditorSonnetread-only

    Checks a build against its own foundations: rogue values, off-scale spacing, bypassed tokens, doc drift. Conformance, not taste.

the loop

per page

Three moves, over and over: decide what to build, build it, check it. A person closes two of the three.

plan

One unit at a time, before any code exists.

  1. build-plannerOpusproposes

    Maps the unit into parts, decides what to build new and what to reuse, and proposes options wherever there's a genuine design choice.

human gate

I approve the plan. Not what it looks like, but what gets built, what gets reused, and what's out of scope. A wrong scope wastes the build; a wrong look just means building another one.

build

Each part in its own git worktree, about three at a time. The orchestrator merges and owns every shared-file edit — that contention rule is what makes running three builders at once safe.

  1. build-implementerSonnetwrites

    Builds one approved unit to the signed-off plan. Writes only its own files, never a shared one.

check

Six passes, each a separate agent, so nothing ever grades its own work. Findings get classified page-layer or shared-layer, and that classification is what decides the next step.

  1. build-verifierHaikuverifies

    Build, tests, linters, smoke checks, screenshots. Mechanics, not judgement, on the cheapest model that can do it.

  2. copy-integrity-checkerSonnetread-only

    Proves every visible string traces to the real content source. Exists because the loop once wrote plausible copy nobody had approved.

  3. legibility-auditorSonnetread-only

    WCAG 2.2 AA on the rendered page, and it classifies each finding page-layer or shared-layer — which is what decides whether the fix is automatic or has to stop for me.

  4. visual-reviewerOpusread-only

    Reviews by looking at screenshots rather than the diff, for the breakage code review structurally cannot see.

  5. perf-seo-auditorSonnetread-only

    Core Web Vitals and technical SEO, but only when the project's contract marks them in scope. Not every build is a public site.

  6. build-reviewerOpusread-only

    A sceptical fresh-eyes audit of code, structure and conventions before anything reaches me.

human gate

I approve the result. A page-layer fix the loop can apply itself; anything touching the type scale, a token or the design system stops here, because a shared fix changes every page at once and that is a decision, not a repair.

port

last

Moves the approved build into a CMS the client can maintain themselves.

  1. port-plannerOpusproposes

    Plans the port: one module per section, the field shape for each, and which repeating content becomes a database table instead.

  2. module-porterSonnetwrites

    Ports one section into one CMS module, lifting its CSS unchanged. Its own folder only.

  3. hubdb-porterSonnetwrites

    Ports one repeating section into a table plus a dynamic template, so a page exists per row.

  4. port-verifierHaikuverifies

    Checks the ported modules against the local mirror, then live in a browser. Never runs a production upload or a publish.

None of these are mockups.

47 real, coded, working pages on a live client site. Built, not drawn. Then cut down, mixed, and cut down again.

V1

Two quick probes, built before any copy existed, purely to read the client's taste. They picked the less tech-forward one.

11 frames
V2

The build loop. For every section with a real choice in it, it proposed four or more directions, then built the best three as whole pages. The labels on the frames are that spectrum: CALM is the on-system pick, DISTINCT is deliberately the furthest from it, WILD is allowed to lose. An alternative that's nearly the same as the recommendation is a fake choice.

10 frames · 3 carried
V3

My own cut, before the client saw anything: three options down to two, so the review was a real decision and not a menu. Then their mark-up came back on it.

9 frames
V4

Six rounds of client feedback. The mass option build was never run again: from here it was refinement, and each round shipped as a new version with the old ones left standing so the client could see what changed.

17 frames

Building all 47 took less time than wireframing three would have. Choosing between them took the rest of the project.