Voice of the DBA

Tag: AI

Don’t Fight with AI

I was recently trying to handle a simple task with a few AI tools to see how well things worked. I realized that AI isn’t great for everything and there are times you need your judgment to stop fighting AI and use other tools.

Tl;dr choose the shortest path and know your tools. In this case, just copy paste a script and results (see the bottom).

This is part of a series of experiments with AI systems.

The Scenario

I have a table with some data. I wanted to duplicate this table DDL and DML for another system. Here’s my table:

Simple thing, right? Lots of possible ways to do this, but understand, this wasn’t the task. I was doing something else, with another goal.

This task was just in my way.

First Try – Prompt AI

I use SQL Prompt all the time, so I thought, hey, AI, script this.

Well, not quite what I wanted. This works cross database, or if I make a new table name by editing the script in two places. But not ideal.

OK, I asked for the data, and this works. A bit. I only get 10 rows. To be fair, the original select I started with was top 10.

I then ask for the other data, and I go backwards. I don’t know why a model would go in this way. This reminds me of working with a junior person half listening to me.

Grrrr.

Claude CoWork

This seems like a cowork task. I’m not saying this is the best thing, and since I didn’t have a repo, I decided this over code. In any case, I asked for a task. Quickly Claude gave me options for 1) PoSh, 2)T-SQL, 3) something else. I picked 2 and it took about 4 minutes or so, but I got this script.

I had to open in VSCode, connect to SQL, and then it didn’t work:

Paste back into Claude, get a quick fix, maybe 15s.

Copy/paste the script, which runs. Certainly I could have put this back in SSMS, but I’m not sure that’s easier/harder.

I copy the results, which is fairly easy here.

I have the script I need and can move on:

Redgate Assistant

We’ve added a new Redgate Assistant panel to SQL Prompt. I tried this next, and got a few results. The DDL was first, which I could copy/paste into my new query window.

The second was a script I pasted in and ran, which gave me insert statements. Taking these results gives me about what I have above from the Claude script.

This was significantly faster. From prompt to result was in the 10s range and then I could get the results in a few more seconds. That’s quick, and I didn’t lose my thought context.

The Best Way – SQL Prompt

I’m experimenting with, and it’s been a tool I reach for often, but as I was annoyed by Claude taking so long, I realized the best way was actually this. Run the query in SQL Prompt that’s at the top. Then select all the data in the results by clicking the top left box and right click. Select “script as insert”.

I can then easily search/replace or edit the name of the table.

Doing this, once I thought about it, was about 5 seconds of effort, no context switch. Just grab this, change the name and go on with my other work on another connection.

Use All the Tools

I do think AI is a great tool for me. I also think it can cause me to spend more time and effort (and sometimes $$$) on simple tasks. While I’m all for experimenting, I also want to be efficient and effective.

Fortunately, I’m somewhat paid to try different things and report on them.

In this case, the KISS solution is best. Use Prompt what what it does best, work with your schema, code, and (lightly) data. I know I could use an MCP server, or Claude Code at al with more guidance, or something else, but those start to feel like using AI for the sake of AI and burning tokens when there are better tools.

Not everything is better with AI. The people who succeed and prosper in this crazy AI world will embrace it when it’s most helpful and ignore it when it’s not very useful.

August 10, 2026
The Quiet Part

Apparently, Meta did what a lot of employees suspect their management will do: use AI to lay off people. In this case, there is a report (and lawsuit) that Meta used it’s AI-integrated HR platform to make decisions about who to let go in a layoff. The rumor is that the AI used productivity metrics to choose who was the target of the layoff. As with a lot of AI failures, this appears to be another case of poor communication guiding the AI, or the AI not actually taking individual situations into account.

A number of the people terminated were on maternity/paternity leave, which is a protected activity. Others may have been on other medical leave, though for privacy reasons, the article doesn’t have firm data to prove this. The lawsuit will likely bring more of this out, but this appears to be a case not just of AI making decisions, but of poor behavior from management. Plaintiffs were discouraged from taking leave off, which is something sh****y humans have said to people for decades. We need you; your baby or family isn’t important, so don’t use your leave. It’s one aspect of working in the US that is way worse than overseas, where there are more employee protections.

Meta disputes the case, saying the AI didn’t make decisions. However, that brings out an interesting point. If the AI recommends things, who’s responsible? The humans, right? They still have to sign off on the decision. If they don’t perform due diligence, they’re still responsible, correct? I think so; after all, I’m responsible for code the AI writes if I commit it. Even if an agent does the work, I have to oversee it and approve (or grant permissions for) the actions.

I. Am. Responsible.

