A local workaround can reveal something the design system is missing.
That was not clear from the screens alone. A component could look correct while relying on local styles or extra controls built by a product team.
I used to depend on developer capacity to inspect those differences. With that capacity already stretched, I needed a way to see the implementation and understand why the workarounds existed.
Put both repositories in one workspace
I cloned the product and design system repositories into the same parent folder, then ran an AI audit across both.
I asked it to compare shared components with their product implementation and flag local workarounds, missing controls, and repeated patterns. Each finding linked back to evidence in the code.
I recorded the component, issue, evidence, owner, and next action in one inventory. The actions were keep, improve, merge, or retire. That gave the team work to prioritise rather than a list of differences.
Understand why the workaround exists
One repeated pattern looked like poor adoption at first. The shared component existed, but it lacked some controls the journey needed. Feature teams had added those controls locally.
That changed the action. Asking teams to remove the additions would leave the requirement unresolved. The useful next step was to define the missing controls and plan how the shared component could support them.
I review the findings with engineers before deciding what should change. We check whether each difference is an unnecessary override, a valid local need, or a gap worth fixing in the system.
The audit helps us address the reason for the workaround, rather than only its appearance.
AI does not decide what to fix. It helps me see the system clearly enough to decide where to start.