What Makes a Design System AI-Ready? An Interview with TJ Pitre

Over the past fifteen years, design systems have evolved from simple pattern libraries into the backbone of digital product development. But are they truly prepared for the era of AI, radically adaptive, and generative user interfaces? In our interview with TJ Pitre, founder and design engineering pioneer at Southleft, we explore what an AI-ready design system actually means in practice and how to bridge the ever-widening drift between Figma and code. We gain insight into how to eliminate the hidden flaws that cause inconsistencies, and why voice-generated, context-aware interfaces might represent the next level of digital interactions.

Based on your articles and your company's work, it's clear your focus is on design systems, but from a fresh perspective. You've been in this space for a long time, seeing the evolution from early pattern libraries to modern systems. Looking at this journey and into the future, how do you believe design systems need to evolve to be ready for sentient design or generative UI? Essentially, how can we prepare them to support more adaptive and intelligent interfaces?

TJ Pitre: I think this is one of the most important topics that probably isn't being talked about right now. At Southleft, we've always focused on design systems as a core service. We began as a front-end design and development agency, but we couldn't call ourselves a design system agency 15 years ago because design systems weren't an everyday, commonly used terminology. They really weren't even a thing back then. We were calling them pattern libraries, and they were ways we could create modular components throughout the various digital environments we had to support.

Specifically, before I started this business, I worked for Martha Stewart, who had a number of digital properties that all needed to be managed, and the majority of those were under one roof. Some were adjacent to it. So quickly, we had to figure out how to create modular content in the form of what we called modules back then. Now, we call them more like components or composed structures. If you're familiar with Martha Stewart, she's meticulous for organization and has this really vast taxonomy of how to display her work, crafts, recipes, and articles. We wanted to make sure we translated that meticulousness into the digital properties that were managed under my group – I was the director of front-end design and development over there.

The digital properties we were managing usually had some sort of parent-level theme, and the web applications inherited from that theme. This was basically a themeable design system we were creating, but it was architected within one platform. It wasn't as modular as the design systems we create today, but it was the beginning stages of object-oriented programming. The scalable modular architecture of CSS – like Jonathan Snook, Nicole Sullivan, and all these pioneers of object-oriented methods for keeping things simple and not repeating yourself – all kind of lent itself towards what we do today in design systems.

It sounds like those early experiences with modular content deeply shaped your approach. How did that foundation influence the way you build design systems today?

TJ Pitre: The piece after that is we've always done front-end development and design, whether it was a design systems related project or not. The front end of the content management system, a theming layer, whatever it was we were building, we were always building it in this method. Sometimes we would talk about it depending on the client and their understanding of the vernacular. We would mention that we try to keep it simple and not repeat ourselves, making things flexible and modular for editorial layouts. We were doing drag-and-drop interfaces for a long time in CMSs that supported layout curation.

Fast forward to now: the work we're doing is still important. We want to get to a point where we work with organizations and they think of design systems as table stakes. It's like when someone looks for a website these days, it's rare to find a WordPress shop that leads with mobile-first responsive as a service, because you just assume that will be part of the deliverable. We want to get to a point where design systems are like that. We feel our job is to ensure that the majority of organizations venturing into the world of design systems, or who currently have them, have them in a state to be what we like to call AI-ready.

What does it actually mean for a design system to reach that state? What hidden issues do companies usually face when they try to make this leap?

TJ Pitre: We have a method we've been working on with organizations since early last year called context-based design systems. What that basically means is it's a way to enhance wherever your canonical source of truth is, to do a bit of housekeeping. We always use this analogy: your design system is running, but your check engine light is on. Everything seems to be working fine, the car is getting from point A to B, but you're not quite sure if it's a loose gas cap, a blown alternator, or if you just need windshield wiper fluid. Eventually, the cracks start to show. The hard part about not having AI involved in this process is that you don't know when things start to break.

The biggest and most important piece we see when we work with organizations is this bifurcation or drift between code and design. A lot of that could be fixed with two things: steady communication – which can be difficult with large international teams – and acute attention to detail. I'm talking layer names, descriptions for variants in component sets, and, assuming Figma is your source of truth, annotations. All these things should be built into the system to allow places to serve this information from.

