Do you really need all this AI?

Your AI is costing you more than it should.

In 2024, Klarna replaced 700 customer service agents with an AI assistant and announced the AI was handling the work of all of them. The CEO projected $40 million in annual savings and told the press. By May 2025, Klarna started rehiring humans. CEO Sebastian Siemiatkowski said on record: "We focused too much on efficiency and cost. The result was lower quality, and that's not sustainable."

The part that gets buried in the headline is what those AI conversations were doing. A large share were answering questions like "What is my balance?" and "Can I update my address?" Those are retrieval questions. A coded decision tree answers them for pennies. Klarna was routing every one of them through a language model, at full token cost, for every user, every time.

The solution they eventually built was a tiered system: rule-based routing for simple questions, AI for medium complexity, humans for the cases that needed judgment. That is what they should have built first. It took a year of customer complaints and a very public reversal to get there.

That is not a story about bad AI. That is a story about over-adopting AI where cheaper tools were already doing the job.

Tokens cost big $$$

Every time an AI model reads or writes anything, it works in units called tokens. Think of a token as a piece of a word. Simple words are usually one token each. Longer or technical words get cut into pieces. Here is what that looks like:

"I would like a burger"
[I] [would] [like] [a] [bur] [ger]
 1     1      1    1    1     1
= 6 tokens

"Your chatbot is overengineering your budget"
[Your] [chat] [bot] [is] [over] [engine] [ering] [your] [bud] [get]
= 10 tokens

One short customer question and one short answer use roughly 100 to 300 tokens — about the length of this paragraph.

Your Claude subscription charges by token. Your OpenAI API charges by token. If your website has an AI chatbot, an AI-powered search bar, AI-generated product descriptions, or an AI form helper, each user interaction is making what is called an API call. An API call is a request your website sends to an AI company's server: "Here is the question. Please think about it and send back an answer." The AI company reads the question, generates the answer, and charges you for every token it touched.

Here are approximate rates from the top providers as of mid-2026:

Prices change frequently. Always check the provider's pricing page before you build.

If 500 people a day ask your chatbot "What are your business hours?" and each exchange uses 200 tokens, that is 100,000 tokens per day. On the least expensive model in that table, roughly $0.015 a day. On the most expensive, closer to $1.50 a day. Neither number breaks the bank on its own. Multiply it by every question, every page, every AI feature you built, across every user every day, and the number grows fast and quietly.

When developers layer AI into every part of a product regardless of whether it is needed, we call it overengineering. Building it because it can exist and because we want "new" and "shiny" and to say that we can. The cost compounds fast, and the problem stays hidden even when the bill comes.

Don't reinvent the wheel

Just because we have AI does not mean you need it for every task. The old ways of doing things work well and cost less.

Search boxes, contact forms, FAQ pages, dropdown menus, autocomplete fields, recommendation engines, and content filters all existed before GPT-3, before ChatGPT, before anyone was vibecoding at 2am. A lot of them still work. A lot of them work faster and cheaper than an LLM wrapper built around them.

A FAQ page that answers "What are your hours?" costs nothing to load. A coded decision-tree chatbot that routes "What is my balance?" to a stored answer costs nothing to run. An AI chatbot that routes the same questions to a language model costs tokens every single time.

Don't add AI unless it solves a real problem

Before adding AI to anything, ask three questions:

• Does this problem require reasoning, or just retrieval?
• Does the user need a conversation, or an answer?
• Could a simple conditional, a database query, or a static page do this instead?

If the answer to the last question is yes, you have your answer.

The cost of overengineering

Overengineering is not only a code quality problem but a budget problem as well. AI coding assistants are trained on complex enterprise codebases, which means they default to generating complex solutions even for simple tasks. A 200-token request can quietly expand to 10,000 tokens per request when system prompts, tool definitions, and conversation history pile on, and that math runs every single time a user clicks something.

MIT Sloan data from 2025 found that 95% of generative AI pilots at companies failed to produce measurable business value. A significant portion of that failure is not model quality. It is scope: companies building AI where a spreadsheet, a form, or a canned response would have done the job at a fraction of the cost.

Vibecoding with discipline

Vibecoding is fast. It is also the fastest way to build something expensive and fragile if you skip one rule: use the simplest solution that solves the problem.

When an AI assistant generates a complex architecture for a simple task, push back. Ask for the stripped-down version. Break requests into small, specific scopes. Never reach for a multi-model agent chain when a single function call will do. Treat AI like any other paid tool in your stack: deploy it where it adds value you cannot get cheaper elsewhere, not everywhere because you can.

The best AI implementations start with a problem someone can describe in one sentence. The worst ones start with "we should add AI to this."

Before you call a model, call the obvious thing first

AI is a tool. So is a hammer. You would not use a hammer to open a jar, and you should not route a balance inquiry through a language model. The question is never whether AI is capable. The question is whether the task requires that capability.

Klarna used AI for everything, including the questions a decision tree could answer for free, and paid for it in quality, public trust, and a very public reversal. The tiered approach they landed on is what they should have built first. Match the tool to the task. Simple question, simple solution. Complex question, bring in the smarter tool.