Aera

Act I — Day zero

What does a design system need when the team isn’t human?

At Yara, a 120-year-old fertilizer company, I led fifteen people, all human. I now lead multiple teams, all agents.

Ahua, the design system I led at Yara, was a people system. Fifty product teams used it because it made their work easier, and the hard part of getting them there was never technical. Diverse global product teams had to agree to speak a unified design language.

Our definition of a team has shifted dramatically in the past two years, and so has who counts as a collaborator. In the teams I lead now, agents write the code and I decide what ships. In this new reality, a design system becomes the first, last, and only line of defense against AI slop and miscommunication.

A designer looks at a frame and understands what was meant. Padding reads as intent, a wrong blue reads as a mistake, and the gap between the two gets resolved by somebody who has seen a thousand buttons and reads the pattern instantly, against the shared set of decisions we call a design language. That set is what a design system is: a collection of decisions, which blue, how much space, what a button does when it is pressed, made once instead of again on every screen. An agent has none of that. It fills the gap with whatever is most plausible in its training data, in a language foreign to the product. Everything the design team carried as culture, an agentic design system has to carry as contract.

Yet what made Ahua work at Yara became the foundation of my next design system, built for an entirely new kind of collaboration.

Ahua swam so Aera can fly.

Aera stands on four pillars.

Pillar I: Schema as contract

Every design system starts by defining a source of truth. For a long time that was the design, usually a component library and documentation in Figma, and that is where the truth always broke: in the layers of translation between design, code and documentation. A design system for the agentic era had to redefine the source of truth first.

In Aera, every component begins as a declaration of its slots, properties, variants, states, color mappings and accessibility requirements. Everything else, from the code to the tests to the design and the acceptance criteria, derives from it. A schema is a shared language a machine can read and a person can argue with.

Anything that mattered twice became a contract test that fails the build. To an agent a written convention is a suggestion and a failing build is an agreement.

Pillar II: Engines

A schema cannot settle a value. It declares that a component has a background and which role that background plays, and then it stops. What blue, how much space, which size of type, how fast a thing moves: these are the decisions a team argues about for years and settles differently every time it is asked, and that argument is where fragmentation comes from. An agent settles them too, plausibly and wrongly.

Engines settle them objectively. The decision is produced by a rule instead of an opinion nobody remembers how it was made, and an agent can read the rule. A color engine derives every scale from a single OKLCH definition, with a chroma curve and gamut mapping doing the work that hand-picking used to do, so eight accent hues share one ramp instead of needing eight sets of chosen values. It works per category, because hues carry different inherent brightness: a yellow and a blue at the same nominal step read at different lightness, so surfaces, text, borders, interactive states and signal colors are each derived by their own rules rather than off one uniform ramp. Other engines derive spacing and sizing, the type ramp, and the motion curves. Every value runs from its raw definition, through the role it plays, down to each component.

The engines settle the values. The rules they run on are mine, and so is the final call.

Pillar III: Ontology

The schema defines what a thing is. The ontology defines how everything connects, from a single token up to a pattern, so the whole system can be read as one graph. The graph is generated from the schemas, so an agent can read the whole system before it touches a component, and a change to a token can be traced to everything it reaches.

Pillar IV: Antifragile team

Building a design system is fighting entropy. Frameworks, libraries and product requirements never stop changing, and a system has to co-evolve with the product to stay relevant. Planning and building an entire system from scratch is architecting failure. It has to start as a smaller system that works, on a foundation strong enough to carry what comes next.

That is why the fourth pillar is the team itself. The crew self-improves on purpose: what it learns goes into the agentic playbook, the crew’s skill files and the ceremonies, and into a long-term memory it reads before every piece of work. Its testing assumes that people and agents both hallucinate, so the work is checked whoever did it.

The stack underneath was chosen for robustness and scale.

We set a spine precise enough to grow from, and grew the rest as the product asked for it.

Act II — Volume

How do you trust work made faster than anyone can read it?

The first thing agents take away is your ability to read everything.

Ten roles, one interface. I talk to the Tech Lead, an agent that plans each mission, splits it into tickets, dispatches them as parallel lanes in isolated workspaces, and integrates what comes back. It never writes production code. Each lane is one ticket, one agent, one report, and a lane’s claim that something is fixed is a claim about its own workspace rather than the assembled system. The tickets sit on one board that agents and humans read, so I can take a ticket myself and work in parallel with the lanes. In one of the missions three lanes found the same defect and fixed it three different ways, and the Tech Lead kept one. Integration is where the Tech Lead proves its value.

The process came from the one I established at Yara. Ahua ran on Large-Scale Scrum, holding fifteen people together across multiple tracks: React, React Native, design, content and regional support. Aera runs on LeSS AI, my adaptation of it for a crew of agents. It is model-agnostic on purpose: the AI models underneath keep changing, and a methodology that needs rewriting for each new one is not a methodology. Ninety-eight missions so far, each between one and five days, each running the same five phases: preflight, the lanes, demo, debrief, signoff.

The phases exist to put a person where judgment is required. Preflight decides on every token to be used, because agents never invent them mid-mission. Architecture questions come to me and are never settled quietly. At demo I look at rendered pixels in both themes on a fresh build, and approval is explicit, because a green pipeline is not automatic consent. Automated testing can’t reliably catch the taste issues.

