I don’t think there is any question about it. Your AI cost crisis can only be attributable to human error.

Pay for intelligence when you need intelligence. If you’re doing the same task twice, have the model write a program to do the task for both of you.

I put $30 on the Anthropic API three months ago. I burned $2.70 in the first few days figuring out my approach. Twenty cents since. Less than $3 total, and most of that was tuition.

That twenty cents built a text analysis engine. Sentence tokenizer, statistical metrics, entropy calculations, composite scoring for a website I built. The model wrote the code, I reviewed it, I deployed it as PHP on a Linux box I already own. The electricity cost is a rounding error on my power bill.

I keep reading about companies spending six figures a month on AI tokens and I’m doing the blinking eye meme. Putting every customer ticket, every document summary, every code review through a model, thousands of times an hour, 24/7, paying per token every time, seems crazy when the model could build you a deterministic tool instead.

Deterministic work belongs in traditional code.

But the integration pattern the industry has settled on is “put the model in the hot path.” Keep the AI in the loop on every request, forever. Perpetual token cost for work that stopped being an AI problem the moment someone understood the requirements. Your output changes when a new model version ships. Your pipeline breaks not because your code changed but because theirs did.

The model can write its own replacement for most of these use cases. Ask it to classify tickets? It can write you a classifier. Ask it to score text against a rubric? It can write the scoring engine. One build session. One deployment. Done. Stable output you control.

Companies pay the model to do the same work over and over because that’s how the tooling is sold. The SDKs make it easy to call the API. The tutorials show you how to put the model in your pipeline. The pricing page shows per-token costs that look cheap until you multiply by volume. Nobody in that funnel is suggesting you use the model to build something and then turn it off.

This is the SaaS treadmill applied to AI. Recurring revenue for the provider. Recurring cost for the customer. For work that could be a one-time build.

AI APIs are the right call when you need reasoning on novel inputs. Creative work, ambiguous classification, anything where the rules can’t be fully specified in advance. Pay for intelligence when you need intelligence. But if you’re sending the same shaped request a thousand times a day and getting predictable outputs, you don’t have an AI problem. You have an engineering problem. And the AI is the best engineer available to solve it for you once, without ever touching API billing.

Twenty cents. The result runs on its own.

Today I walked through an empty warehouse, powered down the internet connection, collected the last IT equipment for recycling, turned off the lights, and locked the door.

For almost six years, I was often the one to handle the difficult conversations, the one to stop and drop everything to run halfway across the state to handle an emergency because we needed boots on the ground. Terminations, restructuring staff, the meetings nobody wants to be in, a fraction of my work but just as critical as anything else. That just became my job while building out an enterprise grade IT environment for the company (IT that just worked and stayed out of the way). The kind of work that never ends up in a job description, but the kind of work that finds the person willing to do it.

After a few years it became a running joke. If I showed up to a job site unexpected, the first question was “who’s getting let go now?” followed by “Bryan’s going to be the last one here. And if Bryan’s gone, we’re all done anyway.” Polite chuckles. It was always in good fun. I never took it personal and teased them right back.

Every single person I was tasked to let go from the company I tried to do so with as much dignity, respect and empathy as I could provide regardless of the reasons for the termination. Even in rough cases I still reached out and offered my hand in parting.

My time with this company is now past tense. And I was, in fact, the last one out the door. No handshake. No hug. No “you did your best.

If you’ve ever been the person in your org who does the work nobody else wants to do, you already know how this story ends. You don’t get a ceremony. You get an empty building and a set of keys to return.

And you look for the next chance to do the right thing where you can.

#OpenToWork. #Leadership

You get exactly what you asked for. Not what you meant.

I watch people write prompts like they’re Googling something. A few keywords, a vague direction… Then they’re frustrated when the output is generic, wrong, or just weird.

But the model did exactly what you told it to do… and that’s the problem.

The old genie story works because the genie isn’t malicious… it’s literal. “I wish for a million bucks” and a million male deer appear in your yard. The genie did exactly what you asked it, you just didn’t think about your question.

LLMs operate on the same principle, minus the malice and the deer (usually). When you prompt “write me a marketing email,” you’ve described approximately four billion possible outputs. The model picks one. You hate it. You try again with the same vague prompt. You hate it differently. You conclude the tool doesn’t work.

The tool works fine. You made a genie wish.

What changes everything is realizing that prompt engineering isn’t about clever tricks or magic words (usually). It’s about the same skill that makes someone effective in any leadership role: the ability to articulate what you actually want with enough specificity that another intelligent entity can deliver it.

Tell it who it’s writing for. Tell it what tone. Tell it what success looks like and what failure looks like. Give it an example of something you loved and something you hated. Tell it what to leave out (the negative space is just as important as the positive).

In other words: do the work you should have been doing with your human teams all along.

The uncomfortable truth about prompt engineering is that it isn’t an AI skill. It’s a communication skill. The people who are bad at prompting are usually the same people who send their teams vague Slack messages and then get frustrated when the deliverable misses the mark.

The genie didn’t get it wrong. It followed the rules exactly.

As technology leaders, our most critical job is understanding the actual architecture of the tools we buy. If we evaluate probabilistic AI models using the same procurement mindset we use for enterprise software, we expose our organizations to catastrophic, invisible risks. I looked at the recent DoD/Anthropic negotiations as a case study in how dangerous this category error can be.

(Read, The Room Where It Gets Built — Essay #8: LLMs Are Not Shelf-Stable Products)
 

Representation isn’t sentiment, it’s mechanism. It flips a mental switch from “something other people do” to “something I could do.” When that switch doesn’t get flipped, we don’t just lose individual talent, we lose entire generations of potential and the perspectives they would have brought into the room. This connects directly to the AI training data argument: the room where these systems are being built has a representation problem, and the output will reflect it.

(Read, The Room Where It Gets Built — Essay #4: People Can’t Chase What They’ve Never Seen)