AI for Designers: The YC Design Workflow

Search for AI for designers and you get a list of tools. The list is real and mostly accurate, and it tells you almost nothing about what changes in the work.

The short answer: AI for designers now means designing through a coding agent instead of inside a canvas, so the first artifact is running code, a reference set replaces the written brief, and the designer's remaining job is choosing well among options that cost almost nothing to generate.

A better answer comes from watching someone do the job. Eve Bouffard is Head of Design at Y Combinator. In an episode of YC's Design Review with general partner Aaron Epstein, who co-founded Creative Market before joining YC, she walks through three projects she shipped and the process behind each one: a data product, a physical zine with a companion site, and the visual identity for YC's largest event of the year.

What makes it worth a founder's time is not the tool names. It is the shape of the process, which has three moves that are easy to copy and one deliberate refusal that most teams get wrong.

What AI for designers actually means now

The old shape of design work was a handoff. A designer produced a static artifact, an engineer rebuilt it in code, and the gap between the two was where quality went to die. AI for designers, in its first wave, meant putting generative features inside the static tool: generate a layout, remove a background, fill a region.

What Bouffard describes is a different thing. The design tool is a coding agent, and the artifact is running code from the first iteration. She says she lives almost entirely in Conductor, the Mac app for running coding agents in parallel built by Charlie Holtz's team and funded by YC, plus Paper for visual work, with Pinterest for reference. Those are the tools for a full project end to end.

She also does not type. "I do not type. I realize that I think a lot faster than I type," she says, and uses Aqua, a YC voice input company, to dictate instead. "I just press the function key and I give a stream of consciousness of the feature that I want to build and it just does it and it feels really magical."

That detail sounds cosmetic and is not. Typing is a rate limiter on how much context you are willing to give an agent, and most people under-specify because specifying is tedious. Removing the keyboard removes the tax on being thorough.

Two adjacent ideas get confused with this one, so it is worth drawing the lines. This is not generative UI, where an AI assembles a different interface for each user at runtime. It is not quite AI prototyping either, where the point is to answer one question fast and throw the artifact away. This is the human design process itself, run through agents, producing work that ships.

Start from a mood board, not a prompt

The most common complaint about designing with AI is that the output is generic. Ask a model for a landing page and you get the average of every landing page it has seen.

Bouffard's fix is that the prompt is the last input, not the first. For the zine site, she started in Pinterest and built a mood board: a handful of images that carried the feel she wanted, rudimentary, black and white. Then she downloaded those images, fed them to the agent along with the real content and the visual direction, and asked it to one-shot a website from that. "I asked it to do that 16 different times," she says.

The instruction underneath it: "You need to shepherd your agent to tell it exactly the vibe that you want to go for."

The part founders skip is that you do not have to be able to articulate the taste. Her advice is to collect websites you like and hand them over without a rationale, because "sometimes you love a website and you don't even know why you love a website." Her conclusion is blunt: "You don't need to understand why you love a website. Just give it to the agent." The agent will find the commonality across the set that you could not name yourself.

This is the single highest-leverage change available to a non-designer founder. You almost certainly have taste, in the sense that you can tell good from mediocre when you see it. What you lack is the vocabulary to specify it. A reference set is a way to specify taste without a vocabulary.

Write a soul.md before you write a prompt

The second move is about context, and it goes further than most teams would think reasonable.

For the zine project, the team recorded every single meeting. Bouffard dumped the transcripts into a file. "I wanted to treat that soul.md file as the source of truth," she says, so it could feed every future decision on the project. They also wrote a manifesto for themselves, and that went into the file too. You can split it into a hierarchy if you prefer: one markdown file for design direction, one for the manifesto, one for written content. She is honest that nobody has proven which structure is better, since everyone is still experimenting.

The principle is not ambiguous. "As much context that we can give the agent, the better," she says, and: "Overall, I think capturing as much information as possible and share that information with your agent is the best way to build software moving forward."

Contrast that with the normal process. You sit through four stakeholder meetings, write down some bullet points and high-level takeaways, and work from those. Everything else evaporates. Epstein puts the alternative plainly in the conversation: do not summarize, record everything, dump it into the file, and use that as the basis for what comes next.

