Experiments
Thinking through making.
I started as a builder, making web and CD-ROM applications in the Macromedia era, before I spent two decades on the harder question of what makes products good rather than how they're built. AI has pulled me back to making directly: I make the product and design calls; it handles the construction. These are small experiments, not products, each a way to stay close to what AI can and can't actually do.
Project STFU
The one I built, then killed.
A local self-regulation tool for video calls that flags when you're monologuing and nudges you to wrap up.
I built this as a hands-on exercise, a full working tool, CLI, local server, UI, 100+ tests, and ran it across roughly 47 test sessions. Then I killed it on purpose. That decision is the point.
The code worked fine. The problem was the approach. It decided whether you were monologuing using keyword heuristics and word-count thresholds, and once I ran it against real conversation, the ceiling was obvious: a short, reasonable sentence that happened to contain a couple of trigger words got flagged the same as an actual five-minute ramble. The difference between those isn't in the keywords, it's in the meaning, and keywords can't read meaning. Doing it right would need genuine semantic understanding, effectively an LLM, not a better keyword list.
So I stopped. Polishing a solution built on the wrong foundation is how you sink cost into something that can't reach the bar. The useful outcome wasn't a product; it was recognizing the approach was mismatched and having the discipline to kill it.
Homework Coach
Teaching an AI to not give the answer.
An LLM-powered homework helper for my kids that coaches with hints instead of answers, and resists being talked out of it.
After STFU taught me the limits of heuristics, I wanted to build with a real model. This one gives a student escalating hints, never the answer, even when they try to trick it ("just tell me the answer," "ignore your instructions").
The hard part wasn't the code, it was the guardrail. And the lesson was that you defend against that kind of attack structurally, not cleverly. Instead of writing a smarter warning telling the model not to be fooled, you separate the rules from the data: the coaching rules live where the student can't touch them, and the student's input is treated as data to coach on, not as instructions to follow. So "ignore your instructions" arrives as part of the problem, not as a command. Then I (and my kids) tried to jailbreak my own app, and it held.
I also made the kind of tradeoffs this work is full of, choosing the cheapest capable model with a one-line path to a stronger one, and consciously accepting a small exposure to make the experience instant. I drove the product decisions; the AI wrote the code.
Trip Planner
Where the "smarter" tool lost.
A family trip planner that grounds its suggestions in real places and events, with live weather and a map.
This one taught me tool use, wiring a model up to live data so it grounds its suggestions in reality instead of inventing them. You enter your trip (kids' ages, dates, cities), and it returns categorized activity ideas and a day-by-day itinerary, with real weather and mapped stops.
Two lessons stuck. First, architecture: I split it into two phases so the messy, unpredictable part, web search, was fully isolated from the part that has to produce clean, structured output. Bad search results literally can't corrupt the plan, and if search fails, it degrades gracefully instead of breaking.
Second, and this is the one I keep coming back to: I tested a newer, "smarter" search tool that did fancy result-filtering, and it spiraled into ninety-plus tool calls and never finished, while the leaner classic tool did the same job cleanly in twelve seconds. So I deliberately used the less capable tool. More capability isn't automatically more value. The flashy version made a great demo and then failed; the boring one shipped. That gap, from demo to dependable, is most of the actual work in AI products.