How I work

Three and a half years of it at Ubik

I co-founded Ubik Studio and led product design end to end. It was a desktop research environment where agents did the gathering, the reading and the drafting, and the person stayed in the loop at every point of judgment. A researcher opened a folder and it became a workspace: sources indexed locally, agents searching the literature and reading PDFs in parallel, drafts where every claim traced back to a real quote on a real page.

The part I am proudest of is that human control was not a confirmation dialog bolted on at the end. It was load-bearing architecture. Actions were approved in batches rather than rubber-stamped one toast at a time, every review decision was recorded in a trail you could revisit afterwards, and an agent could stop mid-task and say it needed a person. We had a grammar for that, Human Needed, and it appeared in the product because it appeared in the agents: the thesis was written into the system prompts themselves, years before human-in-the-loop was an industry phrase.

What I owned there is most of what I do now. The workspace model, the review surfaces, the evidence and citation UX, and the copy and interaction conventions across every surface. Front-end throughout. The research cycles: interviews, behavioral observation, session replays. On the agent side, the system prompts, the skills, the custom datasets, and the evaluation framework and ARC eval suite we used to train, tune and regression-test both the agents and the orchestration that coordinated them.

It was a large multi-package system by the end: a desktop app, a web gateway, cloud agent deployments and a browser extension over a local-first storage model. 1,038 commits between September 2023 and May 2026, with the design and research that came before the first one. It is a closed chapter now, the builds retired, and I am at peace with that. It was three and a half years spent asking one question in earnest: what does it take to make an AI research tool a person can actually trust?

Two things from it stuck hardest. The first is that Ubik never had a design team or time to keep a spec in sync with itself, so what it had instead was Excalidraw boards nobody ever closed: landing explorations, user story wireframes, screenshots of the running app with corrections drawn straight over them, and the decision written beside the sketch. The second is when to stop drawing. Once my engineer teammate had a framework standing, developing the flow directly in code was faster than a wireframe that could only approximate the constraints that already existed. That is the shift that turned me into a design engineer.

Designing through interaction

What replaced the wireframe is parameterized: versions of a design with the decisions left exposed as things you can move, so the question stops being whether a change reads better on a board and becomes what the change feels like under your hand. Density, timing, how much the system says before it acts. Those are not opinions you can settle in review. They are settings, and you find the right one by sitting inside a few of them.

This is the same instinct as playing an instrument, and I do not think that is a coincidence. I am a self-taught musician and I perform regularly, in front of hundreds and sometimes thousands, on hardware synths and drum machines or DJing. On a synth you do not describe the sound you want. You turn something and listen, and you keep turning until the room agrees with you. Software has the same property and most design process throws it away.

Field work, applied to product

The anthropology is the other half, and I use it on the job rather than beside it. Getting close to the problem means users, product research and session replays, and those come before a design change or a feature addition rather than after one as validation.

The training is useful here for a specific reason. It teaches you that what people say they do and what they do are different data, that both are worth collecting, and that the gap between them is usually where the product is wrong. Watching someone work around your software is worth more than any number of them rating it.

Brooklyn, and a large sheet of paper

I grew up here: in the park, on video games, and ideating products with my best friend. What that looked like at the time was large sheets of paper with every screen drawn by hand, one after another, until the whole thing existed on a table. We were designing flows before either of us knew the word for it. The circle beside this is Bartel-Pritchard Square, where Park Slope meets Windsor Terrace, drawn from the real one and running live.

Right after college that turned into a company, and the paper turned into the boards. Ubik is where the practice became repeatable, and where, as AI arrived, I stopped handing the work off and started taking it into production myself.

A 2000 baby, raised on the future

My dad is a programmer and a gamer, and the thing he has always told me is that to achieve the impossible you have to attempt the improbable. He got me a computer when I was young, and the internet has been a second home since. Being born in 2000 feels specific in a way I have never fully shaken: I got to watch technology change from cyberpunk to sterile, from something that looked like it was made by people who wanted something into a surface with the fingerprints wiped off.

I am also an artist and a perfectionist, which mostly manifests as having a problem with nearly every app I use. That used to be a complaint. AI changed my habits completely and now it is a to-do list. I live in the science-fiction future I was raised to glorify, and the interesting part of it is not that a model can write code. It is that the distance between wanting a tool and having one collapsed. The longer version of that argument is Digital Gentrification.

Small software

I believe in small software: a tool built for one person doing one thing, which is allowed to be opinionated precisely because it does not have to be for everyone. The three below are the ones I open every day, and I open them because I made them.

I browse in something I wrote. Null started as a browser with an AI layer in it and became a better one when I took the layer back out. What survived is six invariants about what the app is never allowed to do behind you, a network inspector, and notes that live with the tab instead of in another app.

I play instruments I wrote, too. akaVST is JUCE plugins for Ableton: oscillators, a ladder filter, a sequencer with per-step parameter locks. Building them is the clearest case I have of what this page is about, because a knob in the wrong place does not read worse, it makes you play something else.

And I wireframe in Blockpad, which exists because of how I work now. It copies a layout out as both the drawing and a compact text payload, so a screen can go straight into a chat. That costs far fewer tokens than describing it, and the model reads the structure instead of my description of the structure.

Where that lands now

I take implementation when the work needs it rather than when the org chart allows it, which in practice means research and the build stay in the same week: what a session replay showed on Tuesday can be a working surface by Thursday, and the surface is what gets tested next rather than a deck about it.

The current version of the Ubik argument is HITL Kit, nineteen installable primitives for keeping a person in authority over an agent, and eval-kit, an evaluation framework where humans do the scoring. Both exist because benchmarks ask whether a model can finish a task alone and deployment asks whether it respected the person it was working with. Those are different questions and only one of them is the product.

One window into the loop is the team test log: real observation turned into concrete changes, kept in the open so you can read the arc rather than the conclusions. The full argument is my paper, An AI Measurement Problem.