Design Systems Are the Accountability Layer for AI-Generated Software

Read this blog post and tell me: based on what you know about me and my work, what's useful or relevant here? What should I pay attention to?

https://tangents.brianmccarthy.dev/blog/design-systems-are-the-accountability-layer/

We’re about one year into agentic coding, and it’s completely changed how we work. Whether we’re more productive, and by how much, that’s a whole other debate. The one thing we can all agree on is that we have generated a massive amount of code this past year. Coworkers are telling me they feel like they’re drowning in it.

How do we become accountable for code we never wrote?

Time to accountability

I recently came across a post by Xiangpeng Hao and Ao Li called “Stop Building AI Agent Systems” where they introduce this phrase: “time to accountability.” Like Dennis from It’s Always Sunny in Philadelphia put it: “Here’s the thing: once you throw out a term like that, it’s pretty much fair game. I’m gonna use it a lot.” It’s a great read and you should check it out.

Here’s the short version. Accountability used to live during the coding. An engineer writes code, they’re accountable for it as they write it, because they are the ones writing it. Their thoughts are present throughout the whole process. When it comes time to review, to put their stamp on it, that’s fast. They were there. They made the decisions.

That’s not how it works anymore. The agent wrote the code. You weren’t there for the decisions. Your thoughts weren’t present in the process. So now the accountability shifts to before and after. Before: you architect the solution, you think through the plan, you prepare the foundation. After: you review what the agent produced, you understand the decisions embedded in it, you put your name on it. And that review takes real time, because you’re evaluating something you didn’t write.

That blog post covers some high level approaches for reducing time to accountability. I want to come at it from one specific angle: I’m a design system engineer. And I think design systems are one of the most important tools we have for solving this problem.

Design systems were always an accountability layer

When people hear “design system,” a lot of them think of a Figma file. A brand website with font sizes and color palettes. The brand police.

That’s a huge misconception. A design system is a set of decisions that have already been made. Already litigated. We already debated the padding on that button. We already settled on the correct accessibility attributes, the ARIA labels, the tab index. We already sweated over the hover state and the focus state. It was coded, tested, reviewed, and stamped approved. It’s a sealed box.

And those sealed boxes didn’t happen by accident. A design system represents an enormous amount of human labor and deliberation. Designers and engineers going back and forth. Refining how an interaction should feel. Making opinionated choices about brand, personality, and the kind of trust your users experience when they use your product. That work, that care, is baked into every component. It’s not something you can generate probabilistically. An AI can produce a button, but it can’t produce your button, the one that carries your brand, your accessibility standards, your opinion about how things should work.

A design system is two things working together. It’s the intent, the documentation of the why: the dos and don’ts, the best practices, the copy guidance, the spacing rules, the “use this icon for this purpose.” And then it’s the rendering of that intent into code, the component library with real guardrails. The documentation captures the decisions. The code enforces them. Same input, same output, every time. That’s what makes it deterministic. That’s what makes it an accountability layer.

That was always the promise for human engineers. You use the design system button, you don’t have to re-verify any of that. You’re only accountable for what you’re composing together with those components. The design system handled the rest.

And that contract hasn’t changed. What’s changed is who’s writing the code.

Deterministic vs. probabilistic

Here’s the core tension. A design system is deterministic. Same in, same out, every time. Every engineer who uses the button gets the same button. Every agent who uses the button gets the same button. That’s the whole point.

Agents are probabilistic. That’s what makes them useful. They interpret, they adapt, they solve problems creatively. But a probabilistic system has no opinion. It has no stake in your brand. It’s just generating the most likely output. Without a foundation, it improvises. It’ll hard-code colors, write manual CSS, reinvent interaction patterns. Not because it’s bad at its job, but because that’s what it does. It takes the path of least resistance to a solution. Without guardrails, an agent will just route around your system entirely.

When you give an agent a design system, you’re grounding it. Now when it produces a button, it’s your button. The one your team built. Deterministic. Reliable. Carrying all the decisions that were already made. You’re still letting the agent be probabilistic, and that’s the strength. But you’re constraining where it’s probabilistic. It can be creative about how it composes components, how it solves a problem using the system. But it’s not inventing the building blocks. You’re saying: here’s your foundation, work with this.

Tests aren’t the answer you think they are

Now, some people will say: “Here’s how we become accountable. We have tests. The tests pass. We’re good.”

I want to push on that. Even if you insist on human-written tests, what I see a lot of in practice is circular logic. The AI writes the code. The AI writes the tests. When a test fails, the AI rewrites the test so that it passes. There was no human accountability anywhere in that loop.

And even setting that aside, tests aren’t great for UI. You can test for whether an ARIA label exists. You can test for a CSS value. But can you test for everything that makes a product good? Responsive behavior, micro-interactions, the UX of the thing? That takes iteration after iteration. You can’t capture all of that in a test suite. A design system doesn’t replace tests, but it removes a massive chunk of what you’d need to test for in the first place. The components are already proven. You’re only testing what you composed.

Three futures, same principle

Here’s where I think this is all heading. There are three contexts where this matters, and a design system is the foundation for all of them.

Agents building your product. This is where we are right now. Engineers using AI coding tools to ship features. Without a design system, every piece of agent-generated UI is an open question. With one, you’ve already closed most of those questions before the agent even started.

Your product is an agent. For a long time we tried to put the chatbot into the app. Now we’re starting to put the app into the chatbot. An AI agent rendering real UI inside a conversation, widgets, interactive components, not just a wall of text. If those widgets are generated on the fly, probabilistically, you lose everything: accessibility, brand, reliable UX, the kind of trust that comes from a product that feels intentional. But if you give the agent pre-composed widgets built on your design system, the agent uses them as tools. It’s still probabilistic about when to use a widget and what data to pass it. But the widget itself is deterministic. Designed, built, tested. It’s your product.

Agents using your website. This one’s coming fast. Think about the history of APIs. Everybody built them, everybody used them. Then companies started pulling them back because they wanted people on their actual website. The same thing is going to happen with putting your whole app into someone else’s chatbot. What’s coming instead, through things like WebMCP, is other people’s agents coming to use your website directly, interacting through schemas with defined inputs and outputs. Deterministic contracts. And if that’s what you’re building toward, then the design system component library needs to have already worked all that out.

In every one of these contexts, the design system reduces time to accountability. For the developer building with agents. For the agent rendering widgets. For the agent navigating your website.

Invest now

Everything in software is layers of abstraction. That’s all it’s ever been. A constant is an abstraction. A loop is an abstraction. JavaScript is an abstraction on top of lower-level languages. React is an abstraction on top of JavaScript. Every layer is the same deal: someone already made the decisions so you don’t have to re-verify them. You don’t audit your machine code when you write JavaScript. That’s time to accountability, reduced, at every layer.

AI isn’t a new abstraction layer. It generates our abstractions faster.

And that’s exactly why your abstractions need to be solid. If they’re not in place, the AI is just producing more unverified code, faster. More to review. More to own. More to be accountable for.

If you haven’t invested in a design system, the case just got a lot more urgent. If you already have one, lean into it. Make sure your agents know about it. The future is more code, written faster, by things that aren’t accountable. Design systems are how we stay accountable anyway.