The question and what sits behind it
Surface form: "Can you use Cursor, Claude Code, or similar tools to go from design concept to working prototype?"
What the evaluator actually wants to know: Whether you can make design judgment runnable without waiting for engineering. Whether your process survives implementation constraints. At AI-native targets like Linear, Vercel, and Midjourney, whether you have enough fluency with these tools to make design decisions inside an implementation surface that changes week to week. They are not asking if you write production code. They want to see you can build something functional enough to test, demonstrate, and learn from.
Classification: evidence gap
This is an evidence gap. The missing proof requires building and publishing something. No verbal reframe repairs it.
A perception gap means the proof exists but the evaluator misreads it — you fix that with framing. Here, the proof is incomplete. Framing alone cannot close it.
What exists: three functional applications live at Brand Pulse, Retail Velocity, and Carrier IQ. I checked all three on September 19. Brand Pulse emitted live server-sent events showing agent connection, search queries, and structured results. Retail Velocity ran a discovery pipeline and returned restaurant leads with ordering URLs, POS vendor labels, and source snippets. Carrier IQ exposed a stateful workflow with structured intake, quote polling, review states, trace viewing, and an approval action. These are working software, not mockups.
What does not exist: any public record of how they were built — no repository, commit history, inspectable prompt configuration, or record of rejected approaches and versioned corrections. An evaluator who uses the apps can verify that something functional was produced. They cannot verify the build process, and the build process is what this objection is actually about.
Grain of truth: The apps prove you can ship functional software. They do not show how, what you decided along the way, or what you learned when something broke. An evaluator screening for code-assisted prototyping ability is screening for process at least as much as outcome.
Two provenance constraints to name. Retail Velocity visibly attributes its infrastructure to TinyFish Search, TinyFish Fetch, and TinyFish Agents on its own interface. That disclosed dependency sets a boundary on authorship claims — you can claim the application layer, not the underlying agent infrastructure. Carrier IQ does not display third-party attribution the way Retail Velocity does, but its overlap with TinyFish's public insurance workflow remains unresolved in the provenance record. Strongest ground for interaction and workflow complexity, not for blanket authorship. I covered the broader provenance problem in Issue #9; these boundaries have not changed.
Classification confidence: high.
Who screens for this and how
Three companies on your target list screen for code-assisted prototyping directly. Several others screen for adjacent constructs that look similar but test different things. The difference determines where this gap is a real liability.
Direct screens — act on these
Linear (Senior/Staff Product Designer) requires prototyping beyond Figma with "tools like AI, HTML/CSS, Origami." Linear is the only target that publicly describes its assessment method: team interviews walking through past product work and tradeoffs, followed by a paid two-to-five-day work trial on a real project. Senior trials normally use the full five days. Linear has said explicitly that interviews over-reward polished talkers, which is why they use the trial format. Your live apps give you material for the interview rounds. The work trial is where the evidence gap matters most — they will watch you build.
Vercel (Senior Product Designer, Growth) names the tools: v0, Cursor, Claude Code. Requires working prototypes built independently. The application includes portfolio, GitHub, and website fields. No public live-build exercise was located, but the portfolio must show what was measured, tested, and improved. The GitHub field is a signal. They want to see a repo.
Midjourney (Senior Product Designer and Design Lead) says candidates should prototype constantly in Figma and code, with Claude and Cursor in the workflow. The compact rule in the posting: "Prototypes > presentations." Portfolio required; no separate build exercise described publicly.
Code-prototyping language at IC level, not at the Director seat
Ramp (Product Designer) describes an AI-first workflow from LLM into Claude and Cursor, then into Figma. But Ramp's Director, Product Design posting asks the director to define design work in an AI-native environment without explicitly requiring personal tool use. This signals organizational direction — the team will expect it even if the posting does not demand it of the director.
Figma (Product Designer, CMS) says code should be part of the design process and that the designer builds working prototypes. AI-assisted software shipping is listed as a plus. The broader Design, Dev, & AI Tools posting puts "a designer who can code" under added advantages.
Different constructs wearing similar labels
Anthropic (Product Designer, Evals & Prompts) asks for experience building LLM evaluation pipelines, graders, and regression suites. That is evaluation-infrastructure ownership. Different construct.
Mercury (Senior Design Manager) emphasizes a point of view on AI-native interfaces and experimentation. Code-assisted tools are not named.
OpenAI (Product Designer, Codex) asks for recent production-code shipping. Materially stronger requirement than code-assisted prototyping. Covered separately in Issue #11.
Linear, Vercel, and Midjourney screen for this directly. The evidence gap is a real liability at all three until closed. Ramp and Figma signal the direction. Anthropic, Mercury, and OpenAI are testing different things.
Verbal bridge — use now
"I use Claude Code to turn design concepts into working applications. Brand Pulse, Retail Velocity, and Carrier IQ are live — you can use them. They show the functional result. What they don't show publicly is the build record: the repository, the iteration history, the rejected approaches. I can walk you through the build decisions and the code-assisted workflow in detail."
Confidence: moderate. The apps are real and inspectable, which gives this statement a foundation most candidates lack. Moderate rather than high because the authorship and dependency boundaries are not fully documented in public. Retail Velocity attributes its infrastructure on the interface itself — name that boundary before they find it. Carrier IQ has the most complex interaction surface and no visible third-party attribution, but its overlap with TinyFish's public insurance workflow is unresolved. If pressed on authorship for either, own the application-layer decisions without claiming the full stack until provenance is documented.
Build Queue item that closes this
This was already consolidated in Portfolio Playbook Issue #11 as the single priority build. Publishing it with process evidence closes the code-assisted prototyping gap without requiring a new concept.
Build: Delegation Contract — Inspectable Build Record
Four parts:
A deployed working prototype on a Juno-owned URL. At least one consequential flow from delegation through review, intervention, and a changed later run. The evaluator should be able to use it.
A public GitHub repository linked from the prototype and case page. Chronological commits or tagged versions, setup instructions, named dependencies, and a README that separates AI-generated implementation from your product, interaction, orchestration, and quality decisions.
A build record inside the repository or linked case page. The original brief. Selected prompt excerpts. Rejected approaches. A failed output with evidence. Diagnosis. The versioned change. Predefined evaluation conditions. The next-run result. What remained untested. This is the correction-record specification from Issue #8, built into a real artifact.
A proof-entitlement statement. Says this demonstrates code-assisted prototyping and development-process judgment. Does not claim production-engineering experience, ownership of underlying model infrastructure, or production-code quality at organizational scale.
Why this format: the evaluator evidence points line up. Vercel's postings ask for working prototypes with visible decisions and outcomes. Figma's CMS posting says a working prototype should expose interaction ideas and technical possibilities. Joel Lewenstein at Anthropic has described a coded prototype as harder to bluff because it exposes details. Linear tests through real work trials. The pattern across these sources is consistent: a working object plus inspectable decisions.
The build process also prepares you for Linear's work trial in a way the finished artifact alone does not. A five-day trial evaluates ownership, self-direction, responsiveness to feedback, and course correction — qualities that show up in how you work, not in a polished deliverable. Building the Delegation Contract with a real commit history and documented decision points is practice for that format.
Sequencing: The verbal bridge can carry initial conversations at Vercel and Midjourney, where the screen is a portfolio review. Linear's work trial is where the gap is most exposed. The Delegation Contract should be underway before you accept a trial invitation — not necessarily shipped, but far enough along that you've internalized the workflow you'll need to demonstrate.
Confidence: high for closing the public process-visibility gap. Use with caution for any production-code claim — this artifact would not satisfy OpenAI's Codex requirement or any role that asks for recent production-engineering history.
Quick-reference card
"Can you build functional prototypes with AI coding tools?"
"I use Claude Code to turn design concepts into working applications. Three are live now. They demonstrate functional prototyping; the missing public proof is the build record behind them. I can walk you through the decisions and workflow."
If they press on specific tools: Name Claude Code directly. Name Cursor or v0 only if you've actually used them. They are checking for practiced fluency, not a tools inventory.
If they press on authorship: Be precise per app. Carrier IQ — strongest ground for workflow complexity, most stateful, no visible third-party attribution on the interface, but the TinyFish insurance-workflow overlap is unresolved. Own the application-layer decisions, not the full stack. Retail Velocity — name the TinyFish infrastructure dependency before they notice it on the interface. Naming what you didn't own reads as operational maturity at this level.
If they ask for a repo: "The build record isn't public yet. I can walk you through the architecture and decisions now, and I'm building an inspectable version with a public repository." Say this only if the Delegation Contract build is underway or imminent. Do not promise what does not yet exist on a timeline you cannot keep.
- Linear's paid work trials: Linear publicly explains why interviews over-reward polished talkers and how their two-to-five-day paid trials evaluate ownership, course correction, and self-direction on real projects.
- Anthropic designers building with code: Nate Parrott describes how Anthropic's product design team feeds Figma files into autonomous coding loops, then uses the codebase to map error states and system logic before development begins.
- What hiring managers say they inspect: The 2026 State of AI Design report captures named evaluators including Anthropic's Joel Lewenstein and Superhuman's Phil Vander Broek describing how they now screen for AI fluency in design candidates.
- Ramp's split between IC and Director expectations: Ramp's Product Designer posting requires Claude Code and Cursor fluency, while its Director posting asks the leader to define AI-native design practice without naming personal tool use as a requirement.