Two design leaders shipped PRs with agents this week. What broke was the review: comments they couldn't read, reviewers nobody wanted to be, and the fixes we're trying.
One of my design leaders shipped an accessibility fix this week. He wrote the ticket, pointed a cloud coding agent at it, got a PR, walked it through QA, and it passed about an hour before our weekly 1:1. A day earlier one of my design directors showed me his first PR: a paper cut where a clinician selector used the browser’s default dropdown instead of our list component and had no search, so he swapped in the component and added a filter, with checks green and a tech lead review pending. Both of them called their changes small. I told both of them they were underselling it, because this is the thing we said in January would happen and it’s happening, and the quality of what came out was a lot better than “small.”
What I want to write about is the part after the PR opens, because that’s where the friction was, and it’s the part nobody designed.
He couldn’t read his own review. QA and the reviewing engineer left comments referencing code he didn’t understand. It was related to his change, but he had to go back and forth with QA just to learn what the comments meant. It resolved because the task was simple; a more complicated one would have stalled right there, with a designer holding a PR he can’t defend. The ask that came out of it, which our engineering partner had already been thinking about, is that the agent produces a plain-language summary of the diff for the person who asked for it. We don’t want designers to be developers. We do want designers to understand what a developer, or an agent, has done. Educate us; we’re not going to rewrite it, but we should know what it means.
Nobody wanted to be the reviewer. An engineer was uncomfortable being assignee on a designer’s PR, and the tech leads I’ve heard from would rather not be the default either. My position, written down for our leadership this month, is that everyone in product should have read access, a subset should have write access, and everything still gets reviewed exactly the way it’s reviewed today, by the tech lead or engineering manager of the squad that owns the code rather than whoever is free, and to the same bar as anyone’s code. What changes is volume: there’s more getting reviewed, so there’s more QA to fund, and that’s the real cost of the builder model rather than a reason to slow it down.
It doesn’t matter who did the thing. It matters who owns it, who reviews it, and who merges it to production.
He asked the agent to pick the reviewer. This was the move I hadn’t seen before. He had the agent look at our ticketing system, check which engineers were already on how many PRs and how heavy each one was, and recommend a reviewer. It’s untested as of this writing and I still think it’s brilliant, because it’s exactly where the director got stuck the day before, and his PR was rich enough with context that the agent could have answered the question if he’d thought to ask it.
He’s pacing himself on purpose. He wants to run a handful of these in parallel and open several PRs a week, and he’s holding back because he doesn’t want to overload review and QA before his own confidence is there. The initial part takes the agent a long time; the review is where the wait is. That’s the state of the art in our org this week: the constraint on designers shipping is no longer the designer.
There’s a workflow forming here that I think we should take seriously. After our weekly leadership review of where the gaps are, an agent goes to work over the weekend on the tickets and design updates from that week, and on Monday the design leads review the PRs it drafted, peer review them as humans, sync with the designer who’s going to finish each one, and get it done. No separate design board. We don’t want to ever differentiate designer versus PM versus engineer on a board; we’re all builders in that future. It doesn’t matter who did the thing. It matters who owns it, who reviews it, and who merges it to production.