Drafts While I Sleep

Every design project starts with the same tax. Before anyone can react to an idea, someone has to make the first version of it. For a product designer that's usually a mockup: a careful picture of software that doesn't exist yet. It takes hours, it goes stale the moment the real components change, and engineers still have to translate it into code.

I stopped paying that tax by hand. I run a small system of autonomous agents that turns design requests into working prototypes, built from the team's real design system, and hands them to me as drafts to review. It runs on my own laptop, and it builds while I'm in meetings or asleep.

This essay is less about that system than about the way of working behind it: what I let agents do, where they stop, and why I think the pattern matters.

The loop

The system watches the two places where design work starts: the issue tracker, where requests are assigned to me, and team chat, where people ask for things in conversation.

A few times a day, a scheduler wakes it up. For each new request, an agent makes a judgment call before anything gets built:

• Does this already exist? If a prototype already covers the request, it points to that one instead of building a duplicate.
• Is it clear enough to build? If not, it asks a specific question rather than guessing.
• Can it be shown as a prototype at all? Some requests are research, copy, or policy questions. It says so and moves on.

When a request is ready, a coding agent starts in its own isolated workspace. It reads the repository's design rules, finds the closest existing patterns, and builds a few interactive states from production components. It checks its own work with the same tools an engineer would use: type checks, linting, and validation. Then it opens a pull request marked as an agent-generated draft that needs human review, links it back to the original request, and sends me a short summary.

I can also ask directly. A chat message with a rough brief, a screenshot, a doc, or a link gets a draft back in the same thread, usually within the hour. If the draft is close but not right, I reply with feedback, and the agent revises the same draft rather than starting over.

The building blocks

None of the parts are exotic, which is part of the point.

• A headless coding agent. A command-line AI agent does the reading, building, and checking. It runs with a narrow set of permissions and must return a structured result, so every run ends with something a script can act on.
• A component workbench. Prototypes are interactive stories built from production components. A prototype doesn't just look like the product. It's made of the product.
• Version control and pull requests as the review surface. Every draft is a branch and a pull request. Review, comments, and history come for free, and nothing reaches the main branch without a person approving it.
• The issue tracker and chat as inputs and outputs. Work comes in where people already ask for it, and results go back to the same place.
• Operating-system plumbing. A scheduler wakes it, the system keychain holds credentials, and a short script holds everything together. No servers, no new infrastructure to maintain.

Where the agents stop

Getting an agent to write code was the easy part. The real design work was deciding where it stops.

Drafts, not decisions. Everything the agents make is a proposal. Pull requests open as drafts, labeled so nobody mistakes them for finished work. Marking one ready for review, or merging it, is a separate, explicit step that only a person takes.

It acts as me, on my machine. The agents use my own accounts for code, the issue tracker, and the AI model, so every pull request and comment traces back to a real person who is accountable for it. When teammates started running the same setup, the rule held: each person runs their own copy, with their own credentials, acting only on their own requests. They share one chat bot, and each laptop claims a request before acting on it, so nothing gets built twice.

Backpressure. Agents can produce drafts faster than people can review them, which is its own problem. The system counts open agent drafts across the team and pauses scheduled work once too many are waiting. Direct requests still go through, because someone is clearly waiting for those.

It reports when it does nothing. At first, a quiet morning looked exactly like a broken system. Now every scheduled run checks in, even when nothing was ready to build, with what it looked at and what's waiting on me. Silence is never ambiguous.

It can be told to stop. A single message pauses scheduled work while I'm away. People take vacations, and their automations should respect that.

One request, start to finish

Here's a real example, with the details kept generic.

The request. A ticket asked for a small change: rename the two permission sections on an access-control settings page, where admins define what a role can do. The old labels confused people. One of the proposed replacements collided with a term users already knew for something else.

The first draft. The agent read the ticket, found the existing settings page in the prototype library, copied it into my work-in-progress area, and renamed the sections. It worked, but it was thin. A label change doesn't show how the names feel inside real tasks.

