A few weeks ago, I started with a set of installation scripts. I finished with a full lab: six SQL Server replicas across two Azure regions, automated failure drills, and a live dashboard that shows recovery as it happens.
Work like this could easily take days. With AI, it took a few hours of hands-on time, spread over four or five days alongside my regular work.
But speed isn't the story I want to tell. The story is what happened in between: the moments where the AI produced something that looked right, worked in tests, and was still wrong. Those moments were caught by experience, not by the tool.
In this post, I'll walk you through the whole project: where it started, how the conversation with the AI unfolded, the specific mistakes I caught, and the results. If you don't work with databases, don't worry. There's a glossary at the end, and the lessons apply to anyone using AI at work.

The live dashboard replaying the second drill: West US 2 is down, node-1 stays primary, and the clock tracks how long the system runs without disaster recovery.

The same moment in the terminal dashboard: drill phases, success criteria, and a live event log, for when there's no browser available.
Where it started
I was working on a project to run SQL Server on Linux virtual machines in Azure. A colleague shared a set of automation scripts that built two SQL Server VMs and connected them in an Always On availability group. The scripts worked well. A full install took minutes.
This architecture is a standard, documented pattern for high availability that any organization can use, and nothing in this post includes customer details or data.
Then I tried to build a second group of servers, and the problems started. Some settings were hardcoded inside individual files. Changing them in the main configuration did nothing, because they never reached the scripts that actually ran. So I started editing.
The more I edited, the more I found to improve. And the more I read, the more ideas I had. Why stop at installing servers? The same toolkit could deploy the environment, simulate real failures, measure the recovery, and show it all on a dashboard. Not just installation scripts, but the whole process around running a resilient database platform.
That's infrastructure as code: describing your servers, networks and configuration in files, so a script can build them the same way every time. And that's where AI came in.
When I asked the AI to review the original scripts, it found real problems on its own:
Two of the scripts couldn't work together. One template hardcoded names that only matched the other script, so the first one built resources under the wrong names.
Each run overwrote the other's records, because both used the same deployment name.
Passwords were never saved. A rerun would generate new ones, reinstall SQL Server and wipe the data.
That's the part of AI that impresses me: it reads every line, fast, without getting tired. But reading code and understanding a production system are two different things, as you'll see.
Want to read the rest for free?
Subscribe free and this post unlocks for you on the web, no card needed. Every free subscriber gets 3 premium posts a year, and this can be one of yours. After you subscribe, reopen the post from your welcome email or sign in on the site.
Want every post, not just three?
Become a Founder and get every premium edition, the full archive, and the Founders' Rate: 30% off, locked in forever, for the first 100 members only.
Keep reading with We The People, in Tech or Not
Practical lessons on databases, AI, and business, from 20+ years in the field, for people in tech or not.
Become a FounderA subscription gets you:
- Every premium edition on databases, AI, and business
- Full access to the archive
- Founders' Rate: locked in forever for the first 100

