The vending machine trap.

In the past year I've walked into a lot of organizations that are using Claude — or ChatGPT, or Gemini, it doesn't much matter — and gotten a version of the same frustrated report. "We're paying for it. People are using it. But it's not really changing anything."

When I ask what "using it" looks like, I usually get the same answer: people open the chat, type a question, read the response, copy the parts that seem useful into whatever document they were already working on, and move on. Maybe they've gotten good at phrasing things. Maybe they've bookmarked some prompt templates. Maybe one person on the team has figured out some tricks they occasionally share in Slack.

The outputs are fine. Not remarkable, not specific, not something that couldn't have come from a different tool or a different model or a smarter Google search. Fine. The company is spending $20 to $200 per seat per month for outputs that are, when honest, fine.

That's the vending machine trap.

What the vending machine trap actually is

A vending machine is a tool you approach with a specific request, interact with once, get a single output from, and walk away. The machine doesn't know you. It doesn't know your preferences, your history, your context, your standards. It produces the same output for you that it produces for anyone else who puts in the same coins and presses the same button.

That's exactly how most teams use AI. They approach it per-request, in isolation, with no accumulated context, no established conventions, no persistent relationship between the tool and the work. Every session starts from zero. The AI doesn't know the project, the client, the voice, the format standards, the things you always catch and fix in the final draft. You tell it none of that because you'd have to tell it again tomorrow anyway.

The result is outputs that are generically competent. They're produced by a model that has read everything, trained on every style, absorbed every convention — and therefore defaults to none of them specifically. Without specific context, it writes for nobody in particular, in a voice that belongs to nothing in particular, in a format that could be anything. That's not the model failing. That's the model doing exactly what it can with what it was given.

The vending machine trap isn't a prompt problem. It's a relationship problem. You're treating a powerful context-sensitive system like a stateless query engine.

The other trap

Some teams recognize this and conclude that the solution is to build something. Bring in a developer. Commission a custom AI tool. Spend six months and real money creating a product that wraps the model in proprietary logic, trained on your data, tuned for your use case.

This sounds like the right instinct. In some cases, for some organizations, it is. But I've watched it go wrong enough times that I treat it as a distinct failure mode of its own — the over-engineering trap.

Here's how it usually plays out. The custom tool gets built. It costs somewhere between $80,000 and $250,000 and takes six to twelve months. The team uses it. It's better than the vending machine. Then, eight months after launch, the underlying model releases a native feature that does 80% of what the custom tool does, for free, as a settings toggle. The $200,000 workflow is now a checkbox.

Or the vendor gets acquired. Or the API pricing changes. Or the model the tool was tuned for gets deprecated. Or the one engineer who understood the system leaves. Any one of these is enough to strand you with a product you can't maintain, built on a platform you don't control, in a field that moves faster than any custom build can keep up with.

Why both traps feel reasonable

The vending machine approach feels reasonable because it's low-friction. You're not over-committing. You're experimenting. You'll figure out where AI fits as you go. This is a fine attitude for month one. After month six, it's avoidance in a lab coat.

The over-engineering approach feels reasonable because it addresses a real problem — context — with a real tool — software. Engineers are good at building solutions to context problems. The instinct to build is not wrong. What's wrong is the assumption that the context problem requires a custom product to solve. It usually doesn't.

Both traps share a common root: treating AI as something that requires either no investment or a massive investment. A light-switch and a construction project, with nothing between them.

The gap between "marginally useful chat tool" and "reliable business capability" is real. It's just not as wide as either trap assumes, and it's not primarily filled by better prompts or custom software.

What both traps have in common

Neither failure is about the model. The models are genuinely good. Claude, in particular, is capable of producing remarkably specific, useful, on-brand outputs for complex professional work. I use it daily for client deliverables, proposals, technical documentation, and operational work across a dozen different contexts. The capability is there.

What's missing in both traps is the layer between the model and the work: the structure that gives AI what it needs to be useful in your specific context, maintained by your team, updated as the work changes. Not a prompt. Not a product. Something else.

Teams that have built that layer get consistent, specific, genuinely useful outputs from the same subscription everyone else is already paying for. Teams that haven't are stuck choosing between fine and expensive.

The question worth asking

If I were doing a quick diagnostic on any team's AI usage, I'd ask one question: before you type your first message in a session, how much does the AI already know about your work?

If the answer is nothing — if every session starts from zero — you're in the vending machine. You're paying for a model and getting a fraction of what it can do, because you haven't given it what it needs to do more.

If the answer is "we built a custom tool that handles that," the follow-up question is whether you'd be fine if that tool stopped working tomorrow. If not, the custom build may be solving the right problem the expensive way.

The answer to both is the same, and it's neither a better prompt nor a custom product. But that's a different essay.

Field notes

Most of the organizations I work with on AI workflow aren't starting from zero — they're stuck in one of these two places. The vending machine is more common and easier to fix. The over-engineering trap is rarer but harder to talk about honestly, because someone usually spent real money on it. Both are recoverable. Neither requires starting over from scratch.

R.P.