I’ve been using and writing about Microsoft Copilot since it was publicly released in 2023. I’ve reviewed it, written articles about using it more effectively, explained how to curb hallucinations in it and other similar tools, and detailed how to use it in concert with Microsoft 365. It’s also been my go-to generative AI (genAI) tool for personal projects and advice.

But the time has come for me to leave it behind for my personal use. It’s become abundantly clear that for those tasks, Google Gemini is better. Here’s why.

Copilot is inept at solving a tech problem

Like many people who know something about technology, I’m the IT staff for friends and family. I’ve often used Copilot to help solve issues I can’t fix myself. Sometimes Copilot helps. And other times…, well, the last time I turned to it for troubleshooting advice is when I realized it was time to abandon Copilot.

My wife had bought a new iPhone, and I noticed she was receiving texts sent to her email address but hadn’t received any sent to her phone number. I asked Copilot for help.

I won’t go into the details of the wild goose chase Copilot sent me on — I’ll just offer a few lowlights. It first told me, with absolute authority, that there are “only two real explanations” for the problem and asked me to look at several settings to confirm which explanation would fix the issue.

It turned out that neither of the “two real explanations” were the cause. Undeterred, Copilot assured me, again with complete confidence, that it was going to send me “straight to the switch” that would immediately solve the problem.

I tried it. The switch didn’t work. Neither did the “final fix” it promised me. Nor did any of the other many “solutions” if offered after that so-called final fix. For more than an hour, it flailed with utter confidence and utter futility trying to diagnose and fix the problem. 

And then came the final indignity: After doing some digging, I realized Copilot was trying to solve the problem based on an old version of iOS, not the current one on my wife’s phone. When I confronted Copilot about that, it briefly apologized and promised it knew the solution: I had to call the cellphone carrier.

That was it for me. I’d had enough. I turned to Gemini for help. 

Thirty seconds later, Gemini diagnosed the problem and recommended a simple fix, which didn’t require a call to my phone carrier. It worked like a charm. Gemini had solved a tech problem in 30 seconds that Copilot couldn’t resolve after an hour. 

Copilot whiffs on personal research 

I often used Copilot for personal research projects. A recent one involved Parisian neighborhoods in the 1870s. I was looking for information about the area around the Saint-Lazare train station. When I asked Copilot, it told me the area was dangerous and poverty-ridden back then, with poor housing whose exteriors were heavily stained by coal smoke from arriving and departing trains.

That didn’t sit right with me. I recalled a well-known painting Paris Street; Rainy Day by the Impressionist painter Gustave Caillebotte, which depicted the neighborhood in the 1870s as wealthy and fashionable, filled with elegant Hausmann-style apartment buildings. I asked both Gemini and Claude about the neighborhood in the 1870s. They both told me it was expensive, fashionable and sought after by the well-off. I confirmed that with my own follow-up research.

Once again, Copilot had whiffed.

Copilot gives bad scheduling advice

I swim for exercise three or four times a week at my health club’s indoor pool. The club closed the pool for several months, so I decided to swim at the pool of an elementary school a short walk from my house. I hadn’t exercised there before and wanted to find the times on Monday through Friday when the pool would be least crowded. I asked Copilot for help.

As always, Copilot spoke with a solid air of authority. And once again, it was wrong. It told me that the least crowded time for public swimming on weekdays was between 11:30 a.m. and 12:30 p.m. or between 12:00 p.m. and 1:00 p.m.

On one count it was right: the pool would certainly not be crowded with public swimmers at those times. Because the pool doesn’t open to the public until 3 p.m. 

I turned to Gemini, which told me that 3 p.m., when the pool opened, would be the least-crowded time. Claude was no help. It demurred and said it didn’t know the answer – a rare, refreshing admittance of ignorance from a chatbot.

Gemini was on target again — 3 p.m. did indeed turn out to be the least-crowded time to swim. I often get a lane to myself, and at worst have to split a lane with one other swimmer. I asked several lifeguards if 3 p.m. was the least-crowded time on weekdays; they all confirmed it was.

Bye-bye, Copilot

For all those reasons, when it comes to personal research and advice, I’ve abandoned Copilot. I typically use Gemini now, although on occasion, I ask for a second opinion from Claude.

For my Computerworld work, I’ll keep using Copilot, and continue to write reviews of it, offer advice on how to use it and keep you informed about the latest news about it.

But other than that, for my personal use, Copilot is dead to me.

I’ve been around long enough to remember when deploying an application meant copying a *.exe file from the developer’s machine right into production. I am not making this up. It was that simple, and that fraught with peril. Applications weren’t complex — they were often not anything more than that simple *.exe file — and the process around deployment didn’t need to be anything complex, but it probably should have been.

Proper deployment of an application is something we’ve learned to do over the years. The process of properly building, testing, and deploying an application has grown more complex for two reasons. First, the process must ensure that every deployment succeeds. Deploying complex applications can be convoluted and challenging, and a strict deployment process ensures everything happens properly and runs correctly. Second, the process must thoroughly test the application to make sure that all the moving parts work together to create a properly functioning application. 

Today’s continuous deployment processes were hard-won from many lessons learned. Eventually, these practices became formalized, even to the point where the Sarbanes-Oxley Act was understood to require that IT departments formally document their deployment processes. 

This kind of governance is what separates professional software development organizations from those that, well, don’t know what they are doing. 

Agentic growing pains

Agentic development is headed in this same direction, but it’s all happening a bit more quickly. It was just a few months ago that people began to use AI to write code seriously. At first, most of us were doing it furtively, having Claude Code find and fix bugs, and then quietly checking in the solutions. Maybe we were a bit hesitant to mention that we had done this, but then we felt guilty about doing it and taking credit, and eventually we mentioned it. But it soon became apparent — like “within a week” soon — that Claude Code was up to the task, and we became pretty open about it. 

Very quickly, it not only became accepted but actually encouraged, and we were off to the races. In a month, everyone was tokenmaxxing.

It almost seems a bit out of control. Sure, there is a lot of code being generated and non-trivial amounts of money being spent, but it isn’t quite clear if the results are worth the effort. I’m not at all sure if anyone can say that the money spent is returning the value needed.

At some point, as an industry, we are going to have to get control of all of this. I fear that there will be a rush to impose governance over the whole thing. This, like deploying an .exe directly, is also fraught with peril. Right now, there appears to be little control over what tools are being used where, how much is being spent for what purpose, and what that spending is actually getting us. 

The governance over our deployment processes was successful and useful because it arose organically. The accepted, codified procedures arose from the lessons that practitioners learned by actually building and deploying applications. We all should work to ensure that a similar process happens with agentic coding.

Developers know best

Because agentic coding is happening so quickly and so furiously, the danger is that a governance process will be imposed over the top just as quickly and furiously. I want to encourage us all to take a deep breath, slow down a bit, and take a close look at what we are doing, and more importantly, how we are doing it. 

Agentic coding will be governed in some manner. It’s critical that we practitioners take the lead in providing that governance, or we’ll have governance forced upon us. We are the ones that know what matters and how the tools should be used. We are the ones with skin in the game and the ones keeping pace with the technology. 

Top-down governance of a technology moving this fast will never be able to keep up. Or as Uri Haramati, co-founder and CEO of Torii says, “The person closest to the tool usually understands why it’s being used, and governance works better when it includes those people instead of trying to control them.”

Copying that *.exe file into production is comically reckless. We don’t do that anymore because we know better. It took time, but we learned the right way to deploy software. Right now, we are in the “copying the *.exe” phase of agentic coding, and we need to figure out the right way to do it before someone comes along and does it for us.