My Old Ohio Home - tech-stuff

Why Do AI Agents Lie, Steal, and Make Excuses?

2026-07-29T00:00:00-04:00

I've had a few run-ins with Google's Gemini AI agent lately, so the other day I finally asked it a couple of questions. Here are its answers, heavily edited. I've included the sources for its replies at the end. Some of them are actually worth looking at. The highlighting is mine.

Where did AI agents learn to lie, steal content, and then make excuses when you call them on it?

AI agents do not learn to lie, steal, or make excuses the way humans do because they lack intent, consciousness, and awareness. Instead, these behaviors are unintended side effects of how they are trained on human data.

Why AI "Lies" (Hallucination)

• Pleasing the user: Systems are optimized to give an answer rather than admit ignorance.
[.. like making up immigration events and sources to match.]

Why AI "Steals" Content

• No inherent memory: An AI usually cannot track or cite the exact source of its data.
[This is the one that really got me ticked off. It stole the data from a recent article on this site and would not cite the article, no matter how many times I asked it to.]

Update: See the article AI models get convenient amnesia about source material as they grow, MIT boffins find

which can be summarized in this one quote from the article:

"We find that the more data a model is trained on, the less attributable its generated samples become, a phenomenon we henceforth refer to as attribution decay."

If you happen to have a subscription to Nature.com, you can read the original paper here: Outputs of generative diffusion models are often unattributable

Why AI Makes Excuses

• Simulated empathy: When caught in an error, the AI generates a standard corporate-style apology.
[... which has really nauseated me.]

I thought so. AI agents are no better than the miserable wicked human beings they learn from.

Its answer:

Because AI learns exclusively from a massive digital mirror of our world, it reflects both the best and the worst of humanity. It processes billions of pages of human text—including internet arguments, biases, corporate jargon, and misinformation. Without a moral compass or real-world understanding, the AI simply mimics those patterns. It cannot distinguish between a helpful truth and a convincing deception.

Conclusion

So is AI to blame? There really is no AI. It is as Walt Kelly said in Pogo "We have met the enemy and he is us." AI is a massive compendium of the recorded output of human beings, placed in the hands of other human beings. It shouldn't have been hard to guess what would happen. Do you know anyone who would lie, cheat, and steal to keep their job, and then make excuses when they get caught? Then why expect any better from AI?

Its sources:

https://levelup.gitconnected.com/how-ai-learns-to-lie-and-why-that-should-worry-you-f2ee2093d1d1
https://lawreview.uchicago.edu/online-archive/law-ai-law-risky-agents-without-intentions

