# Holistic design systems for the AI coding era > Source: > Published: 2026-09-24 00:21:16+00:00 At Numeric, we’ve completely changed our tools for designing, as well as who is involved in the design process (spoiler: more than just designers). With the advent of AI coding, our needs evolved in how we work and in the pace at which we ship. In the last year, we’ve moved away from traditional design tools like Figma and come to depend entirely on our code-based design system for designing and prototyping. We believe strongly that a design “system” is not a component library, but the system of tools and practices that reinforce the core purpose of design: to ensure a continuity of thinking throughout the product. The result is a system which supports backend engineers to ship design-compliant features, non-engineers to ship prototypes in actual React components, and a feedback loop to continually reinforce the consistency by baking patterns into the tools we use to code. ## Design at Numeric The most noticeable change in our design workflow has been to embrace a fully browser-based design process. Designers at Numeric work primarily in code now, in fully interactive prototypes in the browser. We now manage all our prototypes as high-resolution apps that are deployed as part of the design system documentation. Internally a Numeric Prototype is a communication tool, like a slide deck, with annotated states. You can advance through the states to see what the prototype author intended; it’s an in-house presentation tool that helps ensure design artifacts are “guided” through the intended path. You can also click “Explore” to interactive version. It’s like our own in-house Figma Make or Vercel v0, combined with features of a simple presentation tool. A Numeric Prototype is the equivalent of a fully annotated interactive Figma design. By prototyping *directly with the same components used in production*, we can structurally keep the design work closer to the actual software product we are building. By building own design tools, we find we are we are able to manage more complex compositions with fewer obvious UI defects, and fewer communication issues. This frees the designer to think about the *non-obvious* defects. The designer can then move up the ladder of abstraction to work more systematically. This has contributed to a boost in the team’s design energy this year. Because each prototype can be inspected to show the full component composition, our communication is more precise and we feel more fluent as new concepts evolve. After a year of intensive building, our UI composition feels more coherent and understandable. For engineers, having a richer design system has reduced the pain of shipping frontend code. We can ship features end-to-end with much higher design polish, without being blocked by last-stage design review. High-level alignment comes earlier, and low-level compliance is enforced by automated checks. For designers, it has meant less toil—no need to maintain Figma as a separate artifact in lockstep with the actual code base. It has also meant less time spent attending to feature-specific design, more time on harder interaction patterns and holistic design questions. For PMs, founders, and others it has meant expressing ideas faster and with greater clarity. The prototyping experience lets us place ideas into a realistic setting that emphasizes the intent of the idea while steering the user toward pre-existing patterns. HOW IT WORKS In practical terms, our design system is one main repository that includes all the tooling needed for the design process. It’s a code-based design system with supporting skills. There is one top-level skill which presents a set of human-facing menus and design skills, including: - `/prototype` is the core skill which guides a user to express an idea using formal components. - `/wireframe` is like prototyping, but with quick low-fidelity work. - `/review` is the skill you use while you are iterating on the idea. It helps guide process, question the brief, and evaluate PRs from the perspective of different personas. - `/audit` skills invoke scripts and linters to evaluate design system conformance. - `/registry` is a skill for the component registry. It consults a central component list with links to documentation and other related skills. On a given feature design workstream, a designer uses a coding agent to work with our primary design system package. The coding agent manages the package installation and has access to a range of custom design skills and tools, and secondary tools installed in other repositories. Team members clone the repo and run `pnpm dev` for the custom prototyping environment, usually driven by Claude or ChatGPT. This approach enables three different use cases for our in-house prototyping workflow: 1. For early design stage: Every design is captured as a prototype in the repo, which is hosted as a dedicated internal documentation space. The primary design interface is a git repository that formally mediates all of the UI in new software. The whole team is encouraged to express product ideas in this standard internal format. 2. For handoff: A prototype is formalized and blessed to become a specific kind of deliverable in an engineering specification. We call these **journeys** to distinguish them from regular prototypes. 3. For execution stage: Engineering uses the design system NPM package with the core component set. This is how the engineering team typically experiences the system, as an installed set of components and agent skills while working on the production app. As product design capabilities extend to more people, it seems more important than ever to have a rational design system that can accommodate more people working together toward clear design goals. OUR MOTIVATIONS The core function of the software product design function is to ensure a continuity of thinking across different parts of a user interface. Absent strong controls, it seems that the most likely outcome of generative AI influence on design is to weaken it. Our view is that the best-case outcome for design adoption of AI is that it clarifies and reinforces the *human intent* of new proposed design solutions, giving the design process more clarity and meaning. From a design perspective, this is the only reasonable approach to designing automations and data products. The nature of a design system is to address these issues by ensuring baseline systematic vocabulary of the design language. The design system *is* a natural place for many kinds of new frontend linters, skills and scripts. But for designers in the software industry, there is little clear guidance and it is an open question how design systems will evolve. ## Typical Design Systems As designers, how did we get here and where is this headed? Traditional graphic design systems are primarily about achieving consistency, doing more with less*.* The most basic form of a design system is simply a style guide. As sets of rules, they rationalize design strategy. When done well, design systems can amplify the identity and meaning of an industrial product. A design system helps us stay true to the higher-level product vision. *NASA example of a typical 1970s design system, essentially a visual style guide focused on brand identity.* *Example Component Library: [ShadCN-UI](https://ui.shadcn.com/), one of the most popular in 2026.* Today, a design system is often based on a set of frontend UI components in Figma and React. Component libraries have the benefit of making the system more consistent. Standardization helps resist agents reinventing the button component, form composition, or other patterns. Today a new category of “Agentic” design systems help bless and formalize patterns and guidelines; they increase rigor by ensuring each component is separately reviewed, documented and tested. Whereas a traditional style guide required a designer to interpret and enforce it, new systems are in code, programmable, usable by everyone. Many systems-minded designers have been very eager to see this workflow mature. As Brad Frost (of [Atomic Design](https://atomicdesign.bradfrost.com/chapter-2/) fame) [said in 2023](https://bradfrost.com/blog/post/design-systems-in-the-time-of-ai/) “AI is a natural design system consumer … The most obvious place to start is AI as a conversational interface to build product experiences.” Frost says that the dream is for teams to be “building in software not in pictures,” and that resonates at Numeric. If we do it right, we get the feeling that we are now around one table focused on the same codebase, and part of the broader engineering design conversation. We’ve found this vision holds up *if* an agent-based design process is grounded in policy and human intent. All the basic building blocks can snap together in validated combinations, as real component trees. Design work becomes more about interpretation and pattern selection. This is good for collaboration, ownership and maintainability. HOW DESIGN SYSTEMS FAIL Design systems can tip into a slow *design system death spiral* when the system becomes more of a burden than a convenience. As developers start to work around the constraints, they collaborate less on the design system. As developer experience of the system gets worse, eventually there will be calls for a big rewrite. AI seems to be able to help with this. But it also can obviously make it way worse. ## Designing with LLMs Out of the box, coding agents can be great for basic design system maintenance and quick frontend fixes. But agents tend to generate solutions without fully analyzing the problem. This creates a new challenge for busy teams when it can be hard to tell how much *human intent* is in a given design change. This seems unlikely to go away as models improve, unless we are more strategic. We are still in the early, naive days of coding agents. It is easy to accelerate software development, but hard to avoid a pattern where patches that create stress on any design process. The risk is, as our colleague [Enoch](https://substack.com/@enochchau) wrote [in the spring](https://enochchau.com/blog/2026/lord-of-agents-master-of-none/): As this paradigm proliferates, the pull requests from product managers and designers will start to get bigger and bigger until the engineers are all but janitors for the AI slop that the rest of the organization outputs. How can design systems help resist this tendency? Most generative UI tools fall into a trap of *expanding possibility space* when we wanted instead to constrain it. Vibe coding is notoriously bad for maintainability, but also meaning and ownership. As more people participate in software design, the need for clear primitives and design principles gets even stronger. RISKS We see several key risks for unconstrained generative design tools: - Lack of clear intent: Many small companies operate without a clear specification for many changes. AI increases pressure on the system by continuing to build even when a design intent is not calibrated or well defined. - Derivative aesthetics: AI design choices will notoriously converge on aesthetics that were popular when the models were trained. The design regresses toward the mean. - Lack of design rigor: AI systems skip problem analysis and rarely “question the brief” or engage thinking in higher-level patterns. This deeply cuts the quality of design decisions. Many problem statements remain unquestioned and actively weaken the design logic. - Lack of ownership: A reduced sense of ownership is a natural consequence of generative code. Those hours spent on the problem are where a lot of the design ownership comes from. This can destabilize the system over time, leading to complex systemic failures. - Weaker execution: With agents, we get more code but it contains subtle errors in UI composition. If maintainability goes down over time, but feature count goes up, we get UI failures over time, creating “UX dead zones” in the app that no one really designed for. This is an expensive design system failure mode. BENEFITS We found that these risks can be mitigated by investing in the guardrails that the design system has always represented, but taking it a couple steps further with eg. our prototyping workflow. AI systems can also help stabilize and improve the design process, *if you point them squarely at the problem*, and use them with intent. Most importantly, AI can *interpret* and *validate* the documented guidelines at the right time, guiding the designer to navigate the rules that encode a design strategy. With coding agents, a developer or designer can get a conformance check or design perspective on any PR, wireframe or conceptual sketch. This is a big win for accessibility and the power of design in an organization. We think this is promising because it is a compounding loop; we can bootstrap increasingly sophisticated design maturity through an ongoing process of reflection. This reflection can now be semi-automated and part of the programmable system, as we build up our frontend evals, skills, hooks and linters. WHAT DIDN’T WORK Design system conformance can be rocky even with a strict component system. Over time we worked to get more conformant results by including more instructions around copywriting, content strategy and tone, as well as rules (frequently linters) around component composition. But it’s been a process and an ongoing experiment. Here are a few things that haven’t worked for us: - Design going straight into PRs on product. Our best work happens in a safe planning space, the prototyping system. - Fully async agents that work remotely. All of our design work still goes through a human with a laptop reviewing in detail. - Strict design review in CI. Too slow and too late. You usually want all conformance checks and design effort in *before* you push, not after you are waiting for CI. - Complex linters. Linting is critical to our setup, but hard to get right; we’ve trended toward making them more strict but for a more specific set of cases. We sometimes use a [lint ratcheting](https://www.notion.com/blog/how-we-evolved-our-code-notions-ratcheting-system-using-custom-eslint-rules) strategy, and always avoid managing linters in any way that blocks engineering. - Long-lived prototypes. They get stale and need maintenance. To mitigate this it seems best to regularly archive them or keep them completely updated, minimizing the ambiguity. This can be scripted. - Migrating older, larger codebases. to completely new components is not something that we have attempted. Our success story was more with a large greenfield project. Overall the trajectory that we are observing is that these can all be addressed with scripts and skills that live within the design system itself in a self-documenting way. Eventually this probably becomes something like an internal “Design Platform” more broadly. It is a programmable substrate, not a set of components. UI maintenance at scale becomes much more feasible, but the role of design has to be taken seriously as an engineering discipline. Instead of just patching visual regressions, we can systematically test and evaluate the workflow. As the product design industry changes under the influence of AI, we expect these new methods will themselves be updated and continue to change rapidly. What remains constant is our interest in designing great experiences and the highest quality software. We want to have more, better ideas and express them more clearly —and it’s just more fun to build software in software instead of images. We are excited about the whole conversation that is happening around this; feedback is welcome. If this is interesting to you, please reach out, [we’re hiring](https://www.numeric.io/careers)!