Six months ago, my job started in FigJam and ended in Figma. For the past three months, it ends in production.
The shift started over the 2025 holidays with a free hour and Claude Code. Getting back to the office in January, I knew my designs were going to be built and iterated directly in the code editor. There was no going back to testing Figma prototypes.
Until 2025, the process after aligning on direction always went like this:
Design the views in Figma, go back and forth with developers and collect their objections, then test the prototype with users and iterate. Write user stories, hand over high-fidelity mockups in Linear issues or via Slack, walk the developer through everything, wait for their PR. QA. Test again with real users and use their feedback to go back to Figma. Repeat.
Good process. Proven. But I was always one step removed from the thing actually shipping.
The new process is more direct.
The first iteration still starts in FigJam: somewhere to think, somewhere to sketch before anything becomes a file. After that, I write a PRD, break it into GitHub issues, and build with Claude Code. I create the PR myself, QA reviews it, and I run the branch locally during user testing.
When users give feedback, I iterate in the codebase. Once the PR is validated, I add CodeRabbit and at least one senior developer to review and ship. We’re running agentic tests too: they walk user flows, screenshot each step, and attach results directly to the PR. QA that runs itself.
I own the entire front end now. As a designer who ships, not as a developer.
The bigger change isn’t the process. It’s where the source of truth lives.
It used to be Figma. Every decision lived in the mockup. Developers worked from the file. Now it’s the codebase. I still start in Figma, but after the first pass I don’t go back. The product is the code, and iteration happens there.
Figma didn’t disappear. It just lost its place in the middle.
Speed reveals a lot about you
When building something real took months of engineering time and careful handoffs, you could stay vague about direction longer. Bad taste got absorbed by friction. Slow feedback loops hid weak calls. A product pointing slightly the wrong way had time to self-correct.
The old bottleneck was execution. We couldn’t build fast enough, so scarcity forced us to prioritize. That constraint is gone.
When agents collapse that friction and the middle gets thin, vague direction fails faster. Speed doesn’t forgive bad taste. It amplifies it.
But there’s a subtler problem underneath. Without the execution bottleneck, builders ship everything they can instead of everything they should. The queue empties so fast that the question of what should be in it gets skipped. You’re not slow-moving in the wrong direction anymore. You’re fast-moving in every direction at once.
That’s the part nobody in the “move fast” conversation wants to sit with.
Also in May: The Floor Just Moved · What Linear Did with Taste · Restraint Is a Taste Decision
Daniel Arevalo is Product Experience Lead at Omny Security. He builds AI-native tools and writes about design, product leadership, and what it means to direct systems that execute at a speed humans never had before.