Tommy Jepsen
How product designers can start shipping code

How Product Designers Can Start Shipping Code

2026-06-20 — by Tommy Jepsen

A product designer on my team shipped to production last week. They had never touched the backend.

For most of my career that sentence would have been a warning. A designer changing production code meant a risk to manage, a process to slow down, a conversation about who owns what. Now it's just a Tuesday. Two things were always in the way, and both are gone.

The first wall was risk

The real reason designers never touched the code was fear of breaking production. Not a lack of taste, not a lack of ideas. Fear. One wrong change and something a customer depends on stops working, in public, with your name on the commit.

So we removed the fear structurally. Main is protected. Nothing merges without a pull request and a review. CI runs on every push. The worst a bad change can do is sit in a branch and get rejected. The blast radius of a mistake is zero, because a mistake never reaches a user.

That single rule changes who is allowed to touch the code.

The second wall was the learning curve

Risk was only half of it. The other half was quieter and rarely admitted: knowing how git works. Finding which file holds the button. The resistance to learning what flex and gap and a Tailwind class even are.

That was a genuine wall. It kept design and code on opposite sides of a handover, where a two-pixel padding fix became a ticket, a translation, and a wait.

AI took the wall down. The designer describes the change in plain language, the model points at the right file and writes the className, and they read a diff instead of memorizing a framework. The knowledge that used to gatekeep the work is now on tap.

Where the line sits

This is not designers doing everything.

What they ship: copy, spacing, color tokens, an empty state, a hover transition, a conditional className. Small, visual, reversible. The things they already specced, now committed directly instead of described in a ticket.

What they don't touch: data models, API contracts, dependencies, anything architectural. The pull request is the firewall, and the reviewer is the one who catches the change that shouldn't ship.

Protected main removes the risk. AI removes the learning curve. What's left is a designer closing the gap between the design and the thing people actually use.

The tooling didn't turn designers into engineers. It removed the two reasons they couldn't ship.

Tommy Jepsen - design engineer in Copenhagen

Connect on LinkedIn

Follow along on LinkedIn for more updates, tips, and insights on UX design and AI.