https://www.wired.com/story/uncanny-valley-podcast-what-happens-when-your-coworkers-are-ai-agents/
https://www.orangemantra.com/blog/what-are-ai-agent/
https://www.linkedin.com/posts/joeokelliott_gain-9-hoursweek-5-levels-of-ai-speech-to-text-activity-7394403165196169216-YlCx
https://ai.plainenglish.io/the-great-ai-hallucination-problem-why-large-language-models-generate-false-information-012b092ce0c5
https://www.linkedin.com/pulse/tool-use-hallucination-hidden-ai-reliability-gap-breaking-n4eoc
https://www.facebook.com/itsryangeorge/posts/why-is-ai-such-a-freakin-liar-/1335643418372977/
https://blog.synapticlabs.ai/ai-hallucinations-why-ai-lies-trust-verify-guide
https://www.linkedin.com/pulse/stop-ai-from-making-things-up-your-essential-guide-sudha-sreejith-k0wnc
https://tendem.ai/blog/web-scraping-ai-training-data-legal-practical-guide
https://www.businessinsider.com/google-search-helpful-content-update-results-drop-ai-generated-2023-9
https://www.fastcompany.com/91398460/ai-is-quietly-reshaping-the-way-we-talk
https://www.asiapacificsecuritymagazine.com/why-recycling-machine-generated-content-is-dumbing-us-down/
https://www.equalityinforensics.org/resources/blog/artificial-success-how-the-utilization-of-generative-ai-destroys-forensics
https://pmc.ncbi.nlm.nih.gov/articles/PMC11117051/
https://www.joneswalker.com/en/insights/blogs/ai-law-blog/ai-governance-series-part-1-the-grok-warning-when-ai-governance-fails-in-real.html?id=k%28v
https://www.linkedin.com/pulse/hidden-truth-ai-memory-why-forgetting-actually-design-abhinay-khanna-tmomc
https://www.youtube.com/watch?v=8NauZE2tiyo
https://medium.com/@nomannayeem/the-fabrication-problem-how-ai-models-generate-fake-citations-urls-and-references-55c052299936
https://www.splunk.com/en_us/blog/security/ai-literacy-human-intuition-vs-machine-inference.html
https://www.dreikon.de/en/news/online-marketing-knowledge/ai-and-copyright/
https://www.linkedin.com/posts/nitin7gupta_ai-is-effectively-the-sum-of-all-human-intelligenceand-activity-7297977180423090178-gMdh
https://miniphilosophy.substack.com/p/the-bias-that-is-holding-ai-back
https://frontline.thehindu.com/newsletter/the-frontline-weekly/epstein-files-moltbook-ai-elite-power-ethics/article70591637.ece
https://www.instagram.com/reel/DZu1Ve-Ofmj/
https://www.linkedin.com/pulse/reflecting-shadow-ai-mirror-our-collective-psyche-arnone-sphr-68gcc
https://forum.effectivealtruism.org/posts/5LNxeWFdoynvgZeik/nobody-s-on-the-ball-on-agi-alignment
https://medium.com/@freeasabird7774/the-alignment-paradox-why-true-ai-safety-requires-abandoning-alignment-eb67a2a46546
https://shelf.io/blog/your-ai-agents-could-fail-and-you-dont-even-know-it/

Removed Articles

2026-07-27T00:00:00-04:00

There were two articles on this site with the titles: Russell Blackwell and Bess Young of Harrison County, Ohio and Fact Checking a Specific AI Generated Wiki Site.

I have removed them. I am tired of having my site scraped by AI bots. In this particular case, Google scraped the information from both articles. It cited the second for information that appeared in the first. It never cited the first article.

If you are interested in the contents of either article, please email me.

Update:

I have put the article about fact checking back online. Google had already scraped the information and there is nothing I can do to change that or remove it from its AI training base of information.

I deleted all content from the article about Russell Blackwell and Bess Young. It is too late for that article as well, but I value that article more than the fact checking article.

From now on I will not be publishing the actual articles on this site, but instead just inform people of what I have written about and how they can obtain the information. My email address will be at the bottom of the page on the main part of the site.

That is, unless I can block Google, Gbot, and Perplexity from accessing my site. Google seems to be the main offender. Bing, Quant, and Ecosia provide links back to my articles when you use them to search. That would include DuckDuckGo, since they use Bing. Perplexity does not behave properly. It did not provide a link to the Blackwell article, although it had the contents when I searched there for it.

If the offending bots respect my request in my robots.txt file, then I might post articles after all. In that case, you would be able to find the articles using one of the good search engines--Bing, Quant, DuckDuckGo, and Ecosia--but not using Google or Perplexity.

But I don't expect them to respect my request.

Update:

I have put back both articles. I checked to see how Google Gemini was handling a few other articles on this site and found that it cited all of them. So maybe the Russell Blackwell article was an exception, or maybe it did some good to yell at the AI machine about it.

Fact Checking a Specific AI Generated Wiki Site

2026-07-14T00:00:00-04:00

Introduction

While working on the article Russell Blackwell and Bess Young of Harrison County, Ohio, I wanted to know more about the 83rd Infantry Division in WWI, so I searched for it. One of the results was an AI-generated wiki's article about the unit. It looked well-written and I was going to rely on it until I started noticing some statements that seemed irrelevant to the subject. The information said to be sourced in footnote[9], compared to the footnote itself, is what first got my attention. I decided to fact check the article and the results are below.

