Two design leaders who took their craft into the codebase this month, why fixing the component beats fixing the screen, and where agent-assisted fixes ran out of road.
One of my design directors called out something in our weekly 1:1 that struck a chord. We were talking about designers contributing code, and I assumed he meant designers patching product screens: a misaligned row here, a wrong shadow there. He corrected me. His proposal is for designers to polish the design system components directly. Fix the border on the component, and the fix lands on every screen that uses it. It also avoids the awkward question of who owns designer-written code in a product repo, because the component already has an engineering owner. “More birds with one stone,” he said. I restated it wrong the first time, he restated it right, and I told him I love it.
He also pointed out that CSS is a craft most product engineers were never trained in, and I think that explains a familiar conversation. A designer flags something, and a product engineer says it’s just a pixel off, don’t worry about it. Say the same thing to a design system engineer and you’ll hear, “No, that’s everything.” Once designers are in the code with them, the debate changes. You’re not debating pixels being off anymore. You’re debating code being off.
You’re not debating pixels being off anymore. You’re debating code being off.
Another of my design leaders showed me what this looks like in practice. He’s been working through a common accessibility failure, where color is the only signal that a piece of text is a link. His audit was simple and convincing: screenshots of each page with the color removed, so you can watch the links disappear. Then, to explore the fix, he skipped the design files entirely. Updating every file would have taken days. He changed 1 or 2 CSS files, pushed to a review server, and every affected page updated at once, with before and after screenshots to show for it. He called it “almost like a repo prototype”: not the final fix, and plenty to learn from.
He had his AI coding agent draft the PRD too, following the design system team’s own process, including a rule that no implementation PR opens until design signs off. My reaction in the moment isn’t printable, but it was enthusiastic. The one thing I added was a guardrail, a mini version of the review process with design system reviewers tagged on the ticket, so the people who own the system can see what the agents are doing in it.
It’s worth calling out where this ran out of road, because the limits are useful. The small, well-defined fixes went through: labels on form fields, decorative images hidden from screen readers. The fixes that got shelved were the stateful ones, like tabs, a typeahead, and validation messages that need to be announced. Each of those reached deep enough into the design system that an agent and a designer couldn’t responsibly finish them alone. For now, that’s where I’d draw the map: agents are good at the long list of small things, and the patterns with behavior still need the system’s owners in the room.
There’s a people lesson in here that he almost left out of the talk he’s preparing. His fastest progress came through engineers he already knew well. They reviewed quickly because they trusted him. I told him that’s the story, more than the tooling. The best way to earn your stripes splashing in another swim lane is to work closely with the folks who swim there. (The review queue is its own challenge, and I wrote about it in Issue 23.)
When teams ask me whether we need more designers to keep up, my answer lately is that I’d rather have more design input on the code: more designers fixing things directly, so engineers aren’t buried in a polish backlog. Design doesn’t have to be behind engineering or ahead of it. More and more, we’re working in the same file.