Luke Wroblewski gets at something that’s been gnawing at me for years: Figma as the source of truth gets stale as soon as it’s handed off. The code, the final user-facing screen in the browser or on their device is the source of truth.

I’ve seen the same pattern play out… design teams invest a lot of time in creating a system, then struggle to keep it up to date as the actual product evolves. Inevitably the design system ends up describing a product that no longer exists.

But now with AI agents, he argues, there’s another way:

When agents write most of the code, the design system can become part of what I’ve called the AI steering layer: the context that keeps every website update aligned with brand, design, and development guidelines. Put simply, a design system for agents is a steering layer for a site’s design and front-end code.

With AI agents, anyone on a team can update a website. Marketing adds landing pages, engineering adds docs, a PM tweaks the pricing page. Each of their agents will happily implement its own tone and voice, colors, spacing, etc. unless something steers them toward a unified whole.

That’s the case for collaborative steering. A design lead and front-end lead define the grid, fonts, colors, spacing, and components once, and everyone’s agents are “snapped to” it. The team keeps shipping and the site keeps its integrity.

Agreed. It’s DESIGN.md and other related brand, style, and design system context. Still need a design system though and shared components that live in the code.

I was lucky enough to spend some time in Brazil a few weeks ago, including two days in São Paulo. What a lovely, vibrant city.

Elaine Ramos in It’s Nice That profiles the graphic design scene in the city. One of my favorites from her article:

…the identity created by Sarau for Bar Ovo in 2024 draws directly on lithographic labels – especially cachaça labels – matchboxes and other packaging, and advertising from the first half of the 20th century, with its profusion of frames, shadows, and line gradients. Pedro Almeida, one of Sarau’s partners, tells me about the reference in the original brief – the collection of chickens that inspired the owners to name the bar – and their concern with giving it the feel of a Brazilian boteco, an unpretentious neighbourhood bar (hipsterism by the book…!).

As the largest metro in the Americas, São Paulo is sprawling and constantly building. More business-focused and forward-looking than its older rival, Rio, this city is about progress over preservation.

Ramos again:

This nostalgic wave is neither new nor unique to São Paulo. Much has already been said about hipsterism and its endless pursuit of the genuine, the local, and the organic, only to be quickly absorbed into the mainstream. But in a city averse to any notion of preservation, shaped not only by rampant real estate speculation but also by a deeply rooted culture of constant renovation, where only a handful of bars have survived for decades largely unchanged – the truly authentic ones – this emulation of tradition takes on an ironic edge.

Graphic designers are left with the difficult task of manufacturing the signs of authenticity and symbolically reconstructing the memory erased by this constant transformation, giving each new bar a distinctive character that can attract its audience and restore something of the affective life and sense of belonging the city has swallowed up. Luckily, some designers are finding inventive ways to do that.

Claire Vo on her How I AI podcast gives a plain-language walkthrough of agent loops in Claude Code and Codex. The episode is technical, but the useful translation for designers is familiar: define the job, give it tools, decide what good output looks like, and make the system prove it. Once an agent can run without you, the interface problem moves into instructions, permissions, and checkpoints.

And then a couple other foundational things that I think are helpful when you’re running loops. And why are these things helpful before we get into what they are? They just keep the work clean.

If you are going to be yolo-ing loops all over the place, you’re going to want some consistency in execution, you’re going to want clean workspaces, you’re going to want conflicts resolved and avoided. And so, all these things are really to make those loops effective.

And so, what are the things? They are work trees. I feel like this entire podcast could be Git 101. But work trees are just basically a way to isolate the work, especially the coding work of an agent away from other agents’ work in a sandbox. There are skills, repeated ways to do common tasks. We have a full episode on what skills are from earlier last year when they came out. Plugins and connectors, these are just the tools that your agent has access to. […] Sub agents, both Codex and Claude Code allow you to kick off sub agents. This is just a way to federate out work from the main thread, so that sub agents can do specific tasks, especially validation. And then there’s some way to track state. And essentially just think of this is like a to-do list.

The practical translation for agent orchestration: write the operating conditions around the work before asking for the artifact.

Calling it a loop makes it sound like automation plumbing. The design work is the brief: what the agent can touch, what tools it can use, and how it knows it is finished.

The employee comparison makes the loop feel less exotic:

Now, people are going to ask, “What should I use a loop for?” And when you’re designing loops or designing agents, I say this is the time for the manager. You are designing a job. And so, just imagine that you’re onboarding an employee. That employee could be an executive assistant. That employee could be a customer service agent. That employee could be a software engineer.

Every Friday, EA, I would like you to review my calendar, see who canceled on me, where I could have used my time more effectively, if there are any follow-ups, and send me a Slack to get this done. Um and I want you to do that every Friday. Guess what? You’ve just designed a loop for your executive assistant. […]

So, I really like to think about loops as designing workflows and designing jobs to be done for people. It just happens to be that you can put this intelligent agent against the loop, and then it’s ready to go.

For designers, that last sentence is the translation layer. A designer already knows this move from creative direction: clear constraints produce better work than a blank request. The only difference is that the worker now happens to be software.

A loop without success criteria is just a faster way to make someone review the same ambiguity at a higher token cost.

We all want our agents to work for us on a schedule whenever we want, doing work that we don’t want to do. It’s great. What are some of the problems? One, loops can get expensive. So, I just kicked off an automation that happens on a regular basis. It does wide-ranging work. It decides when to spin off sub agents.

And it does loop-based validation, which means it’s burning tokens until it hits a threshold that it decides is successful. If you do not write that loop well, or your validation criteria is too thin, guess what? Your agent is going to burn tokens. I think we’ve seen this with open claw in particular or some of these agent harnesses is they’re really good at loops. They’re very diligent. They get interesting work done, but man, do they love to burn tokens.

[…] Loop-based prompting is just its own thing. Goal-based prompting in specific is just its own thing because you have to be very precise about evaluation and success criteria. If you are not, you will be very disappointed and use a lot of tokens for not a lot of output.