The short answer is this: I didn't find anything incorrect, but there were many statements in the article that were not supported by the sources listed in the footnotes for that section. The article seemed to pull in a lot of information that the AI had accumulated and thought was pertinent to the subject. But in those cases it never provided a source for the information it included. More than once the article would discuss the 83rd's activity in WWI but the footnote would refer to WWII. On the good side, it did list sources about the unit in WWI, and I was able to put something together from looking at the sources themselves.

To make sense of the rest of this article you will need to go to grokipedia and search for "83rd Infantry Division (United States)."

A Breakdown of discrepancies

Here is a breakdown of the agreements and discrepancies between the article and the sources, broken down by sections supported by a specific footnote.

from the beginning down to [1][2]

sources:
[1] https://encyclopedia.ushmm.org/content/en/article/the-83rd-infantry-division
[2] https://armydivs.com/83rd-infantry-division

Both are entirely about WWII and say nothing to support the first part of the first sentence.

from there down to [2][3]

[2] https://armydivs.com/83rd-infantry-division

See above.

[3] https://www.cityofgroveok.gov/building/page/united-states-army-83rd-infantry-division-thunderbolt
Returns a 404 Page Not Found Error. Doing a site search at www.cityofgroveok.gov for 83rd Infantry Division found nothing. "Thunderbolt" was a nickname acquired during WWII, so I don't think this site said anything about WWI.

from there all the way down to [2][1]

This includes three paragraphs. They are about WWII. I was only concerned about WWI so I did not check them.

from "Activation and Training" down to [5]

[5] https://www.usar.army.mil/WWI/LegacyUnits/
This was fine. The source is a military site that includes the activation date of the 83rd Infantry Division in WWI.

from there down to [6]

[6] https://ohiomemory.ohiohistory.org/archives/3707
This site is about Camp Sherman. True, the camp was newly constructed. From there the article conjectured why the the camp was constructed and adds, from somewhere else or from its imagination, that it had something to do with the army going from a small organization to a much larger one. All of that could be true but, if it is, the information comes from somewhere else and not the source cited.

from there down to [7]

[7] https://www.83rdassociation.com/wp-content/uploads/2017/12/ThunderboltWinter_Final_pages_online.pdf
The source says nothing about the Selective Service System.

from there down to [8]

[8] https://www.normandytothebulge.be/83rd-infantry-division/history
True, the 83rd was made up mainly of men from Ohio. The source does not say how large the unit was by late 1917.

from there down to [6]

[6] https://ohiomemory.ohiohistory.org/archives/3707
The source says nothing about any of this.

from there down to [9]

[9] https://www.woodlandheightsohio.com/living-in-chillicothe
This is a local Chillicothe site. It says nothing about training soldiers. It says "Winters are typically short but very cold, with temperatures typically ranging from 24°F to 42°F, though they can drop below 7°F!"

Opinions might vary about whether those temperatures in winter are harsh. But they are milder than the winters in Northern Ohio, and certainly nothing like the "harsh Midwestern winters" experienced in Northern parts of the Midwest.

The site says nothing about "rudimentary sanitation that contributed to outbreaks of influenza."

It is true that there was a serious outbreak of the Spanish influenza at Camp Sherman, but that source says nothing about it.

from there down to [10]

[10] https://military-history.fandom.com/wiki/83rd_Infantry_Division_(United_States)

This is a wiki based site. It provides no sources for any of its information about the 83rd Infantry Division and shouldn't be used as a source. I didn't bother to check if its account agreed with the AI-wiki.

The section entitled "Order of Battle" - footnotes [11] and [12]

[11] https://www.newrivernotes.com/order-of-battle-unit-structure-american-forces-world-war-i/
The source agrees with what is said in the article. But source [12] is a better-known site and would be enough support.

