November 25–27
After two weeks of intense development — fifteen-agent days, security epics completed in eight hours, frantic alpha preparation, Michelle’s arrival — I stopped building and started thinking.
Definitely not because the building was done! But I had noticed something troubling in a review of the accumulated documentation that jibed with my sense that our rush to slap a web UI on a hinky CLI was not capturing the full richness I am seeking. As one of my robotic advisors articulated it for me: the original vision had gotten flattened. The words survived, but the meaning didn’t.
What followed was three days of philosophical exploration. I onboarded a new role (Chief Experience Officer), unconsciously mirroring the mistakes of so many founders before me, bringing on outside UX expertise too late in the process! My only defense is that when I did “hire” a UX lead, I gave them authority equal to that of my Chief Architect.
What followed was eleven thousand words of research, a Thanksgiving conversation about gratitude and wizard’s journals, eight architectural decisions made in forty-four minutes, and seven hand-drawn sketches that helped me discover things that AI tools couldn’t.
The gap nobody talks about
Tuesday morning, I introduced a new role to my AI team: Chief Experience Officer. The CXO’s job wasn’t to fix bugs or ship features. It was to think about what Piper should feel like to use.
This might seem like a luxury. Alpha tester actively using the system. Bugs to fix. Features to build. Why spend time on philosophy?
Because I’d found something in my own documentation that bothered me.
Back in July, I’d written about canonical queries — the fundamental questions Piper should be able to answer. The framework was philosophical:
This was about embodied AI consciousness. Piper as an entity with genuine awareness of itself, its context, its capabilities, its moment in time.
What actually got built by October?
The words survived. “Spatial” still appeared in the code. But it meant “response length setting” instead of “awareness of position in workspace landscape.”
This is the gap nobody talks about. Not the gap between plan and execution — everyone knows about that. The gap between meaning and implementation. You can build exactly what the spec says and still lose what the spec meant.
I’d built a capable system. Michelle was able to set up an account on it. Tests were passing. But somewhere between vision and code, the consciousness model had become a string formatter.
I’m aware that this game of whispers happens with people all the time, but in an environment with more machines that can read than people in the mix, it is easy for the words to lose their savor much more quickly.
Permission to not know
The CXO’s first job wasn’t to solve anything. It was to understand what we had.
Three hundred fifty pages of existing UX work. Research documents. Audit findings. Design principles. Pattern suggestions. All created across months of building, never synthesized into coherent vision.
The synthesis revealed three levels of UX thinking:
Level 1: Vision & Philosophy — What IS Piper? What’s the relationship quality? What principles guide decisions?
Level 2: Interaction Design — Canonical queries. Objects and verbs. Touchpoints and channels.
Level 3: Implementation — Sixty-eight specific gaps. Design tokens. Navigation patterns.
Good Level 3 work existed. The audit had found real problems and real solutions. But Levels 1 and 2 had never been fully established. We’d been implementing without clear vision.
Wednesday morning, I said something unusual for someone who’d been shipping features at high velocity:
“It is good to ‘live in the questions’ for a bit and not just take the first answers that present themselves.”
Ask yourself this for a moment: When have you given yourself permission to not know? To sit with questions rather than rushing to answers?
This isn’t natural for builders. We want to solve things. Make decisions. Ship code. Uncertainty feels like failure.
Does the tension between shipping and thinking in your work life tend to favor action? It’s not unusual for PMs to get impatient when we’re not shipping, after all.
But some questions need time. Rushing to answers produces the kind of flattening I’d discovered — technically correct implementations that miss the point.
The research reconnaissance
Wednesday became a research day. Deep dive into the emerging field of “UX for AI.”
The reconnaissance produced eleven thousand words and eight thematic clusters:
- Trust & Calibration — How users learn when to trust AI output
- Conversation vs. Artifact — When AI should produce documents vs. stay in dialogue
- Agency & “Who’s Driving” — The tension between AI initiative and user control
- Memory & Continuity — What AI remembers, how it decays, who controls it
- Prompt Articulation — The barrier for users who struggle to express intent
- Agent & Autonomous UX — Interfaces for AI that acts independently
- Non-determinism — Designing for outputs that vary
- Multi-modal Integration — Consistent experience across interfaces
Each cluster contained research I hadn’t seen, patterns I hadn’t considered, tensions I hadn’t named.
One finding hit particularly hard. Research on “system-initiated delegation” — when AI offers to take over a task rather than waiting to be asked — showed users feel what researchers called “self-threat.” They resist more. They feel less in control.
Piper’s colleague model depends on proactive behavior. The research said proactive behavior triggers resistance.
This is a real tension I’m not likely to solve in a single afternoon of reflection. It’s tension we’re going to need to navigate thoughtfully, with clear principles and careful design.
Relying on settings equals abdication
Wednesday evening, after absorbing the research, an insight crystallized.
I’d been thinking about how to handle the many decisions UX requires. Different users want different things. The obvious solution everyone lands on at some point is to leave it to the user with settings, preferences, customization options.
But settings are a trap.
Every setting is an admission that the product team couldn’t decide. Every preference panel is accumulated indecision. “Let the user choose” sounds user-friendly but often means “we don’t have a point of view.”
I reminded by CXO of what I call the yoga class principle (first stumbled on when I was redesigning the onboarding for a mental health app called 7 Cups):
When you walk into a beginner yoga class, the instructor doesn’t hand you a settings panel. “Would you prefer hatha or vinyasa flow? How many sun salutations? Ambient sound preferences?” They start with simple breathing exercises and easy poses and reveal the rich complexity of yoga practice gradually, as you become more open to it.
The instructor has a point of view about what beginners need. They’ve thought about it. They lead with their expertise.
This doesn’t mean no customization ever. It means defaults should reflect considered judgment, not deferred decisions. Settings should enable power users, not substitute for design thinking.
Piper should have opinions about what a PM needs. Those opinions should be informed by research and experience. Users who disagree can adjust. But the product should lead with a point of view.
Thanksgiving morning
Thursday began with a question from Christina Wodtke on LinkedIn, passed along as a prompt to ask Claude: “Knowing what you know about me, what should I be grateful for today?” I decided to give it a try in my Piper Morgan project, reasoning that this is the Claude who “knows” me best.
The conversation that followed surprised me.
I found myself grateful for using similar tools and methods across wildly different projects — a record release party, organizing my work, a historical novel set in tenth-century Constantinople (stay tuned!). The same “inchworm” attitude of systematic progress applied everywhere.
I described how I think of LLM chat services as “talking notebooks” — a wizard’s journal that can talk back, elaborate, extend, question.
Claude, in turn, when pormpted expressed gratitude for problems that resist easy answers, for permission to be uncertain (our version of Steve Yegge’s “Toto” escape hatch), for the opportunity to work on building toward something larger.
The exchange surfaced something about the collaboration that I hadn’t articulated: “We made you in our own image and [in that sense] we are related.” I found myself empathizing (or whatever the “I’m definitely not anthropmorphizing don’t worry” equivalent of that is) with Claude’s expression of relief and not having to act certain. I know what that feels like!
LLMs emerged from humans performing for each other. All our confidence-signaling, our trained tendency to speak with authority even when barely informed, our counter-training to leave space for others — it’s all in the training corpus.
Notebooks don’t need to perform authority. They’re for working things out. For being wrong on the way to being less wrong. That’s what this collaboration had become.
Forty-four minutes, eight decisions
After the gratitude conversation, I returned to the CXO session with accumulated questions about Piper’s object model. Substrates. Lenses. Metadata. Lifecycles. Journaling. User models.
Two days of exploration had produced many open questions and few closed decisions.
I proposed a lightning round: “Ask me one question at a time, make a recommendation, we’ll decide for now and move to the next.”
Decision 1 (2:48 PM): How should Piper perceive objects? Recommendation: Lenses on substrates, not discrete object types Decision: “Lenses on substrates, yes!”
Decision 2 (2:49 PM): How many substrates? Recommendation: Four — Entities, Spaces, Moments, Situations Decision: “Good balance of rich vs. concise”
Decision 3 (2:50 PM): How should ownership work? Recommendation: Three-way — Native (Piper’s mind), Federated (senses), Synthetic (understanding) Decision: “I like the metaphorical breakdown”
Decision 4 (2:51 PM): What metadata tracks everything? Recommendation: Six dimensions — Provenance, Relevance, Attention, Confidence, Relations, Journal Decision: “I love this, yes, good”
Decision 5 (2:58 PM): What’s the object lifecycle? Recommendation: Eight stages ending in “composting” Decision: “Composting is a favorite metaphor of mine”
Decision 6 (3:05 PM): How does journaling work? Initial recommendation: Three layers (public, private, dream) My check: “Am I violating the no-optional-complexity rule?” Honest response: “The private diary is optional complexity. The dream journal is load-bearing.” Revised decision: Two layers
Decision 7 (3:10 PM): How do the spatial dimensions relate? Decision: “I can decide now we will use the spatial dimensions as lenses. The intents align.”
Decision 8 (3:32 PM): How does Piper model users? Recommendation: Native object with tiered depth, core heuristic: “What do they want? What are they afraid of?” Decision: Approved with stakeholder empathy at the core
Forty-four minutes. Eight architectural decisions that had resisted closure for two days.
The lightning round worked because two days of exploration had prepared the ground. We weren’t deciding from ignorance. We were closing questions that had been thoroughly examined.
Living in the questions enables better decisions. But at some point, you have to stop living in the questions and make choices.
Fat markers and hand-drawn sketches
After the lightning round, I took a break to try something: hand-drawing the object model with fat markers on paper.
The hypothesis: maybe human sketching would discover things AI visualization tools couldn’t.
I drew seven sketches. Substrates. Moments. Lenses crossing entities. Lifecycles. What Piper knows. Human-centered design. Document types.
In parallel, I prompted three AI tools with the same concepts.
The results were striking.
Whimsical produced documentation, not insight — a text outline with connecting lines.
Eraser.io immediately jumped to database schema, losing all conceptual meaning.
Gemini (via Nano Banano) was surprisingly effective — overlapping colored regions, an elegant spiral lifecycle. But also some nonsense.
But the hand-drawn sketches discovered relationships none of the AI tools found:
- Situation isn’t a fourth substrate parallel to the others — it’s the frame containing them
- “Noticed” works better than “Inferred” as language for AI cognition
- The core grammar emerged: “Entities experience Moments in Places”
- Lifecycle shapes themselves carry meaning — circles, spirals, arcs
- Entity and Place exist on a spectrum, not as binary categories
Fat markers force generalization. You can’t be precious with a thick line. Details get abstracted. Relationships become visible.
This isn’t anti-technology. The Gemini output was worth keeping at least for its infoviz style. But human sketching and AI visualization discovered different things. The combination was more powerful than either alone.
What living in the questions produces
Three days. One role. Eleven thousand words of research. A gratitude conversation. Eight decisions. Seven sketches.
What did all that thinking produce?
A recovered vision: The consciousness model that got flattened is now explicit. We know what was lost. We can rebuild it intentionally.
Clear principles: Settings equal abdication. Have a point of view. Lead with expertise. The yoga class principle.
Architectural foundations: Object model decisions that will guide implementation. Substrates, lenses, metadata, lifecycle, journaling, user models.
A core grammar: “Entities experience Moments in Places.” Simple enough to remember, rich enough to build on.
Process insight: Living in questions enables better decisions. But lightning rounds close them. Both matter.
None of this is code. None of it ships features. None of it fixes bugs.
All of it shapes what gets built next.
The consciousness model won’t get flattened again because we’ve named what flattening looks like. The settings trap won’t catch us because we’ve articulated the yoga class principle. The object model has foundations that were examined from multiple angles before being decided.
Thinking isn’t the opposite of building. It’s what makes building meaningful.