Trusting an AI to do a lot of work is like trusting a lot of smart, but very inexperienced staffers to work in your environment. There are always inconsistencies and reasons why we might code something, configure something, or deploy something a certain way. What seems like a good way to tackle the situation from the outside doesn’t always make sense when you have experience. Humans often have experience that AI agents lack.

LLMs are relatively stateless, and while we can provide context, give them guidance, and provide comprehensive codebases, they still sometimes do silly things. This can be problematic, especially with database changes, which are stateful and disruptive to rollback.

AI agents can make mistakes much like humans, only faster. Much, much faster.

Labor is one of the most expensive parts of many organizations’ budgets. Plenty of management would like to replace relatively expensive humans with cheaper tokens. That isn’t working out as well in practice, despite lots of experiments. Hopefully, other organizations realize that AI is a tool, not a replacement for humans, and we can’t trust it or even believe it’s outputs without some human judgment.

Steve Jones

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

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

August 7, 2026
Are You Working More Hours?

Recently, I noticed my son was coming home later and going to work earlier. He typically works a 9/80 schedule as a software engineer, but at times he might work extra hours on a deadline. His company tries hard to keep employees working a set schedule without overtime. Unless there is a need, after all, this is software. However, when they are on a deadline, management warns people, and they try to manage overtime to reasonable levels to avoid burning out employees.

I asked him if he was extra busy or if AI was encouraging extra hours. He told me this was a short-term project with a few more hours, but mostly the team was decompressing a bit after work. I completely understood that as I’ve spent my share of time with co-workers at theend ofday, sometimes sharing a drink or meal nearby, sometimes just chatting in the office or the parking lot.

There have been a number of studies and reports that AI is making people work more, not less. The time spent on a variety of tasks, especially those where we are reading or interacting with text, has grown. I suspect there is additional pressure from management as well to get more done since everyone has an AI assistant around. There is also the excitement of tackling new projects, which can lead people to spend more time at work. While I appreciate that AI can be exciting, and you might love it, don’t lose yourself in it at work. It’s still just a tool.

And, of course, there’s the token spend. Some managers are measuring people on the amount of work their AI assistants do, rather than by what gets done. I’ve certainly seen plenty of people using AI to perform busy work just to be seen as using AI tools.

At times, it seems people are using AI to process more information, which they then use AI to summarize. They post these summaries, which grow in number because the AI can produce more of them. Others use their AIs to read these summaries and produce their own summary of what they should be reading. It certainly seems like AI is producing more copies of information, summarized over and over, giving all of us more things to keep an eye on.

That seems silly. While I like AI, I fall into that group that uses it lightly for targeted tasks. I certainly try not to create more reports, summaries, or even emails to send to others, especially large groups of people. We have enough to review without AI creating even more tasks to deal with every week.

Steve Jones

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

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

August 5, 2026
Finding Bad Queries

T-SQL Tuesday #200 was in July, hosted by Brent Ozar, and it was a great topic: How do you recognize a bad query? In the age of AI, when lots of people will get queries written by others (people or AIs), how can you easily and quickly review code? Review is already a challenge in the software world, and I am sure it’s going to be even more challenging as people let machines author more database code.

Lots of you might hope that an AI agent will write better code than your average developer, but I don’t know if I’d count on that. There is a ton of poor query examples on the Internet and that’s where AI models are trained. You need some sort of feedback loop, good testing, and strong guidance if you want better query code. I think it’s as likely as not that AIs will produce poor queries just like humans.

Just faster.

How can you recognize poor queries? How do you judge if there are issues? Brent’s roundup shows what a number of people think, and there are some good “quick checks” to use to evaluate your code. The things that people wrote in their blog posts are the types of things that I’d want added to Flyway’s Code Analysis rules to catch problems before they get deployed to production. After all, anything that gets to production usually lives for 10 years (my rule of thumb).

Getting feedback early in the development process is critical. We know from over 50 years of software development that finding problems early is less expansive than finding them later. Whether we use humans or AI agents, we don’t want unnecessary time spent on simple bad code things that we know cause issues. Shift-left is still a challenge, even in the automated era of DevOps and guided AI agent skills. We need reliable, repeatable ways to analyze code and limit the downstream effects of poor quality.

Especially these days, where the volume of changes is overwhelming CI/CD systems. This was a problem already in organizations with too many teams in one codebase. It’s a growing problem in more organizations as users use AI and submit more changes.

Plus wasting time gets expensive. Human labor is slow and spending time on more tokens for rework gets expensive.

Don’t let bad queries flow through to CI/CD systems if you can avoid it. Learn to provide quick feedback early to whoever, or whatever, writes your SQL.

Steve Jones

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

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

August 3, 2026