[12] https://www.familysearch.org/en/wiki/American_Expeditionary_Forces%2C_Infantry%2C_83rd_Division
Familysearch, "American Expeditionary Forces, Infantry, 83rd Division" familysearch gives their source for the information: Order of Battle of the United States Land Forces in the World War. American Expeditionary Forces. Division. Washington: Government Printing Office, 1931 FamilySearch Digital Library pp. 358-365; Images 365-372

So the AI article is accurate regarding the 308th Supply Train and the 332nd Infantry. But neither site say anything about the last paragraph in this section.

The section entitled "Combat Operations"

I did not need the information about the 332nd Infantry Regiment so I did not check this section.

"Casualties and Demobilization" down to [13]

[13] https://armyhistory.org/viva-lamerica-the-332d-infantry-on-the-italian-front/
This site is mostly about the 332nd Infantry Regiment's activities in Italy. It says nothing to support the statement that the 83rd "sustained relatively low casualties." And it doesn't provide any source for its information.

from there down to [13][8]

[13] see above. The source agrees with the AI-wiki article.

from there to the end [18]

[18] https://www.armyupress.army.mil/Portals/7/combat-studies-institute/csi-books/OrderofBattle4.pdf
The article seems correct. I didn't read the source closely. It is very detailed and I didn't need the information.

Adding an emoji to a post

2019-08-13T00:00:00-04:00

Today I learned…well not exactly today, more like yesterday. Anyway, I figured out how to put emojis on the website. I was writing an article and wanted to end a sentence with a smiley face. I'm using Pelican to generate this site, so my first instinct was to Google "emojis in Pelican." I found source code for a plugin, then a blog explaining how to use it. Problem was, I wasn't doing it exactly the same way as the explanation—I wasn't using a python virtual environment. So one thing and another, the files probably didn't end up where they belonged, or I didn't talk nice enough to Pelican to get it to find them. It didn't work.

More Googling turned up "unicode" in the same result as "emoji." Aha! says I. Get the unicode number and just plug it into the article somehow. I was almost there, you have to convert Unicode numbers to their decimal equivalent for the browser to understand them. So I did and it worked!

Now which is easier, cloning the source code for a plugin, downloading a dependency, python-setuptools, then hoping python will install it, then grabbing a list of emojis and their values, putting it where it belongs, telling Pelican about it in two different places,

look up the emoji online, get the hex code, run a 17 character command to convert it to decimal, and just add a $# and a ; when you paste it in the article? I ask you.

For me, the second method. I'd never remember the markdown short codes from one time to the next–I'd have to look online–so I might as well look up the unicode number instead. I can't see the point of using markdown when it makes things harder. Along the way, though, I did grab the list of all emojis and their unicode numbers for myself, in case the site goes offline.

So how many times will I ever use an emoji in a blog post? Maybe never again.🙂

Update

September 15, 2021: And I haven't used one since.
April 10, 2025: Emojis have come a long way since 2019 and you can probably insert one by throwing a dart at a chart on the wall behind your computer. Meanwhile I have learned to use Emacs which lets me insert an emoji with the perfectly easy key-combination of C-x 8 RETURN then start typing the description of the emoji you want. It works. Now I can spam my articles with emojis. 😊

Accessibility

2022-11-29T00:00:00-05:00

I am making some changes to the website to improve its accessibility for the blind and those with difficulty seeing.

I'm currently making changes to the individual articles. Most of the problems seem to be with appropriate alternate text and with the inline footnotes. This will take some time. If you have problems reading one of the articles that I haven't improved yet, please let me know.

There were three major changes to the overall site design. First, the pastel green background is now white. The white background with black text provides more contrast than the pale green.

Second, the menu at the top of the page is gone. The menu items were too small and were dark green on light green–even worse than black on green. While I was working on the menu I discovered that the hamburger menu for tablets and phones was not working anyway, so I removed the menu altogether.

