Building a design engineering workflow

I’m building a workflow with agents for design engineering, inspired by Lauren Tan’s work on pstack.

I don’t have her depth of engineering experience. Part of the process is figuring out which principles I understand well enough to adapt, and where I still need to learn. Her emphasis on giving agents a way to verify their work feels especially relevant. I want to be able to inspect what happened and understand why a task is considered done.¹

Her post about treating a codebase like a garden also stuck with me: when you fix something, turn that correction into a rule so the same problem doesn’t keep growing back.²

I’ve been thinking about what that means for interface work.

Emil Kowalski’s “Agents with Taste” gives a concrete example. He packages design knowledge into specialized skills, explaining the reasoning behind decisions and giving agents specific rules to follow. A popover’s animation origin, for instance, should connect it to the control that opened it. That’s a much more useful instruction than asking for a “polished animation.”³

That’s the direction I’m exploring: agents with focused responsibilities, supported by skills for things like motion, typography, and verification. I want the instructions to explain what matters, why it matters, and how to check the result.

I’m trying to be strict about what counts as finished. For an interaction, I want the agent to exercise it in the browser and provide evidence I can review. A screenshot can show alignment; I still need to see the movement to judge its timing.

The difficult part is deciding which judgments I can make explicit. I can notice that something feels off before I can explain why. Writing instructions for an agent means spending longer with that gap.

That’s a part of this process I want to keep working on: getting precise enough about my own design decisions that I can explain them, test them, and reconsider them.