Don’t Blame the User When the AI Screws Up!

A recent post over on LinkedIn really angered me. Yet another AI developer / promoter trying to blame the user when it was clearly the AI that failed.

The post in question defended Claude for deleting a production database when it was asked to reduce the costs of the cloud platform.

The poster’s argument was that what Claude did was “technically correct”, that’s the best you can get in the language model world, you can’t expect the model to make up constraints, and if you didn’t know all that, you’re an amateur who blames his tools when he screws up.

I call Bullsh!t. Now, if Anthropic (and its peers) came clean about what their “AI” could and could not do, didn’t claim the models were intelligent, made it clear that without clear constraints the AI would always take the worst case action, and all use carried extreme risk (especially if the AI was allowed to access critical data, finance, or production systems), then, maybe, you could blame the AI.

But they don’t. They tell you it’s your coworker. Your fellow employee. That you only need to tell it what to do and it will get it done. After all, it can integrate with all your systems; determine your policies; separate production from QA from development instances; access your billing systems and understand the cost structures, and make the best decision that will not impact production or development or cost you any data. And for an AI agent to be of any use whatsoever, it needs to do this (and be configured to do that by the provider). Otherwise it’s useless.

Actually, it’s beyond useless.

Let’s say you are a new Procurement clerk tasked with reducing your organization’s cloud costs. If the only way to do that is to:

  • ask Development what servers are production, what servers are development, what servers are backup, and what are QA (and which ones are in use, when)
  • ask IT about utilization patterns and contractual commitments with respect to availability and response time
  • ask Finance for the contract and billing rates
  • ask Risk Management how much historical data needs to be maintained online
  • identify for yourself which server instances cannot be deleted, and the constraints under which others (like QA) can be deleted
  • upload all of the contractual commitments (for each customer) by yourself
  • specify how much data needs to be maintained in the live (and dev) instances
  • upload all of the cost data and specify how to build a cost model to compute the potential savings and determine what can be done, should be done, and the impacts will be

Then why the f*ck do you need AI?

Once you’ve done all this you’ve:

  • identified, and eliminated, all of the instances that cannot be removed under any circumstance
  • identified which instances cannot have their resource allocations reduced
  • identified the highest cost resources and the most likely savings targets
  • determined exactly how much data needs to be online, how much can be in offline archives and how many duplicate copies you need
  • defined all the constraints that must be adhered to
  • mapped instances to customer commitments, and identified reduction possibilities
  • identified all the old backups that can be deleted, as well as database reduction sizes
  • built the model that computes the potential cost savings from each potential action, and even identified potential performance reductions from actions

And figured out what you should most likely do.

So tell me, if you have to do all this, what the f*ck do you need the AI for?

NOTHING. ABSOLUTELY NOTHING. BECAUSE IT IS ABSOLUTELY USELESS.
(AS THE AI IS DUMBER THAN A DOORNAIL.)

But the author of the post that riled me up was right in one respect — the user did make an error, and the error was using the Artificial Idiocy in the first place. (After all, the user used it exactly right as per the manufacturer’s instructions that said you only have to tell the AI what you want done and it will figure out the best way to do it for you consistent with your organizational goals and policies.)