Where we are now with this context-based design systems method is that the tools we employ to lint your design system expose a lot of these ugly truths. When we say "death by a thousand cuts," AI shines a light on all those inaccuracies, flaws, or areas where enough attention may not have been provided. It's humbling for a lot of product designers because it shows how much design engineering has gone into the system, but also how much time they were allowed to spend on it. In most organizations, product engineers outnumber product designers ten to one. So sometimes the designer is just trying to make their way through a stack of tasks, and if a layer name is "Frame 1234" instead of what it's actually producing, it happens. But when we're using context-based methods for transitioning designs into code, those are the ugly truths that get exposed and introduce flaws. Context is the big piece you need in order for AI to reduce risk on the output. So, that's the backstory of getting design systems to be AI-ready.

With that foundation set, how does this translate to the actual user interfaces we are moving toward, like the radically adaptive UIs you envision?

TJ Pitre: If we look at design systems for what they've always been, it's a means to an end – the end being the variety of products the system serves, like a mobile app or a website. Eventually, I think we're moving towards this radically adaptive UI. I don't know if I'll quite call it sentient UI, because I think there's always going to be a human wielding some sort of guidelines or rule sets, but who knows.

The part I'm most excited about is this new technology that acts as a layer between where AI sits and where the components are stored. We've been doing this with a tool we created called StoryUI. We needed a way for product managers, product designers, and developers to use a component generation tool inside their Storybook environment. It was similar to v0 or Replit, but living inside the component library that the teams collectively manage. It helped product managers with component inventory, letting them compare variations and states of buttons across all 19 themes the design system supports. Another way to use it was battle-testing composition – using human language to speak into the tool and generate exactly what you asked for. Sometimes it would go off and do something crazy, sometimes it generated exactly what you were looking for. It was strictly using what it was provided: documentation, components, and whatever styling methods were used, like Tailwind or CSS grids.

Story UI interface within a Storybook environment. (Source: Southleft)

That conceptual idea was the first step into ephemeral UI, where AI speaks directly to components based on prompts. The next step we're moving towards relies less on trusting the AI with direct access to components because with 150+ components, there are literally millions of combinations. New technologies like Google's A2UI, Vercel's json-render, or MCP UI act as a middle layer. It's almost like component mapping or contracts – a structured language that allows AI to only access predefined contracts, mapping to composed structures delivered ephemerally based on a user's interaction.

If you imagine a standard ChatGPT interface, you enter a prompt, but these applications aim for you not even to know you're talking to AI. No company would let AI generate their interface without a disclaimer unless they truly trusted the output. Picture going to Airbnb: instead of a complex form with fields for dates, passengers, and filters, you just use human language to say what you're looking for. The AI returns only the results relevant to your input, along with a filled-out form based on what you asked. You've eliminated headaches and gotten exactly what you needed. AI would assemble this layout specifically for you, vetted by that middle layer of human-defined contracts. That's why having an AI-ready design system is the future. We can feel safe with this motion because AI wouldn't be able to do these things responsibly if there were still flawed design systems out there.

If I understand correctly, your current tools identify inconsistencies and accelerate high-quality production, but the ultimate vision is to make it technically impossible to generate an inconsistent interface. Eventually, AI simply won't be able to design something that doesn't align with the underlying system.

TJ Pitre: Correct. The glue that holds it all together is ensuring that your design system is tight. We maintain the design system to be confident that it provides everything AI needs to accurately produce the correct response. We reduce risk through context-based design system methods, ensuring that everything is as tight as it can be in the canonical source of truth. Sometimes people lean more toward code, sometimes more toward the design platform side, but either way, it supports both ends.

Implementing these systems across a large organization must be challenging. For example, a multinational bank might have a functioning design system at its headquarters, but compliance at its global subsidiaries is entirely fragmented. How do you handle situations where enforcing adoption becomes a hurdle – for instance, when headquarters hands it off and pushes a new design system to international teams, but local teams are hesitant to adopt it?

TJ Pitre: Those are organizational issues. The careful rollout of this has to happen from a much higher level, where design system adoption is mandated by stakeholders. It has to be pioneered and evangelized from the very top if these organizations truly want to get their ROI. Design systems are quite expensive and take a lot of resources to manage, so if they want it to be the product accelerator it claims to be, there has to be a carefully orchestrated rollout plan. The reaction from the organization inheriting the system shouldn't be, "Okay, cool, we'll figure it out." It should be, "Yes, I saw this coming three months ago through announcements, and we're ready."

