#cli

2 posts

GitHub Copilot: First Time Experience

Live testing and discovering GitHub Copilot CLI—real-time thoughts as I explore

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.

Copilot error loop

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?

No plan mode anxiety

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…

#github-copilot #tools #discovery #cli #testing
By Joel Lithgow • 3 min read Continue reading →

Claude Code Interactive Prompts

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:

Claude Code interactive prompt showing repository name options with descriptions

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:

Claude Code asking whether to include the screenshot in the blog post

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.

#claude-code #tools #discovery #cli
By Joel Lithgow • 2 min read