The Part Nobody Shows in the Tutorial

I’ve been watching a lot of Jack Roberts lately. If you haven’t come across his tutorials, he’s doing genuinely exciting work — using AI tools to push design in directions that feel fresh and alive. Watching them makes me want to drop everything and go build something beautiful.

Instead I’m building a diff.

Not the glamorous phase. But I’m starting to think it might be the most important thing I do before any of the exciting work can actually stick.

Here’s what I’m in the middle of, and why I think it’s worth talking about.

The Problem With Jumping Straight to “Scale”

There’s a version of AI-assisted design that looks like the tutorials — fast, fluid, generative, full of momentum. That version is real. But it has a prerequisite nobody really talks about: you have to know what you’re working with first.

Our team has GitHub repos with component documentation. We have Figma files with the design system. We have specs, annotations, handoff notes. On paper, it all exists.

But does it all agree?

Are the components that are built the same as the ones that were designed? Is the documentation current? Are the names consistent between design and code?

I genuinely didn’t know. And that meant before I could run any kind of AI-assisted evaluation against our product design work, I first had to figure out where we actually were. That’s the baseline problem. And it’s more common than people let on.

What I’m Actually Doing

The approach: using Claude to pull data from both GitHub and Figma, then running a comparison to surface where they diverge.

On the GitHub side — component documentation, prop definitions, naming conventions, any design system specs that live in the repo. On the Figma side — component libraries, design tokens, frame naming, annotation layers.

Then: the diff.

Where do these two sources of truth disagree? What’s been designed but never built? What’s been built but drifted from the original design? What’s documented that no longer matches what exists in either place?

The answers are humbling. In a useful way.

In our case, I found components with different names in design and code — small enough inconsistencies that nobody noticed, but significant enough that any AI trying to map one to the other would confidently get it wrong. I found documented behaviors that had been updated during implementation but never reflected back in the design specs. I found a whole section of the pattern library in Figma that engineering had quietly deprecated months ago.

None of this was anyone’s fault. It’s just what happens when teams move fast and parallel work doesn’t always sync. But it means our “design system” was actually two slightly different systems that had been quietly diverging for a while.

You can’t run a reliable evaluation against that. You get confident wrong answers.

Why Baseline Before Running

AI is genuinely good at pattern recognition and comparison — but only against a ground truth it can trust. If you hand it two sources of information that disagree, it’ll either pick one arbitrarily or produce a synthesis that doesn’t accurately reflect either.

For the kind of work I want to do — using AI to check whether our product design is consistent, accessible, and properly documented — I need the underlying data to be clean and current first. Otherwise I’m just automating the propagation of inaccurate information at scale. Faster mess, not faster clarity.

The baseline phase is where you find out what you actually have. And it requires more deliberate design thinking than the generative work — because you’re not just gathering data, you’re deciding what counts as truth when things conflict.

When Figma says one thing and GitHub says another, which one is right? Making those calls now, explicitly, is so much better than letting an AI pipeline make them implicitly later.

Those implicit decisions are the ones that compound quietly into much bigger problems.

What the Foundation Phase Actually Produces

By the time this audit is done, I’ll have things that didn’t exist before:

A single reconciled source of truth for the component library — names, states, behaviors — that design and engineering can both point to.

A gap list: things that are designed but not built, things that are built but not designed, things that exist in both places but don’t match.

A decision log: every conflict, what we decided, and why.

None of this is the exciting part. But all of it is what makes the exciting part possible. When I start running AI-assisted evaluations — checking consistency, flagging accessibility gaps, surfacing documentation debt — I’ll be running them against something real. Something I can trust. That changes everything about how reliable the output will be.

The Tutorials Are Actually Motivating the Foundation Work

Here’s what I keep noticing while I watch Jack Roberts’ work from inside my very unglamorous audit: it’s clarifying, not deflating.

The reason to do this baseline carefully is so the generative work can actually land. Better design tools, faster iteration, AI-assisted elevation of the craft — all of it requires the infrastructure underneath to be trustworthy first. You can’t scale quality you haven’t defined yet. You can’t evaluate output against standards that don’t exist yet.

So right now I’m in the gap-finding phase. Pulling the data. Running the diff. Making the calls on what’s true. It’s the part that doesn’t make for a great YouTube thumbnail. But I think it’s the part that makes everything after it actually work.

If you’re somewhere in this phase too — auditing before running, establishing baseline before you can do the interesting stuff — this is an undertalked corner of AI-assisted design work. Most of what gets written is about what to do once the foundation is solid. Not as much about building it. I’m in it right now. More to come.