# Designers who build

Status: draft. Owner: Andrew Flett. Last reviewed: 2026-08-27.
Canonical: https://agentic.madebymany.com/positions/designers-who-build

Designers ship working software now. Not prototypes that gesture at the product, but running, deployable software built through agents, with the engineering floor, tokens, accessibility, the three states of every screen, enforced by the tooling rather than known by the person. The product lifecycle skills exist so a designer never touches a terminal and never sees a stack trace, and still produces something real.

This does not make designers engineers, and it is not meant to. Judgement about what to make and whether it is right stays the designer's job; the mechanics of making it move to the agent and the conventions it follows. What changes is the distance between an idea and a working thing someone can use, which collapses from weeks to hours.

## Design is becoming an ecosystem, not a platform

For most of the last thirty years a designer's craft lived inside one dominant tool at a time: Photoshop, then Sketch, now Figma. This moment is not another tool to learn. Making has become almost free and landed within reach of designers themselves, and design tooling is starting to behave the way engineering's has for years: many small tools, swapped in and out as better ones turn up, held together by standards rather than loyalty. That is messier than one tidy suite and far more durable, because no single tool at the centre gets to decide what is possible.

It is also all still moving. What we do, and how we do it, will look different in a month, and different again in six. When the ground shifts that fast, committing a team to any one tool is a poor bet, and whatever you embed now you will be unpicking soon enough.

> The one thing worth investing in while everything else is fluid is not a tool at all. It is the mindset of the designer.

## The shift is not a better canvas

Most of the industry's energy is going into a friendlier, AI-assisted canvas with the code generated underneath. Moving the medium to code is a real step forward: when the canvas outputs the real thing, design and engineering finally speak the same language, and the handover between them gets shorter and cleaner. It just does not go far enough. The canvas is still sitting in the middle, and most of these tools are closed ecosystems that speak React and Tailwind and not much else, so "you are building the real thing now" means "as long as the real thing lives inside our tool". That is swapping one design artefact for another. The new artefact sits closer to production code, which is progress, but treating it as the finished product takes a small and forgivable act of self-delusion; we have all squinted at a clickable prototype and half-decided it was basically shipped.

The shift we are interested in is designers building in production code themselves, and doing it as the first move rather than the last, so that what they make is the product on the real stack, not a mock-up an engineer rebuilds afterwards. That mindset matters more than any tool. Once a designer expects to build the real thing, the tooling underneath becomes a detail they can change.

## The product lifecycle skills carry the way of working

What we run this on is [the product lifecycle skills](/playbook/delivery), a suite for Claude Code behind a single router, covering every stage from plan to operate. They hold far more than a design system. They carry the foundations of a real codebase, the scaffolding a senior engineer sets up before any feature code: layered design tokens, primitives and reusable components, the architecture and file conventions an engineer would recognise, with accessibility and standards built in rather than bolted on. A designer prompts their way from an idea to a themed, on-brand, working codebase deployed to a live link, structured the way our engineers would structure it. The structure is the point; it is what makes code an agent wrote safe to build on.

[The skills board](/playbook) breaks the whole suite down. The ones a designer meets first:

- `mxa-scaffold` starts a project: a fresh codebase generated from our conventions, themed from a single brand colour.
- `mxa-tokens` is the colour engine, and it is real code rather than a wall of markdown: an npm package with codified colour theory under the hood, deriving a whole contrast-checked palette from that one brand colour.
- `mxa-run` owns the dev loop: it runs the project, fixes the breakages before the designer sees them, and keeps undo cheap.
- `mxa-frontend` carries the house rules: icons over emojis, real content over placeholder, a loading, an empty and an error state for anything that fetches, a visible focus ring on anything you can click.
- `mxa-deploy` puts the result on a URL you can send to a client.

What a designer gets from this is not a blank prompt but a foundation to iterate on. That matters, because AI-generated code pushed more than a few turns from a blank start descends rapidly into slop, and a real foundation is what holds that off. Nothing here forces a stack either: the default is Next.js, Tailwind and Base UI because it is what we would choose by hand, and every skill reads which tool fills its slot from the project it is working in, so a client's stack can take the place of ours.

```callout Built for us, not locked to us
We built this in Claude Code to fit how we work, but Agent Skills are an open standard, so the same folders and scripts run on any agent that supports them, Cursor, Codex and Copilot included. No single tool captures the value, and we stay free to assemble whatever workflow suits us. This is design tooling starting to behave like an engineering ecosystem: open, portable, and ours to arrange.
```

## Which surface suits which person

The more interesting question day to day is which surface suits which person and which job, because Claude has several and they are not interchangeable. Claude Code on the desktop is the richest loop: it runs a dev server, previews the running app in the same window, reviews its own output and heals the obvious breakages, and it is the surface that most turns a designer into a builder. Claude Code on the web trades that depth for reach, running in the cloud with nothing to install, which makes it the way in for someone who will not set up a machine. Chat artifacts are the quick, throwaway end, good for a sketch inside a conversation and not much more. Claude Design is the canvas done well, on-brand and deploying with no plumbing, and a strong front door for the people around the design team, the product managers and marketers who will never open a repo; for our own designers it is the lateral move, giving up the flexibility our prototypes lean on.

The throughline is the same in every case. We keep choosing real, flexible code over polish in a box, because our prototypes lean on whatever a brief needs, our own icon set on one project, a live data feed on the next, and the tools that hand you polish by taking that flexibility away are not built for the work we do.

## Not another Dreamweaver

The field trying to answer how designers should build with AI is enormous, and worth a glance mostly for its size. v0 and Figma Make generate whole screens from a sentence, Cursor and Claude Code are growing design modes onto the editor, and a wave of canvases like Paper, Subframe and Opacity sit in between, with dozens more arriving and disappearing each month. Strip the branding and most are one of two familiar ideas: the visual web editor reborn, point at a canvas and get the markup out, or the canvas paradigm of Figma and Sketch kept intact with AI bolted on to turn the arrangement into code. Both are improvements. Neither is a new way of working; they are faster horses.

```callout A note for the youngsters
Dreamweaver and FrontPage Express were nineties software for laying out web pages by dragging boxes around. They produced slop too, just deterministically.
```

The change worth caring about is not a better canvas or a cleaner export; it is that the agent is becoming the surface. When the thing you work through is a capable model sitting in your codebase, the useful unit is no longer an application with its own window, it is the capability you hand that agent: a skill, a set of conventions, a small script it runs on your behalf. That is why the centre of our own experiment is a skill rather than a tool.

Small utilities still have a place under that. There is a point, somewhere around the fourth attempt to describe a box-shadow to an LLM in words, where you would trade the whole conversation for a single slider. `mxa-editor` exists for that point: one command opens a deterministic visual editor over the running app, the designer nudges a shadow, a colour or a spacing value by eye, and the change is written straight back to the source. It is a hand tool for the small visual calls where a slider beats a sentence, kept for when arguing with an LLM is the long way home.

## What lasts

The prize is not a faster designer. It is a designer who can build. Tools will keep coming and going underneath that, and they should. The capability is the part that stays, and it makes for a more interesting job than the one we started with.