My Life With AI—Part IV: Curses! Foiled Again!

Many years ago, I sat in a strategic planning session for our local school district. My kids were young, not even in school yet. My participation represented a legacy of sorts. When I served on the Town Board, I was the youngest member by a generation or two. They figured that made me the perfect person to serve as liaison between the Town Board and the School Board. I soon found myself sitting on quite a few school committees, from capital projects to technology.

This strategic planning committee was a little different. For one thing, it was ad hoc. For another, it involved a lot of big mucky mucks from every facet of the school district. Still closer to my twenties than my forties, I kept my mouth shut for the most part. Oddly, despite my relative youth, I was the only one sitting in the room with long-term business experience. So they’d keep coming back to me for definitions, tactical advice, and strategic summaries of the goals they had in mind.

Truth be told, I was in no position to determine the relevance or practicality of their goals. You might say I was agnostic towards any proposed policy or procedure. As a result—and like a good scientist is trained to do–my answers mostly included hedging terms and passive language form. For example, I didn’t say, “You should do Plan A because it best supports your goal because that is the goal you must have.” Instead, I’d say, “Plan A could support this aspect of the goal as it has been worded, while Plan B could support it in this way. On the other hand, if the words of the goal were changed in this manner, Plan A would likely mean this, Plan B would likely mean this, and it would open the door to a Plan C.”

“Muddle,” you might be thinking. But this apparent open-mindedness had its advantages. It was more of an unintended consequence than a deliberate aim; people thought a lack of conviction meant I was fair-minded. That led them to ask me more questions, which yielded the same Solomon-like responses.

When the time came for me to make a firm statement, they simply had to listen. And that time eventually came when talk turned towards languages. Ever a classicist (not by training but by self-learning), when everyone else was suggesting the school teach Chinese in high school (because in the 1990s, everyone thought the Chinese would always be our friends), I didn’t openly disagree, I threw in something from left field. “I’d be more interested in seeing Latin taught beginning in third grade because it’s the best way to learn English grammar.”

That stopped them all in their tracks. They were all in favor of teaching students to gain a better grasp of English grammar. They had no idea how Latin could do that because most of them never had classical training in Latin (and were careful not to put themselves in a position of admitting that because they didn’t want to reveal a layperson like me might have a greater understanding of scholastic arts). Now, I knew from a budget standpoint that adding Latin teachers in elementary school was a non-starter. But the same was true of adding Chinese teachers in high school. The whole Latin/English Grammar thing created such a dilemma that talk of Chinese faded.

Instead, they turned to other approaches, such as requiring a foreign language “because it would give students added skills.” That’s when I really went outside the box. That’s when I leaned into their logic. I said, “Yes, that’s right. But we should add programming languages to the list of approved languages. After all, the best way to learn problem-solving skills as a process is by debugging a program.” Did I mention “learning problem-solving skills” was one of the goals the strategic planning committee agreed to?

Of course, this suggestion never passed, but it once again caused a productive and meaningful conversation to occur. It’s probably one of the reasons they kept asking me back to future committees like this.

Was I just blowing smoke about debugging programs? No. I really meant it.

I didn’t receive much formal training in programming. The only way I could confidently learn all the languages I learned was by making mistakes. That meant a lot of debugging.

Debugging can be fun—as long as you find the bug and fix it. I usually found the bug and fixed it in self-contained programs. But what about programs that had to read an external database, extract data from that database, and then process that data?

I hated those.

It’s best to have the fewest number of variables when debugging. That way, you can more quickly isolate and solve the problem. If the program has to get data from a database outside the program, well, that introduces a whole slew of variables. It’s a deprogramming nightmare.

How scary a nightmare? Well, I remember getting so frustrated because I couldn’t find a bug that I entered the entire database as part of the code in the program. It was a kludge, but I got everything to work. (Today’s programmers probably prefer the term “hack” instead of “kludge,” but I’m not afraid to show my age.)

When I first started my life in AI back in 1987, I had to read a commercial database. I could successfully screen the database. I could successfully write the AI code (in Borland’s Turbo Prolog). However, I couldn’t get the Prolog to read the screened database. Finally, I created a makeshift solution (a “kludge”) using a program written in Turbo C (because, at that point, FORTRAN was too old school) as a go-between. It worked, but it wouldn’t win any design awards.

Fast forward to today. I’ve bitten the bullet and learned Python. Well, I don’t know if “learned” is the right word. Let’s just say I can get a Python program to run. I can barely debug it, and only with the help of a suitable compiler (I use Microsoft’s Visual Studio 2022). I can do simple Python programs on my own. It’s the complex ones that get hairy. The programs I need to replace myself are complex.

I haven’t replaced myself yet.

On paper, it’s easy. I use an AI Agent Framework inside a Multi-Agent Systems Platform, all wrapped within a Python program, to orchestrate a series of (old school word) subroutines or (modern word) agents to perform specific tasks and workflows. Through the broader platform (in my case, CrewAI), I write the program in a way that has the agents work collaboratively. The end result should be a weekly report that takes me hours to produce.

So far, the end result isn’t there.

That’s where debugging comes in. Except it’s not debugging the program I’m writing; it’s debugging the programs the agents are relying on. And I can’t see those programs, so my debugging consists of changing subtly what I’m asking an agent to do and seeing how that changes the output.

Oh, and did I tell you that the whole mess has to access and pull data from the biggest external database ever created: the Internet?

Curses! Foiled again!