From DX to BX

Remember when test suites are flaky? Not broken — just unreliable. Same code, Pass on Monday, fail on Tuesday. Devs didn’t stop caring about tests. They started saying “just push it, we’ll catch it in prod.” They merged PRs they weren’t sure about. They stopped catching things early because catching things early cost too much time. The discipline didn’t disappear. The loop punished it until it quietly eroded.

That’s what bad Developer Experience (DX) did to User Experience (UX). Not dramatically. Incrementally. The builder’s experience shaped what got shipped, and nobody really noticed until it was already in the product.

That same pattern is happening now, but with a much larger, less technical building population.

AI moved the starting line. Designers, PMs, marketers —people who spent careers describing what they wanted to developers— are now building it themselves. But the tools weren’t built for them. And the gaps in their experience show up in the product.

A designer working in Figma has a slider for every property. Instant feedback. Change the border-radius, see it move. With AI, they type “make it feel softer,” wait, and get something close but not quite right. They try again. The loop is long. So they stop before they get there.

A PM building a dashboard can picture every edge case that needs to work. Empty state. Error. Mobile at 375px. Forty items instead of four. They know exactly what to check, but validating each one means a new prompt, a new wait, a new build cycle. The loop is too slow to close. So they ship the happy path and file the rest as known issues.

I felt this myself last week, building in Claude Code on the web. Made a change. Needed to see it. Waited for a preview link to spin up. Thirty seconds. By the time it loaded, I’d lost the thread of what I was testing.

That was loop one.

By loop five, I wasn’t checking what I originally set out to check. By loop ten, I was optimizing for “does this look roughly right” instead of “is this actually right.” The standard shifted, not consciously. The loop just kept teaching me what was worth caring about. Each broken cycle is a small compromise. Compounded across a session, you’ve shipped something 70% of what you imagined and convinced yourself it’s done.

This is the Builder Experience (BX) problem. The quality of your ability to see, iterate, and close the gap between what you imagined and what exists.

And here’s what makes it particularly frustrating: taste doesn’t save you. There’s a lot of noise right now about how taste is the new superpower, the thing that separates good AI output from slop. That’s true. But taste is an input, not a guarantee. Even if you have that rare sensitivity (you know when something’s off, you can feel it before you can name it) a slow loop can still beat you. You’ll feel that it’s wrong and not fix it, because fixing it means three more cycles and the thread is already gone.

Good BX doesn’t replace taste. It’s what lets taste do its job.

What bad DX taught us: the builder's experience shapes the product, invisibly, until it's too late to fix. Bad DX became bad UX — not through laziness, but through the slow erosion of what the loop made possible. Bad BX will do the same. Is doing the same.

The tools are starting to respond. But we haven’t named what we’re optimizing for.

So: name it. Measure it. Fix it.

What would great BX actually look like for a designer? A PM? A founder with taste but impatience?

I don’t have the full answer. But naming it feels like the right first step.