I encoded my own design judgment into a product. The question is how far that can go before the human parts are the only ones left.
I am a product designer. Nearly two decades in the field, including a multi-year visual brand refresh and a custom CMS design system at Zillow. I started as an individual contributor, became a design manager, and came back to an IC role.
For most of my career, finished meant a file I handed to engineering. Since February, if a UX idea is worth examining, I build it in minutes. That kind of building is almost effortless now, and it is everywhere. The scarce part is no longer the artifact.
How might I encode my own expertise, and isolate the essentially human parts of product design — the parts I enjoy, and the ones that stay most valuable when generation is cheap?
Around October 2025 I started chasing that question. I began with a knowledge base, then loops, then a human in the loop, then a human over the loop. How far that can go is still open, for me and for the design community.
The idea
Aether AI is the larger platform idea. It encodes an expert’s skills, and the process they follow, into an experience — then builds the front end a person would have working with that digitized expert.
A digitized expert does not mean the person is fully replaced by AI.
Design is the first case. AIP — Asset Intelligence Platform — is the suite I built on that idea, and the one I am sharing now. It encodes a designer’s expertise so a startup founder can use it: brand guidelines, on-demand deliverables, and creative artifacts. It stays in the work while those things are made. Brief, rationale, principles, skills, and craft travel with the founder so iteration stays on strategy and on brand.
I trained it on myself first. A questionnaire with more than five hundred answers, written so I can keep updating them as I learn, and so the system can learn from the work. It earns its place when it cues something I already know — old work, a contradiction, a diagram that is slightly wrong.
Brand Builder writes. Journey Builder reads.
The deliverables are encoded judgment. They become the branded relationship a person touches. AIP keeps the reason for each one, and the style rules, rooted in brand strategy, product strategy, and the design system.
Brand Builder writes the system. Journey Builder reads it, so the path a customer takes still feels like the brand. One without the other is a nice surface, or a map that does not feel like the company.
A great product needs both
Brand Builder is the product I demo first. A founder has a short conversation and leaves with a starter brand: positioning, identity, voice, color, type, motion, accessibility, and a design.md handoff another tool can read. I built it solo, evenings and weekends, by writing brand judgment into skills the product loads when a decision needs them.
A skill is one file with a sharp job. How to read a logo. How a color has to function on a real screen. How the brand sounds in an empty state. A prompt configures one generation. A skill is the judgment I can reuse and correct. Sharpen the skill, and every screen that depends on it improves with it.
If that founder already has a logo, they can upload it. The product says what it sees in the mark, including where it is unsure, and the founder confirms or corrects the analysis. That correction is one input. The conversation, the choices they make, and the skills inform the direction too.
Brand Builder. A short conversation, and a brand another tool can read.
Journey Builder is the customer-journey map next to that brand. It is currently in private beta. It connects to TheyDo, a shared journey-map surface, so the team can build on the same path. Product managers, designers, engineers, and marketers drag and drop the next experience their customers need — one that also works for the business. The brand stays with that work. A person still commits.
The path a customer takes, shaped by the team. Currently In private beta.
How the work travels
An illustration-system builder turns one person’s hand into a portable style. The trained weights leave with the owner and can run on another image model, including a LoRA for open-weight models such as FLUX. The work is the judgment before training: what to describe, what to reject, what is good enough. My own system was the first case.
Preview. Message me for a password to test run.
CreaturePrompt — still a working name — is the safe where image prompts are saved, generated, and sent into the Image Library. The prompt sits beside the picture it produced. Walking a finished library is just the UX of that shelf. It is not a separate product. The best of that library is what I curate before a style is trained. This project is also in private beta. If you’d like to view the full experience, contact me for a temporary password.
KeyPrompt is a Chrome extension that places a saved prompt into any text field and then leaves. It stays clear of the page’s own code, so a redesign of that page leaves the keychain working. I shipped it to the Chrome Web Store because I needed it. It became part of how I work.
I also built the platform to host the work, so it is easy to find, update, and share. The commercial question is for another post.
What a person still decides
The system can draft options, gather research, check contrast, ask the next question, and put a review together. A person sets the direction, decides what feels right, keeps the story clear for the customer, and chooses what the team can reuse. A guess stays labeled until someone agrees with it. A correction stays visible until that person decides it should become part of how the work is done.
Write down how the work is done. A person decides. What they change comes back, and the way of working updates. Someone still has to close that loop. Doing the whole thing automatically is later.
People leave with the guide, the design.md, the prompts, and the trained style. They come back because the decisions are still there.
Where it stands
Some of this is still early: one shared picture of the customer that can inform a smarter roadmap, and a way for a correction to make the next round better. Those are started, not finished.
A lot of the commits behind this are not new products. They are me stuck on one piece of interface, going back and forth until it feels right. That obsession is part of the work. A high count is a weak way to judge what got built.
I have tried giving product, design, engineering, and marketing each a say, and leaving room for someone to name what we are giving up. One person can play all of those parts. I have. The best result came when I changed the draft. I still treat that as an experiment.
What I have put into the system so far is myself. Replacing myself with AI means replacing me, personally. The verdict is still out on whether a person’s decisions can be broken into moments, and a small experience built around each one, in a systematic way. That is the question I am curious about.
I encoded myself first. That only proves the loop can close on one person’s taste. The next test is a designer whose judgment I do not already know.
I built this alone to find out if the idea holds. I want the next version with a team, because the work gets better when someone else has to use it. If you need a product design leader who can set that up and ship inside it, I would like to chat.