A design system can look tidy in the library while the product using it is held together with hacks and sellotape.
The difficult part is finding where that has happened, why it happened, and what is worth fixing first.
The audit I could rarely start
I used to depend on developer capacity to inspect the codebase and trace how teams used components. We already struggled to find enough capacity for planned product work, let alone an audit with no immediate feature attached to it.
I could review screens and speak to teams, but I could not always see what was happening underneath. A component might look correct while using local styles, outdated code, or a wrapper around the system.
Put both repositories in one workspace
I cloned the product repository and the design system repository into the same parent folder. I then ran the AI audit from that folder so it could inspect what the system provides and how the product uses it.
I asked it to trace component imports, properties, wrappers, local styles, hard-coded values, and copied patterns. For each finding, it recorded the component, the intended system source, the product implementation, and the file paths that proved the difference.
The result was a map of adoption, fragmentation, and component health. I could see where teams used the system directly, where they stretched it, and where they bypassed it.
Follow the sellotape
One repeated pattern looked like poor adoption at first. The design system provided the main tool, but it did not provide some controls that the product journey needed. Feature teams had added those controls locally and joined them to the system component.
It was held together with sellotape, but the sellotape had a reason. The product was exposing a gap in the system.
That evidence changed the action. Instead of asking teams to remove their workarounds, I could define the missing controls, add them to the shared component, and plan product migration afterwards.
I still review the findings with engineers. AI can trace patterns quickly, but the team confirms the technical context and decides whether a difference is debt, a valid local need, or a system improvement.
AI does not decide what to fix. It helps me see the system clearly enough to decide where to start.