AI-Assisted Programming: GUI or Command Line? My Current Thoughts

No se nombran archivos, pruebas ni puntos de entrada. Empieza revisando el comportamiento de la GUI en torno a mantener Xcode en primer plano y el caso reportado en el que los cambios afectan al archivo equivocado; el alcance y los criterios de finalización necesitan aclaración por parte de los maintainers antes de la implementación.

AI-Assisted Programming: GUI or Command Line? My Current Thoughts

I'm an Apple platform developer, with experience building apps for iOS, macOS, watchOS, and visionOS.

You might have noticed that over the past two weeks, I’ve reported fewer bugs to Copilot Xcode. This is because I’ve started experimenting with command-line-based programming. After spending some time with both approaches, I’ve discovered that each has its own strengths and weaknesses. In the long run, I believe GUIs have the upper hand, but for now, their drawbacks have kept me away.

The pros and cons I’m about to discuss are based specifically on my personal experience with Copilot: namely, Copilot CLI and GitHub Copilot for Xcode.

Advantages of Using the Command Line

More Flexibility

The command line typically has access to the entire disk, and can even help users who aren’t as familiar with the very use app modify its own configuration files.

When working from the command line, you don’t have to keep the Xcode window in the foreground. This means you can open multiple windows or multitask—like scrolling through X, for instance. This isn’t the case with the GUI, which insists Xcode must be front. If it isn’t, it keeps bringing Xcode to the forefront. I’ve reported this before, and the developers say it’s necessary for other features to function, but I think there should at least be an option to toggle this behavior—maybe make the GUI act more like the CLI in this respect.

Fewer Interruptions

With the GUI, I often run into interruptions, usually due to insufficient context. However, this has never happened with the command line. Most CLI interruptions are caused by network issues or quota limits, not by a lack of context.

Advantages of Using a GUI

Easier to Define Scope and Select Areas

With a GUI, you can directly access the current file, making the context much more straightforward. The AI can usually spot the area that needs to be changed right away. The command line just can’t match this convenience. On the CLI, you have to keep switching between copying and pasting—first the filename, then pasting it into the command line. It’s a simple but rather tedious process, nowhere near as intuitive as just clicking with a mouse. With the GUI, these actions feel natural and seamless.

If you don’t specify the file when using the command line, it ends up searching the entire project, which can take a lot of time or sometimes even fail to find the right spot.

Why I Stopped Using the GUI and Went Back to the Command Line

There’s been a long-standing issue with the GUI that still hasn’t been fixed: it often writes changes to the wrong file. For example, it might overwrite all the content in file B when it’s actually supposed to modify file A. I’ve reported this issue ages ago, but it still hasn’t been addressed. This is much harder to tolerate than the shortcomings of the command line I mentioned above.

So those are my thoughts on the matter. I welcome discussion and would love to hear any suggestions or better ideas you have.