Designers who build

Our designers work on the product itself, not a picture of it. They're trained and tooled to contribute to production codebases, through the same pull requests and checks as the engineers beside them, with agents doing the mechanics and the lifecycle's gates making a designer's change as safe as anyone's. Taste, and the call on whether something is right, stay the designer's job.

This doesn't make designers engineers, and it isn't meant to. What changes is the distance between an idea and a working thing someone can use, which shrinks from weeks to hours, and the handover in the middle, which goes.

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 isn't 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 instead of loyalty. That's messier than one tidy suite and far more durable, because no single tool at the centre gets to decide what's possible.

It's 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'll 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 isn't a better canvas

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

The shift we care about is designers working in production code themselves, as the first move, so that what they make is the product on the real stack and not a mock-up an engineer rebuilds afterwards. Once a designer expects to build the real thing, the tooling underneath becomes a detail they can change.

Where the work happens

Claude is where our designers work. On a laptop, the Claude desktop app runs the whole loop: it starts the project, previews it running in the same window, reviews its own output and fixes the obvious breakages. On a phone, the Claude app picks up the same project for a quick change or a look. On the web, claude.ai/code runs in the cloud with nothing to install, which is the way in for someone who'd rather not set up a machine.

Every project has the same things in the middle. Our skills, one set for each stage of the lifecycle, each knowing how Made by Many does that job. And a design system made for that project, which carries the design quality so the work doesn't slide into slop after three prompts. Either side sit GitHub, where the code is shared and reviewed, and Vercel, which puts it on the internet. The skills a designer meets first start a project themed from one brand colour, keep it running and fix what breaks, carry the house rules (the three states of every screen, real content, a visible focus ring) and put the result on a link. How we make has the full set. They follow the open Agent Skills standard, so the same skills run in Cursor, Codex and Copilot too.

Claude Design is the canvas done well, on-brand with no plumbing, and a good front door for the product managers and marketers who'll never open a repository. Chat artifacts suit a quick sketch inside a conversation. For our designers both are a step sideways: we keep choosing real, flexible code over polish in a box, because a brief needs whatever it needs, our own icon set one week and a live data feed the next.

Make the tool you need

The most useful habit we teach is asking for a design tool at the moment you need one. The project is running, and the agent can add whatever would help you see or decide, then take it away again. From our making sessions:

• "Make a page with every screen side by side, like artboards."
• "Show me this on a phone, a tablet and a laptop at once."
• "Build me a panel to try three or four typefaces, and let me switch between them."
• "Let me try this card with more room: just this one first, then every card."
• "Show me four quite different versions of the header, side by side. I'll pick one, delete the rest."
• "Make me design system docs with every colour, type size and component."
• "Add a pattern for the RSVP list: empty, loading, with an error, and with really long names."
• "Check this for accessibility and fix what you find."

The colours on this site were chosen with one of these, built from a single message. This is it, tidied up. Move a slider and this page changes; refresh and it goes back.

That's also why we stopped maintaining a visual editor of our own. A panel made for the question in hand, wired to the project's own tokens, beats a general tool that has to understand every project, and the agent writes the value back better than any editor could.

What every tool needs is packaged once, in packages we publish, so the agent only writes the part that answers the question: a canvas of every screen as live artboards, a sealed kit of controls that step through the system's own tokens and move every open tab and artboard together, and the system's own tokens, one tab away from any component you're tuning. Each hands back a prompt rather than a file, so the agent does the writing in the right place. They sit beside the tools a designer already reaches for, the browser, Vercel's previews, Claude's panes, rather than replacing any of them.

Opening the walled garden

Engineering has always kept a walled garden: its own tools, its own words and its own rituals, learned on the job and rarely explained to anyone outside it. We teach it directly, in the learning programme. The engineering ecosystem for non-engineers covers setting up a machine and what to do when it breaks, version control, how a frontend is put together, the design system in code, and how a thing gets onto the internet, with the Figma word for each idea next to the code one. Make a thing is designing and building a real thing with an agent, and Make it complex takes it into the world and into production.

Designers come out able to read what the agent did, direct it precisely, and work in a codebase they share with engineers.

Into production, through the same gates

A designer's change goes the same way as anyone's. It's made on a branch and committed through mxa-commit, which runs the pre-commit checks (formatting, linting, types) and keeps fixing until they pass. It opens a pull request, where the pipeline runs the tests, the accessibility checks, visual regression and the performance budgets. A person reviews it, it merges, and it's promoted to production with a recorded sign-off.

The gates don't care who wrote the change, and that's what makes it safe for a designer to make one. The engineering floor is enforced by the tooling instead of remembered by the person, so a designer's pull request is held to exactly the standard an engineer's is. How we assure quality shows what each gate checks and when.

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.

The change worth caring about isn't a better canvas or a cleaner export. 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's the capability you hand that agent: a skill, a set of conventions, a small tool it builds or runs for you.

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.