Building and Scaling UI Systems for Internal Tools at Meta

Most engineering organizations end up with internal tools that nobody owns: a sprawl of dashboards, admin panels, and workflow apps built during hackathons and internships, each reinventing tables, filters, and forms. Cindy Zhang's central claim is that this sprawl is not a design problem but a distribution problem. A component library only becomes an organization-wide system when the team behind it solves adoption, contribution volume, safe change at scale, and organizational survival — in that order.

Zhang is a front-end engineer at Meta on the internal tool product platforms team, working on internal tooling infrastructure and design systems. She presented this 33-minute, 53-second talk at QCon San Francisco 2025; InfoQ published the recording and transcript on June 11, 2026. The system she describes is XDS, short for cross-design system, a name chosen to express the intent to work across every organization at Meta and deliver one unified way to build internal tool experiences.

These notes report what Zhang presented. Where I add context that was not in the talk — for example, background on the tools she names — it is labeled as such.

What You Will Learn

• How to evaluate an organization's culture, codebase, and existing solutions before deciding whether a shared UI system can take root.
• Why a pilot on a real, well-used product is a stronger adoption strategy than a perfect design specification.
• How Meta runs a contribution community that supplies more than half of its design system's commits, and what that community costs to operate.
• How to change a component API used a million times in a monorepo using JS AST codemods, ESLint fixers, and LLM-driven codemods.
• Which testing and rollout controls make broad UI changes survivable, and why some risky changes still slip through.
• Why a successful grassroots project can still be cancelled, and what organizational structures reduce that risk.
• How a mature, saturated system avoids stagnation by expanding from components into routing, observability, and backend patterns.

Where XDS Started

Six years before the talk, Meta's internal tools were built on top of the web infrastructure and components that had been made for Facebook itself. Zhang describes two categories of gap. The first is functional: consumer social products do not need the complex tables, search and filtering, information density, and layout patterns that operational tooling depends on, so those pieces were missing or weak. The second is aesthetic — she notes the tools simply looked dated. Today, by contrast, internal tools share a component system and library with a more modern look and feel, plus support for the complex components and patterns that tooling actually requires. Zhang credits this to the combined work of internal tooling teams across Meta as well as her own team.

The team's scope has since grown well past a component library. It now also covers routing infrastructure, tool management and observability, and backend systems for building common patterns. The scale numbers Zhang reports are the context for every decision later in the talk:

The ratio at the bottom of that table is the crux of the talk. Ten engineers cannot personally serve thousands of contributors and 10,000 surfaces. Every technique Zhang describes — community programs, lint rules, automation, codemods, kill switches — exists to keep that ratio workable.

Reading the Environment Before Building

Zhang's first lesson is that you should understand your space and its opportunities before you start. Her team's assessment of Meta's internal environment identified several conditions:

• A hacker culture. Internal tools get built during internships, hackathons, or simply because someone wanted to improve their own workflow. Any engineer can build an internal tool with very few guardrails.
• A monorepo, which makes distribution of a shared library much easier.
• Mostly in-house tooling. Meta does not purchase many SaaS solutions, so there was a large opportunity to build an interconnected user journey tailored to the company's operational needs.
• Duplicated effort. Zhang had previously worked on an internal tooling team that kept remaking the same components. Multiple component and internal teams shared this problem, and because they were spread across the company they had poor visibility into each other's work. Centralizing offered real reduction in duplication.
• A risky incumbent. An existing component library was broadly used by internal tools, but it shared components with Meta's external products. Changing a component for an internal-only use case therefore carried risk to customer-facing surfaces. Tool builders wanted to spin up tools quickly and experiment with low risk, and the existing system did not support that.

From those conditions the team derived the qualities of an ideal solution rather than jumping to a design. The ideal system would help Meta build bespoke, interconnected tooling adaptable to operational needs; centralize fragmented efforts and expertise; stay separate from the external design system to reduce risk to customer products; and fit the existing move-fast, hacking culture of internal tooling. Zhang generalizes this: once you evaluate your own situation, you can derive the properties your solution must have.

Getting Off the Ground

XDS began as a grassroots effort by a handful of people who wanted tooling at the company to be better. Zhang is explicit about the failure mode they were avoiding. An earlier attempt at an internal design system at Meta had failed, and in her account it failed because it never got past the design phase — it spent too long trying to craft the perfect design and the perfect process.

