Designers can already act on front-edge judgment directly. Tools like Cursor, Claude Code, and Cline let them scaffold real components, wire up real data, and iterate on real interactions. That’s not theoretical. Designers are doing it today, including me, on cybersecurity workflows where a fake prototype teaches the wrong lesson.
What’s missing isn’t capability. It’s environment.
Your design team doesn’t need exclusively Figma files. They need a sandbox repo.
A 1:1 clone of your production front end, with the same components, design system, lint rules, context files, agent configs, and tooling, but with the backend mocked. API calls return realistic data that mirrors your actual schemas. Auth is simulated. Third-party services are stubbed.
A CI job syncs front-end changes from production. Mock data auto-generates from your API specs so nothing drifts. The sandbox stays current without manual maintenance.
No broken builds, no merge conflicts, no accidental production deployments.
Just real, shippable work, in a safe environment.
This is the infrastructure argument underneath The Two Edges of Judgment. Judgment at the edges is useless if the only place a designer can exercise it is a picture of the product.
Not a playground. A contract validator.
A sandbox repo isn’t a place to experiment. If prototypes use the same tokens, components, and lint rules as production, you’re not designing ahead. You’re stress-testing the system.
Every design decision gets validated against real constraints before it touches an engineering queue: not wireframes, not Figma prototypes, but code that follows the same rules as the thing that ships.
That changes the handoff.
When the prototype is done, the code is at least 70% production-grade. Engineering reviews it and ports it to production. The translation layer between what design intended and what engineering built practically disappears.
One thing most teams miss: enforce domain boundaries in the sandbox. That means no direct API calls, typed mocks, and feature flags that mirror production toggles. If you skip this, you’ll build beautiful demos that bypass real constraints: interfaces that look right but can’t exist under production conditions.
The sandbox works because the constraints are real. That’s what makes the output trustworthy.
Hackathons produce demos. Sandboxes produce work engineering can actually use.
Also in April: The Disappearing Middle of Software Work · The Two Edges of Judgment · Judgment Is the Territory
Daniel Arevalo is Product Experience Lead at Omny Security. He builds AI-native tools and writes about design, product leadership, and what it means to direct systems that execute at a speed humans never had before.