Accidentally in Code

The other week, I found a menu button in the wrong place on mobile. Floating around the middle of the page when it should have been anchored to the side. Two things went through my head. First, the disappointment of finding a bug on the weekend. Second, we had things in place to prevent exactly this: a full design system and snapshot tests.

I dispatched the bug fix. It shipped the next day.

Then I dug into why the design system and snapshot tests had let it through. The first answer was simple: Chromatic only snapshotted at desktop width.

Awkward given I spent most of my career working on mobile. But I’d been heads down on my computer, aggressively pushing a replatform, and somewhere along the way I forgot about this part of the system.

There’s an open question about what engineers do in the software factory and whether we’re needed at all. This is where the analogy works for me. The engineer doesn’t fix the widget. They fix the system that produced the faulty widget and let it make it all the way to the user without being flagged.

I turned on snapshots for every story at 390px, internal pages included. Even the internal views I’m pretty sure no one is ever looking at on mobile.

The first build turned up more than a menu button. A few of the portals and internal tools needed proper mobile navigation, and there were nine smaller layout bugs, found one at a time by eye: squeezed save buttons, pills overlapping names, filters running off the edge of the screen.

Looking at things myself gave me a sense of the scope of the problem and the extent to which our current system wasn’t working. So the next step was a detector that measures every story at 390px for elements escaping their container or overlapping each other. It recorded the existing problems as a baseline, and the baseline can only go down. We burned through 80 entries in about two weeks. Mobile CI now fails on horizontal overflow. That’s what stops the next menu button shipping.

Then the design system, which is supposed to stop us building things that don’t work on mobile. I did a full audit with Claude (Fable), which found assorted deficiencies, including two invite flows that were 93% identical and slowly drifting apart. Those are fixed, along with a lot of smaller duplication, and each fix came with a guard: a ratchet against hand-built cards, a lint rule for mobile classes, a check that every component has a story.

In our first month CLAUDE.md said “use the design system”, but these rules always break eventually. An instruction is a suggestion. A guard fails the build. Standards that used to be inconsistently applied in code review are now enforced automatically.

Which is all very tidy, but the process often isn’t. I went from under-snapshotting to over-snapshotting before finding (I hope; still TBD) a middle ground. I spent hours reviewing Chromatic diffs. Phone-width checks flaked because fonts hadn’t loaded yet. Browsers disconnected mid-run. I cut snapshots that added nothing, and found a few stories that weren’t capturing what we thought they were.

This is where the real learning curve is. It’s also where the work is. Turning on mobile snapshots was one decision; making them catch the right things without failing on fonts or burying me in diffs has taken two weeks and is still in progress. It’s why I think software engineers will still be employed despite how good Claude is at writing code: maintaining systems of this size is just hard.

Even when the bug is fixed, the system still needs work. Which is, I guess, why some people find AI so wasteful: what a vast amount of work to not have a button in the wrong place. But the point isn’t the button; it’s a system that ships product to your standards.