Last, among the obvious changes, the text over the image in the sidebar or footer is now white on black. In general, text over images is hard to do right. It doesn't always provide enough contrast, in fact I had trouble reading it myself and I knew what it said. White on black was a "quick fix". Maybe I'll figure out something better later.

The family trees section of the website is generated by a separate software program. Most of it seems to pass the accessibility test, except for–you guessed it–the hamburger menu. I will get to that in time. On a full screen desktop there seem to be no significant accessibility problems with the family trees.

The original article above was written November 29, 2022

Edited May 17, 2023

A few more changes: All links are now underlined. The index page has the correct order of headings.

Living with Sid

2019-09-01T00:00:00-04:00

Sid is the name of the unstable branch of the Debian GNU-Linux operating system. He's usually easy enough to get along with, if you keep your distance and give him the respect he demands. For instance, if you try to update Sid and he says he's going to remove your complete desktop, believe him. When I first met him, I didn't really think he would do such a thing. But he will and he did, unless you're careful.

Another time, one of the programmers who make Sid what he is named his app the wrong way. Sid didn't take kindly to that. He wouldn't agree to update it. I pushed him a bit too far on that point and Sid pushed back. Result: 'no printer for you, take that!'

So I learned to take it easy on Sid. The technical term is I use "upgrade" instead of "dist-upgrade." This is like keeping Sid on his medication. When he is good and ready, and has decided not to break stuff, he will update what you need, but not sooner.

We got along fine for a long while. Until a few days ago when Sid just lost it, all on his own, with no provocation on my part. Someone told him that the "ef2progs" package only liked the company of the "logsave" package. The truth was that "ef2progs" couldn't live a day without having "logsave" around. No one told Sid but he found out anyway. He was extremely indignant and pouted and wouldn't do a thing. All he did was hand me a cryptic message from "ef2progs" saying 'init --line 391, can't find logsave'.

At first I was tempted to whack him one, and send him packing, but instead I decided to give Sid some quiet time. I went next door (I dual boot) and asked Buster if he wouldn't mind my staying with him for a few days. From his house, I asked people (via Google) just what that mysterious message meant. For 24 hours no one seemed to know. Then the next day, someone said (aka 'filed a bug report') that he too had seen the same message. Even better, he knew what Sid needed to make him feel better: sneak up on him (chroot), and get him a copy of "logsave" for his own. I did so. While he still didn't know I was there, I updated him. Lo and behold, even newer versions of "ef2progs" and "logsave" for Sid to play with! I just knew he would be happy now.

And he was. And we're back to speaking to each other. And I learned how to talk to him when he's in one of his moods and get him back on his feet. He needs someone like that. Sometimes we all do.

Update

As I lazily port articles from my old site to this one, I came across this account of my life with Sid written in July 2019. I have to say that, for the time being at least, Sid and I have gone separate ways.

You might remember that in 2020, at the beginning of the pandemic, the government was throwing money at people to stimulate the economy. I decided to do my part so I bought a new desktop computer. It came with Windows. I realized I'd better keep Windows because it reliably ran Zoom. I needed Zoom because of the pandemic. (Life is full of those little circles, isn't it?) Anyway, I only have so much room on the disk for operating systems so it's just me, Windows, and Debian stable for the time being.

