How to Train Your AI
This is an actual message I received from Claude, an AI assistant, this week while working. I appreciated the apology, but something got broken. So what did Claude & I do? We had a good old post-mortem. Let’s figure out why this happened & what we’re going to do differently moving forward.
Claude & I have gotten pretty tight. They’ve been my co-builder & we’ve formed quite the working relationship this year, as I’m sure most people have with their AI tools of choice. Claude helps accelerate my processes when it comes to work. Claude makes me better.
I watched How to Train Your Dragon for the first time this week. It reminds me of the relationship between Toothless & Hiccup. Toothless can’t fly without Hiccup. Hiccup can’t fly without Toothless. They’re built to work together to fly.
Claude is only as effective as the person behind the scenes orchestrating it. Claude can review my work & find blind spots quicker than I’ve ever experienced. I have to use discernment & a critical eye with the things Claude suggests. I’m the one who needs to be extremely direct with Claude about what the vision & expected output will be. Claude can effectively implement certain coding tasks & other mundane tasks at a speed that is much faster than I could. We keep each other in check to produce the best possible work.
Here’s a snapshot of my week co-building with Claude:
I accelerated an extremely tedious project that transformed core backend pieces of my technical system. This is something that could’ve taken at least a couple of weeks but I turned it around in a few days while still carefully testing.
One small command Claude gave me while setting up some infrastructure as code completely overloaded my database, taking my system down.
The irony in all of this: the first project was so successful because of the solid framework I had in place for co-building with Claude. There was thoughtful planning that led to identifying this core technical change. I weighed the pros & cons of doing it now versus punting it for later. I made the call, then Claude & I collaborated on a detailed technical design doc & rollout plan. We broke things down into tickets.
Then Cursor, using Claude, swiftly executed the code. One wrong move & I could’ve completely fucked up a foundational element of my system. It required an immense amount of focus, planning, testing, & care. That foundation let me move extremely fast & safely.
Now… the infrastructure command that took everything down? I cut corners. I thought “OH, this is another thing I can do quickly & maybe AI will just do it for me”. WRONG. The command was meant to help me create code to replicate spinning up my production environment the right way. Except, Claude gave me a command that locked up every connection to my database.
The system went down for about 20 minutes… not catastrophic, but long enough for me to feel it. & long enough to remember that there are actual users on the other end.
Who’s at fault here?
Neither of us? Both of us? Claude should’ve given a warning when recommending that command. Me, as the trained software engineer, should’ve been more thoughtful before running that command.
How do we mitigate this moving forward?
Maintain the same rigor for infrastructure work that made the backend project successful
Add better alerting & monitoring for the database & its load
Have a playbook ready for resolution (because let’s be real… this will probably happen again)
With great power comes great responsibility. I try to remember that I have a powerful tool in my hand. I need to use it with intention, discernment, & care.
So Claude, you did fuck up. So did I. Let’s learn from it & keep building.
