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.
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 compare shared components with their product implementation, then flag local workarounds, missing controls, and repeated patterns. Each finding linked back to evidence in the code.
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.
I added the findings to one inventory across design, code, and products. Each row recorded the component, known issue, evidence, owner, and next action. Actions were limited to keep, improve, merge, or retire, which turned the audit into work the team could prioritise.
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.