Polly D'Arcy, VP of Design at Wealthsimple, on what happens to a design team when anyone can ship, managing “design drift”, and how to teach agents (and humans) good judgement
taste.md is the idea that survives the interview. scaling one designer's taste doesn't work, but writing the judgment down in a file both humans and agents can read is the closest thing to a real answer. design drift at 3x shipping speed is just what happens when everyone tweaks components and nobody owns the whole.
the conviction-to-fidelity rule is the quieter one i like more. most prototypes are built at whatever fidelity was fastest, which means every idea looks equally finished and the feedback lands on the wrong layer.
question for the builders reading: does taste.md live next to the component code, or is it documentation that rots? the location decides whether agents actually read it.
The Compass detail is easy to skim past: if three people can unknowingly work the same PR through an agent, the team pays for the same fix three times and then pays again to reconcile the versions. Agent work needs the same visible claim on a task that a person creates by taking a ticket, otherwise the speed gain leaks out as duplicate effort.
100%. This is one of the most salient points I really liked from Polly. It's such an issue for the industry right now - the non-collaborative nature of AI. Part of it is us needing to adapt our ways of working, but the technology needs to do a beter job of enabling collaboration for sure. We run into this all the time at our workplace too.
The fix that works before the tooling catches up is sequencing: the agent's first action on any task should create the visible claim, a draft PR or ticket in the shared queue, before it starts the work itself. Notifications after the fact only tell you a collision happened, while a claim up front is what stops two sessions from starting the same job.
taste.md is the idea that survives the interview. scaling one designer's taste doesn't work, but writing the judgment down in a file both humans and agents can read is the closest thing to a real answer. design drift at 3x shipping speed is just what happens when everyone tweaks components and nobody owns the whole.
the conviction-to-fidelity rule is the quieter one i like more. most prototypes are built at whatever fidelity was fastest, which means every idea looks equally finished and the feedback lands on the wrong layer.
question for the builders reading: does taste.md live next to the component code, or is it documentation that rots? the location decides whether agents actually read it.
The Compass detail is easy to skim past: if three people can unknowingly work the same PR through an agent, the team pays for the same fix three times and then pays again to reconcile the versions. Agent work needs the same visible claim on a task that a person creates by taking a ticket, otherwise the speed gain leaks out as duplicate effort.
100%. This is one of the most salient points I really liked from Polly. It's such an issue for the industry right now - the non-collaborative nature of AI. Part of it is us needing to adapt our ways of working, but the technology needs to do a beter job of enabling collaboration for sure. We run into this all the time at our workplace too.
The fix that works before the tooling catches up is sequencing: the agent's first action on any task should create the visible claim, a draft PR or ticket in the shared queue, before it starts the work itself. Notifications after the fact only tell you a collision happened, while a claim up front is what stops two sessions from starting the same job.
putting taste in a file for agents is a neat idea, does it also help new designers onboard faster?