What I learned after a weekend of AI troubleshooting gone wrong (8 key lessons)

Grant Fritchey walks through a real troubleshooting saga – using Wine, a shim DLL, a misconfigured registry entry, and a lot of trial and error – to get a BridgeCom Maverick radio’s Windows CPS running on Linux Mint. Along the way, repeated dead ends revealed a pattern: AI tools stay locked onto whatever direction you last pointed them, and it’s up to you to redirect, request alternatives, and demand measurement over guesswork.

In this article, Grant shares everything he learned from the experience, including 8 key takeaways to help you avoid similar trouble when using AI in the future.

But first, some background…

The hobby: ham radios

My hobby is ham radios. No, I’m not going to spend endless time talking about that. I just bring it up because, a whole lot of ham radio these days involves using a computer. One of the most common things you’ll see people doing with a computer and their radio is using what is called Customer Programming Software (CPS) to “program” the radio (basically, set up frequencies, offsets, and a slew of other settings for digital radios).

The fun starts when I decide to see if I can set up all my radios on a Linux machine. Now, understand, there’s not just one CPS. My BridgeCom Systems Maverick radio has a CPS. As does my Baofeng DM32-UV. Another for my Radioddity GD-88. Then, one CPS for a stack of analog radios called CHIRP.

Now, CHIRP runs natively on Linux, but these other radios are Windows-only. So, I need to get a Windows program to run on Linux, and I’d sure love to avoid just setting up a slow virtual machine (VM).

So, what did I do? Asked an AI, of course.

Why did I turn to AI to help me get a Windows program running on Linux?

I’ve been putting large language models (LLMs) to work for some time now. I first presented a session on using an LLM to build a database, write queries, and even do a little tuning, three years ago. At work, and at home, I take advantage of what agentic AI has to offer. Heck, I even pay for my own Claude account to use with my radios.

Along the way, I’ve learned some stuff about how to work with the AI.

The first thing you should do is make darned sure that the AI knows what tools you have. Whether we’re talking data platform or, in my case, radios, you have to make that clear to the AI up front.

You could, if you wanted, type stuff in to the prompt. For example, “I’m working with PostgreSQL 18 and I need to add the postGIS extension” could help you get some decent advice from the AI.

However, if you really want to get the most out of AI, you need to feed it a lot more than that. In my case, I outline what radios I have, what I use them for, and what my goals with the radios are. I even list the equipment and software I have to help me work with the radios. I have all of this stored in a markdown file.

Feeding the AI: why a markdown file changes everything

First up, text is the best way to work with AI. Sure, they can look things up, examine images, etc., but when you’re in Visual Studio Code (VSCode) working with GitHub CoPilot or, in my case, Claude Code, text is your best buddy. Markdown supplies that. However, markdown also has a couple of other uses.

First up, you can structure a markdown file, grouping information under headings and subheadings. Lay out tables of data. All sorts of stuff that’s going to make communicating with the AI more efficient. Next, you can format that stuff so it’s easier for a human to read too. This makes it a very effective mechanism of communication between both parties: the evil AI, and those lovable rascals (humans).

So, when I finally go to the AI to say, “I’d like to be able to program my BridgeCom Maverick from a Linux machine”, I don’t have to explain what a Maverick is, if I have a programming cable, etc etc. The markdown communicates this for me, up front. I can either paste the information in at the start of a session, or simply reference it as an attachment to a conversation or task.

Another choice is to make it one of the definitional documents for the AI engine running locally on my machine. I even sometimes just plop it in the project I’m working on in VSCode so it’s always there, in the repo.

The more effort you put in, the better the AI will serve you

Is this a lot of work? Yes. “Then why do it?”, I hear you ask.

Well, see the title of the article: the AI struggle is real. Can you just deposit yourself in front of the AI and start typing prompts? Sure. Will you get consistently good results? Nope. In fact, chances are you’ll forget something, make a typo, whatever. Your prompt will be poor and so the answers you get from the AI will be poor also.

