Building Arbor · Part 5

Closing the Loop on Code — and Why the Foundation Comes First

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.
Above the grade line, a sketch. Below it, every footing resolved. The red line leaves the roof and finds its way back down. Made for this series with an image model, not a historical drawing.

Part 5, the last of Building Arbor. A series about my design-system work on Arbor at Linktree.

The Figma plugin closed the loop on design files. The conductor connected every source of truth through one front door. One surface was left: where engineers actually decide — the pull request.

Arbor Doctor

Recommendations matter most when they close the gap between spotting a problem and making a change. Arbor Doctor brought the system’s suggestions directly to the pull request. It could review a pull request, spot where the code didn’t match Arbor’s guidance, and add a clear note about what to fix. Instead of a vague message like “this doesn’t follow the system,” it gave a specific, actionable comment right where it was needed.

This follows the same approach as the rest of the series: gather the insights the conductor provides and deliver them right when and where decisions happen, like during a review or in the code diff, while changes are still easy to make. Not a comment someone leaves after the fact, or a lesson learned once it’s shipped.

Foundation before intelligence

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

In a mature system like this, agents now write most of the code. That might seem like the main story, but it actually makes the behind-the-scenes work even more important. AI amplifies whatever foundation it’s given. If you give it solid tokens, true design-to-code alignment, and thorough documentation, it builds on that strength. If you give it a messy system, it spreads that mess even faster.

So the biggest risk in a system like this was not technical. The real danger was trying to scale AI before building and trusting the foundation. The researcher could only give reliable audits because the system itself was reliable first. Build the foundation first, then add the intelligence — in that order, on purpose.

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. Making the “why” behind a choice discoverable, rather than trapping it in one person’s memory, lets a system evolve through contribution instead of fragmentation.

What it becomes

A design system built this way stops being just a component library and becomes the foundation for AI-assisted product development. Teams move from intent to implementation with far less translation and rework, and coherence doesn’t fall apart under the speed.

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