Design wasn't the slow part. The gaps were.
The work that stalled my process was rarely the design itself. It was everything around it.
A ticket with no acceptance criteria. A flow I couldn't tell was feasible. A requirement buried on page nine of a PRD. A component nobody had documented. Each one sent me off to chase context, ping an engineer, or guess, and guessing is where rework comes from.
- Vague ticketsNo acceptance criteria, no definition of done.
- Feasibility unknownWas this a one-line change or a month? No idea until much later.
- Requirements missedThe one line in the PRD that changes everything, found too late.
- Undocumented componentsBuild new, or extend an old one? Nobody could say what would break.
I didn't want autopilot. I wanted a sharp teammate.
Tools that hand you the answer make you a lazier designer. I'd rubber-stamp whatever came out. So I flipped the brief: the agent does the legwork, but it makes sure I've set the direction first, then it delivers.
Built with Claude Code, each one turns a little context into a real outcome: a synthesis, a timeline, a gap list, a fixed component. A quick check up front, then the work.
An agent that does your thinking is just a faster way to be wrong.
The principle behind all fourFour agents. Each asks what I'd rather skip.
They're named, not numbered, because the team talks to them like colleagues. Each owns a corner of the process where I used to lose time.
Already knows our personas cold, that's what makes her fast. Synthesizes findings and drafts testing plans for our internal tools from almost no starting context.
What's the one task we're measuring, and what does “done” look like?
Our in-house engineer. Generates timelines, pressure-tests feasibility, and aligns a design with what's actually buildable.
Is this a one-line change or a month? What edge cases haven't you drawn?
Aligns the work against our PRDs and PR/FAQs, then tells you plainly what the design still misses.
The PRD asked for X. Where is it in this flow?
Reads our component repo and drills into Storybook: checks documentation, estimates the blast radius of changing versus building, solves accessibility violations, and gets the code ready for a clean MR.
This already exists. Extend it, or accept what breaks if you fork it?
The first versions were too eager.
My early builds over-explained, every answer came wrapped in caveats and clarifying questions. Useful, but exhausting. So I tuned them down: ask only what's needed, then deliver something I can act on.
The design work was the conversation.
What each agent asks, in what order, when to push and when to back off, that was the craft. And the translation underneath it: Leo speaks engineering, Atlas speaks PRD and stakeholder. After a few rounds I walk into those rooms already fluent in their language.
- Suggestions, never decisionsThe agent proposes; I decide. I can always override, and it expects me to.
- It cites its sourceEvery claim points back to the repo, the PRD, or the research, so I can check it.
- It flags, I judgeScout surfaces the blast radius and the a11y gaps; the call to fix or fork stays mine.
Faster starts, sharper questions, fewer loops.
The agents didn't take work off my plate so much as change the shape of it. I spend less time chasing context and more time deciding. And the briefs I write are better, because something makes me write them.
The agents don't solve the problem. They make you think.
The whole point