As AI costs rise and the industry shifts from subscriptions to token-based pricing, the real economics of AI use-cases are starting to surface. Now that every interaction has a visible price, the question is no longer can AI do this, but is it worth paying for it to.
A bit of history
When the first AI tools appeared, usage was heavily subsidised to drive adoption — especially for OpenAI and Anthropic, newcomers that needed to build a user base, unlike Google. In practice, using AI was basically free.
I’ll admit I was sceptical at first that these chatbots would generate much value. They were useful — a genuine revolution for search and data aggregation — but I didn’t see much beyond that. Then came agents that could pull online content directly, hook into tools via MCP, and later use Skills. New use-cases appeared quickly, and the prediction of AI replacing jobs started to feel a lot more real.
Usage climbed. Companies began incentivising employees to replace or improve tasks with AI, and Adobe was no exception. My background is in economics, not computer science, and it became clear to me — and to specialists — that while usage was growing, it wasn’t sustainable under a subscription model.
The economics of AI can be oversimplified into a few elements:
- Training requires enormous amounts of data and costs a fortune — billions of dollars. The model learns billions, sometimes trillions, of parameters that encode the statistical relationships between tokens (or pixels), so it can predict the likely next token given some input.
- Inference — running queries against the trained model — also costs money. It’s far cheaper than training, but not free: every prompt has to be tokenised, and every token in the response requires a full pass through all those parameters.
- Inference is still fundamentally next-token prediction. The model doesn’t “look up” your question somewhere in its training data; it attends over the context you give it to weigh which learned patterns are relevant, then predicts the next token. The cost comes from doing that, repeatedly, across a very large network.
Paying a flat fee for a model that internally generates anywhere from hundreds to hundreds of thousands of tokens per interaction was never going to add up. As the bills ramped up for the AI companies, a change in the economic model was inevitable.
Agentic AI
Agentic AI is far more capable. It can use tools, produce output directly in your system, and generate many more types of content. I started using AI seriously once agents arrived, mainly to help build new functionality in my applications — and that’s when the real cracks started to show, for me and for other power users.
AI is a powerful tool, but it has structural limits that aren’t easily bypassed:
- Output quality is bounded by training data. AI doesn’t think or create; it reproduces patterns. That can be extraordinarily powerful — its knowledge is broader than any human’s — but it won’t recognise your coding or design patterns, and it won’t know the specific edge cases you have to account for. Context awareness helps (more on that later), but the sheer volume of training data means the patterns it has absorbed may not match your standards.
- The context trap. You can feed the model context, rules, and skills to steer how it works. But those same guardrails can be incomplete, restrictive, or actively misleading. Because the model is probabilistic, it will infer a solution from what you give it — without knowing whether that’s the right thing to do. It won’t sense that something is off and stop to question it. So context is as much a curse as a cure, depending on how the model weighs it.
- Probabilistic output is a problem when you need a definitive answer. Ask the same thing two different ways and you’ll get two different answers. Ask the exact same question twice and you can still get different results — partly because earlier turns become context that shapes later output, but also because generation involves sampling. This is real: even at temperature zero, model APIs are not fully deterministic, thanks to how requests are batched on the hardware. At one point the common advice was to always ask twice to get a “refined” version — which, if you think about it, is an odd thing to need from a tool meant to make you efficient.
The more I used these agents, the more I watched errors pile up in my codebase — and mine isn’t large, just tens of thousands of lines across small applications, nothing like what runs real businesses. A few examples: it rewrote a working API exception because it didn’t match the pattern of neighbouring methods; it pulled in dependencies I didn’t need; it assumed methods existed when they didn’t. That last one is the giveaway. A developer checks that a method exists before calling it. An agent has seen the pattern ten times, so on the eleventh it simply assumes the method is there. It also misread deliberate exceptions as bugs and tried to “standardise” them — where a human would suspect it was done that way for a reason and go looking for it. There is no such reasoning in the model.
None of this is exotic. Studies now put the rate of hallucinated, non-existent package recommendations from coding assistants at around 20% — common enough that attackers register those fake package names to wait for someone to install them.
I know we’re always “six months away” from the model that solves all this, and the next model will be better. But power users are increasingly seeing the models stagnate — the improvements aren’t exponential anymore. They still get better, but I suspect these limitations are structural and here to stay.
To be fair to the optimists, that view is contested, and the strongest counter-argument is worth stating plainly. Progress hasn’t stopped so much as moved: raw pre-training scale may be hitting diminishing returns, but a newer axis — test-time reasoning, letting the model “think” longer before it answers — is producing real gains on exactly the long, multi-step tasks that used to break these tools. The economic picture isn’t uniformly bleak either. The same MIT research that found 95% of enterprise AI pilots delivering no measurable return also found a 5% succeeding spectacularly — and they tended to win by picking one narrow problem and executing it well, rather than spraying AI across everything. Honestly, I read that less as a refutation of my argument than as evidence for it: the winners are the ones being deliberate about where AI goes. But it’s a real counterweight, and worth holding onto as you read the rest.
The token-based shift
The economic model had to change, and the new one makes good use-cases harder to find — because token-based pricing changes how you approach AI in the first place.
Under a flat fee, it was easy to throw anything at the model. An imperfect answer wasn’t ideal, but refining it only cost you time and a bit of efficiency. Nothing more.
Now, when an answer needs reworking, you pay to correct it and spend the time reviewing the correction. It’s no longer just a time cost — it’s a real one. This is exactly where the probabilistic nature of these models starts to hurt.
Token consumption is the other half of the problem: large tasks and bulk content generation — precisely what we got used to during the “free” era — are now genuinely expensive. Using AI for a bit of everything is probably going extinct. You have to decide, deliberately, when AI beats a more human approach.
I’m sceptical of how AI is sold — as a replacement for people. But I do believe it has real use-cases. Here are the ones I think hold up in a token-priced world, with their trade-offs.
Use-cases that hold up
1. Summarisation
The first use-case I trust is using AI to navigate and condense large bodies of information — documentation, a codebase, an Adobe Analytics implementation, or a topic you’re researching. AI is exceptional at ingesting data, making connections, and giving you the overview. I think this has the broadest potential of all: technical writers, business users, and developers all benefit.
It’s also, unfortunately, the use-case most likely to drive cost up. But there are good reasons to pay to speed up ingestion rather than read everything yourself. In the end, the details still need to be understood and the decisions still need to be made by a human — but not everyone needs to understand every detail.
What surprises me is how little documentation clients and users actually produce, because this is where AI shines and where a virtuous loop forms: more documentation → more data for AI → better understanding and summarisation later.
2. Learning something new
I now use AI mostly to get up to speed on an unfamiliar framework — but it works just as well for personal interests, like checking that a marathon plan follows sound principles, or that a diet isn’t missing key nutrients. It’s a sub-class of summarisation, but I’d give it its own category: here you’re moving into territory that’s unknown to you but well documented in general, and you’re using the tool to widen your understanding and light up your blind spots. Because AI is impartial, it often surfaces things your own research would miss.
The cost here can be high too, but there are ways to keep it down (see below).
3. Building test suites
This one is for developers. Many codebases are short on tests, because tests are tedious to write and run — mine included. Since AI has seen so many codebases and is good at summarising existing code, it’s well suited to scaffolding a base set of tests. Cost scales with how much you generate, so the efficient move is to have it produce a few solid examples, then scale them out yourself once you have a template.
4. Brainstorming
Ideation has its limits (more on that shortly), but brainstorming and drafting a plan of action is one of AI’s strongest plays. Thanks to its breadth, it can approach a problem from angles you’d never think of, which is exactly what you want when you’re trying to avoid blind spots and get a plan off the ground. You can go deeper with its help too — but for owning the result and truly understanding it, I wouldn’t hand over the whole process. And remember: AI knows a great deal about a great many things, but it doesn’t know your data or your context, which may not be something you want to share with the AI companies anyway.
This is the most cost-efficient use-case I’ve found — as long as you don’t disappear down the rabbit hole.
5. Reviewing, not generating
The flip side of writing code or content with AI is having it review what you’ve already produced — and this is one of the most underrated, cost-friendly uses there is. Point the model at a function, a contract clause, or a draft and ask “what’s missing, what’s inconsistent, what would break here?” That plays directly to its strength: spotting patterns across a vast body of prior examples. It’s also cheap, because the work is in the short critique, not in generating pages of new content. In a way it’s the inverse of building test suites — instead of asking AI to produce something you then have to check, you keep ownership of the work and use AI as a second pair of eyes. The catch is the familiar one: treat its findings as suggestions to weigh, not verdicts to accept.
6. Translation and localisation
This one is close to home at Adobe, where content has to work across dozens of markets. Translation and localisation are a natural fit: the task is well-bounded, the training data is abundant, and the output is constrained enough that the probabilistic wobble matters far less than it does in, say, code. It won’t replace a professional translator for high-stakes or culturally nuanced copy — tone, idiom, and brand voice still need a human — but for getting a first, usable draft across a large volume of content quickly, it’s hard to beat on cost or speed. Pair it with a human review pass and you capture most of the value at a fraction of the effort.
Keeping the cost down: AI as a compiler, not a runtime
I promised a few times that there were ways to keep the cost in check, so here is the principle I keep coming back to: use AI as a compiler, not a runtime.
A runtime is something you call over and over, paying every single time. A compiler you run once to produce an artifact — a script, a template, a query, a config file — that you then reuse for free, forever. The expensive mistake is treating AI as a runtime: asking it to redo the same class of task on Monday, then again on Tuesday, paying tokens each time and reviewing the output each time.
The fix is to push the model toward the reusable artifact rather than the one-off answer. Instead of letting it complete a task blindly, ask it how it would do the task, where it gets its data, and — wherever possible — to hand you a script you can run yourself. The test-suite use-case is the same idea in miniature: generate a couple of solid examples, then scale them out by hand from the template instead of paying the model to grind through all of them. Even for learning, the artifact can be a cheat-sheet or a checklist you keep, not a conversation you re-run.
Done well, this turns a recurring token cost into a one-time one — and as a bonus, it forces some determinism back into your process. A script does the same thing every time, which is exactly what the model itself can’t promise.
Future-proofing your work with AI
We’re now seeing new offerings that automate whole tasks through AI workflows. For users, I think that’s a bad bet on several levels:
- You no longer own the process. You’re dependent on a provider to run your tasks, and with probabilistic models you’ll get the occasional surprise.
- “Just use Skills” doesn’t really fix it. Yes, Skills can enforce a proper flow and the right tool calls. But that’s reinventing the wheel — and the wheel is a technical specification. If you already have a description detailed enough to feed the AI, you’re better off building a deterministic system from it.
Cost aside, two principles keep AI in its place:
- Own the outcome. The biggest mistake I made early on was not taking enough ownership of the result. Whether it’s a script or a summary, you need to be able to fully understand it and stay critical of it.
- Don’t let AI drive. Its breadth is seductive, and it’s easy to believe it knows better than an experienced person in their own field. It doesn’t. Experienced people perceive far more context and fit their work into your system in ways the model can’t. In IT this is everywhere: seasoned developers find AI’s code ugly and inefficient, while newcomers vibe-coding their first project are amazed it produces a working proof of concept at all.
The tool is real, and it’s useful. But in the token era, the winning move is to treat AI as something you point at the right problems — not something you hand the wheel.