Classification: Hybrid
Part perception gap, part evidence gap.
The perception gap: Most roles Juno is targeting do not require production engineering history. Current Staff+ design postings at Headway, Render, Mariana Minerals, and Checkout.com all separate prototyping or code fluency from production engineering. None requires an engineering background or CS degree. The evaluator asking "can you code?" usually means something else. Reframe.
The evidence gap: Juno built three live AI systems through Agentic Labs — solo on the application layer, using the agent infrastructure (Search, Fetch, Agents) from TinyFish, where she was most recently Head of Product. The Labs are her own builds on that infrastructure: product logic, interfaces, orchestration, review architecture. The systems are real — Retail Velocity was independently observed streaming live restaurant discovery, extraction, and scoring results on August 29. But her linked GitHub account has zero public repositories and zero commits. An evaluator who wants to inspect how she builds has nothing to look at. The capability is demonstrated; the process isn't. Build to close it.
Diagnostic: Which Question Are You Hearing?
"Can you code?" is three different questions. Answering the wrong one wastes the response.
Startup CTO or technical co-founder. They are asking: Will hiring you create a dependency where every design idea has to be translated into engineering work before anyone can evaluate it? This is a staffing concern on a team of five to eight. They need someone who ships without filing a ticket. Route to Branch 1: Maker Capability.
Design VP or Head of Product. They are asking: Will you make sound decisions near code, or will I spend my time mediating between you and engineering? They have engineers. They need a design leader whose decisions survive implementation. Route to Branch 2: Technical Fluency.
Recruiter running a screen. They are checking a box. Give them the Agentic Labs headline, name one system, say Claude Code, move on. If they probe further, listen for whether the follow-ups sound like the CTO version or the VP version.
The conversation shifts to specific languages, frameworks, testing practices, pull-request review workflows, or deployment pipelines. They mention a technical screen or pair-programming exercise. This is a different role category. Acknowledge the boundary — don't sell past it.
This is the Ashby Design Engineer profile — TypeScript, React, CSS proficiency, shipped code to hundreds of users, technical screen required. That is an engineering admission ticket. You do not have it. Say so cleanly. Ask whether the role requires that background or whether the posting describes a preference the team might flex on. Sometimes they won't flex. That saves you time.
The structural distinction: Most Staff+ design roles posting right now need design judgment made runnable — prototyping, technical specification, working in code-adjacent tools. The Labs demonstrate exactly that capability with current tools. Roles that genuinely require engineering employment history are a different category, and recognizing the boundary quickly saves time on both sides.
Branch 1: Maker Capability
Surface-form question: "Have you actually built things, or do you hand off specs?"
What they're worried about: You will create work for other people instead of reducing it.
The grain of truth: You are not a production engineer. You have never held an engineering title. If the role requires someone who can own a production codebase, maintain it, debug it at 2 AM, and review other engineers' pull requests, that is not your profile. Say so if asked directly.
The evidence: Three AI systems through Agentic Labs — Brand Pulse, Retail Velocity, and Carrier IQ — application layer built solo using Claude Code, on TinyFish's agent infrastructure. TinyFish is where you were most recently Head of Product. The Labs use TinyFish's underlying agent services (Search, Fetch, Agents); the application layer is yours: product logic, interfaces, orchestration, review architecture. That relationship is a strength when disclosed cleanly and a liability when it looks like it was obscured. These are live systems that accept input and return results.
Lead with Retail Velocity because its behavior is immediately observable. Enter a city, watch it discover restaurants, scan their ordering pages, extract brand presence data, assign confidence scores, return a ranked list with evidence. That is a running system making real-time decisions about extraction, scoring, and presentation.
Carrier IQ demonstrates a different surface: multi-carrier orchestration with staged workflows, review states (Bindable, Normalize, Referral, Call review), agent traces, evidence attachment, and a human approval gate.
Say this: "I built three AI systems — designed and implemented the full application layer solo using Claude Code, on top of TinyFish's agent infrastructure. They're live right now. Retail Velocity discovers restaurants in a city, scans their ordering pages, extracts brand compliance data, and returns scored results with evidence. I can walk you through it, or you can run it yourself."
Branch 2: Technical Fluency
Surface-form question: "How comfortable are you working near code?"
What they're worried about: You will design things that don't survive implementation. Or you will defer to engineering on every technical question, which slows the team and signals that design doesn't understand the product deeply enough to lead.
The grain of truth: Your technical fluency is real but bounded. You can architect AI agent workflows, make decisions about orchestration and state management, build functional systems. You are not going to debug a memory leak in a React component or optimize a database query.
The evidence: The market is already drawing this line for you. Render's posting asks for "comfort near code — you can read it, prototype with it, and collaborate with engineers without a translation layer in between." Mariana Minerals says their Staff designer "prototypes in code rather than only in Figma" and states that writing production code is "a plus, not a requirement." Checkout.com says "this is not a front-end engineering role" while requiring experience with AI-assisted development workflows.
Anthropic's internal account of how their product designers use Claude Code describes the same model: designers making visual adjustments and state-management changes directly in the codebase, generating functional prototypes from mockups, using the codebase to map logic flows and error states before engineering discovers them. Engineers help with repo setup and permissions. The document recommends memory instructions identifying the user as "a designer with limited coding experience who needs smaller changes and explanations." Your Agentic Labs work fits this model.
Say this: "I work in code through Claude Code — I've built and shipped three AI systems that way. I'm not replacing an engineer on your team. I make design decisions that account for how the system actually works, I prototype in running code so we can evaluate against real behavior, and I collaborate with engineering from inside the problem rather than across a handoff."
Branch 3: System-Level Judgment
Surface-form question: "Can you make architectural decisions that shape product outcomes?"
What they're worried about: Design will be downstream. You will optimize pixels on top of an architecture someone else chose.
The grain of truth: Your architectural decisions are visible in the product behavior of the Labs, but the reasoning behind them — why this orchestration pattern, why these review states, what you tried and rejected — is not documented publicly. The judgment is implied by the output. The process that produced it isn't.
The evidence: The value here is not that the systems exist (Branch 1 covers that) but that specific architectural choices are embedded in them — choices that determined what the product can do and how humans interact with it.
Carrier IQ is the clearest case. Four review states rather than a binary approve/reject: that's a judgment call about exception taxonomy. A bindable quote needs approval. A referral needs routing to a different workflow. A normalization needs manual adjustment. A call-review flags something the agent couldn't resolve and requires human follow-up. Collapsing those into pass/fail would have been simpler to build and worse for the operator. Per-carrier agent traces and evidence attachment rather than an aggregate confidence score: that's a position on what trust requires when AI acts in a consequential domain. The operator needs to see what the agent saw and did, carrier by carrier, to make a confident decision. The re-verification control lets an operator challenge a single carrier result without restarting the full workflow. Each of these is a product-architecture decision that determined what the system can and cannot do.
Brand Pulse shows a different set of calls. Parallel signal collection across Reddit and X with hourly synthesis rather than continuous streaming — a decision about information cadence and cognitive load. A 24-hour cache — a tradeoff between freshness and cost. A weekly narrative layered on top of hourly scores — a judgment that operators need both the granular signal and the synthesized interpretation, and that those serve different decision timescales.
Say this: "Look at Carrier IQ's review architecture. Four distinct review states instead of approve/reject, because different carrier responses require different human actions. Per-carrier agent traces and evidence, because trust in an AI-generated insurance quote requires the operator to see what the agent saw. A re-verification control that lets you challenge one result without restarting the workflow. Those are product-architecture decisions I made — where humans intervene, what they need to see, how granular the control has to be."
The Evidence Gaps That Remain
I covered the code-visibility gap in "The Code-Prototyping Screen" two weeks ago. The finding has not changed.
The public-repository gap
Zero public repositories. The live systems carry the conversation in most screens. But for technical evaluators who want to see how you build — iteration history, rejected approaches, the boundary between AI-generated code and your decisions — the gap is real and actionable.
Build a correction-lineage artifact for Carrier IQ. A documented sequence: failed output, diagnosis, versioned system change, improved result on a comparable later run. Pair it with a public repository — even partial — that includes a README separating AI-generated code from your design and quality decisions. The recommendation from Issue #8 still stands.
The TinyFish provenance question
This requires a conversation before you publish anything. Retail Velocity visibly states it is powered by TinyFish Search, TinyFish Fetch, and TinyFish Agents. Carrier IQ does not name TinyFish but shares substantial overlap with TinyFish's public insurance-quoting material. Confirm what you have permission to disclose and what attribution is required before publishing implementation artifacts. I covered this in "Fix the Boundary Before You Sell the Trust Framework" — blanket independence language is unsupported until authorship and permission are documented.
The framing that works in the meantime: you built the application layer solo on TinyFish's agent infrastructure, where you were most recently Head of Product. That's precise and honest. It does not require you to claim you built the infrastructure itself, and it does not require TinyFish's permission to say.
Two-Minute Reference Card
Classification: Hybrid. Reframe the perception gap. Build to close the evidence gap.
Adverse fact (state cleanly if asked): "I'm not a production engineer. I've never held an engineering title."
Who's asking — route accordingly:
- Startup CTO: Worried about dependency. Lead with maker capability. Agentic Labs — three systems, application layer built solo on TinyFish's agent infrastructure, Retail Velocity as the demo.
- Design VP: Worried about mediation. Lead with technical fluency. You work in code through Claude Code, you make decisions that account for implementation, you prototype in running software.
- Recruiter: Checking a box. Headline, one system, the tool. Move on.
- Hard filter: They ask about specific languages, PR review, production incidents, or mention a technical screen. Acknowledge the boundary. Ask whether the role requires it or prefers it.
Three evidence anchors:
- Maker: Three live AI systems, application layer built solo using Claude Code on TinyFish's agent infrastructure. Retail Velocity is independently observable right now.
- Fluency: Postings at Render, Mariana Minerals, Checkout.com explicitly separate code fluency from production engineering. Anthropic's designers work in codebases with AI tools and engineering support. Your profile fits this model.
- Judgment: Carrier IQ's review architecture — four review states mapping to four different operator actions, per-carrier evidence and traces, re-verification without full restart. Brand Pulse's cadence and caching decisions. These are product-architecture calls.
Known gap: Zero public repositories. Live systems prove capability but not process. Build the correction-lineage artifact. Publish a partial repo with a decision-boundary README.
Lines not to cross: Do not claim engineering experience you don't have. Do not imply the Labs required no AI-assisted code generation. Be precise about the TinyFish boundary: you built the application layer on their agent infrastructure, where you were Head of Product. Don't claim you built the infrastructure itself, and don't claim full independence until attribution is resolved.
-
Anthropic's designer-in-codebase model: Their product-design workflow document describes designers making state-management changes and mapping error states directly in the codebase, but does not disclose the merge, review, or deployment boundary for designer-authored changes — a detail that would sharpen the fluency-versus-engineering distinction considerably.
-
Headway's ambiguous code expectation: Headway's Provider posting says prototyping in code is core to the role and that designers "ship improvements to our codebase," but unlike Mariana Minerals or Checkout.com it never clarifies whether production-code contribution is a screening filter or a growth expectation.
-
Proactive disclosure research is thin: A study on negative self-disclosure in hiring found that candidates who candidly disclosed weaknesses were more likely to advance, but a separate experiment on realistic job previews produced a backfire effect — meaning the panel's advice to stipulate the adverse fact without volunteering a rebuttal remains supported but not experimentally settled.
-
Correction-lineage artifact status: The Issue #8 Portfolio Playbook specification broke the Carrier IQ correction record into three separately evidenced claims — receipt, system change, behavioral result — but the August 22 accountability note confirmed the artifact had not shipped, and this gap remains the single highest-leverage build item across code credibility, AI depth, and hands-on craft.