I do not write code.

Every day on X, I watch designers who live in terminals ship things I could not. Whole sites going live from a single prompt thread. For months I told myself the feeling was curiosity. It was FOMO.

Most FOMO is noise. FOMO that repeats for months, from people who are actually shipping, is information.

Two weeks ago it won. I ran the workflow myself: two Next.js landing pages, no frontend engineer, no handing anything off. Just me, a design canvas, and a terminal window I lived inside for three or four days straight.

Both are live now. This is exactly what happened, and why I think any website designer sitting this out is already behind.

The scope first, so nobody reads more into this than what happened. Two single-page landing sites, not a 40-page platform. Two weeks end to end. I come from design and product. I have never written production code. What I brought was judgment about what good looks like. What I did not bring was React. That gap is the whole point.

What Paper.design is

Paper is a design tool built on real HTML and CSS. It looks like a normal canvas. It is not. Every element you place is a live web element. Draw a layout and you are writing flexbox, whether you know it or not. Select anything and copy it out as React and Tailwind, production ready.

Any element on the canvas copies straight out as Tailwind or React CSS, production ready.

The unlock: Paper's MCP server

Paper exposes the entire canvas to coding agents through MCP. Claude Code reads every frame, every token, every component, and writes back. Open a file in Paper Desktop and the server starts in the background. No configuration.

That one thing changes what a design file is. It stops being a picture of a website. It becomes a surface a coding agent works on directly. Which is what let someone who cannot write the code still direct it.

The design file is just another database the agent can write to. Image credit: Paper.design

The workflow: Paper, Claude Code, GitHub, Codex

The exact loop I ran on both pages. Connected end to end.

1. Design the system on the canvas. Real fonts, real CSS, real content. Paper pulls live data from APIs and sheets, so there is no lorem ipsum stage. I designed with the actual copy from day one.

2. Claude Code connects over MCP. It reads the canvas and writes components straight into the Next.js repo. Design tokens stay one source of truth across canvas and codebase.

3. Everything syncs through GitHub. Every change is a commit. Full history, reviewable diffs, nothing stuck on my laptop. The design file and the codebase stop drifting apart.

4. The real work is in the terminal. The canvas starts it. Claude Code finishes it. This is where I spent one or two days straight in a single window. Routing, CMS wiring, responsiveness, performance passes, refactors. Everything a page needs beyond what a canvas shows was one prompt away, with full context of both the design and the repo. I never opened the code to write it. I opened it to read what got built and say what to fix.

The moment I will remember is the self-correction. On a couple of tasks I gave one prompt and then just watched. The agent ran what it built, decided it fell short, and reworked it. Then did it again. A few passes later it landed on something better than what I asked for, and I had not said a word since the first prompt. It wrote, judged its own work, and rewrote, without me. That is what made it feel different from anything I had tried. I set the direction once and it closed the gap.

5. Codex reviews the code. One agent writes, a different one reviews. Codex reads the pull requests and flags what Claude Code missed. Two models with different blind spots catch more than one model grading its own homework. This mattered more for me than for most, because I could not catch a bad pattern by reading the code myself. A second agent was my code review.

6. Ship. What comes out is a standard Next.js codebase. Any engineer could pick it up tomorrow. None needed to, and neither did I.

No ticket that said "make it look like the design." The design already was the code. When a client asked for changes, I made them on the canvas and they were in production the same day.

My first thought once this was running was not "impressive." It was "why was this not done years ago." Every piece already existed. A canvas, a coding agent, a repo. Someone just had to stop treating the design and the code as two different things. Obvious ideas look inevitable the moment after they arrive.

The design leaders I was envying on X were not smarter. They started earlier.

Terminal showing Codex and the Paper MCP server active, calling paper.get_jsx, paper.get_tree_summary, and paper.get_screenshot to read a live Paper artboard.

Paper Shaders

Both pages shipped with animated shader effects. Mesh gradients, grain, that living texture. This is the motion that used to die in handoff, because a designer would perfect it on the canvas and the developer would receive a screenshot of it.

Paper Shaders fixes that at the root. Dial the effect in visually, export it as a lightweight component. Open source under Apache 2.0, zero dependencies, free for commercial use. The design is not a picture of the effect. It is the effect.

Is Paper a Figma replacement?

No, and the "Figma killer" takes flooding YouTube are missing the actual shift.

