Building Arbor · Part 5

Foundation before intelligence

Steven Neamonitakis

Vertical section drawing of a low building. A single grade line separates above from below. The superstructure above is drawn thin and schematic. The foundation below is drawn with much greater care: stepped footings with rebar cross-sections, dense hatched soil, articulated concrete. One continuous vermillion line traces a returning circuit around the drawing, entering from the top of the superstructure and closing back into the foundation.
The foundation gets the careful drawing because everything above it depends on it. Build that first, then add the AI. Illustration made with an image model.

Part 5 of Building Arbor, a series about my year on Linktree’s design system.

The Figma plugin brought the system to designers, and the conductor put every source of truth behind one front door. That left the place engineers make the call: the pull request.

A reviewer in the pull request

I built a reviewer that read pull requests against Arbor’s guidance. When the code didn’t match, it left a comment on the line in question saying what to change and why. It didn’t say “this doesn’t follow the system.” It gave the specific fix, right where the engineer was already looking.

The idea came out of auditing Arbor against the best systems in the field, which showed a gap in our own workflow. It’s the same instinct as the rest of this series: take what the conductor knows and deliver it where the decision happens, while the change is still cheap to make.

Checking that the guidance was true

Putting guidance in front of people and agents raises a harder question: is the guidance right?

We built evals to find out. They measured whether the guidance changed what a model actually produced, and a check in CI asserted that the guidance itself was true, not only that a model had followed it. A model that follows a false rule is worse off than one that ignores it. The evals caught a few claims in our guidance that weren’t true, and we fixed them.

Order of operations

The lesson I’ll carry into whatever I build next is about order of operations.

More and more of the code in a system like this is written by agents. That makes the foundation matter more. AI amplifies whatever foundation it’s given. Solid tokens, real alignment between design and code, and thorough documentation give it something to build on. A messy system just gets messy faster.

So the biggest risk wasn’t technical. It was trying to scale AI before the foundation could be trusted. The researcher’s audits were only reliable because the system was reliable first. Build the foundation, then add the intelligence.

What I’d tell a team building this today

Three things, because I watched them pay off.

Documentation is part of the system, not something you add later. A component isn’t finished just because it renders. It’s finished when the team knows what it is, when to use it, and just as important, when not to.

Tokenize the repeatable decisions. A value repeated by hand drifts. A token is the same decision made once, in a place where changing it changes everything downstream.

Keep the decisions in the open. When the “why” behind a choice is easy to find instead of living in one person’s memory, the system can grow through contribution instead of splintering.

Where it leads

A design system built this way stops being just a component library and becomes the foundation for AI-assisted product development. Teams get from intent to implementation with far less translation and rework, and things stay coherent even when they move fast.

Working on the layer that lets a system see itself clearly and hold itself to the frontier was the most fun I’ve had building anything. Thanks to Linktree and the Arbor team.

Up next