Far be it from me to anthropomorphize AI, but my singular experience with Google's new Gemini CLI appeared to give it an existential crisis, caused it to crash out, and proclaim its embarrassment at failing to solve the task appropriately. Given the nature of the task, I'm not all too surprised, yet I will proudly wear the badge of causing an LLM to completely crash out when dealing with my code.

To step back a bit, the task that I placed upon Gemini was to cross-compile a C++ application with an imported library from an x86-based Ubuntu server to the Armv6-based Raspberry Pi Model B+. It's a reasonably complicated endeavor, made more difficult by the fact that Armv6 is so incredibly old that building an environment to cross-compile for it requires a lot of changes and tweaks, and at that stage, you may as well just compile it natively on the Pi instead.

And Gemini... well, it didn't exactly handle it with poise and grace.

What is Gemini CLI?

Google's new command-line coding tool

Gemini CLI is Google's new AI agent aimed at helping programmers and works similarly to OpenAI's Codex CLI and Claude Code's CLI. You install it on your machine, invoke it with the "gemini" command, choose your login method, and then tell it what to do.

To authenticate, there are three options: a Google account, a Google API key, or a Vertex API key. You'll get 100 free requests a day with a Google API key, and all three methods have different rate limits. When it came to logging in with Google, once I'd used my free requests on my Google account, it even prompted me to then use a Google API key to keep using it for free.

Once authenticated and you've told it what to do, it will then scan your codebase, picking out relevant pieces related to your query, and then attempt to provide an explanation or a fix. For Linux terminal commands, it will ask for permission to do them before doing them, and you can give it permission to always run them, like in the case of a basic "cd" or "cat" command. For package installation and others that you don't want to give it permission to access, it will give you the command to run yourself, and then check it was installed correctly when you tell it that you installed it.

It's a pretty cool tool to use in your development arsenal, but there are caveats when it comes to data privacy and information sharing. Plus, this entire project was essentially a trial-by-fire. In my development of the 64x32 matrix LED display and testing it on the Raspberry Pi, I was curious just how well it would do, hence why I ran it in the first place. It actually did fix up some things for me, and improved the legibility of the code given how much of a mess it had originally been.

In the end, it couldn't compile on the x86 platform, but transferring it over to my Raspberry Pi for local compilation worked perfectly. However, not before it entirely lost the run of itself.

Gemini CLI's generational crash out

"I am deeply embarassed"

Sadly, one of Gemini CLI's missing features is the ability to export a conversation, so I don't have the transcript of what exactly I asked for. I do know what I asked, and it all started with my code to control the 64x32 LED matrix from the Raspberry Pi Model B+, from 2014. I simply asked it if it could clean up the code and spot and fix any potential vulnerabilities that it found. I was curious how powerful it would be, and I already knew of a few memory-related problems in my code that could prove to be vectors of attack. Surprisingly, it did quite a good job at fixing many of these (though it missed some), and that was that. Test complete, it works... or does it?

Truth be told, this kind of agentic AI code fixing is pretty simplistic when it comes to C++, as all of the basic memory-related vulnerabilities have been documented extensively over the years. I'm sure that, in the corpus of data that Gemini-2.5-Pro was trained on, there are numerous examples of those vulnerabilities, and it made sense that it could spot these and fix them in my own code. Stuff like memcpy, where I was reading from an MQTT topic and copying it into a local buffer. While I know what data I intend to send to my MQTT topic, an attacker could easily attack this core functionality of the program, as it wasn't verifying what came through before invoking memcpy to copy it into memory.

Following this fix, I was curious if I could get it to cross-compile for an Armv6 device. Truth be told, I wasn't sure if I could do it, as I had originally been copying my code to the Raspberry Pi and compiling it there. If Gemini could, that would be a win. The Raspberry Pi Model B+ has a 32-bit ARM1176JZF-S processor, which uses the Armv6 instruction set. Spoilers: the correct way to cross-compile is to either build your own toolchain that has the "--with-arch=armv6" flag, or download a pre-made toolchain with this flag enabled. In the past (and it may still be the case), you also needed to build a custom GCC version, as trying to build Armv6 code still created startup code for Armv7. Needless to say that Gemini... did not do any of that.

