Parlay

Why

An AI agent can build software from a description. The descriptions it works best with are technical ones: components, state, routes, frameworks. Many designers do not speak that language, and should not have to. What every designer does know are the basics of the craft: who the person is, what they are trying to do, and how the product should answer.

Parlay gives a designer a familiar tool for working with an agent. You describe what users need, not how to code it, in terms a designer already uses: goals, personas, conversations, flows. The technical decisions are made once, in a separate place, and the agent applies them.

It also fixes something older. Design handoff has always been a lossy copy. A designer knows what a person is trying to do; the code ends up knowing only which widgets were on the screen. When an agent writes the code the loss gets worse, because it re-infers the intent from pixels every time it touches the file. Parlay keeps the intent as the source of truth: everything downstream is derived from it and can be regenerated from it.

The bet behind it is that the description can be a conversation: what the person asks for, what the product answers, and what happens when something goes wrong, written down before any screen exists. If that is enough to build from, the screens become something you derive, not something you hand over.

How it works

A feature moves through five phases. The first two belong to the designer and are written in plain language. The agent carries the rest, and stops for a confirmation at every boundary. Each phase produces a file a person can read and edit.

1 · Intents What the user is trying to do Goal, persona, priority, context, action, constraints and how to verify. Plain Markdown, designer-authored. Only the goal and the persona are required.
2 · Dialogs The conversation between person and product Each intent becomes the turns of a dialog: what the person says, what the product answers. The agent drafts them, asks about anything ambiguous, and points at what the intents forgot.
3 · Artifacts Four co-equal specs Surface, capabilities, infrastructure and domain model. The surface describes the interface in a closed vocabulary of Shows, Actions and Flows: what is shown, what the person can do, where it leads. It names no framework.
4 · Build A buildfile the agent reads instead of guessing A framework adapter maps the vocabulary onto real widgets. This is where the technical choices live, so the designer does not have to make them. Test cases and a coverage review come out of the same step.
5 · Code Generated, tested, regenerable Stable components are preserved verbatim on the next run; only what changed upstream is rebuilt.

The pieces

Closed interaction vocabulary. Shows, Actions and Flows are interaction design terms, not engineering ones: a list, a status, a text input, a confirmation. They describe an interface without naming a framework, so the same spec can target any of them: a command line, a web app or a native one. The target is a choice made at build time, not something the spec knows about.
Framework adapters. One adapter per target translates the vocabulary into widgets. It is the place for engineering knowledge: set up once, by whoever has it, and reused for every feature. An existing codebase can be onboarded by drafting an adapter that matches its conventions.
Application blueprint. Shells, routing, auth, data strategy and error handling are decided once per app, not re-argued per feature and not asked of the designer each time.
The loop. A single command walks a feature through all five phases and stops at each boundary for a confirmation, so the designer reviews decisions, not diffs.
Agent-neutral. Skills and subagents are deployed for Claude Code or Cursor, or as a single instructions file for anything else.

Takeaways

The bet held. Block Printing is a working app that I use, and every workspace in it began as a conversation between a person and the product, not as a screen. The layout came last.

This is less new than it sounds. Before interfaces were drawn they were described as dialogues, and the early work in human-computer interaction was about exactly that level: turns, actions, feedback, errors. Pixels arrived later and took most of the attention, mine included. Now that an agent can produce the pixels, the attention can go back to where the field started: the interaction itself, and what the person is trying to do.

It is also why the tool can feel familiar. Goals, personas, dialogues and flows are the first things a designer learns, and they turn out to be the right level to brief an agent at. The technical part still exists, but it is no longer the price of entry.

References

Parlay on GitHub. github.com/ddwht/parlay
Block Printing, the first application built with Parlay. block-printing