XDS took the opposite approach. Two engineers and four designers worked part-time, built the initial system within a single half, and produced more than 100 components. The first component was the token. Her advice is blunt: do not get bogged down trying to create the perfect system, just do it.

Supplementary context, not stated in the talk: a "half" is Meta's six-month planning period, and design tokens are named primitives such as colors, spacings, and typography scales that components consume instead of hard-coded values. Starting with tokens is what makes later theming work possible.

The adoption strategy had three deliberate parts.

Solve hard problems in the first half. The team upgraded PowerSearch, a complex filtering component used across a few hundred tools, to XDS, improving accessibility and usability in the process. Because builders did not want to duplicate that work or maintain a competing version, those few hundred tools immediately had a piece of XDS running the moment the migration completed. This is a distribution trick worth naming: migrating one widely embedded component converts hundreds of surfaces into partial adopters without asking any of their owners to do anything.

Deliver features teams did not already have. The team built a context-based form system that helped manage form state — a need common across many tools — and added genuinely net-new capabilities, specifically dark mode and theming. Net-new features give teams a reason to adopt beyond parity.

Pilot visibly on a real product. The team fully migrated a tool it owned called Butterfly, an if-this-then-that workflow builder used across the company. Butterfly was a good choice because it contained a lot of form fields, had thousands of monthly users, and carried enough complexity to exercise the system while still being achievable. Zhang's framing is that you should pilot on a product with sufficient complexity to prove the system, but bounded enough that you can reasonably finish.

Her summary of this phase: look for the right opportunity to inject a system, solve hard problems in your first half, focus on bringing value to your space, make your work visible by piloting on a well-used product, and do not let the pursuit of perfection stop you shipping.

The Two-Year Crossover

Zhang showed a growth chart comparing XDS against FDS, the component system used before it, and asked the audience to guess how long it took XDS to overtake the incumbent. Guesses ranged from six months to two years. The answer was two years, and the old system's usage stayed fairly flat for most of that period rather than declining.

Two implications follow. First, the practical growth strategy is to target new use cases where teams are already investing effort and energy, because you win by capturing new work rather than by converting existing surfaces. Second — and this is the part Zhang directs at engineering leaders — you must be persistent in supporting the system before you reach the crossover point. She asks the audience directly how long their own company would tolerate work on a framework before it crossed that line, and advises that if you only have a six-month runway you should find a way to extend it. A design system funded on a two-quarter horizon will be cancelled before its adoption curve inflects.

Three Scaling Problems

Reaching over a million imports created three concrete problems, and the rest of the talk maps to them:

1. Everyone needs changes. Every team has unique product needs. The platform team did not want to become the bottleneck for all of them.
2. Every change is a blast radius. When components are used everywhere, any visual or behavioral update can affect many tools at once.
3. APIs are sometimes wrong. The team does not always get an API right the first time, and in a monorepo running a single version, fixing an API means updating every call site at once.

Scaling the Team Through a Contribution Community

The answer to the first problem was to build a community model that encouraged contributions directly into the central system rather than forks and workarounds. The value proposition to contributors included proper reward and attribution: each half the team calls out top contributors in a roundup post.

Zhang lists three benefits beyond raw throughput. The obvious one is that work gets done, and it is immediately useful to the contributing team. The second is bidirectional context sharing — the system team continuously learns what product teams are working on and care about, while product teams see how the system is evolving toward their interests, which builds trust between the two groups. The third is recruiting: many current members of her team were previously contributors to the system.

The contribution process itself evolved. It started simple — send a change and the team reviews it — but grew to accommodate different kinds of contributors and requests. Some framework teams wanted to partner closely on updates together, while some product teams took on more than they could handle and would have benefited from extra coordination and resourcing from the platform team. The team therefore set clear expectations and guardrails for different contribution types.

The results and the running costs are both worth quoting precisely. Community contributions make up over half the commits in the system, which Zhang says essentially doubles the size of her team. But a community is not free: each half the team supports over 150 individuals trying to land changes, and together they deliver around 45 change sets per week that the team has to review. For a team of about ten engineers, that is the real constraint.

To keep that volume tractable, the team leans on automation and self-service:

