That’s James Touhey talking. He’s been a designer for more than twenty years, across agencies, his own shop, and in-house teams, and today he’s Head of Design at AnyTeam, an early-stage startup building a second brain for enterprise sales teams. He’s the kind of person who should have total control over how his product looks and feels.
He doesn’t. Or he didn’t.
“You’re at the mercy of your dev team,” he told us. “You’re needing to spend a lot of time explaining the original intention, working with the team to understand what our technical capabilities are, and potential limitations.”
If you lead design anywhere, you know this feeling. You can see exactly what’s wrong with the product. You can’t touch it.
Here’s James telling the story in 100 seconds. The full version is below.
The list that never reaches the top
Here’s what fixing visual bugs used to look like at AnyTeam. James would walk the entire application and take screenshots. Bring the screenshots into Figma. Redline them, annotate them, then run the annotations through a pipeline that turned them into GitHub tickets. In his words: “a whole system just to get QA tickets created for these visual bugs.”
And then the tickets sat. Spacing that’s slightly off, a missing empty state, a rough interaction. To engineering, these are low-level items, so they sink to the bottom of the backlog behind everything that’s “critical.” James put it plainly: “They’re not critical to engineering, so they always end up at the bottom. And for me, they’re the number one thing.”
That’s the quiet tragedy of most product teams. The craft items live at the bottom of someone else’s queue, permanently.
Prototypes weren’t the way out
AnyTeam is an AI-native company. They ship daily, they prototype in Claude Code, and a prototype is how they communicate. “No one wants to spend all day reading through PRDs,” James says. “A prototype is the fastest way to tell that story.”
But he’s clear-eyed about where that stops. “Claude Code has its limitations. It’s not shipping on your codebase. You may create something, but you’re gonna need to recreate it somewhere else, ultimately.”
A prototype tells the story. Someone still has to build the real thing, inside the real codebase, and that someone was never him.
What a task looks like now
With Fei Studio, James’s loop got dramatically shorter. “I can take a quick screenshot, I can go into Autonomy, I can easily locate the exact component that I’m wanting to change, and I can target that component. And then I can start making the intended changes just through prompts.”
When prompting isn’t the fastest path, he switches to design mode and adjusts colors, fonts, and spacing directly, with the kind of tools he’s used in Figma for years. The difference is what’s underneath: “I know that it’s going into the codebase. It’s a real component. Real code underneath. And from there, I’m able to ship a PR.”
Every PR arrives tagged, with a spec doc listing the files that changed and the checks that passed, so his engineers review real, scoped changes instead of decoding annotations. The redline-to-ticket pipeline is gone. The screenshot goes straight to a pull request.
And the setup he dreaded never materialized. He went in skeptical: “This is gonna be a lot to set up, it’s going to require a lot of our dev team.” The reality: “Maybe took a day or so. I’ve been kind of off to the races on my own.”
The 80% rule of getting designs approved
The sharpest thing James said in the whole conversation was about handoff itself.
“If you can build something and deliver it to an engineer, and it’s already built, then you’re already 80% of the way to having that design approved. Whereas if you’re showing them a design and they’re the ones that have to build it and integrate it, you’re much less likely to see it all the way through.”
That’s the whole shift in one observation. When a designer hands over intent, engineering has to rebuild it, and intent gets negotiated down. When a designer hands over a working change, the conversation starts at done. “This is one of those tools that gets you that 80, even 90%. And now I’m trying to get that to 100%.”
The result shows up exactly where the backlog used to swallow things. “The things that make the app special and fun and pleasant to use are often the things that get missed. That’s where Autonomy really steps in, to add that polish and bring those moments to life.”
The part engineers will ask about
Nothing merges without review. At AnyTeam, every change still passes a human reviewer plus an agent that checks the codebase’s token system and conventions. James’s role changed shape: “It really allows me to be a submitter and an approver at the same time.” Engineering keeps the merge. What they stopped doing is hand-building every spacing fix a designer could have shipped themselves.
Asked who this is for, James didn’t hedge: “I don’t think there’s any one team size that Autonomy wouldn’t be useful for.” He’s a design team of one today, but he’s led much bigger teams and wants it there too, and he sees PMs picking it up next.
His closing line is the one we’d frame: “Going back to life without Autonomy would probably be pretty tough right now. I’ve just seen what it can unlock.”
Your design team has its own list sitting at the bottom of engineering’s backlog. Book 20 minutes and we’ll show you how it starts shipping.
Marketing Lead
Discover what the future of product teams looks like!