Tip: if you forget something, add it to the markdown file. It’ll now be stored, so it doesn’t matter if you forget it again!

Now, my actual prompt to the AI was quite a bit more extensive. I didn’t keep it (because I was playing at home, not planning to write this article), but it was something along the lines of:

“I’d like to be able to program my Bridgecom Maverick on a Linux machine. The CPS needed is Windows only. Without installing a Windows VM, what alternatives do I have to get a piece of Windows software up and running on Linux?”

The AI came back with several possibilities, but the one we’re going to concentrate on here is Wine.

Installing the CPS with Wine – and where it went wrong

Wine is an open-source compatibility layer that makes it possible to install and run Windows software on Linux – or, to be more specific, run Windows on a POSIX-compliant operating system. It does this by translating Windows API calls into POSIX statements. There’s no operating system (OS) or license needed – just run Windows native software as if it was Linux native.

Whoop! Perfect. So, I got Wine installed, and then ran through the process of installing the Maverick’s CPS.

That’s when things went off the rails just a little. I launched the CPS and it crashed, with a really obscure error message. Of course, I took the error message to Claude Code, and its answer was very confident. Not only did it know what the error was, it also knew exactly how to fix it. Or so it said.

Another problem emerges

While it got the first bit right (correctly identifying the error), the fix it gave was a different story. Basically, I tried implementing the fix for most of a Saturday afternoon, laser-focused on making Wine work. There was a specific error so, let’s eliminate that error, right? My focus kept the AI focused as well.

We were not exploring alternatives, of any kind, during this process. And ultimately, a whole lot of back and forth (and even a paid product trial) later, we had to give up. The AI guessed it must be a bug in Wine, and who was I to argue? I’d never even heard of Wine prior to this.

Understand the struggle here. I was focused. Because I was focused, so was the AI. Yes, I told it to search for solutions to the fundamental problem. Cool, right? Well, no. What should I have done? Simple: ask it if there was any other way around the problem. It just didn’t occur to me at the time.

The shim DLL ‘detour’ (and why it was a red herring)

I’ve got to go on the road, so leave my Linux laptop and the Wine problem at home. Later, when I get back to looking at it, I finally think, “surely someone else has tried this before.” So, I post questions online, and ask the AI to do some searching of its own.

Between us, we get results – and, as it turns out, someone has done it before! They built a custom DLL to run in front of Wine to solve the problem. They called it a shim (slim/thin) DLL. Well, heck, we’re off to the races. I prompt the AI to work on a shim DLL, which it does pretty darn quickly. We test it with Wine.

No crash!

I’m sitting there, slack-jawed, looking at a Windows app is running directly on my Linux Mint Xfce machine (old laptop, more lightweight implementation). This is awesome! I immediately connect up the radio and go to read from it (a good habit to get into, read from the radio first).

Oh, no. There’s no COM (communication) port available. Back to the AI. I watch it trying to read from the radio, which reboots the radio over and over. STOP! As a general rule, only read from the radio when you have a substantially improved test to run – and that’s what I tell it.

Suddenly, it’s now doing most of the work from a single read, and everything speeds up. It then finally throws up its hands and admits that, nope, this can’t be fixed.

Now, though, unlike last time (maybe I’m more rested or something), I do the smart thing. I start a new session, with a new engine and a new prompt. I’ve also got a log of what we’ve already tried, so the session has that knowledge.

The key takeaway: teach the AI to measure, not guess

Yes, the AI is smart, but you absolutely must provide guidance because it won’t figure this out on its own. It can troubleshoot what it sees and correlate that to other steps, including coming up with its own validations and tests. It just won’t readily see a hole in its own logic.

Let me tell you another thing I’ve gotten into the habit of doing: make the AI document its work. I’ll have it create a readme file that describes what it has done, what worked, what failed. This is because, without it, the AI will circle back to failed solutions – just as we saw with its insistence on reading from the radio over and over!