• Rule-based automation via Butterfly. The same if-this-then-that tool they piloted XDS on is used to set up rules that ensure the team has visibility into every change made to the system and can enforce quality.
• A structured support form. Many support requests arrived without adequate context and required a lot of back-and-forth, so a structured intake form streamlined support and contribution triage.
• An agent for contributor recognition. Zhang says collecting all contributions, reading through the changes, tabulating statistics, and writing summaries for the halfway roundup post used to take her about a week. An agent now helps highlight contributions for demos and roundup posts, significantly reducing the manpower needed to celebrate community wins. This is a good example of automating the relationship work, not just the code work — the recognition loop is what sustains contributions, and it was the part most at risk of being dropped for lack of time.
• Written API guidance backed by lint rules. Learning a large, complex codebase is hard for an occasional contributor, so the team wrote API guidance and criteria for components, thinking through how components should enable particular behaviors or modifications and what the minimum requirements are. Some of this guidance is enforced by lint rules, so contributors see it in the code editor without having to find the documentation. Zhang recommends custom ESLint rules as a way to manage a system at contribution scale and to help new team members learn the codebase, noting that ESLint has a tutorial for writing them.

The pattern here is that documentation that must be sought out does not scale, but a rule that surfaces in the editor at the moment of the mistake does.

Changing Components Without Breaking 10,000 Surfaces

The second problem — blast radius — is severe under Meta's constraints: over 10,000 surfaces, a monorepo running only the latest version of the system, and a change rate driven by both the core team and 150+ contributors per half. Zhang is direct that manually checking every change everywhere is not possible.

The baseline safety net has three layers:

• Comprehensive examples for every component, which can be evaluated manually in isolation.
• Generated screenshot tests for each of those examples, using an internal end-to-end testing framework called just End-to-End. These catch unintended visual regressions.
• Accessibility specification tests for interactive components with behaviors worth asserting.

These checks are part of the expected test plan for any change to the system.

Zhang is careful to say that tests do not catch everything and that reviewers still need judgment. She illustrates with an audience quiz: is adding 1,000 CSS variable declarations to a div risky? The audience said no. It caused an incident — in one tool, including those variables overloaded Chrome's memory faster than normal and resulted in more browser crashes. The lesson is that a change can be semantically harmless and still fail at scale for resource reasons that no screenshot test will reveal.

Because judgment is fallible, larger changes ship with mitigation. Meta has an internal system called Gatekeeper, similar to an A/B testing framework, used to perform gradual rollouts targeting different user groups and to quickly turn a feature off if things go sideways. Zhang's ordering matters: tests catch what they can, review judgment catches more, and a kill switch limits the damage from what neither caught.

Codemods: Changing a Million Call Sites

The third problem is API evolution in a monorepo where everything is on one version. Zhang walks through a real migration.

Around 2021 the accessibility team told her team there were too many headers in internal tools. Investigating, they found that builders were using headings to emphasize text. XDS Text offered a set of types, and because the smaller heading types looked similar to bold text, people reached for them for emphasis. The consequence was that page landmarks were polluted, making it harder for users of assistive technology to navigate.

Supplementary context, not stated in the talk: screen reader users commonly navigate by jumping between headings, so a page where every emphasized phrase is an h4 produces a heading outline that is noise rather than structure.

Fixing this required two things at once: cleaning up landmarks across the existing codebase, and changing how people apply text types in future product code. The design answer was to separate regular text from headings, forcing builders to be intentional about adding landmarks while giving them variants closer to their actual intent.

The migration mechanics are the instructive part. XDS Text was the most heavily used component in the system, with new call sites added every day. The team considered deprecating it, but rejected that because deprecating something used that often would litter the codebase with deprecation flags. Instead, they followed an additive sequence:

1. Add the new Heading component and the new text types alongside the existing ones, changing nothing about current behavior.
2. Write a codemod that maps each old XDS Text type to either XDS Heading or one of the new XDS Text types.
3. Let that mapping also fix the original problem, by converting the smaller headings back into text — so future headings become genuinely intentional.

A codemod is a script that programmatically rewrites source code. Zhang's example transforms component properties using the JS AST (abstract syntax tree), with a migration class doing much of the heavy lifting. Her team also uses codemods for prop conversions, for managing the experimental lifecycle of components, and for migrating older components to XDS.

For engineers who want to build these, she names three open-source resources:

• jscodeshift, the main library for creating codemods.
• ESLint fixers, her favorite approach, because a fixer doubles as a lint rule. That means you can stem the tide of new incorrect usages at the same time as you update existing ones — otherwise a long-running migration races against code being written today.
• AST Explorer, for inspecting the JS AST while writing a codemod.

AI codemods

