Horizon

A personal note on why all the infrastructure exists - and what it's actually for.

There is a wall every designer who codes eventually hits.

Not a technical wall. A collaboration wall. You have the vision clearly in your mind. You have the design. You have, over years of stubborn exploration, even the code. But between the design file and the running product there is a gap that requires resources you don't control - developers with available bandwidth, shared context, aligned priorities, and enough patience to translate intent that is obvious to you and opaque to everyone else.

I hit that wall for a long time. I worked around it the way I always have - by building things myself. Flash ActionScript when that was the tool available. High-fidelity interactive prototypes. VR experiences. Custom embedded devices with their own interfaces. Slow, limited by what I could sustain alone, but real. Things that worked. Things that proved the concept even when no one else would build it with me.

The ceiling was never the idea. It was always the hand-off.

After the Limiter Breaks

I wrote about Breaking the Limiter as the milestone it was - the moment AI changed the dependency model. Not faster prompting, not a better autocomplete, but a genuine shift in what became possible without waiting for collaboration. The question stopped being "can I find someone to build this?"

But the new question is not simply "can I be clear enough?" - I already live that version of the problem. Articulating design intent precisely enough to survive a hand-off has always been the job. Anyone who has worked with suppliers who charge for every iteration knows exactly how expensive imprecision is.

The question that actually changed is harder to name. Something closer to: how do you communicate intent that is grounded enough to guide, and open enough that what you learn from building can improve it? Not a specification. Not a vague direction. Something in between that stays honest to the original intent while remaining genuinely mutable - able to evolve when real-world validation reveals something the design didn't anticipate.

I am still finding the right words for it. But it is a problem I know how to work on - which is more than I could say when the constraint was other people's availability.

Then came Context Design - the discipline of engineering what the AI sees, not just what you ask it. The Knowledge Supply Chain. The infrastructure that makes the partnership reliable rather than occasional.

With the limiter broken and the context engineered, something became available that hadn't been before: the ability to build at the speed of the vision, without a team, without waiting, without translating intent through someone else's interpretation. Full autonomy. Not as an aspiration - as a practical reality.

So I started building the thing I was always trying to build.

The Thing I Was Always Trying to Build

For as long as I have been designing, I have been trying to answer one question: why does the same component have to be rebuilt four times?

Once for web. Once for mobile. Once for the embedded display. Once for the wearable. Same intent, same visual logic, same design decisions - rebuilt from scratch by four different people using four different tools, none of whom fully understand what the original design was trying to do.

I have the presentations. The same interface rendered across a navigation display, a mobile app, a wearable, a car screen. The same UI grammar, the same logic, the same user - but no shared foundation underneath. Every platform is a silo. Every hand-off is a translation loss.

The answer I kept returning to was tokens. Not a component library - a design vocabulary. A system where the visual decisions live in one place, expressed as the smallest possible unit of design intent, and consumed by every platform in whatever language it speaks. The same token. The least hardcoded props possible. The same design, everywhere, maintained once.

I called the project Horizon.

Not because it was distant - because it was always there, just ahead of where the tools and resources would let me reach. A horizon is where different worlds meet without either disappearing. Web and mobile and embedded and physical - same vocabulary, different surfaces, no translation loss.

Bridging the Gap: Design-to-Code

To make Horizon a reality, I had to automate the transition from design to code. Most generators target a single runtime - like React for web - which simply recreates the platform silos. Horizon required something different: a pipeline that could ingest raw design nodes, map design variables to a unified token vocabulary, and output a platform-agnostic specification layer. This spec isn't code; it is a declaration of design intent that can compile into web components, native mobile views, or embedded display code.

This became the operational focus of my work: building a deterministic Design-to-Code extraction pipeline. By establishing explicit contracts at each boundary - from extraction to validation - I could guarantee that the generated specifications faithfully reflect our token system. This automated extraction serves as a form of Context Priming, ensuring the implementation agent is primed with a curated, high-fidelity knowledge base rather than noisy design files. It transformed what was once a fragile, lossy manual hand-off into a self-healing engine, freeing the human creator to design systems rather than write translation scripts.

The Unexpected Glue

When I started using Context-Pipe in the Design-to-Code workflow, it was exploratory. An experiment to improve the extraction and validation pipeline for the component library. A lucky exploration, honestly - I was not certain it would hold.

It held. Then it held under pressure. Then it revealed things about the workflow that the old imperative scripts had been silently absorbing - the need for self-healing state transitions, the value of declaring recovery logic rather than coding it, the way a declarative pipeline makes the intent readable to an agent and a human and a shell command equally.

Context-Pipe turned out to be not just a tool in the workflow but the connective tissue of the whole system. The infrastructure that makes it possible to run an automated pipeline from a design file node to a validated component spec that multiple platforms consume - without rebuilding the orchestration for each target.

The design vocabulary flows. The platforms consume it. The pipeline maintains the chain.

The Horizon

I am closer to it than I have ever been.

Not because the technology suddenly got better - though it did. Because for the first time, the limiting factor is not resources, not collaboration, not waiting. The limiting factor is articulation. And that is a problem I know how to work on.

A display on a boat and a wearable on a wrist sharing the same token for an icon colour. A design decision made once, expressed everywhere, maintained in one place. Digital and physical, finally speaking the same language.

That is what all the infrastructure is for. The context engineering, the pipelines, the automated workflows, the self-healing branches - they are not the destination. They are what makes the journey fast enough to actually complete.

The limiter was always the only thing in the way.

The technical workflow that makes this possible is documented in the Design-to-Code use case - the pipeline, the contracts, and the context engineering behind it.