When I redesigned the homepage for timekeep.ph, the hard part was not writing React. It was judging layout before I had paid the cost of implementing it.
The loop I had been using with agents was easy to start and expensive to finish: describe a section, get JSX, render it in the app, scroll the page, notice that the hierarchy or spacing is wrong, and prompt again for another full pass. Text mocks made the same problem quieter and worse. An agent would describe a clean hero, a clear three-step flow, and a strong CTA, and on the page the weight was still off, the order still felt wrong, or the trust strip sat in a place that only made sense in the paragraph. I only learned that after the browser had already forced me through implementation.
Visual design with agents is only fast when the agent can draw on a real canvas, not only describe UI in text.
HTML prototypes still count as code
There is a real alternative that does not involve Paper. You can tell the agent to draft a standalone HTML file, a small React prototype, or a throwaway page that exists only so you can look at structure before you touch production. That is already better than reading UI as prose, because you get pixels, not a description of pixels.
I still think Paper is faster for the kind of work a homepage redesign needs. An HTML draft is closer to shipping code than it looks: files to open, a local server or preview, enough styling to be legible, and a habit of treating the draft like something you might keep polishing instead of throwing away. Each revision still feels like editing a mini project. On a canvas the same revision is a visual edit. The agent rewrites a section, I get a screenshot, and I can keep or kill the idea without pretending the prototype is almost production.
That difference compounds when you are exploring hierarchy across a full page. With a prototype, every structural change tends to pull styling and layout code along with it. With Paper, the question stays narrow: does this read, or does it not?
The loop that actually got faster
I moved the homepage work into Paper, a design canvas that agents can reach through MCP. MCP is the bridge that lets the agent inspect the artboard, write or rewrite nodes as real layout, and send a screenshot back so I can judge hierarchy, spacing, and type without leaving the design surface. The useful cycle was inspect, draw, screenshot, decide, then move to the next section. I still typed product intent in plain language. The difference was where the answer landed: on a surface I could see, not in a chat reply that claimed the page would feel clear.
That is most of the speed gain. The feedback loop no longer depends on a full code pass just to answer whether the page reads.
What that meant for timekeep.ph
The live homepage is the after state: an owner-facing headline first, then trust, then the three-step path from staff records to payday, Philippine payroll rules, staff tools, and the trial CTA. The sharp line on the page is still a product call rather than a model invention (“You didn’t start a business to do payroll”). Paper did not invent that message. It let me test whether the rest of the page supported it.
In the old loop I would have coded most of those sections before I knew the structure held. In Paper I could see hero weight, step order, and CTA placement as one page, then implement once the shape felt honest. The handoff to production was ordinary work: map the agreed layout into the site, keep the copy decisions, and ship. The canvas was the decision surface. The repo was the delivery surface.
See the result on timekeep.ph.
What I still own
Paper and MCP did not remove product judgment. They removed a slow way to get a picture. Paper did not invent the product message; I still chose the words and the hierarchy. MCP still needs taste on spacing, type, and when a section is done. Agents will offer weak variants, and most of them should get killed. The live site still needed judgment beyond the canvas: what Timekeep is for, who it serves, and what a Philippine owner needs to trust before they start a trial.
That is the same line as Don’t outsource the understanding. Agents can accelerate the work. They cannot carry the responsibility.
Bottom line
If the agent can only talk about UI, you still design in the browser after the code exists. Drafting HTML or a throwaway prototype is a real step up from text, and for some tasks it is enough. For a homepage where I needed to see structure change quickly, Paper through MCP was faster because the agent could draw on a canvas I could reject before I paid for implementation.
Design on a canvas, not in a prompt. Then write the code once the page already makes sense.