What happens when engineering outruns design

Key takeaways

1. 01AI made our engineers faster than our design process could keep up with.
2. 02Moving design into the client's repo fixed handoff, but it created a second source of truth.
3. 03The answer isn't a better prototype. It's designing closer to the product itself.

My first-ever pull request changed a button from black to green.

One hex value, a couple of minutes of work. What mattered was where I made it. It went straight into the product, with no Figma file or prototype handoff in between.

For years, we designed everything in Figma, from complex dashboards down to the smallest error message. Then AI shrank our build times, and the process broke down. A feature took me half a day to design and our engineers a couple of hours to build. Claude Design helped for a while, but it lived entirely on our side. Every screen we handed the client exported as one giant HTML file that engineering could barely use.

Building the prototype inside the client’s repo

So I stopped treating my prototype as separate from the product and built it inside the client’s own GitHub repo. Every flow is versioned, and each one ships with what’s needed to implement it: instructions for Claude, screenshots for engineers, and handoff docs covering specs, UX, and UI decisions. Basically a Jira ticket on steroids.

Engineers started pulling code straight from my prototype instead of waiting for a handoff. That wasn’t the plan. It happened because my work was finally somewhere they could reach it.

When the prototype became a second source of truth

What I didn’t see coming was that the prototype became a second source of truth, and it started drifting from the real source of truth, the code.

It happens in small moves. I round a modal’s corners in the dev environment instead of the prototype, and that change lives in exactly one place. An engineer fixes a bug in production, and the fix never makes it back to me. Over months, the gap gets wide enough that keeping the prototype current stops being worth the time.

The clearest example was our invoice review page. We assumed users would trust an AI-generated invoice review, but they needed more control before they could act on its results. The prototype could show the experience, but only the real product could be tested with real users. As feedback came in, it was faster to make structural changes directly in production than to update the prototype first. The prototype fell behind, and some of our most important design decisions were now happening in the product itself.

I built audit skills and tried pulling changes from the production repo, but nothing kept the two aligned reliably. Eventually I had to ask a different question.

Should I spend hours backtracking every decision into a prototype that was always behind, or use that time to design what comes next?

Where design happens now

I used to think the fix was one clean prototype that always mirrored the product. I don’t anymore. Anything built to be both a design sandbox and a living spec will lose to whatever ships fastest, and right now that’s production code.

So the prototype changed jobs. It’s where we explore larger product visions and define complex features before implementation. New features with backend logic still start there. Anything purely visual goes straight into the live product.

Starts in the prototype

Larger visions and complex features

• +New features with backend logic
• +Product concepts, explored before implementation

Goes straight to the live product

Anything purely visual

• +Smaller UI improvements and refinements
• +Changes tested with real users

If a new engineer asked where to find out what this product is supposed to look like and why, I’d have to tell them it depends. It works because everyone knows the unwritten rules. That’s not something you can scale easily.

What it takes to let designers work in production

Moving closer to production gave me more freedom and more responsibility. If your team lets designers into the codebase, a few ground rules matter. Set up the environment properly. Keep every prompt scoped to the frontend until you know exactly where the backend line sits. Test any change to a real flow the way an engineer would. AI makes a change easy to prompt. It doesn’t make it small.

AI made production code easier to change. A bad change costs as much as it ever did.

That doesn’t mean doing everything yourself. Our biggest improvement was a process change. The reviewing engineer now fixes and merges my PR directly, instead of bouncing it back to me across time zones. A review cycle that used to take three or more days now takes one.

It made me question why we still separate design and development as much as we do. I think there’s room for a third environment alongside dev and QA. It would be a design space in the same repo as the live product. Small UI changes would move through it directly, and bigger features would be tested with real users before touching production. Design should happen against the same system production is built from.

We’re not there yet, and I’d rather say that plainly than pretend the problem is solved.

The next bottleneck

Solving one bottleneck exposes the next one. Engineering got faster, so our design process became the constraint. I moved design closer to code, so keeping multiple sources of truth aligned became the constraint. The tools will keep changing. The work is figuring out what becomes slow next.

Maybe design’s next source of truth isn’t a design tool at all.

It’s the product itself.