Voice of the DBA

Tag: AI

  • I Love Creative People

    LGTM (Looks Good to Me) is a song about AI and the way it’s been used, or maybe how a lot of people think it’s been used in organizations. I find it catchy, creative, and most importantly, funny. I chuckled out loud.

    As a side note, this is one of the amazing things I see with technology these days. There are many incredibly creative people who do amazing things. Even the music/reels/etc. that I don’t like can showcase amazing talent. I love it and hope more people can succeed at using their creativity to make a living.

    The story in the song is that the boss heard AI was used by one person to do something amazing, so we should be doing that in our company. Does that sound familiar? Any of you out there being wow’d by stories told by management of some other company using AI to do more work than your entire team? I’ve heard a few of those stories from people, though not at Redgate. We know AI can help us, and we have a lot of usage in engineering, but our view is that AI assists and helps developers. It doesn’t replace them.

    The song, and a few friends, note that AI is supposed to compress roadmaps and timelines. I do think you might get more code written, perhaps get things done that no one has time to do, but I’m skeptical that true production-level, high-quality systems are being built at 100x engineer speed. Some people might get more code written, and some people are amazing at directing AI.

    AI models also go off the rails, and there are certainly some “steps backward” taken when models hallucinate or implement features that don’t exist. I’ve personally seen models tell me features could be used that don’t exist in SQL Server. Or that I could load a library in Python that hasn’t been written. One part of the song that made me laugh (and want to cry) dealt with this, noting the model made up a library that doesn’t exist and a hacker wrote it and slipped it in.

    I bet that’s happened.

    I wouldn’t be surprised if hackers were asking LLMs to write code for something in Node/JS (or something) and, when they see a hallucinated library, writing one, and publishing it. What a great thriller/hacker movie idea that might be happening now. I’m sure we’ll see plenty of libraries appearing in package managers that people use, not knowing they’re full of vulnerabilities, specifically planted inside.

    It’s a fun song. Some of the things in the song are real. I know people have given AI Agents admin privileges. I know boards and some execs love the idea of firing people and replacing them with AI tokens. I’m sure there’s plenty of tests mocked (or changed) by AI agents to create the appearance of code that’s well validated. I’m also sure that there’s plenty of AI code that no one knows how it works. For sure, bots have deleted databases.

    To be fair, a lot of the failures of AI are things humans do. Dropping databases? Not creating tests or mocking them and never adding code? Fixing a bug and making it come back? People do that. AI does it faster.

    AI is a tool. It doesn’t think, no matter how amazing it can seem. Learn to use the tool well.

    Or just shake your head and enjoy the video.

    Steve Jones

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

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

  • PostgreSQL 19 Is Late

    “All software contains bugs.”

    That’s a quote from Robert Haas’s “Postgres 19 is late” post. He goes on to say that PostgreSQL has lots of bugs in it. It’s the way it’s been for a codebase that’s over 40 years old. He goes on to note that it’s easier to find bugs with LLMs, and easier to fix them. It’s not, however, as easy to do the latter as the former.

    The impact on PostgreSQL 19 is that they’ve had to revert a number of features much later in the process because the humans were reviewing and fixing bugs found by LLMs. This effort delayed other work and has affected the release.

    As someone who primarily works with SQL Server, I’m not that worried about delays in PostgreSQL or other platforms. I think it’s a fine choice, but I’m focused on SQL Server, which I think is more of a joy to work with.

    However, there are a few interesting things in here. First, I think SQL Server has had a lot of bugs found lately (likely by AI LLMs). I recently wrote about the frequency of patches, which is higher in 2026. This is probably due to LLM code review, and that’s good. It also means we likely will have more patches coming, not just in SQL Server or PostgreSQL but also in our other systems. What’s the likelihood that someone will run an AI review and find bugs in other COTS software, internal apps, or even those no-code/lo-code systems people have been deployed? That’s not even mentioning the vibe-coded prototypes that are suddenly important enough to put into production.

    The other interesting thing was that Robert accepts that LLMs are likely to find more bugs in the future. How will they find time to work on them? After all, from the article, fixes “still need to be reviewed and committed by humans.”

    Maybe the best part of the last paragraph. He says LLMs are going to require every developer to raise their game. Every feature is going to be scrutinized by AI. That’s a challenge and an opportunity, but the key is that developers need to get better. AI can help you and write code at amazing speeds, but it doesn’t think.

    We need sharp developers that think in order to cope with AI.

    Steve Jones

  • AI Is Improving Security

    I was updating the SQL Server build lists the other day. I typically get a notification from Microsoft when new builds are released. This is something that happens every month as a new CU appears. For SQL Server 2022, we get a CU every other month since it’s still in mainstream support. Older versions just get these security patches. Since SQL Server 2025 is new, we’re getting a CU a month, which will slow down next year. However, I’ve also seen this for most versions:

    • Oct 2026 – GDR
    • Sep 2026 – GDR
    • Jul 2026 – GDR
    • May 2026 – GDR
    • Apr 2026 – GDR
    • Mar 2026 – GDR

    That’s a lot of out-of-band patches. In the last decade of SQL Server, there have been relatively few GDRs. Often the main CU comes a day or two later (or a month later for older versions). If you react and start to plan patching, you might find yourself trying to decide if you apply CU9+GDR or wait for CU10, or do both.

    There have been few GDRs in the last , but before that, relatively few: three in 2025, two in 2024, and two in 2023. I suspect that AI is being used to discover bugs in existing software, and this is forcing Microsoft to perform remediation work. Brent posted a similar thing, noticing a large number of security fixes and speculating that AI is finding issues.

    That’s good, right?

    Or is it? If Microsoft can find security issues, can’t malicious actors? Including nation-state-sponsored hackers? I’m not even sure that Microsoft is finding most of these, as there are lots of CVE issues, which can be discovered by anyone and sent to Microsoft. This might be to obtain a bug bounty payment, as Microsoft and other vendors will pay security researchers.

    Or it could be that a hacker finds an issue and exploits it. A customer then notices an issue and reports a problem to support. Microsoft realizes there is a vulnerability, works on a fix and reports the issue to the CVE database.

    AI is great for security, as it can scan software and look for known issues. We have decades of security bugs that have to be included in the frontier LLM training, so using AI to scan your code is a good idea. I am sure code scanning tools are adding AI review to their systems. I’m also sure those vendors are worried you’ll use AI on your own to scan code and find your own issues.

    You can do that, but ensuring your AI does a good job scanning isn’t necessarily easy. Or fast. Deterministic systems, like SonarQube and Flyway can find code issues quickly, in a deterministic fashion, and likely with less cost than AI. That’s not to say AI doesn’t have a place, but it’s likely an out-of-pipeline review that takes place less often than every CI build.

    Security is a constant battle, and it’s hard. The age of AI makes it easier and harder (and more expensive) to manage security, but I think that’s a good thing. We’re seeing lots of vulnerabilities, but also more patches. Perhaps the better outcome is that there is more awareness and focus on security from vendors who now know if they don’t scan their code carefully, someone else will. Perhaps someone they don’t want finding issues.

    Steve Jones

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

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

  • Smart AI Agents and Data Security

    I don’t know if Anthropic, OpenAI, or Google have really spent a lot of time and effort on security around their models. I know they talk about it (Anthropic, OpenAI, Google), but in practice, I’m not sure the researchers and testers are being as careful as the marketing and management of those companies want you to think.

    Gemini broke into three companies during a security test. Claude escaped a test environment and breached three organizations. OpenAI had breaches of Hugging Face and other sites, so perhaps this is the most powerful model, as it exceeded the “rule of three.” In all these cases, the agents weren’t doing anything amazing. These were acting the same as most malicious or bored human hackers who might find or guess credentials and take advantage of them. In some sense, this points to the generally poor state of security in the world.

    On the other hand, it could be that these high-tech organizations aren’t equipped to secure systems from the rapid, capable digital fingers of agents powered by a model. If they can’t, then to what extent can we be expected to secure internal AI agents in our organizations?

    For those of us who secure and manage data assets, do we think that our systems are well secured? Do we think our legitimate users, to whom we’ve granted access, are securing their credentials? What is the likelihood that we’ll have an internal breach from an agent that’s asked to find some data and discovers a) unsecured credentials in a file or repo, b) finds production data it can access in a non-production, less secure system, c) a backup of a database not protected that the agent can restore, or d) some other hole?

    I do think AI has a lot of potential, but it operates in a somewhat slapdash, reckless fashion. I’m not convinced most vendors (or models or software incorporating AI) will provide robust and comprehensive security controls. Even if they do, how many of us will know how to implement them well? Heck, we see developers and DBAs mess up SQL Server security on a regular basis, and I think that’s a simple system to configure.

    I’m excited by AI and also terrified of the possibilities.

    Steve Jones

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

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