From handoff to shipping code

Supplyframe sits inside Siemens audit scope, so “the designer used an AI tool” is not an answer anyone in compliance wants to hear. New tools need a reason a reviewer can sign off on.

The first real problem wasn't quality. It was consistency. The same request to a coding agent could come back on-system one day and off-system the next.

An agent can only stay on-system if the system is easy to find and hard to misread. The code was the source of truth, so I started there and worked outward.

The move was simple to say and hard to do: the design team takes direct ownership of frontend implementation, not only the design of it. We stopped treating the mock as the deliverable. The deliverable is working UI in the codebase.

That only works if there is something to build on. Fragments became the contract between design and engineering. Designers compose from its components and tokens, AI tools write against it, and engineers review code instead of rebuilding pictures.

This was a bet on designers, not on tools. The tools make the code fast to write. Knowing what good looks like, and noticing when the output is wrong, is still the designer's job. I own what the tools produce.

We keep written agent instructions in the repo (for GitHub Copilot, a copilot-instructions.md file) that say which components to use and which patterns are off limits.

Context drifts. Long agent sessions slowly forget those rules. Knowing when to start fresh is a skill the team had to learn.

Agent mode inside the IDE, with the codebase in view, produces different UI than a fresh chat with no context. We settled on fresh chats for most UI work, because they keep drift out, and use the IDE agent for small, contained edits.

None of this is glamorous. It's the difference between a demo and a workflow a team can rely on.

When I made the case for turning on GitHub Copilot's vision features, I didn't pitch speed. I pitched the audit trail: a record of what the tool saw and what it produced makes review easier, not harder. The request was approved.

The lesson carried over to everything else. Adoption inside a regulated company is a design problem. You design the argument for the people who have to say yes.

We brought the system's tokens into Figma through Tokens Studio, so design and code read from the same values.

Before making a single Figma component, we listed every component that already existed in code. The Figma library mirrors the code, not the other way around.

New themes slot in as configurations on the same components, so adding one doesn't mean a second system. The longer-term goal is for design tools to generate code that matches production, because the library they draw from is production.

Once the team was building with agents, the next question was what agents need from our products, and from a designer. I wrote agent prompts for the people who use our products and had them work through what the apps can actually do. Where an agent got stuck, a person probably would too. It turned up gaps a feature list hides. The biggest showed up in commodity management: agents couldn't work together, because the modules had almost no event triggers between them. One step finishing didn't tell the next one to start. We added event triggers between modules so agents can follow the flow from one step to the next.

I'm redesigning Findchips around an AI assistant over live part data: results come first, and the AI overview sits in its own tab where people can ask follow-up questions. This is in progress, not shipped.