The goal is to accelerate product development and make everyone's jobs easier. If it feels like it's making things harder, that's probably a sign that something needs to be updated back in the core of the design system. We see it a lot where the product engineering team has deadlines to roll out revenue-generating tasks. They try to integrate new updates from the design system but have trouble, so they shove a component in and add custom styles to make it work. They've introduced drift from the original intent to meet a deadline. This drift continues when 100 or 500 developers do the same thing. Eventually, you end up with things that don't match the original layout, and reeling that back in is tough.

A lot of the tools we built help do that. We have the Figma Console MCP, a holistic design systems manager that reviews everything from a macro level. It's a bidirectional tool that detects exactly how far your code has drifted from your design component. It will ask if you want to incorporate the code changes back into the design, or realign the development back to the original design. This requires communication. The designer should understand why it drifted and why the developer didn't communicate the issue. Normally it has to do with deadlines. Ideally, a short-term fix would be made, a housekeeping ticket would go into the backlog, and the developer would discuss it with the design systems manager later. Maybe it was a miscommunication on how a variant worked. They are all better for having that communication. Most of the time, that doesn't happen, and no one is the wiser until the designer opens the application and realizes it doesn't look right. When that happens 50 to 100 times, people start feeling like they have a design system with only 50% adoption because the front-end application has deviated so far from the original intent.

To that point, it seems you need more than just unified visuals; you need unified front-end systems. You can't successfully enforce a design system if the underlying technical layer is constantly deviating, right?

TJ Pitre: It really does start from the beginning. We created a plugin a couple of years ago called FigmaLint. Even before AI was involved in transitioning designs into code, we partnered with other agencies. If another agency scouted a client and subcontracted us to do the design engineering and component structure development, we'd be estimating projects without really knowing what we were inheriting. We'd trust that the organization could build a comprehensive design system and that the files would be ready for development – meaning we'd understand the states, variants, metadata, properties, and conditionals for each component.

FigmaLint's built-in chat understands your selected component and provides tailored advice. (Source: Southleft)

But there was never a process for an under-the-hood check. Everything was visual and manual. People would say, "These are really pretty buttons," but when we got the Figma designs, the metadata panel would be completely empty. We'd see five versions of a button with no annotations. The fidelity differs wildly; some design-focused agencies would score 100 on FigmaLint, while others gave us what felt more like a mood board.

When you are handed a mood board instead of a structured system, how do you manage the friction of translating that into a scalable web application?

TJ Pitre: When estimating web applications like HubSpot or Airtable, the variations are virtually endless. We'd inherit a beautiful picture of a web application, but it was up to us to figure out how things worked together. If we had all the little foundational components broken out – badges, toasts, tabs – they independently understand what they need to do. It became a friction point. We'd have to tell them, "This picture is stunning, but we need you to break it apart into primitive components." It was surprising to them; they'd say, "Can't you just figure that stuff out? You're the developer." We'd find nothing was componentized, and they'd claim that was a developer's job. We had to push back: "No, this is a designer tool, own your platform." We used to just get Figma designs and a Google Doc saying "button hover state, transition .3 ease-in-out." There's an annotation tool in Figma, why not keep it there?

Long story short, FigmaLint helped us with all that. We'd run it, and if it scored 85 or below, work needed to be done. If they had questions, they could Slack us to foster a culture of knowledge sharing, or use a chat tool within FigmaLint powered by an AI called the Design Systems Assistant. It's a vector database full of best practices from industry influencers like Brad Frost, Josh Clark, Dan Mall, and Nathan Curtis. It has contextual awareness of the component being audited, so a designer could chat with the AI to learn why they need specific states like hover, focus, disabled, and default. We never want the designer to feel bad; we just want to use it as a learning tool and cover our own butts so we don't inherit additional work.

While this approach clearly improves internal consistency and reduces costs, how does it directly deliver value to the end user? What does a customer experience differently today compared to five years ago when using an application built this way?

