Caleb Frost Sanderson

I’m a product designer who writes front-end code, closes the loop on AI-generated UI, and holds the design system’s line across the design–code boundary. I run the design function at Fulcrum and stay hands-on in the craft: design systems, front-end implementation, and keeping what ships coherent when engineers draft fast with AI.

I build the system around the work, not just the work

For most of my time at Fulcrum I’ve been a player-coach: carrying a working IC load while running the design org’s operating system. That operating system is real and documented — an embedded “special ops” model that assigns a designer to each engineering tribe and platform; a 30-day onboarding program; a formal critique culture with a written set of “crit axioms” (“Clarity is kindness,” “You are not your work,” “Pass the mic”); biweekly retros instrumented with a 1–10 team-health score. I didn’t just run rituals — I wrote them down so they’d outlast me.

The piece I’m proudest of is a capability bar, not a process: every product designer on my team has shipped to production in code. Our onboarding literally requires designers to set up an engineering laptop and review pull requests for design fidelity — “reviewing PRs for quality and accurate implementation of the intended design is a big part of what we do.” When our most recent hire merged his first PR within weeks of starting, that wasn’t luck; it was the onboarding mechanics working as designed. I built a team where the design-to-code seam is owned by designers, not handed across a wall.

I hold the line when it matters, and I’m transparent about cost

The single artifact I’d point to for judgment under pressure: a major customer demanded we replace the Android back-arrow with text labels. Changing a platform back button is a hard “no” — it affects every user, not one account. So I ran a same-day design spike, held the platform convention, and also shipped a redesigned discard dialog by end of day that solved the real frustration underneath the request. Customer Success used it to “make the customer feel heard while improving things for all users.” I read it as a classic solutions-vs-problems confusion, and the job was to fix the problem without conceding the bad solution.

That same instinct shows up in how I work with AI output. When a V2 design in flight was really “a wireframe from Claude that still needs hi-fi polish,” I said so in writing, drove the team to a de-scope decision, and named who would close the fidelity debt and when. Cutting scope out loud — and labeling what’s still owed — is the unglamorous senior behavior that keeps speed from quietly becoming a quality problem.

What “designer who codes” means in practice

I’m a strong generalist — UX research, IC product design across web and mobile, design systems, and team leadership. In practice that leans technical: front-end and design-system implementation, where design judgment and code live in the same person instead of being handed off.

Day to day, my front-end work is mostly PR review, enforcing design principles, and maintaining design-system standards — using theme tokens for spacing and color instead of hard-coded values — plus the occasional cleanup PR I push myself. The same thread runs through work toward an agent-operated design system: keeping tokens, themes, and generated UI aligned as one system.

The aim isn’t to occupy a dev seat. It’s to multiply the dev team: understanding the code well enough to keep AI-generated UI aligned to the system, at the speed AI now produces it. As models flood every team with plausible interfaces, the scarce skill stops being generating UI and becomes keeping it coherent.