Designing the output, not the prompt
Generating with AI got cheap. Understanding what comes back is the new design work.
The bottleneck moved
A few months ago, an AI agent could build a working screen faster than I could describe it. That sounds like the end of the story. It wasn't. The next day I opened the project and couldn't tell what had been built, why, or which of the three versions I had actually approved.
The model wasn't the problem. I was. I had a lot of output and no process around it.
Make a Now page for my site.
Generating is cheap, so understanding is what costs
When producing something costs almost nothing, the hard part is everything around it:
- Knowing what you're asking for. A vague request comes back as a confident answer, which is worse than a wrong one.
- Knowing what came back. A diff, a page, a running app, a list of commands. Each one needs a different way of reading.
- Knowing how you got there. Which decision led to which result, and what you would undo.
This is familiar to designers. It's what a design process is for. We never shipped the first sketch. We made versions, put them side by side, critiqued them, and kept a record of why we chose one.
What design already solved
Design systems taught me that consistency doesn't come from talent. It comes from structure: tokens, components, documentation, a single source of truth. Working with AI needs the same structure, applied to the process instead of the interface.
So I stopped asking “how do I write a better prompt?” and started asking “how do I design the outputs I get back?”
Peer: a library of outputs
That question became Peer, a native Mac and iPhone app I'm building to work with coding agents (Claude, Codex, Cursor). Every project has a Library, a place where the agent's work becomes something you can read, not just a stream of chat.
The conversation stays on one side and the outputs live on the other. You can always see what is being made, how, and the path that got there.
Three habits that changed my results
Decide by seeing, not by reading.
For any visual change, the agent builds a small prototype with versions A, B and C side by side before touching the app. I pick by looking. The text I write afterwards is short: “B, with C's rings.”
Write decisions down, outside the conversation.
Conversations end, but decisions shouldn't. I keep a shared memory, which I call the Brain, with decisions, tasks and logs for every project. Any agent that opens the project starts by reading it. We named Peer's artifacts “Library” so they wouldn't be confused with Claude's “artifacts”. That's written down once, and nobody, human or model, has to argue it again.
Peer's artifacts are called “Library”
- Decision
- Boards, tables, pages and bots live in the project's Library. They can be created from the chat or from the + button.
- Why
- “Artifact” already means something in Claude. Two meanings for one word would confuse people.
Make every step reversible.
In Peer, every agent turn is a git commit, with Undo one tap away. Commands show up as a single line instead of raw terminal output, and failures are always visible. When undoing is cheap, I let the agent try more, and I review faster.
The craft of directing
Working with AI didn't make design less important. It moved it. The work now is to shape the request, shape what comes back, and keep the record that connects the two.
That's still design. It's just applied to the process instead of the pixels.