{"id":112551,"date":"2026-08-31T12:00:00","date_gmt":"2026-08-31T12:00:00","guid":{"rendered":"https:\/\/www.red-gate.com\/simple-talk\/?p=112551"},"modified":"2026-08-25T08:33:25","modified_gmt":"2026-08-25T08:33:25","slug":"is-ai-already-learning-from-our-old-poor-quality-code","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/ai\/is-ai-already-learning-from-our-old-poor-quality-code\/","title":{"rendered":"Is AI already learning from our old, poor-quality code?"},"content":{"rendered":"\n

In this Simple Talk opinion piece, Greg Low unpacks how AI models actually filter and weigh training data, why the most common answer isn’t always the best one, and why truth itself can depend on timing and context \u2014 not just quality.<\/strong><\/em><\/p>\n\n\n\n

A while back, I wrote about my experiences with trying to see if ChatGPT could answer questions as though it was a baseball umpire<\/a>. It did quite poorly but, curiously, it got hard questions right<\/em> and easy questions wrong<\/em> – the complete opposite of what I thought it would do. As such, I’m sure that the problem was what<\/em> it was learning from. <\/p>\n\n\n\n

Furthermore, I realized that the only people who ever discussed the hard<\/em> concepts were people who knew what they were talking about. So many other people had an opinion – often wrong – about the easy<\/em> issues. <\/p>\n\n\n\n

Naturally, this left me wondering: where exactly do LLMs<\/a> really learn from?<\/p>\n\n\n\n

Learning from the wrong code<\/h2>\n\n\n\n

I was interviewing a friend for a podcast and he pointed out that the same thing applies to code we write. If I look back at code I wrote years ago, I\u2019d probably cringe. Since then, I\u2019ve learned so much more about what to do right.<\/p>\n\n\n\n

If an LLM is trained on all that code, from all those years – that\u2019s pretty scary! It’s little wonder that it\u2019s likely to produce sub-standard code.<\/p>\n\n\n\n

The challenge is how it would know the difference – and not just for old code. If an LLM is being trained on code that’s simply out there on the internet, it can easily come across a mix of excellent, terrible and<\/em> beginner code. Or even simplified code examples for teaching purposes…or techniques that were once correct but no longer are.<\/p>\n\n\n\n

The list goes on: what about old Stack Overflow<\/a> answers that have since been superseded, and\/or answers that only work for one production version?<\/p>\n\n\n\n

And what about all the code that’s been written to demonstrate what not<\/em> to do – and code that happens to work but is architecturally awful?<\/p>\n\n\n\n

Superficially, these can all look quite similar in training data. So, perhaps it’s not \u201cthe LLM has no idea who to learn from.”<\/em> <\/p>\n\n\n\n

Instead, it’s more a case of, \u201cthe difficult problem isn’t finding examples. It’s knowing which examples deserve to be treated as authoritative, under which circumstances, and at what point in time.\u201d<\/em><\/p>\n\n\n\n

Another of my friends recently pointed out to me that “experts don’t often write down what THEY think is obvious”.<\/em><\/p>\n\n\n\n

Learning without enough context<\/h2>\n\n\n\n

A related and interesting issue relates to code dialects<\/a>. With the baseball umpiring questions, I noticed that ChatGPT had mixed softball rules with baseball rules. This led me to be believe that it probably wasn’t given enough information about the differences between the two sports when it was being trained.<\/p>\n\n\n\n

A similar thing applies to code. I recently saw this AI-produced code for SQL Server:<\/p>\n\n\n\n

SELECT CONCAT(c.FirstName, ' ', c.LastName) AS CustomerName,\n\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 o.SalesOrderID, o.OrderDate\n\n\u00a0FROM SalesLT.Customer c\n\n\u00a0INNER JOIN dbo.GetCustomerOrders(c.CustomerID) o ON 1 = 1\n\n\u00a0WHERE c.CustomerID = 1;<\/pre><\/div>\n\n\n\n
This is not<\/em> valid SQL Server code! I think it would work in Db2<\/a>, but not most other dialects. In SQL Server, that INNER JOIN<\/code> should be a CROSS APPLY<\/code>.<\/p>\n\n\n\n
Initially, I thought the AI must have seen some SQL code and decided to learn from it, and then mistakenly decided it was relevant to me. That wasn’t the case. When I asked OpenAI what it thought about the code, it told me it should run. <\/p>\n\n\n\n
Upon pointing out that it would not<\/em> run – and asking the bot why it (incorrectly) thought it would – its answer was fascinating:<\/p>\n\n\n\n
“Why I thought it might work: I was pattern-matching from SQL dialects and products where a function call in the right side of a join can behave laterally, and I overgeneralized that to SQL Server. <\/em>

In other words, I mentally collapsed these two ideas into one: \u201cSQL Server supports joining to TVFs\u201d \u201ctherefore this correlated INNER JOIN \u2026 ON 1=1<\/code> should work\u201d That second step was wrong. <\/em>

So, the real mistake was not checking the correlated versus uncorrelated distinction before answering. You were right to push back.”<\/em><\/p>\n\n\n\n
OK then, I suppose. So, every individual piece of the answer looks plausible, but the combination is invalid.<\/p>\n\n\n\n
Popularity vs correctness<\/h2>\n\n\n\n
A common programming pattern might occur millions of times because it’s easy, familiar, copied from tutorials, or has been around for 20 years. Unfortunately, a better technique may be comparatively rare.<\/p>\n\n\n\n
So, an LLM’s statistical advantage can become a disadvantage. The most common answer is not necessarily the best answer.<\/p>\n\n\n\n
I can imagine:<\/p>\n\n\n
\n