Before I see any of it, the work runs a gauntlet inside the lanes: code review in two passes, an accessibility audit, a QA sweep, then the whole behavior suite against the assembled tree. Findings are ranked, fixed by a lane whose only job is the fixing, and verified again. After signoff an adversarial auditor re-derives every number and every claim in the debrief from the tree and the registry, on the standing assumption that the report is wrong. It has caught miscounts, and acceptance criteria quietly narrowed to whatever had been built. Nothing critical has survived it.

We tried Behavior-driven development (BDD) testing at Ahua and it did not survive the schedule. Writing the scenarios, keeping them true as the components moved, maintaining the step definitions: it was work nobody could justify against a roadmap, and it died quietly. Aera has 801 scenarios and they run against a fresh build on every change. This is where a crew outperforms a human team by the widest margin I have measured. Testing is exactly the work that is valuable, unglamorous and never finished, and an agent does not resent it.

Every mission checks the dependencies and takes the updates. Ahua sat on React 18 for years: the styling library underneath it had been deprecated, the engineers who could have done the migration had been offboarded, and the work never fit inside a quarter. That is the ordinary end state of a design system with no team. Aera is current because staying current is a line in every preflight instead of a project nobody can fund.

Debrief is the retrospective, and it matters here as much as it did with people. There is one after every mission, and a full one whenever the model underneath changes, because a new model behaves differently and the playbook, the skill files and the memory have to be read again against it.

Roughly every ten missions, usually when a new frontier model lands, the crew runs a bigger one. The architecture, the process and everything learned since the last one go back on the table together, and that is where the leaps happen. A method that is never rebuilt against the tools it runs on stops describing the work.

The crew forgets nothing and learns nothing on its own, so the system does the remembering. A mistake is written down the day it happens, and the memory holds ninety-two rules so far, recalled at the start of every prompt. A rule in a file is still prose, and prose can be read, skimmed or skipped. So each learning is pushed as far down as it will go. Anything checkable mechanically becomes a contract test with a proof that it fails before the fix exists. Anything breached as prose becomes a gate, a hook that stops the work until the condition holds. One rule sat green for two missions while a parsing fault made it skip part of the codebase in silence: the sweep found it, the checker was fixed, a test was added using the file that had caused the blindness, and the learning was written down the same day.

A human team accumulates this as judgment and loses it when somebody leaves. Here it accumulates as files with hooks and contracts, and the difference matters. A learning that stays as prose is something an agent might read and ignore. A learning that becomes a contract is something the build runs.

Act III — Evidence

What makes it a production-ready system?

A complex system can’t be built from scratch, it must evolve from a smaller working system. It can’t be generated from a prompt, but must co-evolve with the product.

A production design system absorbs requests from the product team, versions every change so they can adopt it on their own schedule, and stays coherent across a hundred releases. A fix ships with a rendered example that reproduces the problem, a test, a behavior scenario and a changelog entry written in their terms. That machinery is most of the work, and it only pays back over months.

The system and the product grew up together. The Carbon Economy, a coordination platform for carbon markets that I co-founded, has run roughly the same number of missions as Aera has, and because I own the design and the development of both, a need on the product side becomes a component on the system side within days. That is the loop no off-the-shelf system can close. The case for adopting one was always cost: MUI or shadcn were cheaper than building your own. With a crew that arithmetic reverses, and what you get is a system that fits the product exactly.

The platform’s crew reads Aera the same way mine writes it. Before an engineer there files a request, the product’s agents query the live component library directly and check what already exists. The declaration that makes a component buildable by an agent is the same artifact that makes it findable by one, which is most of what “for human-agent collaboration” turns out to mean in practice.

Verification cannot depend on a person reading all of it. 801 behavior scenarios run against a fresh build on every change. Contract tests assert the architecture. Accessibility is WCAG 2.2 AA with measured contrast and keyboard walks driven from the test suite, and the automated audit finds no violations across 1,218 examples. There is more test and example code in the repository than production code.

None of that replaces looking. Several defects passed every automated gate and were caught by a person in front of a screen: a component that rendered plausibly while carrying no styles at all, a documentation override quietly restyling tables. So the standing rule is to render pixels in both themes, because a computed style can be correct while the result is wrong.

Then the pipeline is green, the review is approved, and the agent stops. I merge. The release engineer versions the change and publishes the release. The scrum master runs the signoff, cleans the board, and the crew is ready for the next mission. Another flight has landed.

A design system of this breadth is, by a bottom-up estimate, three to five person-years of work for a human team.

The crew has no taste. It will build exactly what the system says is good, at a volume one person could never produce, whether the system is right or wrong. All of the risk moved into the system, and that is a design problem.

At Yara the delays came from waiting: for funding, for developers, for a reorganization to settle. Agents remove the waiting. They do not decide what to build or how to build it. If you build it, they still won’t come.

A design system is a collaboration framework. The collaborators have changed, and the systems have to change too.

Aera is in production. The Carbon Economy is built on it, and it ships every week.

Aera marks a new era in product development, one where design, systems and product ship in sync. It lets a team build the thing right. Building the right thing is still a human domain.

Preview the Aera Storybook

Design System Lead

Alexander Toporov

Crew

Tech Lead · UX Engineer · QA Engineer · A11y Expert · Code Reviewer · Technical Writer · Release Engineer · Scrum Master · Adversarial Auditor