Engineering can ship a working prototype before lunch. Claude Code, Cursor, and vibe-coded paths collapse the gap between idea and interface. That is not a threat to design leadership. It is a reassignment of where craft lives.
I lead as a design partner, not as a pixel factory. When code becomes the source of truth, my job is not to outdraw the AI. It is to decide what deserves to be built, what must not ship, and what “good” means after the demo looks finished.
The bottleneck moved
For years, design craft meant screens, systems, and handoff. Those still matter. They are no longer the scarce resource.
What is scarce now: problem framing that survives a fast prototype; specs that an AI-sped engineer can execute without guessing; evaluation criteria that catch pretty-but-wrong work; decision logs that explain why we chose A over B.
If your team measures design by Figma throughput, you will feel like a bottleneck. If you measure design by decisions that kept the product coherent, you become the operating system for speed.
Specs that survive Claude Code
A traditional spec assumed a human would carefully translate mocks into production. An AI-sped eng workflow assumes the model will fill gaps. Gaps get filled with confident nonsense.
I write specs for that world: outcome first; non-goals; constraints; happy path and failure path; acceptance checks that are observable, not aesthetic vibes.
The artifact can be short. It cannot be vague. Ambiguity used to create delay. Now it creates the wrong product at high velocity.
What an eval is (and what it looks like in design)
An eval is a reusable test of judgment. In ML, teams use evals to score model output against a known bar. In design leadership, an eval is the same idea applied to product work: a small, repeatable checklist that decides whether a flow, prototype, or AI-generated UI is good enough to ship, or must be rejected.
It is not a vibe. It is not "looks modern." It is a written bar you can run again next week on a different prototype and get a comparable answer.
A useful design eval has four parts:
- Scenario: who the user is and what they are trying to do.
- Artifact under test: the screen, flow, prototype, or AI output.
- Criteria: 3 to 7 observable pass/fail checks, not taste adjectives.
- Decision: ship, revise, or kill, with one sentence why.
- Optional fifth: a score (for example 0 to 2 per criterion) when you want to compare variants.
Concrete examples you can steal
Example A, onboarding for a B2B AI tool. Scenario: a first-time admin sets up the product in under 10 minutes without a sales engineer.
- Can the user state the product's job in one sentence from the first screen alone?
- Is there one clear primary action per step, not three equal CTAs?
- Does the empty or error state tell them what to do next in plain language?
- Would a new teammate complete setup without asking Slack?
Pass means every must-have is true. Fail means any must-have is false, so revise before engineering spends another sprint.
Example B, an AI chat or agent UI. Scenario: the user asks the agent to draft a customer reply, and they need to trust and edit it before sending.
- Is the model's draft visually distinct from the user's final send action?
- Can the user see sources, confidence, or what the agent assumed?
- Is there an obvious "edit before send" path that does not feel like a trap?
- Does a wrong answer have a recovery path that is shorter than starting over?
Pass means the user can reject or edit without shame. Fail means the demo looks magical but production would create risk.
Example C, a marketplace or fintech decision screen. Scenario: a member chooses between two loan offers.
- Are the three numbers that drive the decision visible without scrolling on mobile?
- Does the UI surface the tradeoff between APR, monthly payment, and fees without burying it?
- Can a staff designer explain the product logic from the UI alone?
- Would I defend this screen to the customer who pays for it?
Pass means the decision cost goes down. Fail means prettier UI that still forces guesswork.
How I run them
I keep a living eval doc per product surface. Before a design review, or after a vibe-coded prototype lands, we run the same criteria. The meeting is shorter because we are not inventing taste on the spot. We are scoring against a bar we already agreed.
Prompts are not the portfolio. Judgment is. Evals are how you make judgment reusable.
Decision logs beat process theater
When eng ships weekly, journey-map slideshows do not protect discovery. Decision logs do.
A decision log is a living record: context, options considered, choice, tradeoff accepted, owner, date to revisit.
This is the design partner’s craft artifact when prototypes appear in hours. It preserves discovery without blocking velocity. It also creates the proof leaders need when a CEO mandates AI: we are not resisting tools. We are raising the bar for what ships.
What I own as a design partner
Clarity of the problem before the sprint of generation.
Quality gates that keep vibe-coded demos from becoming debt.
Taste and judgment when code is already “done.”
Partnership language that helps Product and Eng move faster without abandoning strategy.
I do not own being the slowest step in a mandate. I own making speed safe.
A practical starting kit
Craft did not disappear. It moved upstream of the screenshot and downstream of the demo. Specs, evals, and decision logs are how design partners stay valuable when anyone can generate an interface.
- Write one design eval (scenario, 5 observable criteria, pass/fail) for your riskiest surface this week.
- Run it on the next prototype before you open Figma polish.
- Log every material product decision in a shared place the team actually opens.
How this got written
This came out of advisory work with founders and design leaders who keep asking the same question: when engineering can generate an interface in an afternoon, where does UX sit. I wrote the answer I keep giving as a design partner. I use AI heavily in product work and I’ll say so plainly. I don’t outsource the opinion, because the opinion is the only part that’s mine.
About the author
Ashwarya Subhluxmi has 12+ years of design experience in fintech, leading teams building AI products and marketplaces used by millions of people. She writes about design leadership, AI-native product design, and what changes for design orgs when agents join the team. ADPList Top 50 UX Coach, 2026. She advises early-stage founders and is based in the San Francisco Bay Area. uxbyash.com · LinkedIn: https://www.linkedin.com/in/ashwaryasubhluxmi