Voice of the DBA

Category: Editorial

  • Limit the Blast Radius

    You still need DBAs (that know how to back up systems and test restores). If you think you don’t, or if you manager does, then perhaps they ought to read this piece on how an AI agent deleted a production database. This wasn’t the case of an agent just running around with sysadmin access to all resources, or a lack of tests that allowed bad code to flow through a CI/CD process.

    This was a system design that had a hole in it. An API call to change infrastructure that could change both staging and production. Not something an AI set up, but humans did. A hole from both PocketOS and the API vendor that allowed the AI agent to make the same type of mistake we’ve seen humans make. A mistake of not double checking, not verifying, not following the rules of getting a second set of eyes, even a second set of virtual eyes, on the code that could drop resources.

    Reading this, I can imagine this is how some of the AWS and Azure outages occurred over the last decade. Not the 2025/2026 AI inspired ones, but the 2010-2015 human mistakes that didn’t expect a change to have such a far reaching blast radius,

    You still need guardrails, for both humans and AIs. Don’t get slack and assume either truly knows what they are doing and deserves rights everywhere. Don’t assume that your guardrails were setup correctly. AI agents make great helpers. Use some read only ones to examine your setup and look for holes. If/When we get the next Claude Mythos model (or the equivalents from Google/OpenAI/etc.) have it look for precisely the types of holes that come from bad code that looks to reset, redeploy, or re-anything in your environment.

    We separate out roles for different people to limit the blast radius of the mistakes we inevitably make. AIs aren’t necessarily smarter or better than humans. Just faster. We need separate roles, separate rights, and governance for AI agents, precisely because they can make decisions faster than humans.

    There’s tremendous potential, but and tremendous danger in allowing anyone, or anything, too many rights in any organizations. RBAC, audits, and all the other things we implement to try and reduce the number of silly mistakes are still needed. At some point we’re going to see amazing social engineered emails, messages, XSS, and other items that are designed to fool the AIs just like humans have been fooled in the past.

    We need to ensure we set good guardrails and limits when that starts to happen. Or we’re going to lose control much quicker than expected.

    PS If you want a fun and slightly scary read on how AI could go sideways, I enjoyed The Final System recently, which made me not want to deploy any sort of AI agent beyond tightly scoped ones with very, very limited rights.

    Steve Jones

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

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

  • What Can AI Really Do?

    I wonder how many of you have tried vibe coding something with an AI tool. If you haven’t, I certainly recommend it. I’ve been a bit amazed with a few of my AI Experiments, including my loading of a lot of inconsistently formatted data into a database for USD$5.

    To be clear, there’s plenty of vibe coding that might not be production-ready, but have you ever been handed code from a human developer you didn’t think was production-ready? Or deployed code like that? Certainly, AI could exacerbate the situation, but it can also spark ideas, ease (and speed) development in small ways, and tackle the backlog of things your org needs.

    Especially small tools.

    How big a concern or help will this be? I ran across an interesting article from a semi-technical person trying to build a text analysis tool. This is the type of thing we may do as database pros, but we wouldn’t have time to service every request for this assistance. There is a mixed bag of success in the piece, and a recognition that software developers have skills and knowledge that AI tools can’t necessarily duplicate in the hands of a non-pro.

    However, that’s where I think software engineers and database professionals have to learn to leverage AI tools to become more efficient, prove their worth, and, honestly, get more done without working longer hours. It’s also a place where you might guide users in producing some useful, but less mission critical software for themselves with AI. That might lower the number of requests I get.

    To me, that’s the direction I want to go with AI. More productive, less stress, and the same (or fewer) hours.

    What do you think AI can do for you? Let us know today.

    Steve Jones

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

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

  • Republish: Writing Before Reading

    I’m still in Europe, now in Rome. I’m sure it’s amazing, but while I’m gone, you get Writing Before Reading. I don’t see this in the archive, so here it is in total:

    Writing Before Reading

    This editorial was originally published on May 21, 2020. It is being republished as Steve is gone this week. Have your thoughts changed on reading and writing code?

    Coding is one of the few (or maybe only) places where we learn to write a language before we learn to read it. Many of us get started in some way by working through exercises, looking at very small snippets of code and then starting to write our own. Perhaps that’s because we experiment by changing the behavior of the computer, which naturally takes some writing work on our part.

    Perhaps we can do better, and should to better. Perhaps we would become less susceptible to the Not Invented Here (NIH) stance that so many developers seem to take. Not with major projects, but often with small sections of code or libraries, preferring to structure something new than re-used (and take the time to understand) what’s already there.

    This isn’t to imply that most developers need to write their own code or don’t work to understand others, but often they prefer to rebuild something in a way that is more familiar. It’s a form of the Mere-exposure effect, and it sometimes leads developers to prefer certain patterns, tools, platforms, and more. Perhaps it’s the opposite of the shiny ball syndrome, which leads people to chase the newest thing available in their area.

    I know there are plenty of developers that copy and paste code from the Internet as well, which might seem to be a way of getting around NIH syndrome, but I think many people do this when they find code that solves a problem. Even if they don’t understand how it works, they’ll seek to reapply that same code to a new problem.

    I do think reading code is hard. In some sense, it sucks. I’d often prefer to understand the basic inputs and outputs, perhaps rewriting the code to work in a way that’s more comfortable for me to understand. Maybe I better understand my own code, maybe I’m falling victim to the IKEA effect (I’d rather depend on my own software than someone else’s), or maybe I’m just being lazy.

    There are plenty of articles on how to read other people’s code, and I am trying to get better at this. I do try to debug and reason out how queries are written that solve problems in the forums. I may break apart queries and try to understand how someone has used a window function or a CROSS APPLY in a certain way. It helps build my skills, but it also helps me learn to better read other people’s code and perhaps carry that skill into the future.

    Steve Jones

  • Republish: Other IDEs

    I was very lucky, and honored, this year to be picked as a part of the Redgate President’s Club. This is our sales award club, which primarily goes to reps, but sales engineers and others are picked. I was one of the wild cards, as I helped on a lot of deals last year, so today I’m in Cambridge meeting with product people and execs.

    While I’m over there, you get to re-read Other IDEs. Leave a comment and let me know if things have changed since I first wrote that. Are you using another IDE?