Aakash GuptaDesigning With AI With Designers of Figma & Codex
CHAPTERS
- 0:00 – 3:03
Design in code vs design on the canvas: why it’s a false dichotomy
Aakash opens with the “code vs canvas” debate and invites Ed (OpenAI Codex) and Gui (Figma AI) to draw the line. Both argue the debate is outdated: designers can and should move between mediums depending on the problem.
- •The debate is framed as code-first vs canvas-first design
- •AI shifts the “Overton window” from curiosity to urgency and adoption
- •Designers risk becoming a bottleneck as dev velocity accelerates faster
- •Roles and workflows are becoming more fluid across disciplines
- 3:03 – 6:11
Two complementary modes: exploration in canvas, depth and realism in code
Gui and Ed describe canvas and code as different representation layers for ideas. Canvas excels at lateral exploration and collaboration; code excels at making interactions real quickly and validating behavior in a production-like environment.
- •Canvas is still the gold standard for quick ideation and broad exploration
- •Code enables rapid depth: real interactions, responsiveness, and live testing
- •Pick the right tool for the job rather than committing to a doctrine
- •Design’s scope expands when designers can ship PRs for the “last mile”
- 6:11 – 10:24
When to start where: choosing tools based on objective, fidelity, and scale
They outline how historic workflows (low-fi to high-fi) were shaped by tool constraints, not necessity. Today, teams can start at higher fidelity (even in code) and switch based on whether they’re exploring a flow, refining a component, or pushing a new interaction paradigm.
- •Old dogma: start low fidelity because high fidelity was expensive
- •Now: low-fi can be functional wireframes in Codex to get teams talking
- •Start in code for component finesse and real constraints; start in canvas for broad flows or paradigm exploration
- •The process is iterative and fluid—not linear from Figma to code
- 10:24 – 13:47
Live workflow demo: exporting real UI from Codex into Figma via MCP
Ed demonstrates a day-to-day workflow: prototype and test interactions in a local React app (Codex), then import specific screens or components into a new Figma file. This shows a practical path for moving from working code to editable design artifacts.
- •Codex desktop app connects to a local repo/project for rapid iteration
- •Ed uses a ‘composer’ UI example with multiple dynamic states
- •Figma MCP enables importing snapshots of UI into a Figma file
- •Designers can choose full screens or specific nodes/components to bring over
- 13:47 – 15:15
Figma MCP deep dive: selecting nodes, preserving layout, and improving fidelity
Gui explains how the MCP interaction lets teams choose exactly what to copy and iterate on, not just whole screens. Ed emphasizes that imported designs preserve precise spacing, padding, and radii, reducing manual inspection overhead and speeding iteration.
- •You can target specific components (avoid copying unnecessary background containers)
- •Imports preserve pixel-accurate layout information and responsiveness
- •Reduces traditional “inspect and recreate” effort for engineers and designers
- •Supports faster pixel-perfect refinement once interaction behavior is validated in code
- 15:15 – 20:57
Closing the loop: sending Figma changes back into code
Ed shows the reverse direction: make a tweak in Figma, copy a link to the component, paste it into Codex, and ask it to update the code accordingly. The point is a softer handoff and shared ownership between designers and engineers—even when designers don’t code deeply.
- •Copy link to a Figma selection and use it as input to Codex
- •Codex applies Figma-driven changes back into the local codebase
- •Enables genuine collaboration without strict tool silos
- •Makes “handoff” less brittle by turning it into an iterative loop
- 20:57 – 24:00
Lossiness and fidelity limits: what doesn’t translate (yet) and how teams compensate
Aakash presses on what breaks in translation. Gui and Ed explain current limits (e.g., shader effects, certain transitions) but note that annotations and improved models reduce errors; strong foundations (naming, tokens) make agents more reliable.
- •Some effects and transitions don’t map cleanly to a static canvas
- •Annotations can communicate intent that the model can’t infer
- •Quality of systems (component naming, libraries, tokens) improves agent performance
- •Newer models significantly improve reliability with MCP workflows
- 24:00 – 27:24
Behind the scenes: how AI changed day-to-day building pace at OpenAI and Figma
They describe a shift from design→prototype→engineering to a more continuous loop where staging/flags and rapid iteration are common. Ed describes Codex designers as developer-forward and notes a capability threshold where velocity jumped dramatically.
- •Codex team designers often code; Ed spends ~70–80% of time coding
- •Teams share hybrid artifacts: Figma links plus live URLs for interaction review
- •Dogfooding and model improvements drove a step-change in shipping speed
- •Key tension: choosing when to slow down for deep design vs matching dev velocity
- 27:24 – 33:38
Designers working in staging: empowerment, but also the need for judgment
Gui explains that within Figma, designers increasingly work directly in staging and can ship polish themselves. This power introduces a new question—“just because you can, should you?”—and pushes teams to consciously preserve exploration and craft.
- •The Overton window shifted rapidly: teams now ‘can’t move fast enough’ without AI
- •Designers can implement polish directly, collapsing old priority cutoffs (fewer ‘P2s’)
- •AI unlocks prototypes and technical execution across non-technical teams
- •Judgment becomes crucial to balance exploration, speed, and quality
- 33:38 – 36:19
Roadmap for traditional or regulated teams: how to adopt incrementally
Aakash asks how teams in healthcare/finance and other compliance-heavy orgs can transition. Ed and Gui emphasize starting small, trying tools personally, and building confidence through practical use rather than waiting for formal procurement or permission.
- •Start by trying tools in low-risk contexts—even personal projects
- •Choose the least intimidating entry point (terminal, app, IDE extension, phone)
- •Overcome the ‘blank box’ problem by asking for help and iterating
- •Adoption doesn’t require immediate production shipping—begin with learning and experimentation
- 36:19 – 43:31
AI as your tutor: building capability, not surrendering control
Gui and Ed frame AI as an always-on teacher that helps people learn systems, code, and product thinking through questions. They argue designers still need engineering hygiene (PR review, understanding codebase), but AI lowers the barrier to entry and accelerates learning.
- •AI enables ‘ask and learn’ loops: build, then ask how it works
- •Treat the agent as a tutor/partner, not a replacement for understanding
- •Engineering hygiene still matters (data models, avoiding foot-guns, PR review)
- •Curiosity becomes a defining skill as tools and workflows change rapidly
- 43:31 – 51:19
Roles blurring, not disappearing: spikes, shared tools, and ‘Total Football’ teams
They describe how designers, PMs, and engineers increasingly overlap in execution while retaining distinct conceptual mandates. Gui uses ‘Total Football’ as an analogy: everyone can cover more ground; Ed stresses that core role value (user voice, systems, business) remains.
- •People keep ‘spikes’ (strengths) but don’t own rigid territories
- •PMs prototype; designers ship code; engineers collaborate in design artifacts
- •Internal ‘skills’/playbooks encode expertise and make it reusable across roles
- •Distinct role mandates persist even as tool accessibility increases
- 51:19 – 53:35
Prototypes, not PRDs: what cross-functional work looks like now—and closing thoughts
Ed highlights the shift toward prototypes as a primary communication artifact, even for PMs, while maintaining each role’s core responsibility. Aakash wraps up, emphasizing how frontier workflows will diffuse to more companies over time.
- •PMs increasingly bring working prototypes to stress-test ideas with engineers
- •Coding becomes a medium to achieve role goals, not a role change itself
- •Design identity remains even when most time is spent in code
- •Wrap-up: encouragement to adopt the workflow mindset and tools progressively
