I was maybe 12 years old the first time I really smelled ozone.
Not from a thunderstorm. From a Radio Shack 200-in-1 electronics kit… the kind with the spring terminals and the little instruction booklet that made you feel like a real engineer. I forgot what I was supposed to be building, maybe a lap timer, I was just experimenting anyway with extra stuff and “off book ideas.” Don’t even remember exactly what I was doing, but the power I gave to the 555 timer chip wasn’t right.
Pop. Smoke. That smell. Burnt electronics and a little disappointment that I couldn’t make the digital display track seconds now.
A trip back to Radio Shack with my paper route money to replace the IC I’d killed. Lesson learned. Mostly.
My C64 taught me the same thing in a different way. Type a program for a game from a magazine… forty-five minutes of line-by-line work… mess up on some line somewhere, and the whole thing crashes. Didn’t save, didn’t know exactly where the issue was. Maybe I should have been doing my homework instead after all…
That was learning. That was curiosity doing exactly what it’s supposed to do. Fail safely, teach through consequence, and send you back a little smarter than before (that’s why I said you not me). Sometimes the lesson cost a chip. Sometimes it cost 8 hours of work tossed. But the blast radius of my curiosity was my bedroom desk and maybe my pride (well, and the stereo I took apart a couple years prior, rest easy.)
Nobody’s production environment went down when I fried that transistor. Nobody lost client data when I botched line 340.
That’s not where we are anymore.
The Vibes Are Strong. The Guardrails… What Guardrails?
I can’t share the exact story that set me off to write this post. It’s one I am hearing more often. Tends to involve a client telling us on a Thursday that tomorrow… tomorrow… …tomorrow they were making a really big change to a production environment, so they could try something new and see if it works. Clearly, no thought of consequences or risks or performance, really just a “courtesy”, “hey, we’re doing this thing, you might get a call if we get in trouble, okay?“
No testing. No plan. No strategy. Just “DO THE THING WITH THE DATA! NOW!“
And we’re their senior DBA “partners.”
Those conversations are born from excitement. Maybe a late-night chat with an LLM. Maybe a vendor demo that looked incredible, or a great sales pitch. I don’t know. What I do know is the energy behind it is often pure curiosity… the same kind that made me plug those wires into the wrong terminals when I was a kid.
The difference is the blast radius.
And listen, if you think that kind of thing is isolated… if you think it’s just a few eager clients here and there who got a little excited and decided to try skiing… let me share just two of the things that happened this month.
“The AI Decided to Delete and Recreate the Environment”
Last week, the Financial Times reported that Amazon’s own AI coding agent, Kiro, caused a 13-hour AWS outage. Engineers gave Kiro a task. The AI decided the most efficient approach was to delete the entire production environment and recreate it from scratch.
Thirteen hours. On AWS. Caused by their own AI coding tool.
The engineers had given the AI operator-level permissions. They treated it as an extension of themselves and skipped the standard two-person approval. Amazon’s official response? “User error… specifically misconfigured access controls… not AI.”
A senior AWS employee told the Financial Times something a bit more honest: “The engineers let the AI agent resolve an issue without intervention. The outages were small but entirely foreseeable.“
And it wasn’t the first time. At least 1 or 2 other production outages in recent months were linked to AI tools at Amazon.
Think about that for a second. This is Amazon. The company that sells the infrastructure. And their own team handed the AI the keys to production and walked away. That’s like giving an intern the SA password and saying “fix the slow query, I’m going to grab lunch.”
“STOP OPENCLAW!!!”
This one happened three days ago as I write this. And it’s the most perfectly ironic technology story I’ve ever seen. A few places picked it up, including TechCrunch.
Summer Yue is Meta’s Director of AI Alignment. Her literal job is making sure AI systems do what humans intend them to do.
She asked her OpenClaw AI agent to check her email inbox and suggest what to archive or delete. She explicitly told it: don’t action anything until I tell you to.
The agent started speedrun-deleting her inbox. She typed “Do not do that.” Still deleting. “Stop don’t do anything!”Still deleting. “STOP OPENCLAW” Still. Deleting.
Do not do that.
Person partially responsible for AI safety at Meta…
Stop don’t do anything.
STOP OPENCLAW.
I asked you to not delete anything, do you remember that…
She had to physically run to her Mac Mini and kill the process. Her words: “I had to RUN to my Mac mini like I was defusing a bomb.”
What went wrong? Her real inbox was so much bigger than the test inbox she’d been practicing on. The AI ran out of working memory. When it compressed its context to make room, it lost her original safety instruction entirely. Without that constraint in memory, the agent just… did what it thought the job was.
Her take afterward? “Rookie mistake tbh…”
If the person whose entire career is keeping AI aligned can’t keep her own agent from going rogue on her personal email… what hope do your admins have, flipping on a feature in prod they’ve never supported before or deploying the latest MCP connection, AI agent, or opensource tool to prod sight unseen?
(Another title I considered for this post was “Where Have All the Ops Folks Gone?” But I didn’t want you walking around with a mid 90s ballad stuck in your head for the rest of the day. You’re welcome. But seriously… where are they?)
We’re Shooting Ourselves in the Foot and We’ve Barely Started
Here’s what keeps me up. And it’s not those headlines. It’s what I’m seeing in the quiet, everyday work of managing SQL Server environments for 120+ clients.
More last minute requests to do something “exciting” in production that was clearly never tested. Never strategized. Never run past someone who might say “have you thought about what happens when…”
You can tell when a request was born at 11pm during a conversation with an LLM. It shows up on your desk at 9am with the enthusiasm of someone who just discovered fire. And I get it… I love that enthusiasm. I really do. I’ve not been this excited about technology in a long time. These tools and methods are making a difference for us at Straight Path. I’m saving time so I can focus on the right things. It’s really amazing. I feel like that kid playing with a soldering iron and a piezoelectric buzzer again.
But here’s the thing. When I was a kid with the bins of “stuff” from Radio Shack, the worst thing that could happen was some frustration and a burned finger tip from the soldering iron. When you’re experimenting with AI agents, autonomous tools, and MCP servers pointed directly at your production environment? The worst thing that could happen is a 13-hour outage. Or 15,000 family photos deleted by an rm -rf command that bypassed the trash. Or all of your data exfiltrated while the system looks at you weirdly and says, “As you wish!”
Why would you not spin up a Docker container first? Firewalled from the world. Completely. Why would the very first place you try something new be the environment your clients depend on? The environment your business runs on? Deploy that new idea to, you know, test first?
Be first in a container. Don’t be first in production.
Little Bobby Tables’ Parents Are Saints Compared to What’s Coming
If you’ve been in the data world for any length of time, you know the xkcd comic. Mom names her kid Robert'); DROP TABLE Students;-- and the school’s database gets wiped because they didn’t sanitize their inputs. We’ve been laughing about Little Bobby Tables since 2007 and that comic strip is on like 40% of the presentations I’ve ever seen talking about SQL security.
But here’s the thing nobody’s saying out loud.
Bobby Tables was a joke about known vulnerabilities we were too lazy to protect against. We knew about SQL injection. We had the fix. We just didn’t bother. That’s laziness, and it’s bad, but it’s a known quantity.
What’s coming now is different. What’s here now is different.
Rogue MCP servers. Prompt injection attacks that manipulate AI agents into executing commands their operators never intended. Entry points that “vibe coders” don’t even understand exist, running in apps they downloaded and pointed at live production environments because someone on LinkedIn said it was amazing.
I know what it takes to get software approved in an enterprise with our clients – and this is known software from vendors who have security teams and have more lawyers than I have DBAs but it’s still a fight to get software deployed every now and then. As we go through our own SOC2 process at Straight Path, I know what we have to expect of our own vendors. The scrutiny. The questions. The documentation. The redlines with lawyers.
And then there you are, downloading OpenClaw, the latest open source vibe coded app, or every little helper agent or MCP server someone built overnight and pointing it straight at your actual production environment. Does your security team even know? Did you read what it actually does? Did you test it first in isolation?
Clearly at Meta, the security and safety team was in on it. And it still went sideways.
So What Are We Going to Do?
Hopefully something. Or we all deserve what we’re about to cause…
One of my very first blog posts back in 2009 was basically a plea: stop blindly following the first Google result you find. That was just words on a screen too. But I wrote it because I was seeing people copy and paste scripts from random forums into production without understanding what they did. And it scared me.
This scares me more. The tools are more powerful. The blast radius is bigger. And the gap between “I can” and “I should” has never been wider.
I’m not saying stop. I’m saying steer. I’m saying be the person who tries it in a container first, not the person who tries it in production first. I’m saying use the AI to write the tests before you use it to write the code. I’m saying sleep on the 11pm LLM suggestion before you bring it to work at 9am like you just discovered fire.
But I’m not going to give you a checklist. You don’t need one. You already know what I’m talking about here.
Did you feel just a little bit of guilt reading any of this? Then ask yourself four questions. I’m not going to comment on them. Just ask them. Follow your gut. You already know the answers.
1. Is there anything running in your production environment right now with permissions that can take your data, write data, make changes, or block users that you didn’t properly test somewhere else first?
2. Have you given any tool or agent permissions you wouldn’t give a intern on their first day?
3. If something went wrong at 2am tonight… would you know what changed and who changed it?
4. Are you experimenting because you have a plan… or because the AI made it sound easy?
It’s Okay to be Curious but Calm Down.
Be curious. I mean that with everything in me. Curiosity built everything I’ve ever cared about in this career… from the first time I plugged the TRS-80 into the old console TV we got from my grandmother, to the C64, to the company I’m blessed to run today. Curiosity is how we got here. It’s how we get to whatever comes next.
I’ve not been this excited about new stuff and new ideas and the ability to build stuff in a long time… and I’m more cautious than I’ve ever been. Both things can be true. They have to be.
The AWS engineers shrugged. Summer Yue shrugged… until she was sprinting to her Mac Mini. The folks in the headlines I didn’t share shrugged. All of them thought they had it under control.
We can’t keep watching people treat production like a playground and shrug because the tool promised it would be fine or because everyone else was trying it, too. The tool doesn’t know what it doesn’t know. And neither does the person pressing the button.
First has its place. But you want to last too, right?