TJ Pitre: As a user, you see a tightly coupled front end. You see that what was in Figma – what everybody agreed on – matches one-to-one with the application you are using. All of the user experience intent, the designer's intent, flows through the design system developers, into the product engineers' hands, weaving through business logic, API calls, and infrastructure, while still matching exactly what was in Figma and Storybook.

To achieve that tightly coupled front end, you often mention the concept of a context cascade. How does that apply when AI steps in to transition design into development?

TJ Pitre: Just like the cascade in CSS, knowledge cascades down from the canonical source of truth. If you have flaws cascading from your design system – missing values, detached components – AI is going to read that. We know AI will have a huge part in transitioning design into development. The best we can do is ensure AI has everything it needs to do it responsibly. When context cascades perfectly, AI grabs that knowledge from the design platform, moves it into a Storybook environment where you validate states and variations, and eventually packages up the most pristine version of the components for production.

What happens when that cascade breaks down or when flaws are accidentally pushed downstream?

TJ Pitre: The cascade can also push flaws downstream. If things don't match up, you build a snowball of things you don't want in your production environment. By the time it launches, it might be too late to correct it in the design system, and you've delivered something misaligned to the end user. Sometimes you have happy mistakes – a rushed layout that wasn't approved by design but performed well in A/B testing. Then you have to decide if the code becomes the new canonical source of truth and needs to be updated back into design. It's a chicken-or-the-egg question.

Considering the rise of conversational interfaces, how do you see the role of traditional visual channels evolving? Are we moving toward a mix of conversational AI and adaptive UIs, or perhaps even no-UI environments?

TJ Pitre: I think conversational AI is a huge part. With ephemeral UI, the original thought is often that people will be typing into a box and hitting submit to display an adaptive UI. However, I see a lot of this shifting toward voice-generated conversational interfaces. For StoryUI, we just built a voice canvas where you speak into your microphone, ask it what you want to generate, and it does it. If you don't like it, you can say, "Let's split that button into a button group with a primary 'Buy Now' and a secondary 'Save'." It thinks for a few seconds and replaces it.

Take that a step further into production applications for users. We're seeing the rise of dictation tools like Wispr Flow. I've been using it since it came out, and I just talk to my phone for everything. If I'm chatting with an AI platform like Claude, sometimes I get the actual UI back. Fast forward six months to a year, when radically adaptive UI techniques start appearing, I expect to see microphone buttons where users can just speak their query into existence. The output will be the precise results or form elements they need.

I'd like to touch on AI hallucinations, which is a major concern for highly regulated industries like banking. In a design system, AI might hallucinate weird component combinations – like building a bizarre castle out of standard Lego bricks. But there's also the risk of data inaccuracy, such as displaying an incorrect bank balance. How do you mitigate these dual risks?

TJ Pitre: I'd separate the two. Content and UI are different problems, and I don't think content is where you lean on AI. Your account balance shouldn't come from a model interpreting a vector database. It comes from a secure, deterministic connection tied to your user ID, same as it does today. That part doesn't change. Where AI helps is the layer on top: it takes the real, verified data and decides how to present it. So the data stays deterministic and trustworthy, and the AI is doing predictive UI, assembling the right components to show what you asked for. If the design system is tight and the data source is solid, you've boxed in where hallucinations can even happen. The model isn't inventing your balance, and it can't invent components either, because it can only pull from the contracts you've defined.

As we wrap up, looking ahead three to ten years, where do you see the intersection of design systems and AI heading? What excites you most about the future of this space?

TJ Pitre: I think voice-generated UI is going to be big. Every time I look past what we're currently working toward, or feel like I've finally wrapped my head around things from an engineering and design perspective, something new comes out that gets me thinking about the next step. It's all kind of TBD right now.

The pace of technology is moving so fast it's difficult to pinpoint exactly where we'll be in three years. There's the AI naysayer with the doom-and-gloom mentality saying sentient beings will take over, but I try to be a cup-half-full kind of person. I see all the good that comes out of it, not just in design systems, but in medical technology and in how it supports and enhances our workflows. I hope the people leveraging these products are benefiting from the AI involved, and that we are all finding ways to wield this heavy sword responsibly. I definitely think there is a place for humans in the next three, five, or ten years. It's an exciting time to be a part of it and to have a seat as a navigator while AI steers us in whatever direction the technology brings us.