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 whole architecture. You chase collaboration, wanting to build with others to bring it to life, but you repeatedly hit a wall where that collaboration is simply unavailable - whether due to limited developer bandwidth, competing priorities, or organizational constraints that leave intent that is obvious to you opaque or deprioritized in the larger roadmap.

I hit that wall several times during a long time. I worked around it not because I wanted to build alone, but because the alternative was letting the ideas die. I built things myself out of necessity - high-fidelity interactive prototypes, VR experiences, and custom embedded devices. I wanted to understand the truth behind each human interaction. Great for prototypes and try-outs, limited by what I could sustain alone, but it made the concepts real and served well to give me the insights I needed.

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

Illustrations by Storyset

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 with me?”

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 and collaborative - 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 hitting walls of unavailable collaboration.

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 designed, something became available that hadn’t been before: the ability to build at the speed of the vision, bypassing the bottlenecks of unavailable resources and long queues. Full autonomy, not as an aspiration, but as a practical reality that keeps the building momentum alive and elevates the creativity.

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

The Thing I Was Always Trying to Build

Illustrations by Storyset

For as long as I have been designing, I have been trying to answer a different kind of question: why is there no shared foundation when we implement the same design across different platforms?

Rebuilding a component for the web, mobile apps, embedded displays, or wearables is a technical necessity. Each platform requires different tools, languages, and specialized expertise. But while the visual intent remains identical, the underlying specs, execution rules, and core behaviors are recreated from scratch on every surface. We lack a shared contract, leading to misalignments and translation losses because there is no unified source of truth guiding the implementation.

I have the presentations. The same interface promise 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 architecture underneath. Every platform is a silo. Every hand-off is a translation loss.

I tried several ways to bring design and code closer, from detailing specs and guidelines (Excel files, flowcharts, Flash and ProtoPie mockups) to integrating code directly into design tools (Framer, UXPin Merge, Supernova exporters, Figma Plugins). My latest and current attempt: AI agents.

The answer I kept returning to was tokens. I was hunting for the semantics - not a component library, but 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. Since I hit the collaboration wall, I needed to find a way to bridge the gap.

Bridging the Gap: Design-to-Code

While Horizon encompasses multiple architectural layers (including design language, scenario engines, screen hierarchies, and multi-device combinations, etc). Horizon itself is designed for modularity and flexibility, supporting thousands of distinct scenarios and product combinations, similar to smart home systems but built for the outdoors.

Horizon also addresses the normalization of designs to the company’s development capabilities, focusing on enabling reliable implementation while maintaining an acceptable UX baseline under varying constraints, while adaptable enough to evolve and scale.

To bridge the gap between design and implementation, and AI handoff, I established the Design-to-Code pipeline. This is where the AI agent moves from a magic black box to an scalable workflow. It stands as the absolute antithesis of vibe coding - the reactive loop of throwing prompts at a model and hoping it works. Vibe coding creates fragile, unmaintainable patches. If you ask an AI agent to write platform-specific code directly from a raw design file, it will hallucinate: it misses token mappings, ignores layout constraints, and hardcodes values.

In contrast, the design-to-code pipeline enforces strict, deterministic boundaries ingesting raw design nodes, maps variables to a unified token vocabulary, and outputs a platform-agnostic specification layer. This specification is not code. Instead, it serves as the ultimate source of truth.

When the AI implementation agent receives this spec, it is not guessing token bindings or visual rules. It is primed with a validated, compressed, and token-mapped foundation. The AI agent can then focus its reasoning entirely on what it does best: authoring clean Svelte web components, React views, or embedded LVGL display code that conforms strictly to our design system.

By establishing explicit contracts at each boundary (from extraction to validation), the pipeline guarantees 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, 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. Unified and seamless UX across different platforms and contexts.

That is what all the infrastructure is for. The context design, 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.