The rebuild. I replied in chat with what I actually wanted to see: the full create and edit flows for a custom role, with rule criteria modeled on a pattern we already had elsewhere in the product. The agent added a commit to the same draft. It now had a create flow and an edit flow, but my review found the problems you'd expect from a fast first pass:

• Opening an existing role showed default values instead of that role's settings.
• The name couldn't be edited, and the save button was always active.
• A note meant for me showed up as interface copy.
• The "rule criteria" were a flat list, not real rules.

None of that was a reason to throw the draft away. The structure was right, and fixing it was faster than starting from a blank page.

What I changed in review. Working with an interactive coding agent in my own workspace, I took it from a draft to something I'd put in front of engineers:

• One panel for both creating and editing. Each rule picks a resource type and an access level, optionally narrowed by tag conditions, with a live count of what the rule will match.
• The naming decision itself, recorded in the prototype's docs alongside the rejected options and why.
• The actions the production page has but the draft didn't: clone, delete (disabled when the role is in use, with a confirmation step), and set as the default role.
• A read-only details view for the built-in roles, with a summary of what each grants and the raw definition in a collapsible, copyable block. Cloning a built-in role now creates an editable copy pre-filled from that definition.
• A round of polish: consistent button sizes, status chips beside the title, and scroll behavior that keeps the copy button in view.

Each of those instructions went into the project's notes, in my words and dated, so every later session started from my decisions, not from the original ticket.

The result. Over two days, a one-line rename became a reviewed prototype of the whole feature. I marked it ready for review and merged it. One more payoff: a separate request for "clone a built-in role" turned out to be fully covered by this work. I told the system so in one message. It linked the finished prototype on that ticket and closed its own duplicate draft.

The agent did the volume: copying, scaffolding, wiring states, checking its work. I did the judgment: what the request really needed, what was wrong, and what the names should be. What connected the two was memory.

Memory is the multiplier

Those notes did more for quality than any model upgrade has.

Alongside the code, I keep a set of written instructions and project notes that every agent session reads first. The instructions say how I want agents to work and which workspace is doing what. Each project gets its own notes: the requester's words quoted and dated, the decisions so far, and the open questions.

The agents read those notes before they build. If a project already has decisions behind it, they follow those instead of re-deriving them from a terse ticket. After a build, the system starts notes for the new prototype: what was asked, what the agent assumed, and what it couldn't decide. When I sit down to review the draft, I don't have to reconstruct the context. I'm reading a short record of exactly what I need to judge.

That loop matters. Agents are good at producing and bad at remembering why. Writing the why down, in the requester's words, is what turns a pile of drafts into a body of work.

Why it matters

The obvious benefit is speed: an idea that would have waited a week for a mockup gets an interactive draft the same afternoon. But speed isn't the most important part.

The designer's job shifts from producer to editor. I spend less time drawing first versions and more time on what only a designer can do: judging whether it's right, noticing what's missing, deciding what to explore next. The example above is typical. The agent's draft was wrong in a handful of ways, and every one of those ways was a design decision worth my time. The quality bar goes up rather than down, because I'm reviewing more options instead of polishing one.

Design and engineering get closer. A prototype made of production components is a far better handoff than a picture. Engineers can open it, inspect it, and reuse its structure directly.

Exploration becomes routine. When a first draft costs almost nothing, you stop rationing ideas. "What would this look like?" becomes a chat message, not a project.

It's a responsible way to work with autonomous agents. The pattern isn't "let the AI do the design." It's this:

1. Give agents a narrow, well-defined job.
2. Let them act only where acting is safe and reversible.
3. Make everything they do visible and attributable to a person.
4. Require a human for every decision that matters.
5. Write the reasoning down, so the next session, human or agent, starts from understanding instead of guesswork.

None of that is specific to design. I think it's where a lot of creative and technical work is heading: people setting direction and judging quality, with agents doing more of the first-draft work inside guardrails the people chose.

The agents build the first draft. I still decide whether it ships.

Dylan