The Slow Growing Problems

Both as a DBA and developer, I’ve had plenty of immediate, this-is-broken, fix-it-quickly issues. Usually, I, or someone else, wrote some bad code and somehow got it deployed. I mean, I do test things, and I would (probably) never change code after I’d tested it to fix that one little annoying thing, like the formatting. I’d (almost) never do that, and I’m sure you wouldn’t either.

Yet somehow bugs slip in at times.

Those are the acute issues, and they can be hard to fix at times, but often we can reproduce the problem in development and build a fix. Sometimes we even spot the issue quickly and just fix it in production. I’m sure you never do that, but I have had that experience myself a few times.

However, in the database world, we can have other, slow-growing problems. I saw this post from Jacob Sebastian about production issues that don’t trigger alarms. There are just slowdowns that trickle across multiple systems and cause issues for clients. These aren’t things you instrument for, as a slowdown isn’t necessarily an issue. These things can resolve themselves, or they can develop into a major issue.

I think about this like vehicle traffic. A minor fender bender on a highway might not be a problem, but it can become one. Cars don’t get out of traffic quickly enough, or traffic police don’t arrive soon and move the cars. Traffic starts to back up, which slows down the response, including that important tow truck that might keep things moving. Suddenly, it’s not a few people inconvenienced by an accident, but thousands.

There are likely signals in your environment that would let you know about a potential issue coming soon. These are subtle and not always indicative of a problem individually, but taken together, they indicate a production issue is going to occur. To me, this is a place AI can eagerly be taught to look for these signals and then happily keep looking for them every day.

The future of monitoring is the active examination of correlated data that precede an issue, hopefully giving humans, or other AIs, enough time to respond and prevent customers from experiencing a slowdown.

I’d certainly welcome this in both traffic motorways and database systems.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Note, podcasts are only available for a limited time online.

Posted in Editorial | Tagged , , | Leave a comment

AI Experiments: Parsing Payment Memos

As part of my running the SQL Saturday charitable foundation, I get sponsorship money from vendors. Primarily Microsoft and AMD, but I hope to change that in the future. In any case, I recently got a payment notification that my invoice had been paid.

I knew I had a few invoices outstanding, so I wasn’t sure what was included. MS tries to bundle payments, but I don’t get an email for each one. For this one, I didn’t see an email, so I suspected I’d put the wrong one in or typo’d it.

The Usual Process

When I get payments, I have to reconcile those in my General Ledger, recording the amount and allocating to the events. I then send out payments to the event organizers and record those.

This is a mostly manual process, but since I sometimes submit multiple invoices at once, I have to figure out what was paid. I could submit 3 invoices and get 1, 2, or 3 payments. Microsoft Finance usually bundles things, but since I can have a lot of events in flight, I need to know where money gets allocated.

In this case, I didn’t see an email and didn’t want to log into the invoice system and start finding the various invoices paid and clicking through details. Instead, I logged into the bank to verify the amount and I saw a memo. It was something like this (I’ve changed a bunch of data in here.

2026-06_0123

I thought it would be obvious which invoices were paid, but I couldn’t quickly figure this out. I decided to turn to AI.

AI to the Rescue

First, I knew I had a “no training” AI plan with Claude, so I wasn’t concerned about data release here.

I had this prompt and then pasted in the data: “can you help me separate this by ? and make sense of what is included?”

The result was interesting, and useful. It labeled this task as EDI 820 parsing, so apparently this is EDI format. The last time I worked with EDI is was XML based, but perhaps this is the new way of doing things.

The results were great. I got a summary, none of which I needed, but good to know this was easily recognized and parsed.

2026-06_0124

The really interesting part was below some of the acronym descriptions, where my invoices were found.

2026-06_0125

I knew this would be certain events, but wanted to double check the numbers. When I put in an invoice number, I use the date and event. Here I got 3 of my events (1146, 1154, 1134) paid from a day where I invoiced 5 events. This let me quickly enter my GL and also know to whom I was sending money.

A cool time saving AI trick. Rather than 10-15 minutes to reconcile things, AI gave me answers in seconds and I had fixed the GL in a couple of minutes, allocating the funds to events.

Of course, I needed to ensure data security with my plan and I verified these were events where I had planned to send money. Still me as the expert reviewing things and making decisions, but way easier than trying to sort out invoice numbers from a bunch of EDI text.

Posted in Blog | Tagged , , | Leave a comment

Liability for AI Errors

This week there was an article that speculated that doctors in the UK could be liable for errors made by AI tools unless rules are changed. The argument is that AI tools should be treated as products, which isn’t necessarily the case right now. Right now doctors may face all the liability instead of AI tool makers having some responsibility. From my reading, this doesn’t appear to say that doctors aren’t still accountable for mistakes, but they aren’t wholly accountable. The Medical Protection Society wants the technology vendors to bear some responsibility.

I have to admit I’m torn here. If doctors are using tools, they should be sure the tools work well and they agree with the recommendations or results. However, I think AI changes things somewhat. If I read a medical device, say one that analyzes blood, I expect that the results are deterministic and accurate. If they aren’t, how could I, as a doctor, know that. The companies the built (or maintain) the device would be culpable for errors.

Using AI assistance, however, is a little different. This is a non-deterministic interpretation of data. In the same situation, if an AI were to interpret blood results and summarize them, perhaps failing to point out a deviation of a value and this impacted patient care, is the AI responsible? The doctor for not realizing there is an issue? Joint responsibility?

I think it’s unclear. I’m not 100% sure how I feel here, and I lean towards both being liable. If someone is training an AI model to help with medicine, then they ought to bear (and feel) accountable for results.

This seems different than software engineering to me. In medicine we have humans overloaded and AI is supposed to help, but has to be responsible. I don’t think the stakes are as high in producing software. It’s an arbitrary decision to say we need to get xx work done with yy resources. AI can help, perhaps amplify the abilities of people to produce code, but the people still have to verify the AI results. Any time pressure is a decision we make, not one brought on by medical issues.

Perhaps this seems hypocritical, and I will admin I’m not 100% sure how I feel, but I’m more concerned with AI technology bearing responsibility in healthcare than software. Do you feel the same way? Or perhaps in either case the AI is just a tool? Let me know what you think,

Steve Jones

Posted in Editorial | Tagged , | 1 Comment

Republish: The Degradation of the Turing Test

I’m on my way back from Frankfurt and PASS Europe. It’s been a long week, a quick Tue-Fri trip to the EU and my brain is a bit fried. Lots of chats and conversations, and more than a few time zones.

You re-read The Degradation of the Turing Test while I try to sleep on a plane.

Posted in Editorial | Tagged | Leave a comment