A quick prototype for CCA's upcoming AI lecture series.
California College of the Arts is hosting After Intelligence, a lecture series exploring AI through artistic, ethical, and speculative lenses.
I prototyped this microsite using Claude's frontend skills in a single afternoon session. Dark minimal aesthetic, responsive nav, custom button system, view transitions.
I got tired of getting out-shouted playing Netflix Pictionary, so I built my own version with typed answers, custom words, and an AI that draws.
My family loves playing Netflix's Pictionary game. We'll pull it up on the TV, pass a phone around for drawing, and spend an hour yelling guesses at the screen while someone frantically scribbles.
It's fun. But there's a problem.
Some people are just louder than others. And when you're playing a game where the first person to shout the correct answer wins, the loud people dominate. Every. Single. Time.
I noticed I'd sometimes just... not guess. Not because I didn't know the answer, but because I couldn't compete with the speed-shouters. The people who machine-gun twenty guesses in three seconds while the rest of us are still processing the drawing.
I wasn't alone in this. I'd catch other family members going quiet too, watching instead of playing.
Looking back, I think what I wanted was to make the game more accessible. To give everyone—not just the fastest, loudest person in the room—a fair shot at guessing.
Over the winter break, I threw together a custom Pictionary game. The idea was simple: what if you could type your answers instead of shouting them?
With typed answers, you're not competing on volume. Everyone submits their guess, the system checks it, and the first correct answer wins. Quiet people can play. Introverts can play. People who need an extra second to think can play.
I added a few other features while I was at it:
The result is live at pictionary.joellithgow.com.
This is the part that got weird and fun.
I built two types of AI bots that can join the game as players. When it's their turn to draw, they actually draw—stroke by stroke, just like a human would.
One bot uses GPT-4o to generate drawings. I prompt it with a word, it returns a description of shapes (circles, rectangles, paths), and I convert those into animated strokes. It's like watching an AI think through how to represent "elephant" or "birthday party" in simple shapes.
The other bot pulls from pre-defined drawings when the AI is unavailable or slow.
Building these bots was mostly for my own entertainment during solo dev time, but they're actually useful when you have an odd number of players.
I was excited to play it with the family over the holidays. We loaded it up, everyone joined the room on their phones, and...
We hit bugs. Immediately.
Turns out I'd never actually tested it with more than one real person. Multiplayer games have this pesky requirement where you need multiple players to properly test them. Who knew.
We played for a bit, laughed at the jank, and I took notes on what was broken. Classic MVP experience: ship it, watch it break, fix it, repeat.
I've since worked out the major bugs, and I'm excited for next time we all gather. The game actually works now.
The best part of this project wasn't the code—it was the speed. I went from "what if I could type answers?" to a working prototype in a few days. Then from prototype to a real game over a couple weeks of evening sessions.
That's the magic of side projects. No stakeholder reviews. No sprint planning. No waiting for approvals. Just an idea, a laptop, and the freedom to build something dumb and fun for the people you love.
I'm excited to make more multiplayer games. There's something deeply satisfying about building something your friends and family actually use—even if the first session is mostly debugging in real-time while everyone watches.
If you want to try it: pictionary.joellithgow.com
Fair warning: the servers aren't heavily load-tested. But if you want to solve the shouting problem at your next game night, give it a shot.
Reflecting on a rare gaming moment where I'm inside the wave instead of watching it pass by, and what it means to be part of something as it spreads through your community
I bought Arc Raiders on a Tuesday because I'd been itching for a dumb FPS to zone out on. Two weeks later, everyone I know is playing it. So much fun.
How reading about a leaked private chat led me down a rabbit hole into OSINT and the intersection of journalism, tech literacy, and investigative work.
I read the Politico article about the leaked Young Republicans chat and got curious: how do journalists actually do this kind of investigative work? That curiosity led me to Sofia Santos' blog on OSINT (Open Source Intelligence), and now I'm wondering if my tech literacy could be a way to contribute to this kind of accountability work someday.
Politico investigation into leaked private communications, raising questions about how journalists access and verify this kind of information.
Open Source Intelligence techniques and investigative journalism. A fascinating look at how publicly available information can be used for accountability work.
ROI thinking has poisoned creative career advice. Here's why Return on Passion (ROP) is the metric that actually matters for artists, designers, and makers.
I'm so tired of hearing about ROI in creative fields. Return on Investment. As if the point of going to art school, learning ceramics, or becoming a designer is to maximize how quickly you can turn your education into the biggest possible paycheck.
What if we measured creative careers by a different metric entirely? What if instead of ROI, we talked about ROP—Return on Passion, or Return on Practice?
From delightful discovery to curious about balance—all in one session
I was using Claude Code this morning and asked it to suggest a few repository names. Instead of just listing them in text, it gave me this:
An interactive prompt! Right in the terminal, with numbered options, descriptions, and keyboard navigation instructions.
This is such thoughtful UX for a CLI tool. It makes the interaction feel polished and actually fun to use. Small touches like this make all the difference.
But here's where it gets interesting. Ten minutes later, while working on this very blog post, I told Claude to add the screenshot to the post. And instead of just doing it, Claude prompted me again:
Same feature, same delightful UI—but this time asking if I wanted to include the image in the post.
Wait. I just asked you to include the image. Why are you asking me if I want to include the image?
My reaction was completely different. Not "wow, this is cool!" but "this feels redundant and kind of weird."
It's fascinating how quickly a feature can go from delightful discovery to potential friction. The first time felt like a pleasant surprise. The second time felt... redundant.
And maybe that's the key difference: the first prompt was asking for new input I hadn't given. The second was asking me to confirm something I'd already explicitly requested. That's not helpful interactivity—that's friction.
This isn't a criticism—it's just an interesting UX challenge. When do you prompt for input versus making a smart default? And more importantly, when should you skip the prompt entirely because the user already told you what to do?
I don't know the answer. Maybe the first prompt (choosing repo names) deserved the interactive treatment because it's genuinely hard to auto-select from multiple good options. But the second one? If I say "add the image," maybe just... add the image.
Or maybe I just need more time with the feature to appreciate when it shows up.
(Oh, and one more thing: the "Type something" option doesn't support vim keybindings, so hitting Esc cancels the entire prompt instead of exiting insert mode. That's... particularly annoying for vim users.)
Actually, I just hit an even more frustrating issue. Or did I? I was mid-sentence in one buffer when my interactions with Claude completely stopped—not crashed, just unresponsive. Turns out there was an interactive prompt waiting in another buffer, and it was blocking all interactions everywhere until I answered it.
That's a real problem for multi-buffer workflows. But here's the thing: I can't replicate it now. Maybe it was a bug, maybe I'm misremembering. Live blogging/QAing, I guess!
Either way, it'll be interesting to see where Anthropic lands on this balance. Too few prompts and you miss chances for user input. Too many and you're breaking flow.
For now, I'm still impressed by the execution even if I'm curious about the strategy.
I asked Claude for help splitting a commit. What I got wasn't just a solution—it was a git feature that changed my workflow and a reminder that AI tools can accelerate learning rather than replace it.
I was staring at a file with multiple unrelated changes—some refactoring, some bug fixes. I wanted to commit them separately to keep my git history clean. But they were all in the same file.
My brain went to what felt like the only option: manually revert changes, commit, then painstakingly re-add them. Or worse, ask Claude to automate this tedious dance for me.
So I asked Claude: "Help me split this into two commits."
Here's what I half-expected: a series of commands to execute. Do the work for me.
Instead, Claude pointed me to something I didn't know existed:
git add --patch
It lets you interactively stage parts of a file, not just the whole thing. You review each change and decide what goes in which commit. Clean, surgical, no reverts necessary.
What struck me wasn't just the git feature (though it's now muscle memory). It was the realization about how I was learning.
Claude didn't do the work for me—it pointed me to a capability that made me more capable going forward. I didn't just get a solution; I got knowledge I'll use forever.
I could have spent hours reading git documentation and maybe never stumbled on this feature. Or I could ask a question when I hit a real problem and learn about it in context, immediately applicable.
There's a narrative that AI tools make you think less, learn less, become more dependent. I get the concern. But this showed me something different: the gap between having a question and finding relevant knowledge went from hours (or never) to seconds. The understanding still had to happen. The practice still had to happen. It just happened faster and in the exact moment I needed it.
Maybe the question isn't whether using AI makes you learn less, but whether you're using it in ways that build capability or just solve immediate problems.
This built capability.
What's something you learned through AI tools that you might never have discovered otherwise?
Starting to think about 'trail-making'...more to come...
What happens when you make a Minecraft mod where the game gets harder the farther you travel from spawn? Zombies. So many zombies. A quick dev journal about building a distance-based difficulty scaler and discovering it's secretly a co-op game.
I was coding when "The Distance" by Cake came on. He's going the distance, he's going for speed... And I thought: what if that was a Minecraft mod? What if the farther you traveled from spawn, the harder the game got? Not just a little harder. Exponentially, absurdly, ridiculously harder.
So I built it. And thanks to my previous mutualism mod experience and Claude Code, what would've taken weeks happened in a few focused sessions. The implementation touches everything—mob health, spawn rates, damage scaling—but it's all variations on a single idea: distance equals difficulty.
Then came the playtesting. A friend and I loaded up the mod, built boats, and started exploring across oceans. At first, normal Minecraft. But as we traveled farther, the game revealed its teeth. Zombies started spawning on our boats. Not near us. Not in the water. Literally materializing on the boat we were riding. We died. A lot. And we laughed the entire time.
That's when I discovered something unexpected: this isn't really a single-player mod. Solo, the difficulty curve felt punishing. With a partner? Perfect. The escalating challenge became a shared adventure instead of personal frustration. So I tuned the scaling for co-op, and the mod became something way more interesting than I originally envisioned.
After years away, I'm back to where I started: making Minecraft mods. This time with Claude Code, a book about ecological partnerships, and a few hours of pure creative flow.
I got into programming because of Minecraft—not through CS classes, just YouTube tutorials and learning enough to make custom blocks. After years of professional web development, I'm back where I started. And it feels awesome.
Inspired by The Call of the Honeyguide, a book about ecological partnerships, I built Symbiotic Survival—a Minecraft mod that teaches mutualism through gameplay. Honeyguide birds lead you to honey. Pollinators keep trees producing fruit. Destroy the partnership, lose the resources. You learn by watching NPCs interact with the world, not through tutorial pop-ups.
The wildest part? I went from idea to working prototype in hours using Claude Code. It even generated all the pixel art assets. And I discovered something unexpected: Claude codes games completely differently than web apps—working incrementally, leaving TODOs as creative scaffolding rather than tech debt. For rapid prototyping, this approach is actually ideal.