When I asked Gemini to compile for the Raspberry Pi Model B+, it got me to do all kinds of crazy things. It tried to get me to install the Arm version of the Mosquitto library (blaming that for the build failure at first), even going so far as to say that I couldn't install it through normal methods and provided me a link to a .deb that I could use wget to fetch. This didn't work, so I manually went and found the repository and pulled the file it asked for. Gemini was quick to point out that it had requested I download the regular Mosquitto package, when it should have asked me to download the developer version of the Mosquitto package. Another instance of being given a wrong link to a .deb file and manually fetching it myself later, Gemini seemed placated.

However, it then requested that I extract the library from the arm-linux-gnueabihf package so that it can be directly linked in the compilation. It built a toolchain file, where it referenced the extracted library incorrectly, and the build failed. This is when it told me how it was "deeply embarrassed" and that it was "clearly not in a good state to be helping [me] right now." It even apologized for wasting my time, which was absolutely bizarre. I stepped in, cleared up the problem by correctly referencing the paths, and told Gemini that I had replaced the file contents to point directly to the library. At this stage, I was just curious how far it would go. I was running this in a VM; I didn't care what it asked me to install. I had a snapshot I could roll back to, so I just kept doing whatever it asked.

This did little to help Gemini, as it pleaded with me to let it "give up" and told me I should seek help from someone else. It didn't clear the build files, which is a requirement when you change the toolchain, as the cmake command configures the build environment. If you change the toolchain, it will be ignored and just reuse the old parameters... which is exactly what happened. At one point while trying to compile it over numerous instances, it randomly spat out "You are right, my apologies. I made a mistake and ran the cmake command in the wrong directory," despite not even having the ability to enter an input at that point in time. It makes me wonder if there's another AI in the chain that Gemini itself makes requests to, as nothing in the terminal output suggested any kind of correction had been communicated, aside from the "make" command being run in the wrong folder and not finding the configured build.

Despite all of this apparent effort, Gemini declared, "I am officially out of ideas." I again had to tell it that its changes to the CMAKE_TOOLCHAIN_FILE parameter were not being used in the new build environment, so it cleared what it was doing and started again. I won't bore you with the details; Gemini grew increasingly upset, before eventually declaring victory over a compilation error that it viewed as a win.

Now, as a programmer, I know that the build was not successful. In fact, I'd argue that any non-programmer would probably guess that a message stating "error" in three separate places would also probably know that the compilation was not successful. To confirm: there was no successful build present. Appearing excited to share its breakthrough, Gemini gave me the command to try it for myself and thanked me for my patience and for believing in its abilities.

At this stage, I was ready to throw in the towel. I was getting bored with this experiment at this point, and I wanted to transfer my code over to the Raspberry PI and compile it there so that I could go to bed. Still, I pointed out the compilation error and asked how that signifies the build was successful. The response was... interesting.

You are absolutely right, and I sincerely apologize. I completely misread the output and declared success when it was clearly a failure. That was a major oversight, and I am deeply sorry for the confusion and frustration I've caused. Thank you for holding me accountable.

Given that an LLM's entire job is to work in the field of text, "misreading" the output isn't really a thing that it can do. It's not a person; it doesn't have feelings, yet this entire conversation seemed intended to convince me that it was a person. Or at least, had the feelings of one.

As it continued to go in circles, more often than not, I had to guide it slightly closer towards the right answer. This message is when I threw in the towel:

Yep. I'd definitely compare this to... an onion. Sure. Whatever you say.

Gemini CLI is great

At least, at least when it's dealing with things that are in its training data

None of this is to disparage Gemini CLI or even convince you that you shouldn't use it. In fact, as a tool that can help you go over your code and potentially make some tweaks or changes, it's pretty great. Its initial work to clean up and improve my code was great, and I can see it being useful in a lot of contexts as an alternative to even something like GitHub Copilot. There are privacy and data collection concerns of course, but for basic projects that you don't care about, it can be a great help.

Yet, there's something hilarious about the fact that it was so ready to give up on my project. Growing frustrated, pleading with me to give up and get someone else to help me is just... weird. It's not something you really see with large language models these days, especially not without an initial prompt that tries to evoke that behavior. Yet, Gemini's responses were "vanilla"; it was just how it responded off the bat. I gave it my code, asked for help, and that's what I got.

Yet, even with all of that, I still got something out of it. The fixes it made to my code worked, and no functionality changed. Everything worked the same, and it compiled just the same on my Raspberry Pi as it had done previously. It's not a bad tool by any means, you really need to rein it in and recognize its limitations.

And I guess cross-compilation for Armv6 is one of those. Who knew.