I trusted AI to redesign this entire blog. The layout, the CSS, the deployment pipeline, the shortcodes. I use it to build home automation, organize my notes, fix my English. But I won't let it write a SQL query against a production database.
That's not a contradiction. That's risk management.
The irony
AI is one of the reasons I stopped blogging. The scraping, the attribution anxiety, the feeling that anything I write gets ingested into a model and regurgitated without credit. Why spend hours testing and documenting when the output gets laundered through a chatbot?
And then AI is the reason I started again. Not because I got over those concerns (I didn't). But it turns out AI is spectacularly good at all the things that aren't writing. The stuff that kept me from blogging wasn't the blogging itself. It was the everything else. The theme that needed updating. The CSS that looked dated. The deployment that was fragile.
AI handled all of that. Not perfectly, not on the first try, but well enough that I could focus on what I actually wanted to do: start blogging again.
I've seen this pattern before. I resisted smartphones for years. Privacy concerns, data collection, the feeling that Google knows too much about me. My wife eventually got one for me and I gradually started using it more and more. Now I'm the family tech support. The utility won. Not because the concerns went away, but because I got tired of the inconvenience of fighting it.
The same thing happened with AI. I'm not sure that's a good lesson. It might just be a true one.
How I got here
I didn't wake up one day and hand my entire workflow to AI. It was a progression, and each step required the previous one to not blow up in my face.
Stage 1: The chatbox
I started chatting. Mostly around unfamiliar topics, but also testing how well it knows the things I know a lot about. Two things hooked me early.
First, grammar. I'm an ESLEnglish as a Second Language
A non-native English speaker. speaker and AI turned out to be a patient, non-judgmental editor. Something that understands what I'm trying to say and helps me say it better.
Second, research. Not the "give me an answer" kind but the interactive kind. I'd go in with an open mindset, knowing I don't know enough to ask the right question yet. Ask broadly, follow threads, let the conversation narrow down. It's the opposite of the XY problem - instead of asking how to implement my premature solution, I'd describe the goal and let the tool help me find the right approach.
Stage 2: Coding outside my lane
Once I understood where AI gets things right and where it falls apart, I got more comfortable letting it write code. But only in areas where I'm not the expert.
Home automation was the big one. Sifting through container logs, debugging Docker networking, writing automation scripts. I know what I want the system to do. AI helps me get there faster, especially when I'm troubleshooting something unfamiliar at 22:00 and don't feel like reading three forums.
Same pattern with this blog. Hugo templates, CSS layouts, PowerShell scripts. I know what the result should look like. I don't need to be an expert in Go templating to get there.
Stage 3: File access and credentials
This was the leap. Going from "chat window where I paste things" to "agent that reads and writes files on my machine" felt risky. Giving it API credentials felt even riskier.
But it paid off. Right now I use Claude Code (but I'm not married to it). It manages my Cloudflare configuration, drafts LinkedIn posts, pulls analytics, and orchestrates the blog deployment. The key was compartmentalization: a separate credential vault with only the access it needs. Minimal permissions, read-only where possible, no production database credentials.
What I actually use it for
Every example here is something I did this week:
- Fixing my English. Editing that understands context, not just grammar rules
- Research and decision-making. Comparing tools, summarizing options, interactive Q&A until I understand the options
- Coding outside my expertise. Home automation, Hugo templates, CSS, PowerShell
- Reorganizing and categorizing. I dump a pile of unstructured notes and AI finds patterns, suggests categories, creates tags
- Admin tasks. Timesheets, status updates, ticket descriptions
- Diagnostics. Sifting through log files, finding patterns in noise
- This blog. The redesign, the content pipeline - and this very post (more on that below)
The risk/benefit framework
I didn't plan to have a framework. It just emerged from watching myself decide which tasks to hand off and which to keep.
There's an xkcd comic about whether automating a task is worth the time. How often do you do it, multiplied by how long it takes, compared against how long the automation takes to build. For most tasks, the break-even point is depressingly far away.
AI changes that math. What used to take a weekend of scripting takes an afternoon of prompting. More tasks cross the "worth automating" line.
But the other half of the equation is risk.
A typo in a status update? Nobody notices. A wrong UPDATE statement without a WHERE clause? No, thank you.
So the real question isn't "can AI do this?" It's: "If AI gets this wrong, how bad is it and how quickly will I know?"
Why SQL is the hard part
The obvious answer is elevated access. I have sysadmin on production servers. If AI acts through my credentials, it has the keys to everything.
But the deeper problem is infrastructure. Despite years of progress in database DevOps, fully automated CI/CD with environments in good shape is still a rare sight in practice.
Testing stateless code is just easier. Reset the environment, run the suite, done. Databases carry state that took months to build. Rollback means "restore from backup and hope."
So when I say I don't trust AI with SQL, it's not just about the permissions. It's about the absence of a safety net. That's a solvable problem, and one our industry needs to solve regardless of AI.
How to start
The advice I'd give myself two years ago:
- Learn the tool first. Understand context management, prompting patterns, and limitations. You need this foundation before the tool is useful
- Start where you ARE the expert. You'll catch the mistakes. If AI writes bad SQL and you know SQL, you'll spot it instantly. If it writes bad code in a domain you don't know, you won't know it's wrong until something breaks
- Estimate the impact. How bad is it if AI gets this wrong? How quickly can you recover? Low impact, fast recovery - go for it. High impact, slow recovery - keep doing it yourself for now
- Invest in the boring stuff. The biggest wins aren't flashy. They're the admin tasks, the formatting, the categorizing
About this post
This post was written with AI assistance, and I expect every future post will be too. The prose is just better than what I'd produce on my own.
Every idea and opinion is mine. I read the final version and I'm responsible for it. That's the human-in-the-loop part - not approving a draft, but owning the output.
The bottom line
Fire is a good servant but a bad master. Same with AI. The same risk assessment that makes you a good DBA should guide how you adopt these tools.
The database world will get there. Better test environments, proper CI/CD, automated validation. When the safety net exists, I'll be happy to let AI help with SQL too.
I haven't tested it yet. Not really. But I'm building toward it.
Thank you for reading