Six months ago, my job was starting in Figjam and ending 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, have back and forth with developers and collect their objections, then test the prototype with users and iterate. Write user stories, hand over hi-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.
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.
I’m turning this into a free course — how to close the loop yourself, from first sketch to production, using Claude Code. More on that in the next few weeks.
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.
The market dynamics problem
Karri Saarinen — the CEO of Linear — gave a talk at Figma’s Config that I’ve been thinking about since. His argument: technology makes it easier to build, but harder to care about the craft. We replaced purpose with metrics. We delegated judgment to A/B testing.
He’s right about the observation. I think he got the cause wrong.
Technology has always been deflationary. More with less. That’s what it does — the deflation is the feature, not the bug. The problem isn’t that better tools exist. The problem is what happens in a hyper-competitive market when the barrier to building drops toward zero.
VCs demand volume, scale, and speed. Companies race to ship before competitors do. AI makes the race faster. And in a fast race, the things that take time — judgment, iteration, care, refinement — get squeezed out first.
Most teams end up with functional interfaces. Competent output. Nothing you’d remember.
Quality becomes differentiation precisely because craft gets scarce when production gets cheap. Which makes the teams that hold onto it under pressure the interesting ones to study.
Karri’s own company is the clearest example I know.
The floor just moved
For most of design’s history, producing something that looked professional required years of tool mastery. That scarcity was the craft. Getting to competent was the barrier, and the barrier created the value.
The floor has moved. The number of people who can produce decent-looking design — not exceptional, not memorable, but good enough to ship — is nearly vertical now. An afternoon with v0, Cursor, or any current generation tool will get you there. What used to require months of Figma fluency is now a prompt away.
This changes what exceptional actually means.
The traditional T-shaped designer — deep in UI craft, broad in adjacent skills — is getting much broader. Not because anyone decided this was strategically wise. Because the work demands it. When I write a PRD, break it into GitHub issues, build the front end with Claude Code, run the branch locally for user testing, and orchestrate QA through agentic tests and CodeRabbit — I’m not doing a developer’s job. I’m doing a designer’s job in 2026, where owning the outcome means owning the full loop.
The “stay in your lane” instinct made sense when lanes were hard to cross. Switching required months of ramp-up, and discipline required constraint. But most of those crossings are cheaper now. You can operate in parts of the stack that were previously someone else’s territory — not because the work got easier, but because the tools handle the parts that required rote execution rather than judgment.
What you still can’t delegate is knowing what to do. An AI will generate a hundred dashboard variations. It won’t tell you that your users don’t actually want a dashboard — they want relevant data pushed to them before they know to ask. That’s not a prompt. That’s judgment built from time spent watching real people use real things under pressure.
That’s what taste protects. And it’s the only part of this job AI hasn’t touched.
What Linear actually did
Linear is the clearest example I know of a product that won on taste.
They defined quality through their customers’ own language: intentionality, seamlessness, speed, personal, and scale. Every one of those proxies came from listening closely to what their customers actually cared about — not from a design principles document.
Intentionality means you can feel that the people who built this thought carefully about your situation. Seamlessness means they understood your workflow well enough to get out of your way. Speed means they delivered on that understanding, fast.
None of those are aesthetic judgments. They’re empathy made into product decisions, baked into the product as craft and into the marketing as identity.
Linear didn’t win by being faster or cheaper. They won because they had a sharper point of view about what their customers actually needed — and they held that point of view under pressure.
The two wrong responses
I’ve watched the designer response to this moment split into two camps, and both are wrong.
The first doubles down on execution craft. Figma mastery. Pixel perfection. Component systems built to withstand nuclear winters. The logic: if AI makes execution cheaper, get so good at execution that you remain indispensable. This is a race you will lose. Not because mastery isn’t valuable, but because the tools will keep catching up. They always do.
The second delegates everything to AI. Prompt, accept, ship. No friction. The logic: execution is a commodity, so stop doing it. This camp mistakes speed for direction. You can move very fast in exactly the wrong direction — and when the middle compresses, you find out faster.
Neither camp is asking the question that actually matters: are we solving the right problem?
That’s not a taste question. It’s a restraint question. And restraint is the skill both camps are missing.
What taste actually is
I want to be careful here, because “taste” sounds like something you either have or don’t — a vague aesthetic sensibility, art-school intuition, the confidence to wear unusual clothes.
That’s not what I mean.
Paul Graham wrote about this over two decades ago: great work requires exacting taste plus the ability to gratify it. The ability to gratify it, execution, just got dramatically cheaper. What’s left is the exacting part.
Taste is judgment built from proximity. Pattern recognition developed over years of paying close attention to what works, in the real world, for real users, under real constraints. The ability to know which problems are worth solving and which solutions will hold up after the initial polish wears off. The capacity to see when a form isn’t serving its function — when you’re borrowing answers to questions your users aren’t actually asking.
One question changed everything about the Omny alert system redesign: What job is this operator actually trying to do in the next 30 seconds? We hadn’t written that down before we started building the first version. That question, asked and answered, was worth more than two months of polished execution in the wrong direction.
This is what Karri was pointing at when he said technology lets you distance yourself from understanding what the right solution is. The real risk isn’t that tools make you lazy. It’s that they let you skip the proximity that builds taste in the first place.
Trust the AI on how. Verify on what and why.
The real problem with faster horses
Let’s assume Ford actually said it. The issue isn’t that users asked for faster horses. It’s that “What do you want?” is a terrible research question.
Of course they said faster horses — that was the only frame of reference they had. But dig into the actual problem and you hear something completely different. Not “faster horse” but: long rides leave me sore, I can’t bring my whole family, the horse needs rest and costs money year-round. None of those answers mention a car. Every one of them points directly to what a car solves.
Good research doesn’t ask for solutions. It uncovers problems. And the same people who cite Ford to avoid user research are now using AI to build products faster than ever — which means they’re building the wrong things faster than ever.
Henry Ford couldn’t build a car in a weekend. You can ship a working product in hours. The barrier to building dropped to zero. The barrier to understanding what people actually need stayed exactly the same. Which makes that question — what are they actually struggling with? — the only one that still creates a real advantage.
Restraint is a taste decision
The skill that separates builders who ship great products from those drowning in features isn’t technical. AI can’t supply it.
It’s restraint — the discipline to say “we could build this, but it doesn’t belong here.”
Consider a focused client portal. Agencies love it. Then enterprise prospects start asking for invoicing, time tracking, project management. Each one is buildable in a weekend with AI. So you build invoicing. Support tickets shift from “how do I share a file” to “why isn’t my invoice syncing with QuickBooks.” You’ve absorbed a job that wasn’t yours to absorb.
The restraint move has three versions: build a clean integration instead of a native feature. Partner with an invoicing tool rather than becoming one. Or just say no — serve the need without absorbing it. Each requires more judgment than building the thing would have.
This applies internally too. My content operation has a lot of moving parts. One app for all of it sounds efficient. In practice it’s brittle and a nightmare to maintain. What works: purpose-built tools, each with one job, connected by agent skills. The restraint isn’t in choosing less capability — it’s in choosing the right surface area for each tool.
Plan mode in every major AI tool is a signal that spec-driven development is now standard. But jump straight into plan mode without the strategic thinking first, and you end up with a beautifully planned feature that shouldn’t exist. Before I open plan mode, I run a conversation that determines whether I should be planning this thing at all. That’s the step most builders skip — and it’s where restraint actually happens.
AI can pressure-test your thinking and surface trade-offs. But it can’t decide what your product should be. That strategic judgment is on us. And it’s the most valuable work we do now.
The bubble is expanding
For most of design’s recent history, taste was hidden behind execution. If you could use Figma well, deliver polished components, handle handoffs cleanly — that was enough. The role was bounded. You could fill it without ever being asked to have a real opinion.
The execution layer is compressing now. The role is expanding. Strategy isn’t someone else’s job anymore. So is knowing which problem is worth solving, and having conviction about what will resonate with the people you’re building for.
The gap is more visible now precisely because execution no longer fills it. If you’re not doing the judgment work, it shows in a way it simply didn’t when craft could cover for it.
The designers who are thriving in this environment aren’t the ones who adopted the fastest new tools. They’re the ones who were quietly doing the judgment work all along and are now valued for it more directly. The ones who struggle are working within the old, smaller boundaries — and the space around them makes that obvious.
The role isn’t shrinking
Every industry where production costs collapsed followed the same arc: a flood of competent-but-generic output, followed by a sharp premium on what production can’t generate.
When photography made portrait painting cheap, illustration found new territory. When digital audio made music production cheap, the things that couldn’t be replicated — live performance, authentic voice, the specific sonic signature of a room — became more valuable, not less.
The same law is at work now. When AI makes interface generation essentially free, it doesn’t eliminate the need for someone who knows which interface to generate and why. It makes that person the only person who matters.
The work that’s always mattered most is suddenly the only work that’s clearly not going anywhere.
The question is who’s actually doing it.
This is part of a series on the future of work with AI agents: How I Code → The Death of Front-End Engineering → Design Leadership Has Evolved → The Disappearing Middle of Software Work → About Craft, Taste, and Speed.
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.