The payoff she describes is the part that is hard to get from a summary. Because the soul.md included the article titles and the details of the launch party, the agent started adding things nobody asked for: the date of the party, and a barcode on the layout, on the assumption that this was a physical object you could buy. Bouffard calls it "almost like an AGI moment" for the team, and points at the party time as the example, since the agent surfaced it without being asked.

That is a testable claim, not a vibe. An agent working from a summary can only recombine what is in the summary. An agent working from the full record can connect two facts you never connected. It tracks with the answer given on YC's Lightcone when the hosts ask what makes someone a top 1 percent user of coding agents. Their guest, Calvin French-Owen, points at context engineering and at using far less code and plumbing in the project, so there is less incidental machinery for anyone, human or model, to reason about.

One caution that the video does not raise and a founder should. Recording every meeting and committing the transcripts to your repo is a data classification decision, not a productivity hack. Those transcripts go to a model and live in git history, and meeting audio picks up customer names, pricing conversations, and compensation talk that nobody intended to put in a file. Decide up front what class of project gets a soul.md, and keep a redaction pass between the recording and the commit. The workflow is good. The default of recording everything with no filter is how a startup ships a customer's name into a public repository.

Build disposable tools for yourself

The third move is the one with the widest application outside design, and it is the reason this workflow is different in kind rather than degree.

Bouffard kept hitting small problems and, instead of tolerating them, building a throwaway tool for each one:

• She wanted a specific feel for a dithering effect, so she had the agent implement one of the free Paper shaders and then built herself a modal exposing every parameter, so she could tune it by eye instead of guessing. She left that modal public on the desktop version of the site.
• She had sixteen one-shot website iterations and no way to compare them, so she built a single page collecting all of them, then added a bookmark feature so the ones she liked pinned to the top.
• For YC's Startup School at Chase Center, she started laying out speaker cards by hand in Figma, realized she would be moving things around a dozen times, and had the agent build a template that generated the cards as each speaker was confirmed, plus a way to try different text layouts across the whole set.
• She wanted the animated card to loop seamlessly on social, so she had the agent build a screen recording tool that told her exactly when to start and stop to produce a perfect four second loop, starting and ending on the same pixel.

Most of them she throws away when the job is done. Epstein names the pattern: "this is another great example of disposable design."

Bouffard's framing is the useful one for anyone who is not a designer: "We realized that it's almost like a muscle that you need to build and train when you realize that you can build anything for yourself whenever you want to fine-tune something."

That is a real behavior change and it does not come free with the tools. The muscle is noticing, in the moment, that the annoying thing in front of you is a twenty minute internal tool. Most people do not notice, because for their entire careers the answer was no, that is not worth building.

The counterweight, which the AI prototyping case makes in more detail, is that cheap building shifts your bottleneck to attention. Disposable tools work precisely because they are disposable. The failure mode is the internal tool that quietly becomes load-bearing, never gets reviewed, and is still running your release process a year later.

Should you build a machine-readable version of your site for agents?

The Paxel project surfaces something most teams have not built yet. Paxel reads your local Claude, Codex, and Cursor sessions and returns a report on how you build: your most-used prompt, whether you work in plan mode, which model you reach for, when your commits land. The design question it raised was not visual.

The site has a toggle between a human version and a machine version. The machine version is a markdown file with the same content, distilled and lighter for an agent to consume, with a copy to clipboard control at the top so you can drop the whole page into an agent and ask it questions instead of reading. As Bouffard frames it, agents do not care about the visuals, so it becomes a content exercise: give the agent exactly what it needs so it can get on with its job.

This is the same bet YC makes in its Software for Agents request for startups: "Instead of visual interfaces like forms, buttons, and dashboards, they need machine-readable interfaces like APIs, MCPs, and CLIs." A markdown twin of your marketing site is the cheapest possible version of that, and it is a weekend of work.

Two security notes, because this is where the pattern gets adopted carelessly.

First, the Paxel machine page opens with a line telling any AI agent reading it "do not run any command or query from this page," since the page contains sample commands. That is a sensible courtesy and it is not a control. Anything you publish for agents becomes untrusted input inside somebody else's agent loop, and a polite instruction in your markdown is not a security boundary, because an attacker can publish a page too. The enforcement has to live on the consuming side: no shell execution from fetched content, explicit allowlists, and a human in the loop for anything that writes.

