About
Architecture, then radio, now AI. The job has not really changed: work out who a system is actually for, and then build the thing that serves them.
Background
I got to architecture through the Army. A four year ROTC scholarship paid for Howard's School of Architecture in Washington, and I graduated in 1996. Fourteen years in the Army Reserves followed: signal officer training at Fort Gordon, then the public affairs course at DINFOS. Those are the same job twice. Take something complicated and make it land with a person who has to act on it now.
I practiced architecture in Detroit and then Minneapolis, and in Minneapolis I started volunteering at KFAI because I wanted to be near the music. That turned into co-hosting a show called Groove Garden, which turned into my own show, Rhythm Lab Radio, on Minnesota Public Radio in 2005. For a while I was an architect during the day and a radio host at night and did not think of it as a career change. In 2006 I left architecture for a station that had not launched yet, 88Nine Radio Milwaukee.
Twenty years later I am still there, by way of digital director and creative director, now Director of Strategy and Innovation. The thing I am proudest of is HYFIN, which we launched on June 19, 2022: an urban alternative station for a Milwaukee audience the market had spent decades treating as a format rather than as people. Four years earlier I started 88Nine Labs to make the local tech scene less closed than I found it. Both are the same problem in different materials. There is an audience the existing thing does not serve, and somebody has to build the one that does.
The building started when Cursor first arrived. My first hackathon was AfroTech, where I built SkillSync alone in Streamlit over a weekend, and what I took from it was not the project. It was that I could get from a problem to a working answer without waiting in line for anyone. Then Lovable showed up and I aimed it at the thing I had been carrying for years, our playlist, because a playlist is the promise a station makes to its listeners and ours was not keeping it. Everything I have built since is an AI system, and the question underneath has not moved since architecture school. Who is this actually for, and does the thing we shipped serve them.
How I think AI products should be built
Responsible AI is a system design constraint, not a review step at the end. A policy that says do not fabricate is a wish. A pipeline stage that will not pass a claim without a source is a constraint, and it holds when nobody is watching. So when I want a model not to do something, I try to remove the parameter rather than filter the input. The tool that lets my assistant phone me takes no phone number; the number lives on the server, so there is no argument to inject. I have pulled each of those guardrails out once to watch its test fail, because a safety test you have never seen fail is just a comment.
Domain expertise is not a nice to have in this work, it is the thing that tells you what good output looks like. A model will assemble a perfectly plausible sentence about Milwaukee radio. It takes twenty years in the format to know which plausible sentence is wrong. Every evaluation set is somebody's judgment written down, and if nobody in the room has the judgment, the eval ends up measuring fluency and calling it quality.
So I build enough to evaluate, and evaluate enough to explain. Enough to evaluate means shipping the thin real version instead of specifying the thick imaginary one, because you cannot write a rubric for a system you have only described. Enough to explain means I can tell you why it failed, on which input, and what changed after. A demo that works is not evidence. A trace that shows the failure and then the fix is.
Where the line actually is
I am not an engineer and I am not going to claim to be one. No algorithms whiteboard, no week on call for somebody else's system. I am also not going to print a product title above this paragraph before I have held the job, on a site whose whole argument is about not overstating.
What is not new here is the product work. Twenty years of deciding what to build for an audience and then asking whether the thing we shipped served them: radiomilwaukee.org, the podcasts, 88Nine Labs, HYFIN from nothing to on air. That is product management with a different title on the door. What I have not done is that work inside a product organisation, with a roadmap I negotiate and engineers I do not control. The practice is the old part. The context is the part I am moving toward.
On the technical side, here is the real line. I can read a schema diff and tell you which migration is going to hurt. I can design an eval suite, choose the dimensions that matter, and argue about why the rubric is wrong. I can hold a genuine conversation about architecture tradeoffs, whether a problem wants retrieval or a longer context or neither, and I have made that call badly enough to know what it costs. I write code every day with Claude, I ship it, and I read it before it goes out. The constraint is specification rather than syntax: I can build what I can describe precisely, and I get into trouble on code I did not design.