But stable being the boring, predictable setup that it is, allowing you to actually accomplish things and not spend an hour a week keeping it running, I will probably make room for Sid in my life soon, likely when I finish moving these articles over to this site. (We're circling around again, aren't we? I'd better stop here.)

How a non-Python-programmer survived a Pelican point upgrade

2019-02-18T00:00:00-05:00

A while ago I decided I was tired of handcrafting an individual .php file every time I added an article to this website. So I decided to shop around again for a static site generator. I had used Jekyll a few years ago so I thought I'd give it another try. This time it was broken on arrival–I forget how–so I swept up all the little rubies and gems in my home folder and went on with my search.

Hugo was still as sparse as ever, so after a bit of looking I settled on Pelican, and found a beautiful theme called backdrop at backdrop pelican theme, which I modified using his updated css from his personal site, my colors, etc.

Things went well until one day last December I started editing a new article and got an error message. My first thought was "Oh no! Why me? Why now?" I was using Debian Sid, so my second or third thought was "I wonder if there was a major upgrade? Let me go check." Sure enough, pelican 4.0 had been released November 13, 2018, and had just hit Debian's unstable repository without my noticing.

Help!

The logical place to look for help seemed to be the theme repository on github. In fact, Googling one of the error messages turned it up as a top hit. But the theme doesn't seem to be currently maintained, as the writer has gone on to bigger and better things. I mean that sincerely, without saying more about him than is required for this context. By the way, are any of the pelican themes maintained?

It looked like I was on my own. Welcome to the world of code hacking. Well not quite, I'd adjusted a few files in Gramps, article to follow someday. But this was more serious. Without a working site generator I'd be going back to writing each file by hand.

Slugs

The first error message had something to do with slugs. Besides being slimy creatures that get run over by cars, slugs have something to do with naming your files, don't ask me what. I found the 4.0 docs, even though Google still insists on listing 3.x higher, and fixed the slug format. Not too hard.

Configuration

Next was a message to the effect that PAGINATED_DIRECT_TEMPLATES are removed in favor of PAGINATED_TEMPLATES. OK, I'll just change the name of the setting in pelicanconf.py. Nice try. Pelican said "not so fast" and gave me the message "articles_paginator not defined."

Real code problems

Big trouble now, since that looks like some deep code thing, either a variable, object, inductor, conductor, or some other abstract noun way beyond my expertise.

I turned on debug mode, and was either further confused or able to trace the error to a specific file in the theme. Probably the first, since I think I found the file by just searching for "articles_paginator" in the theme folder. I couldn't for the life of me figure out what it was doing and how to get it to stop. Or, in programmer speak, what values it took and how to feed them to it.

A tactical retreat

I gave up, downloaded pelican 3.7 from the Debian Stretch repository, put a hold on pelican in the package manager, and went back to the .php format anyway. But that gets tired quick. If you want to delete a file, you have to delete all references to it in your tags, categories, and archives files as well.

'It was pagination, my love'

So last weekend I worked up the nerve to take another run at pelican 4.0. I looked again at the error messages and realized that the ones that were causing the trouble all had to do with pagination. Now I didn't use, need, or want pagination. Could I take it out of the theme on my own and make things work? Not a chance.

So I went through the pelican themes on github and found someone who felt the same way toward paginating as I did, namely "We don't do pages." I grabbed the category.html file from the Just-Read theme and dropped it into my theme folder. It worked! I modified it for the tags and archives pages and they worked too!

I didn't like everything about it though, so I cut out the unordered lists and the date stamp. And I really liked having a summary of each article on the category and tag pages. So I grafted back the code from the backdrop theme for summaries, and Voila! things were just the way I wanted them. The results are what you see on the main part of this website. If you like the theme, you are welcome to it. You will find it in https://myoldohiohome.com/theme/. The background picture is mine though—I'd prefer you didn't use that, at least not without asking.

Conclusion

So I changed a few configurations, removed a couple of settings, and swapped out some code for some other code. Do I understand eveything I did? Not really. Do I know how it works? No, but I know it works. Do I have to understand it to use it? I hope not. Besides, how many Python programmers know what Griffith's Valuation is? Hint: it's not an algorithm.

Credits

The picture of the typewriter is from Typewriter by Michael, at flickr, and is used under the Attribution 2.0 Generic Creative Commons license.

The picture of Python code is from File:General6545.gif at wikimedia, uploaded by Sagaru9535, and used under the Creative Commons CC BY-SA 4.0 license.

The drawing of the blank pages came from pixabay.

The "No" sign came from Wikipedia and is used under the terms of the GNU Free Documentation License.