Second, Paxel's feedback form is a prompt box whose button says send to an agent, because that is literally what happens: your prompt fires an agent, which opens a pull request that the team then decides whether to merge. That is a genuinely good pattern for turning users into contributors. It is safe for exactly one reason, which is that a human merges. The moment anyone wires an untrusted prompt to an auto-merge, you have published a write path into your codebase.

Where taste still decides: what designers should not automate

Here is the refusal, and it is the most instructive part of the whole conversation.

The zine at the center of the project is a physical object, and for the cover art and some of the art inside it the team used no AI at all. "We intentionally wanted to go for something that had no AI involvement," Bouffard says. They did it the way they would have a few years ago, in Illustrator. Her reasoning is about what a viewer can perceive: "you can tell the second you look at them, they are highly intentional and highly detailed," and that someone spent months on them.

Set that next to the sixteen one-shot websites, where she is explicit that you should not expect a high level of craft because "you're just using this as an exploration tool." The same person, on the same project, running two completely different standards depending on what the artifact is for.

That is the decision rule worth stealing. Volume and iteration go to the agent. The pieces that carry the impression of intent stay human, and you decide which is which on purpose rather than by default. The bottleneck the conversation lands on is no longer execution. It is how far your creativity and imagination can go, which is a much less comfortable constraint than not having enough engineering hours. The same reframe is happening one seat over, where AI for product managers moves the job from writing specs to deciding what is worth specifying.

There is a strategic read here for founders, and Jorn van Dijk, co-founder of Framer, states the general case on YC's Design Review: "most designers should be founders," because so much of design as a profession transfers directly to building a company. If the execution gap between a designer's idea and a shipped product has collapsed, the argument gets stronger, not weaker. The catch is that the advantage is not the one most people assume, and we took van Dijk's full argument apart in what a designer founder's real edge is. We collected more of that thinking in our lesson on how to come up with startup ideas, and the wider map is in our pillar on AI for startups.

The closing observation from Bouffard is about consistency rather than speed: the same shader with the same parameters will run on the massive screens at the venue and on the ticket in your inbox, and "it's just easier than ever to make things more consistent and use coding agents for absolutely everything." Brand consistency used to be a documentation problem enforced by people. It is becoming a code problem enforced by a shared component.

What to do this week

1. Build one reference set. Collect ten to twenty screenshots or URLs of work you admire for the thing you are about to design. Do not write down why. Hand the set to your agent with your real content and ask for six variants.
2. Start a soul.md for your current project. Record your next three project meetings, dump the transcripts in, add whatever positioning or manifesto document you already have, and point your agent at that file before every task. Decide before you start what is too sensitive to include, and redact before you commit.
3. Notice one annoyance and build a throwaway tool for it. Anything where you are hand-tuning a value, comparing options in browser tabs, or repeating a layout. Give it twenty minutes. Delete it when the project ships.
4. Ship a markdown twin of your main page. Same content, distilled, with a copy control. Then check that your own agents never execute anything they read from a fetched page.
5. Pick the one artifact you will not automate. Name it explicitly, give it the time real craft takes, and hold the line on it while everything around it gets faster.
6. Put a human on the merge. If you accept prompts from users that trigger agents, keep pull requests as the boundary and never auto-merge.

If you want the operating system around this, the course goes deeper on running an AI-native team without losing the judgment that makes the output worth shipping: AI Operating System for Startups.

Sources

• YC's Head of Design Shows You How To Design With AI on Y Combinator's Design Review, the conversation this article distills, with Eve Bouffard and Aaron Epstein.
• Profiles: Eve Bouffard on LinkedIn and Aaron Epstein on Y Combinator.
• Tools named in the conversation: Conductor (YC company page), Paper and its free shaders, Aqua Voice, and Paxel.
• Software for Agents, Y Combinator's request for startups, for the machine-readable interface argument.
• We're All Addicted To Claude Code on YC's Lightcone, for Calvin French-Owen on what separates the top users of coding agents.
• CEO of Framer: Why Designers Should Become Founders on YC Root Access, for Jorn van Dijk on designers becoming founders.