Zhang adds a newer option. Traditional codemods rely on static analysis of the JS AST to derive context. LLM-based codemods can work across multiple files, read and understand context and intentions from those files, and therefore need less static analysis. That makes much more complex migrations feasible, and Zhang says they are fairly easy to write. The downside she names explicitly is that they are non-deterministic, so you need to be very careful when reviewing them.

That trade-off deserves emphasis for anyone tempted by the convenience. A jscodeshift transform either matches a node pattern or does not, so reviewing a sample of its output tells you something about the rest. An LLM codemod can behave differently on structurally similar files, so review effort scales with the number of changed files rather than with the number of transformation rules.

Designing to avoid codemods

Zhang's last point in this section is that some migrations can be avoided by designing APIs for extensibility up front. Two strategies she found helpful:

• If a component has a large number of optional features, batch those features and create helpers to contain the API signature.
• Avoid Boolean flags when the feature is not inherently Boolean. A variant enum instead of a Boolean allows expansion into more use cases and versions later.

The second is the more general lesson: a Boolean encodes exactly two futures, and the third case always arrives.

Her review of scale management: leverage your community and help them help themselves; set up programs, lint rules, and automation to manage intake; use examples, screenshots, and behavioral testing for components; find ways to build kill switches to mitigate risk; and if you manage a large codebase, invest in learning to write codemods and in designing more extensibly.

Architecture And Data Flow

The system Zhang describes is best understood as a pipeline that turns distributed contributions into safe monorepo-wide change. The following diagram summarizes the contribution, review, and rollout flow she describes.

