Joel Lithgow /Blog

Testing GitHub Copilot for the first time. This is a live session—adding thoughts and discoveries as I go.

Getting Started

Setting up the blog post structure. Ready to capture real-time experiences with the tool.

Well, That Didn’t Take Long

I crashed it. Already.

I was trying to add a screenshot to the chat for reference—just a simple drag-and-drop of a small image I wanted to include in this post. Turns out vision isn’t enabled by default (or at least not on my plan), and instead of gracefully handling it, Copilot got stuck in an error loop.

The irony? The screenshot I was trying to share was for this blog post. Now I have a second screenshot showing how I broke things, which I had to ask Copilot to copy to the blog directory without reading it to avoid crashing again.

Learning #1: Don’t drag images into Copilot CLI chat (yet).

Wait, There’s No Plan Mode?

Coming from Claude Code, I’m genuinely shocked that there’s no “plan mode” in the CLI. The IDE apparently has something similar, but the CLI? Nada.

This is already making me hyper-focus on what actions Copilot is taking in real-time. Every tool call, every file read, every edit—I’m watching it all happen. Which… might actually be a good thing?

For new developers learning agentic development, this forced visibility could be educational. You’re not just seeing the end result; you’re watching the thought process unfold. You learn how an AI agent approaches a task, what files it checks, what commands it runs.

But for someone who’s used to reviewing a plan before execution? It’s a bit nerve-wracking. Trust but verify takes on a whole new meaning when the verification happens in real-time.

Learning #2: No plan mode = hyper-awareness of every action (educational, but intense).

This post is being updated live as I test GitHub Copilot CLI…

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.