Code comes to the canvas: a full live demo of designers editing production code and opening a PR
Designing in code | Config 2026 · Georgia Russ
42 min total·Actually worth watching closely: ~29 min·3 must-watch clips
- 0:17 – 5:43Listen
Speed isn't the solution: what's left of design in the AI era
The opening names the tension head-on: AI makes prototyping faster than ever, but faster hasn't made design better. The speakers put the value of design back on divergent exploration and collaboration, which sets up the whole session -- why the answer is bringing code onto the canvas.
You can only judge how good an idea is once you have seen many of them; speed optimizes the way you work, it doesn't pick the right one for you.
This stretch is argument, with little more than title cards on screen. Fine to listen to while doing something else.▶ Jump to 0:17Speaker · Georgia Russ - 5:43 – 9:38Listen
Code isn't an artifact, it's a material on the canvas
The mental model for the new concept: a code layer on the canvas isn't code stuffed into a design file, it's a window into your actual repository, making design and code two modalities you can move between at will.
Read it as a window, not an embed -- every demo that follows only makes sense on that framing.
Mostly conceptual, with slides as light support. Catching the metaphor matters more than watching the screen.▶ Jump to 5:43Speaker · Georgia Russ - 9:38 – 16:11Watch
Pull the repo onto the canvas, then let it split itself
Two ways to create a code layer, live: clone a repo from your connected GitHub account and watch it come up running, or select a design layer and say "build an interactive code layer from this design." Then one instruction is sent to several code layers on the canvas at once.
No dev box, no Git knowledge, no terminal -- the agent handles the cloning and gets it running.
All screen work: picking the repo, the automatic setup, the code layer duplicating into a row of variations that all refresh together. These state changes only land if you watch.▶ Jump to 9:38Speaker · Niko - 16:11 – 20:33Watch
Lay out every screen, bring everyone in
Deterministic screen extraction: walk a flow once, then lay every screen you passed onto the canvas to compare how the versions differ and argue edge cases like whether there should be a password field. Then, wearing a growth PM hat, duplicate a code layer and prompt it directly -- and finally, the reveal that the fully working Figma Design in the demo is itself a code layer on the canvas.
The canvas isn't just where you work alone, it's where engineers and PMs get pulled into the conversation -- and since AI is very good at building things that look polished and are full of holes, early edge-case feedback is worth a lot.
The moment the screens fan out and the "wait, that's the real product running" reveal are both visual. The narration loses its weight away from the screen.▶ Jump to 16:11Speaker · Ben - 20:33 – 24:18Listen
Playground or production line: when to use which
The practical split: during exploration, use a prototyping environment freed of backend baggage, where the models run faster and use fewer tokens; once you move to implementation, nail the details directly on real production code.
Split by use case -- don't force one environment to carry both exploration and delivery.
A methodology bridge with nothing to watch. The conclusion is enough.▶ Jump to 20:33 - 24:18 – 30:55Watch
Hands on real production code
With the GitHub repo cloned locally, work begins on production code: first the agent uses the context of the code base to map the whole website into a diagram, then annotations placed on elements carry the instructions, with each exchange producing a commit and a revertible history, all behind the safety of a branch.
Branches and commit history are packaged so a non-engineer can pick them up intuitively -- get it wrong and you can roll back.
The diagram being generated, the shimmer on the annotated element, the badge appearing on the page -- confirming "it changed the right thing" is something you can only do by watching.▶ Jump to 24:18Speaker · Georgia Russ - 30:55 – 34:23Watch
The designer takes over: from design file into production code
From the designer's side: use the product diagram to confirm whether the feature is actually implemented and which surfaces the badge needs to appear on; then draft freely on a blank canvas, drop the design link into the editor, frame the target area and say "add it, matching my design." When the result is close but not exact, drag the element into place by hand.
For the first time designers have production-code-level visibility -- no more going into the app, creating a test user, and getting lost hunting for the right state just to check coverage.
Diagram to framed selection to dragging the element into place is one continuous chain of actions; you have to watch to feel the control coming back to the designer.▶ Jump to 30:55Speaker · Angel Nenciso - 34:23 – 42:26Watch
Closing the loop: back to the design system, ship in one click
When alignment and color aren't right, fix them in the familiar design panel. The built-in connector detects the variables and components in the code base so changes stay inside design system constraints, and when things have diverged too far you can sync back to the library. Finally, Copy Designs brings the code-only page back onto the canvas, and one click creates a PR for engineering review -- closing on four principles.
Designers editing production code directly and merging through normal review is now a path that works end to end.
The panel tweaks and variable picking in the first half are fairly static and can be skimmed; the code page coming back to the canvas and the hand-off for review are where the session lands, and worth stopping for.▶ Jump to 34:23Speaker · Angel Nenciso