flowchart TD
    A["Product teams and framework teams
150+ contributors per half"] --> B["Structured support and
contribution intake form"]
    B --> C{"Contribution type
and guardrails"}
    C -->|"Close partnership"| D["Joint work with platform team"]
    C -->|"Community change set"| E["~45 change sets per week"]
    D --> F["XDS core system
1M+ imports, one monorepo version"]
    E --> F
    G["Platform team
~10 engineers"] --> F
    F --> H["Component examples
evaluated in isolation"]
    H --> I["Generated screenshot tests
via just End-to-End"]
    I --> J["Accessibility specification tests
for interactive components"]
    J --> K["Human review and risk judgment"]
    K --> L["Gatekeeper gradual rollout
and kill switch"]
    L --> M["10,000+ internal tools and pages"]
    F --> N["Codemods: jscodeshift,
ESLint fixers, AI codemods"]
    N --> M
    M --> O["Automation rules and
contribution-highlight agent"]
    O --> P["Halfway roundup post
and contributor recognition"]
    P --> A

Two loops are visible. The outer loop is social: contributions flow in, recognition flows back, and that recognition is what keeps the contributor supply alive. The inner loop is technical: every change passes through isolated examples, generated screenshots, accessibility assertions, human judgment, and a staged rollout before it reaches the 10,000 surfaces. Codemods are the separate path used when the change is to an API rather than to behavior.

Surviving Cancellation: From Grassroots to Stable Team

At some point a grassroots, distributed effort must become a centralized, stable team. Zhang's account of why is a cautionary story rather than a theory.

In April 2023, during widespread layoffs at Meta, her engineering team was spared — but they subsequently received a message saying the project was cancelled. She describes this as a big shock, because XDS was still gaining adoption and reach across organizations at the time.

Her diagnosis is about visibility rather than value. The strategy up to that point had put most of the team's visibility with the builders themselves and perhaps their immediate managers. Everyone working directly on internal tools knew XDS; that familiarity did not translate into visibility with upper management, who may not even be aware a grassroots project exists. Zhang's conclusion is that this model carries organizational risks the team had not considered.

Two responses came out of it. The first was the council: a virtual team of contributors from across the company, invited by the platform team, whose purpose is to ensure the system can continue to be maintained and that context is preserved over time, so the system can survive moments like this with more stability. The council is essentially a distributed continuity mechanism — knowledge held in more than one org cannot be deleted by one reorg. The second was organizational: the team ultimately found a new home in a new organization and revived the central team.

Zhang's advice to anyone in the grassroots phase: when forming your team, make sure you have upward visibility and support from leadership, or seek out an area that is invested in your success. A large distributed system has many potential homes in a company, so you can likely talk to leaders to find who is looking to support the space. Organization matters, and a stable structure preserves the long-term stability and reliability of the platform.

Avoiding Stagnation in a Mature System

With adoption saturated, scaling challenges handled, and a stable team in place, Zhang names the next problem: stagnation. A mature system makes it easy to drift into inward-facing maintenance work or to chase the long tail of components that nobody urgently needs.

Her team's response was to reapply the same playbook they used at the start, but with more leverage — this time they had community reach. They asked the community a deliberately open question: what are your biggest challenges with building internal tools?

The answers were not what a design system team might expect. The top themes were not about design or about using the components at all. They were about connecting the UI pieces to the backend and to the surrounding platform. Specifically, builders found routing and preloading too difficult and complex, and they wanted to improve their tools' performance but lacked the ability to observe and debug performance issues.

This reframed the mission. The team revisited its original goal of a single unified solution and applied it to the whole platform rather than only the design system: reviving old infrastructure, consolidating and connecting separate pieces, and using the design system's reach to maintain momentum. Concretely:

• Tools became first-class citizens of a platform. Using their knowledge of the codebase and their codemod experience, the team moved every tool onto that platform. That allowed central data sources to be connected to tools and enabled better observability and management features for tooling.
• Partnerships across the company. The team worked with various platform and tooling teams to deliver connected features and drive programs.
• Patterns and compositions. Beyond individual components, the team built lockups for common page types they had observed. Crucially, they did not stop at templates or components — they made those pages work end-to-end with the backend and routing systems, which is the hard part.

AI-generated internal tools

Zhang notes that emerging technology keeps the space interesting, and that more code is now written by AI. Her assessment is that coding LLMs already do a pretty good job of building UIs, but they need to be taught how to build in a specific environment such as Meta's internal tooling ecosystem. Her team is investing in teaching these models how to build internal tools and in improving their context.

The strategy she reports finding helpful is to generate templates to ground the AI and then work on top of them to make modifications. This aligns directly with the team's existing work on patterns and backend systems: the patterns are the grounding artifact. She says there is more work to do here, but she has already seen designers and non-technical people successfully generate tools.

Her diagnostic questions for a stagnating system are worth reusing verbatim: reconnect with your mission and community to find opportunities; look at how your platform connects with other pieces end-to-end in the builder's flow and what outcomes that produces; set a long-term vision for how your space should change to solve those problems; and work out how to leverage or update the system to get there.

Zhang closes on the community relationship as a virtuous cycle — the platform team's work enables the community to build tools, which enables the platform team to build better platforms — and with the observation that code and designs come and go, but the culture you build sticks around.

Trade-offs And Limitations

• The crossover takes years, not quarters. XDS took two years to overtake FDS, and the old system stayed flat rather than shrinking for most of that period. Any team with a six-month mandate should assume it will be judged before the curve turns.
• A contribution community is not free labor. It doubles the effective team size, but it costs 150+ relationships and ~45 change-set reviews per week to operate, plus the ongoing investment in guidance, lint rules, intake forms, and recognition. Without automation of the review, intake, and recognition work, the community becomes the bottleneck instead of the solution.
• Tests do not bound risk. The CSS-variable incident, where 1,000 variable declarations on a div overloaded Chrome's memory and increased browser crashes, shows that screenshot and accessibility tests do not surface resource-level failures. Reviewer judgment and Gatekeeper rollouts exist precisely because tests are incomplete.
• AI codemods trade determinism for capability. They handle multi-file, intent-dependent migrations that static AST analysis cannot, but Zhang warns that their non-determinism demands very careful review. Review cost scales with files touched rather than with rules written.
• Deprecation is not always available. For a component with a million call sites, flagging it as deprecated would litter the codebase; the additive approach of introducing new components and codemodding onto them was chosen instead. That is more work up front and requires the old and new APIs to coexist.
• Grassroots success does not confer organizational safety. XDS was cancelled in April 2023 while still growing, because visibility sat with builders and their immediate managers rather than upper management.
• Meta's advantages are not universal. In the Q&A, an attendee asked what to do without a monorepo — when you cannot see who uses your components, they may use them in unexpected ways, and you need to make a breaking change. Zhang called this very challenging, noted that most open-source systems handle it with semver but that semver cannot guarantee consumers actually update, and suggested that within a company you can always talk to the affected teams. Her concrete recommendation was to first invest in observing usage, because discovering call sites is the prerequisite for migrating them. She was candid that she does not have this problem herself, so she could not speak to it from experience. Read together with the rest of the talk, the monorepo is doing a large amount of load-bearing work: it is what makes both single-version consistency and codebase-wide codemods possible.
• Overlapping efforts require negotiation, not conquest. Also in the Q&A, Zhang was asked whether expanding into observability and adjacent platform areas ran into competing grassroots efforts. Her answer was that her team was already working on platform pieces many tools depended on, and that the expansion began in collaboration with the other interested teams — a separate org reached out, and the two groups jointly created the mandate. That coupled buy-in meant less friction afterwards. She does not present this as a generalizable method so much as what worked in that instance.

Practical Takeaways

• Audit your environment before designing anything. Culture, repository layout, build-versus-buy posture, and the risk profile of the incumbent library determine what kind of system can succeed.
• Ship in one planning period. Two engineers and four designers part-time produced 100+ components in a half. The earlier attempt that optimized for a perfect design and process never shipped.
• Migrate one widely embedded component early. Converting PowerSearch, used in a few hundred tools, made those tools partial adopters without asking their owners to act.
• Ship at least one net-new capability. Dark mode and theming gave teams a reason to adopt beyond parity with what they already had.
• Pilot on a real product you own. Butterfly had thousands of monthly users and enough form complexity to stress the system while remaining finishable.
• Budget for a multi-year adoption curve and secure sponsorship that survives it.
• Convert contributors into capacity deliberately. Attribution, roundup posts, and clear guardrails per contribution type are what make external commits sustainable rather than a review tax.
• Encode guidance as lint rules. Rules that appear in the editor beat documentation that has to be found, and they help new team members learn the codebase.
• Automate the recognition work, not just the code. An agent replaced roughly a week of manual collection, reading, tabulation, and summary writing per cycle.
• Layer your safety net: isolated component examples, generated screenshot tests, accessibility specification tests, human risk judgment, and a Gatekeeper-style gradual rollout with a kill switch.
• Learn codemods if you own a large codebase. Start with jscodeshift, prefer ESLint fixers when a rule can both fix old usages and block new ones, and use AST Explorer while developing transforms.
• Prefer additive migration to deprecation for very heavily used APIs: add the new component and types first, then codemod call sites onto them.
• Design APIs for extension: batch optional features behind helpers, and use variant enums instead of Boolean flags when the concept is not truly binary.
• Build a cross-org council so system context and maintenance survive a reorg or cancellation.
• Ask your community what actually blocks them. Meta's answer was routing, preloading, and observability — not components — which redirected the team's entire roadmap.
• Ground AI tool generation in templates derived from your own patterns and backend systems, then let the model modify on top.

Key Terms

• XDS (cross-design system) — Meta's component system and library for internal tools, named for the intent to work across every organization at the company.
• FDS — the component system used for internal tools before XDS, which XDS took two years to overtake in usage.
• PowerSearch — a complex filtering component used across a few hundred internal tools, migrated to XDS early to accelerate adoption.
• Butterfly — a Meta internal if-this-then-that workflow automation tool, used both as the XDS pilot surface and later as the rule engine that automates contribution management.
• Gatekeeper — Meta's internal feature-gating system, similar to an A/B testing framework, used for gradual rollouts by user group and as a kill switch.
• just End-to-End — the internal end-to-end testing framework used to generate screenshot tests for XDS component examples.
• Council — a virtual, cross-company team of invited contributors formed to preserve maintenance and context for the system independently of any single org's headcount.
• Codemod — a script that programmatically rewrites source code across a codebase, typically to migrate an API.
• JS AST (abstract syntax tree) — the structured tree representation of JavaScript source that codemods traverse and transform rather than editing text directly.
• jscodeshift — the main open-source library for writing JavaScript codemods.
• ESLint fixer — a lint rule that can automatically repair the code it flags, so it both migrates existing usages and prevents new ones.
• AST Explorer — an open-source tool for inspecting the JS AST while writing codemods.
• AI codemod — an LLM-driven migration that reads context and intent across multiple files, enabling more complex transformations at the cost of determinism.
• Landmark — a structural page element, such as a heading, that assistive technology uses for navigation; overusing headings for visual emphasis pollutes the landmark structure.
• Design token — a named primitive value such as a color or spacing unit that components consume, making theming and dark mode possible. XDS's first component was the token.
• Half — Meta's six-month planning and performance cycle, the unit Zhang uses for build timelines, contributor counts, and roundup posts.

Reference: Cindy Zhang, Building and Scaling UI Systems for Internal Tools at Meta, QCon San Francisco 2025, published by InfoQ on June 11, 2026.