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.