Meta engineer Cindy Zhang walked through how XDS migrated thousands of internal tools by treating the migration as code. The pattern is portable to any large design system estate.
When a design system reaches the scale of 10,000 internal tools, the temptation is to freeze development, write a migration plan, and hope. Meta's internal tooling team reached for something else: codemods and feature flags. The pattern is concrete enough that any large engineering org can steal it, according to front-end engineer Cindy Zhang in an InfoQ presentation on Building and Scaling UI Systems for Internal Tools at Meta given at QCon San Francisco.
Zhang works on Meta's internal tooling infrastructure and design systems. She described XDS, Meta's unified UI system that she said powers more than 10,000 internal tools. The scale figure comes from Zhang's own account of her employer's estate; it should be read as Meta's own accounting rather than an independently audited number. Even with that caveat, the floor it sets is the point: a manual migration was never going to scale.
The mechanism Zhang walked through has three parts. The team writes JavaScript AST transforms that mechanically rewrite deprecated API usage in consumer code. Those transforms are increasingly generated with AI assistance, so the codemod surface keeps up with new deprecations faster than humans can write migration guides. Every transformed change is gated behind a feature flag, so a refactor that breaks a downstream tool does not break production; it breaks a flag.
That ordering matters. Most engineering orgs run migrations the other way: announce the deprecation, write the docs, then chase the stragglers for a year. The Meta sequence inverts it. The codemod is the announcement. The feature flag is the safety net. Human review happens on the codemod itself, not on every consumer change.
Zhang also described the community contribution model that keeps XDS moving. Internal teams propose new components, and the XDS team reviews them for promotion into the shared library. Promotion is the prize: once a component lands in XDS, every tool in the estate can pull it on the next dependency bump. The incentive structure is what scales, not headcount. There is no design system team large enough to author every component a 10,000-tool estate needs.
The forward-looking piece is the most underappreciated. Zhang framed XDS as deliberately expanding from a UI library into a full-stack platform, with state, data, and routing primitives moving into the system alongside the components. The shape is the same one the React ecosystem has run at the framework level for a decade: components were not enough, so hooks and server components joined them. Inside Meta, the UI library has become a place where full-stack assumptions get made on the company's behalf.
For engineering leaders running their own large internal-tooling estates, the takeaway is not "adopt XDS." It is a pattern that can run on Monday: pick one deprecated API in your design system that is still in use, write a JS AST transform that rewrites it to the new API, land the transform behind a feature flag tied to the consumer tool, and generate the next transform with an AI assistant whose prompt is treated as a reviewable artifact. The shape of the work is the same whether the estate has fifty tools or ten thousand.
The cost is real. Codemods need tests. AI output needs human review. Feature flags accumulate into a debt of their own, and someone has to retire them on a real cadence. The benefit is that migration stops being a project and starts being a property of the codebase. At 10,000 tools, that is the only shape migration can take.
The watch item for the next year is where the bottleneck moves. As AI codemod generation gets cheaper, the binding constraint stops being the transform and becomes the review surface: who owns the prompt, who signs off on the AST output, and which feature flags get retired on what schedule. The orgs that solve the review problem will out-migrate the ones that solved the codemod problem first.