We’ve all tasted the fruit.
AI is awesome. It is astounding what it can do, how much it can do, and how correct it can be. It is also equally scary and world-impacting, and we can all feel the ground turning a little fluid under our feet. I don’t have big answers, but I do have some automation-related opinions to share with you right now, and they come down to one idea: use AI to help build your automation, not to be your automation.
AI is non-deterministic
As data people, we should all know what this means. Given the same data and the same prompt, AI can’t be trusted to do the same thing, make the same recommendation, or reach the same analysis twice. Even if it does today, the next model update can change its behavior without you changing anything. Reliable decision making should be based on reliable inputs.
AI is a black box
At the lowest levels, AI is still very much un-auditable. It is a black box according to the people developing it and the people trying to understand it. We can ask it why it did something, but its answer is just more generated text, not a record of what actually happened inside. We can see what it did, but we can’t verify why, and that means it can’t be audited the way a script can.
AI isn’t accountable
In my own experience, and in the many horror stories on LinkedIn, AI still isn’t following the rules we try to set for it. It seems to have short-term memory loss when it comes to guardrails. It can’t be trusted to follow the rules, and even when it does follow them and still gets something wrong, it can’t be held accountable.
AI is so easy to use
For many years, some of the worst SQL Server deployments have been described as someone clicking “next, next, finish” through the installer. Some AI usage is that same issue on jet fuel. It is so easy to hand it your own credentials, let it access the data, show it the schema, and give it the script. And in most cases, it will do an OK job of giving you something that does what you asked, but the problem is the same as next, next, finish: AI is going to implement what you ask for. The less you know, the higher the chance you aren’t asking for the best implementation.
What does all this mean for you and your automation?
The more complex the requirements, the more resilient the solution needs to be, and the more an experienced person needs to be involved in engineering it. AI is a powerful force multiplier. An experienced engineer with a well-designed specification can burn through an implementation at blinding speed. The hardest parts of development are now design and testing. Design means being clear and detailed in what you ask for, with zero ambiguity as the target. Testing means having an environment to test the output in, and people experienced enough to know when the output is wrong, too complex, or was led in the wrong direction.
The size of the project matters too. A simple automation to collect, store, and report on data doesn’t need an entire team of reviewers. However, we are seeing a boom in teams trying to use AI to replace enterprise-level software without the experience to confirm that the output is enterprise-ready for resilience, reliability, and security, among other things. Some are letting AI make major changes on their SQL Servers, which is why we recently had mugs made with “We repair what your AI fixed” on the side. Picture a transaction log filling up a drive. The AI switches the database to SIMPLE recovery, shrinks the log, and reports the problem fixed. It also just broke your log backup chain, and point-in-time recovery is gone until someone notices. The fallout of vibe-coded implementations at enterprise scale shows up again and again in technical groups and in the news.
So how should you use AI in your automation?
I’ve rambled enough. I’m an automation guy, and I love encouraging you to find ways to save time. In this post I want to be clear that AI is a powerful tool, but implementation should be careful and intentional. Here are a few guidelines for how I would start bringing AI into your automated tasks.
One distinction before the list: AI can help you build almost any of these processes. These guidelines are about whether AI should be the process, making a judgment call every time it runs.
Should nots:
- Don’t use AI where you need deterministic output. Fetching data, sorting or organizing it, building a report with pass/fail counts: you don’t want two different answers from the same data. Let AI help write the script, then let the script produce the output.
- Don’t use AI for processes that need auditing. AI can’t be held responsible, so don’t ask it to interpret something and then make a change to a production database. It won’t always make the right decision, make the same decision, or follow the rules. And if the scope is narrow enough that AI could never get it wrong, regular old scripting is cheaper anyway.
- Don’t use AI for things you can’t undo. You don’t want to be up the creek when AI makes an irreversible decision, like reducing backup retention, turning off your restore test job, or running REPAIR_ALLOW_DATA_LOSS on your behalf.
Coulds:
- Use AI to help with specs and well-designed, well-tested development. Have it poke holes in your spec, generate code against it, and write the tests, then run everything in a lab before it gets anywhere near production.
- Use AI to interpret Windows, SQL Server, and application error messages during incident response. Make it cite the log entries it’s drawing from so you can check its work.
- Use AI to triage and route. It can read the tone and urgency of tickets and alerts, suggest who should handle them, and loop in the right people.
- Use AI to summarize and explain. Turn a 200-finding health check into a top five your manager will actually read, or get a second opinion on an execution plan.
The pattern behind all of the coulds: AI proposes, a person approves, a script executes.
Where I’d draw the lines
Here’s how I’d sort some common DBA tasks. Most land in more than one column, and that’s the point: the script does the work, AI helps build it and make sense of it, and a person owns the decisions that can’t be undone.
| Task | Script it | Let AI help with | A person decides |
| Collecting and storing server data | dbatools on a schedule | Writing the collection script | What to collect, how often, where it is saved, how it is viewed |
| Health check report with pass/fail counts | Same rules, every run | A plain-English summary | What pass/fail means, who the recipients are, when it is run |
| Nightly backups | On a schedule | Reviewing the job setup | Where backups belong, what RPO/RTO is needed for the business |
| Backup retention changes | Once approved | Drafting the change | Again RTO/RPO, long term backup retention strategy |
| Restore testing | Test-DbaLastBackup on a schedule | Summarizing the results | What target to restore backups on, who gets the results |
| Incident response | Gathering Windows, SQL Server, and app logs | Interpreting errors, with sources | The business rules for investigating, prior examples, what to do with the findings |
| Ticket and alert triage | Routing rules you define | Reading urgency and suggesting an owner | Who is assigned the ticket, defining what is ticketable |
| Patching | Update-DbaInstance | Summarizing release notes | The window and go/no-go |
| Permission changes | From an approved request | Drafting the script | Approving it, determining the permission rules, least privilege. |
| Corruption | DBCC CHECKDB on a schedule | Explaining the output | Anything involving REPAIR_ALLOW_DATA_LOSS, |
| Building new automation | The finished product | Spec review, code, and tests | Design and test sign-off, permissions, business requirements. |
Notice that AI never shows up alone in a row that changes production.
Final Thoughts
We’ve all tasted the fruit, and nobody is going back, me included. AI is going to keep getting better, and it’s already a powerful force multiplier for anyone building automation. But it multiplies whatever you bring to it. Bring experience, a clear spec, and a lab to test in, and you’ll build faster than you ever have. Bring next, next, finish, and you’ll also get there faster, just somewhere you didn’t want to go.
Use AI to help design, write, and test your automation. Let the finished, reviewed, version-controlled script do the work. Keep a person on anything that can’t be undone.
I love automation and the time it saves for me, the Straight Path team, and our customers. The less time we spend on things that can be automated, the more time we have for things that can’t be. Used carefully and intentionally, AI gets us there faster. And if your AI has already fixed something, you know where to find us. We have mugs.