March 2026 · Q&A format for podcast and interview use
Q: What's the first book you remember that really got to you?
A book called VOR, James Blish, 1958. I read it as a teenager in the Midwest. It's about an alien that crash-lands in the Arctic and turns out to be a living nuclear reactor. Something about that — genuinely alien biology, hard science under pressure, the isolation — just wired something deep.
Q: What came after that?
Clarke's 2001 — I read it before seeing Kubrick's film, which matters. The ideas landed on their own terms before the imagery colonized the imagination. Then Bradbury's Illustrated Man, George Stewart's Earth Abides. I was essentially reading the golden age of SF in something close to real time.
Q: You've also mentioned Shirow — Appleseed and Ghost in the Shell. How did you come across those?
I actively sought out the original Japanese editions after discovering Shirow's artwork while working in Silicon Valley in the 90s. This was before Western translation infrastructure really existed, before the '95 Oshii film made GitS a cultural touchstone. The footnotes in the originals are extraordinary — dense technical and philosophical asides that translations always struggled to convey.
Q: What does your reading life look like now?
I'm a Tsundoku practitioner — I acquire books much faster than I read them. Large Kindle library, heavy deal-hunting. Current authors I come back to include Wil McCarthy, Greg Bear, Linda Nagata, Neal Stephenson. Nagata's Red trilogy is the most rigorous treatment of autonomous weapons and AI-mediated warfare I've encountered. I read it differently now that I'm actually building the systems she's describing.
Q: You started your career as a mechanical engineer. How did you end up in AI?
I had a mechanical engineering degree from Rose-Hulman. Then I moved to Silicon Valley to join Teknowledge as an Apprentice Knowledge Engineer in 1985, working on expert systems. That move changed the entire direction of my career and began a lifelong journey into UI development and software engineering.
Q: What was Teknowledge like?
Xerox Lisp Machines. I had a Dandelion as my primary machine for several years. Interlisp-D. The live, inspectable environment — DWIM, Do What I Mean, as an actual design philosophy. It felt like a conversation with the machine rather than shouting instructions through a narrow pipe.
Q: And then the bubble burst.
I was there when it happened. Xerox Lisp Machines, Thinking Machines, Symbolics — companies that represented the future of computing — vanished overnight once it became clear that general-purpose hardware running C was going to outprice specialized AI hardware on raw performance per dollar. I watched the whole pantheon fall in real time.
Q: How does that experience color how you see the current AI moment?
I'm extremely sensitive to the hype, because I saw firsthand how expert systems failed for the same reason — over-promising and under-delivering. Most people working on AI today weren't born when I was writing knowledge bases at Teknowledge. The scar tissue is real. And the mania today actually scares me — too many people drinking the Koolaid and not questioning the hype. The rate of change alone is disconcerting. It's almost impossible to stay current without devoting a significant portion of your day just trying to stay aware.
Q: After the AI winter, you pivoted hard into UI work. What did that look like?
Raw X-Windows before the toolkits established themselves, Display PostScript on NeXT and SGI, Objective-C. I did a lot of work at the protocol level — understanding the client-server rendering model, the event loop. And I was building teams around it, so I was making architectural and hiring decisions, not just navigating the transition personally.
Q: You built a GUI builder in PostScript. Tell me about that.
I was dreaming in PostScript back in those days — literally visualizing its stack nature while I was sleeping and then implementing it the next day. The builder was an internal tool that other engineers used to realize UIs without needing the deep knowledge I had. That pattern — absorb the hard thing yourself, then build the abstraction that lets others work without needing that depth — that's been consistent across my entire career, honestly. More instinct than conscious choice.
Q: The SGI years gave you some memorable moments too.
I landed an NDA with id Software to port Quake 3 Arena to IRIX — shipped official binaries that ran in SGI's wall demo room. The special-effects team at Weta Digital in Australia actually emailed thanks. After rendering Gollum all day, they'd fire up Quake 3 on their IRIX workstations to unwind. That's one of my favorite stories from that era. Also contributed X11 extensions to the classic maze demo — my name is still in the FreeBSD man page with my original UUNET address.
Q: And then Netscape.
UI development during the browser wars — one of the most consequential periods in the history of software. From there the throughline never really broke. Rich internet apps at Sapias — custom map rendering of vehicle locations before Google Maps existed. Then a decade at Demandbase evolving through Flex, AngularJS, React and Redux. Every stop refined the same question: how do you keep the system live, inspectable, and honest while the hardware and hype cycles change underneath you?
Q: You've been at Cox Automotive for seven years. What's the arc of that work?
The first phase was portfolio-scale composable UIs and web components — Lit, Stencil, design systems, portfolio-wide standards. Then in 2025 it converged into something bigger: a complete declarative UI platform where a single YAML spec is the source of truth.
Q: Walk me through how it works.
Five MCP servers working in concert. Juris is the core reactive runtime — it parses the YAML, manages state, generates previews and exports. A Tailwind server generates CSS on the fly. An SVG server resolves icons from an 18,000+ icon library using a unified family::name:variant syntax. Lit and Stencil servers export the spec to production web components. Everything is dual-protocol — full MCP for LLMs and clean REST for browsers. Agents and humans use the exact same services.
Q: Why YAML specifically?
Declarative, human-readable, and it maps naturally to the kind of spec-first thinking I've been doing for forty years. The runtime is deliberately deterministic — once the YAML is fed in, there's zero probabilistic behavior left. The probabilistic part stays in the authoring phase where the LLM is helping generate or edit the spec. That separation matters a lot to me.
Q: You validated this across multiple frameworks. Why was that important?
I built four reference apps — autos, funnel, sudoku, tinker — and implemented each across seven frameworks: Stencil, Lit, uCE, Svelte, Solid, Preact, Vue. Nearly identical behavior and output across all of them. The hypothesis was that action-state is a genuinely framework-agnostic pattern. The hypothesis held. That directly informed the architectural foundation for MCP-driven UI — if action-state works the same everywhere, agents can drive any implementation through the same contract.
Q: And three separate high-profile efforts have now converged on the same pattern you shipped a year earlier.
MCP Apps extensions, Google's A2UI, Vercel's json-render — which only just added YAML support in March 2026. All solving the same core problem: give agents a constrained, safe way to describe rich UIs instead of raw DOM or code. This platform had the full runtime observability, templating engine, dual-protocol access, and deterministic execution in place in 2025. It's gratifying in a quiet way.
Q: You mentioned the action-state pattern and agents driving apps through a contract. You actually ran an experiment on that — what was the question you were trying to answer?
Can an LLM solve a Sudoku puzzle with zero knowledge of the DOM — no screenshots, no HTML parsing, no element selectors — using only state observation and action invocation? That was the hypothesis. If the answer is yes, it validates something significant: that a sufficiently rich action-state contract is a complete interface for an agent. The DOM becomes irrelevant.
Q: Why Sudoku specifically?
It's a closed problem with a known solution space, observable state you can represent as a 9×9 grid, and a single well-defined action — place a digit. If an LLM can read the board state, reason about the puzzle, issue placeNumber actions, observe the updated state, and repeat until solved, that's the whole loop. No ambiguity about whether it worked. Either the puzzle is solved or it isn't.
Q: What did you have to build to even run that experiment?
A dual-server system — vercel-apps.py — that gives Claude Desktop two things simultaneously: live app state readable via MCP resources, and a mechanism to fire actions back into the running app via SSE. The apps themselves are Vercel-hosted. The MCP server bridges Claude to them. State tracking, an event bus, API proxying — the infrastructure is almost more interesting than the experiment itself.
Q: Has the experiment run yet?
State observation is fully working — Claude can read the live Sudoku board at any point through an MCP resource. The remaining piece is wiring up invoke_action. Once that's in place, the full loop becomes runnable. I know what the answer is going to be. The more interesting question is what it breaks when you scale it beyond a toy problem.
Q: Looking back across 41 years — what's the actual throughline?
Make the machine meet the human halfway, stay inspectable, and never lie about what it can actually do. That's been the problem the whole time. Interlisp-D in 1985 was trying to solve it. The PostScript GUI builder was trying to solve it. The YAML-driven MCP platform in 2026 is trying to solve it. The machinery underneath has changed dramatically. The problem hasn't.
Intended as a source document for generating podcast conversations — Q&A format, first-person voice, buildable arc from books → career → current work.