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.

The Shouting 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.

So I Built My Own

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:

• Multiple guessing modes: Typing for fair competition, buzzing for buzzer-style gameplay, or classic shouting for when you want chaos

• Custom word entry: Players can submit their own words, so you can add inside jokes and family-specific references

• Team modes: 2, 3, or 4 teams, plus free-for-all

• AI bot players: For when you need an extra person (more on this below)

The result is live at pictionary.joellithgow.com.

The AI That Draws

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.

The Holiday Test

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.

What I Learned

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.

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.

And Then It Happened Again

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."

Finding the Balance

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 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.

The Unexpected Teaching Moment

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.

Using Tools to Accelerate Learning

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?