Figma is the standard for product design and it is not going anywhere. Deep component libraries, large teams, complex app work. That lives in Figma, and Paper is not pretending otherwise. It literally ships copy and paste from Figma.

Figma has moved toward code too. At Config in June 2026 it launched Code Layers, in closed beta, which turn a design layer into interactive code on the canvas. Worth being precise about what they are for. Figma's own product chief framed them as a space for exploration, an environment where you are iterating on ideas rather than producing code meant to go to production. That is a deliberate and reasonable choice for a team that wants to try directions fast.

It is also the opposite of Paper's choice. In Paper, production HTML and CSS is not a mode you switch into. It is what the canvas is made of, from the first rectangle you draw.

You can see it in which direction each tool is moving. Figma is adding code to a canvas that was built for pictures. Paper started from code and added the canvas. They may end up in a similar place, but the starting point still shows in the seams.

Websites are a different job from product design. A website is HTML and CSS pretending to be a picture during design, then rebuilt as HTML and CSS afterward. That round trip is pure waste. Paper deletes it by making the canvas the medium the web is actually made of.

So here is the claim, scoped exactly as I mean it. If you design websites for a living and Paper is not in your toolkit yet, your pipeline is outdated. Not your taste. Your pipeline. You are paying a translation step that no longer needs to exist.

Developers are still needed

Read the title wrong and you hear "developers are obsolete." That is not the claim. I shipped two landing pages, not a banking platform.

Two single-page sites on Next.js is a well-scoped problem. Known patterns, a clear system, content and layout as the hard parts. A coding agent handles that under direction, even direction from someone who cannot code. It is exactly the work where a frontend engineer was doing translation, not invention.

The moment it turns into invention, developers own it. Auth flows, real backend logic, data models, anything that has to scale or stay secure without falling over the first time real traffic hits it. On our product work, engineers are in the loop on every commit, because that is where judgment has to live in code, not just in the design.

And I will be straight about the edge of my own experience. I have not run this workflow on product frontend yet. The app UI, the multi-step flows, the state that has to hold together across a dozen screens. Those are a different level of complexity, and I will not claim what I have not shipped. Landing pages, I can vouch for. Product surfaces, I am still testing. Anyone telling you a canvas and an agent already replace a product engineer is selling something.

So the real line is narrower and more useful. This did not remove developers. It removed them from the simple tasks and moved them onto the ones that were always the actual job.

Where Paper falls short

It is open alpha and behaves like it. Edges are rough. Some canvas operations lag behind what a seasoned Figma user expects.

And it worked because I brought judgment, even without code. I knew when a layout was off, when the type was wrong, when to push back. The agent executes. It does not have taste. Hand this stack to someone with neither code nor an eye and you get fast garbage. The skill did not disappear. It stopped being syntax.

Who this is for

Website and marketing designers, first and most urgently. Brand designers who want shaders and effects that ship exactly as drawn. Anyone already working with Claude Code or Cursor who wants a visual surface their agent can touch.

Website developers too, and not as a threat. This is the workflow that stops handing you a static design to rebuild pixel by pixel. What lands in the repo is standard Next.js you can read, own, and extend. It takes the translation work off your plate and leaves the engineering that actually needs you. The frontend dev who spent half a project matching a Figma file was never the point of the role. This gives that time back.

Who can wait: product designers deep in app work and large design systems. Your center of gravity stays in Figma for now.

The bigger shift

Here is what the two weeks taught me, beyond the tool.

For a long time, the industry paid a tax called handoff. A designer draws a picture of software. An engineer rebuilds the picture as software. Everything lost between those two artifacts gets paid for in review cycles, drift, and shipped compromises.

Paper's bet is that if the canvas is code, the tax is zero. That is not a feature. It is a structural change, and the same thesis Rango is built on. The expensive part of building was never the design or the code. It was the layer between them.

And it settles something I have argued for a while. Designers were always told the same thing: learn to code, or get left behind. This is the quiet counterargument. I did not learn React. The code came to me. I designed in the visual language I already think in, and production code fell out the other side. Code is not asking designers to meet it halfway anymore. It is closing the distance on its own. The skill that mattered was never syntax. It was taste, and taste is exactly what I kept doing.

The craft did not get easier. It got closer to the surface. Every decision I made landed in production the same day, which is either thrilling or terrifying depending on how good your decisions are.