The real bottleneck to AI adoption on design teams is task decomposition.
We’ve been running a coding agent inside the design team for a stretch now, and the most useful thing we’ve learned has nothing to do with the tool’s ceiling. It’s about how you hand the work to it.
Give the agent an end-to-end task, “build this flow,” and you get something that’s roughly right and frustrating to fix. Give it a small, well-bounded skill, “write the function that does this one thing,” and the output is good enough to use. Same agent. The difference is entirely in how the work was cut.
This sounds like a prompting tip. It isn’t. It’s an organizational capability, and most teams don’t have it yet.
The instinct people bring to an AI agent is delegation: hand off the whole job the way you would to a person, then judge the result. Agents don’t reward that. They reward decomposition, breaking a job into parts small enough that each one has a clear definition of done. That’s a different skill than delegating, and it’s a different skill than designing. It sits closer to how an engineer thinks about breaking down a system, which is exactly why the designers who pick it up fastest tend to be the ones already comfortable with version control and how code is structured.
So when people ask why AI adoption on a design team is uneven, the answer usually isn’t access and it usually isn’t resistance. People have the tools and they want to use them. What’s missing is decomposition fluency: the ability to look at a chunk of work and see the seams, the natural places to break it into agent-sized pieces. That’s a teachable skill, but we haven’t been teaching it, because for years it wasn’t a design skill. It’s becoming one. The teams that name it and build it deliberately will pull ahead of the teams still waiting for the tools to get smart enough to take the whole task. The tools aren’t going to meet us there. We have to meet them.