With the readme (markdown), however, we can ensure a state of knowledge from one session with the AI to the next. No more repeating already failed solutions. Is this more work? A little more, not a lot, but a great habit to develop. It keeps the crazy-sophisticated search engine from finding the same thing over and over.

And, just to be clear, all these things go into source control – so you have a history.

The real fix: a misconfigured Wine registry setting

Back to the story and, this time, I prompt the AI with: “Here’s what we’ve done. Here’s where we’re stuck. You can read everything attempted so far. I need to know if there are alternative solutions to this problem. Have other people ran into this. Further, is there a way we can measure and observe the behavior, rather than just trying it over and over again with adjustments to the code?”

In response, I gave it permission to stop knocking its head against the misbehaving shim DLL and look for alternatives instead. I also told it to measure what it does. The AI then made just one attempt to run the shim dll, measuring and observing the behavior along the way.

The result? It immediately declared the path to be a dead end. It wasn’t a problem with Wine that needed to be hidden behind a fake DLL. The actual problem was that Wine was misconfigured. The shim DLL was stripped away and the configuration setting – actually a registry entry – was done to Wine.

What happened next was joyous: the software fired up! We had a COM port. It worked. TA-DA!!!

With that issue resolved, I then read from the radio (good habit, remember), which put the radio into PC READ mode – a great sign, handshake accomplished.

Unfortunately, though, it just sat there. 0% complete. OK. Sure. Windows to POSIX, probably kind of slow. I’ll wait a bit. 0%. FUDGE! OK. I go back to the AI.

The AI now knows what to do

It now knows to look for alternatives, and to measure and observe what it does. It cogitates for a bit and comes up with a plan… and immediately launches the software. Unbeknownst to me, after launching the CPS, it gave me instructions. I just couldn’t see them because the CPS is there.

I’m sitting there for a while, thinking that the CPS must have hung, so finally kill it. I then discover my instructions. ARRGGHH! Back to the AI which, of course, responds with “if you need me to do things within the app, you’ll have to tell me what to do, before you launch the app.” For crying out loud. See, this is a struggle!

Regardless, the AI is at least now observing and measuring, and it identifies the issue quickly. It’s all obscure stuff on how reads are done in Linux versus Windows, and what a Visual Basic (VB6) app (yes, the app is brand spanking new and written in VB6, don’t hate me, hate how old school ham radio can be) needs to see.

Result!

So, the AI figures it all out, builds a radio emulator (when you tell them to let themselves off the hook, they do), and begins to test a number of solutions without ever connecting to the radio. And they all lived happily ever after (well, the test harness was run against the proposed solution, and it worked).

For confirmation, we then tested it with the CPS. This, too, worked, albeit slowly. Nothing a little tuning couldn’t sort. Next up, write to the radio. Claude Code at this point was crazy conservative about testing and measuring before doing anything, so I was ready to jump in and just do the write myself.

However, it ran everything through the test harness in the other direction, which worked like a champ. All I did was do the tests that Claude couldn’t. And everything was functional. Result!

I’ll be sharing these insights with the BridgeCom community, so that others can take advantage!

Final thoughts

Don’t get me wrong, I’m not here to complain about how awful AI is. It helped me to get things working in an area I had zero knowledge of (and still have very little knowledge of). I’d never even heard of Wine.

Yet, with the help of the AI, I have a Windows app running in Linux.

The real purpose of this article is to give you some advice on improving your use of AI. Because, let’s be clear: AI is just another tool. I’ve had frustrations with hammers, despite having worked with them for around 59 years (yes, I got a wood working set when I was 4…and yes, I put nails in the floor and sawed the leg off a table).

Ultimately, knowledge and understanding improves your usage (and judgement) of any tool.

8 ways to work better with AI (the key takeaways)

Finally (and most importantly): never forget that, while we’re using the AI as a tool, you still always have one more available – your own brain. I love these agents, but I’m still needed – and so are you.