Last month, I sat in a sprint planning meeting where someone suggested we "just use Claude to refactor this module." The suggestion landed like it always does, casual, reasonable, cost-free in the minds of everyone in the room. But I caught myself doing the math: if this module gets refactored by AI, then shipped to 200,000 active users who might trigger that code path dozens of times daily, what are we actually paying for here? Nobody had thought to ask. I realized most developers I know haven't either.
That conversation stayed with me. It led me down a rabbit hole of financial disclosures, infrastructure costs, and the uncomfortable truth that the AI revolution we're living through might be built on a business model that doesn't actually work yet. Anthropic's recent numbers crystallized something I'd been suspecting: we're treating AI like magic, when really we're staring at one of the most expensive infrastructure problems in software history.
The Token Economy Has Real Math Behind It
Here's what most of us don't think about: every time someone uses an AI tool, something is literally computing. Tokens are being processed. GPUs are burning electricity. That's not free, and it's not negligible. When you're running inference at scale, millions of requests, billions of tokens, the math stops being theoretical and becomes your entire business model.
I've built features where costs were architecturally inherent. A background job that processes images? I know the per-image cost. A search system? I can calculate queries per second and storage. But with AI, the variable cost structure is fundamentally different. Using the product more doesn't just scale your infrastructure linearly, it can actually destroy your unit economics if you're not careful.
Anthropic's financials reveal this tension perfectly. Sixteen billion in revenue sounds incredible until you realize they're losing money on scale. That's not a short-term problem to solve. That's a structural question about whether the business model works at all.
What This Actually Means for Developers
When I use an AI tool in my workflow, I'm no longer just thinking about whether it solves my problem. I should be thinking about whether it solves my problem cost-effectively. This is new. This is important.
The article mentions something that clicked for me: optimization now requires thinking in three dimensions instead of two. We've always optimized for correctness and speed. Now we need to optimize for cost per useful result. That's a completely different design constraint.
I've started tracking where I'm actually using AI tools and questioning whether the output is worth the inference cost. For boilerplate? Absolutely. For debugging complex logic? Sometimes, depends if I'm calling the API ten times or hundred times to solve it. For writing documentation? The economics get murky fast when the output needs significant human review anyway.
The uncomfortable question I'm grappling with: as these tools become ubiquitous in development workflows, will the cost structure become the primary constraint on what features we can actually build?
My Take: We're Confusing Growth with Viability
I agree with the original article's core argument, but I think it's underselling how urgent this is. Yes, Anthropic's operating loss was "only" $693 million in the first half of 2026. Yes, that's different from the headline $80.7 billion net loss (which was mostly accounting). But here's what bothers me: neither number is sustainable indefinitely.
Most SaaS businesses I've worked on or studied achieve profitability through unit economics that eventually work. You charge enough per customer that, after operational costs, you make money. AI companies are charging based on usage, and the usage is exploding faster than efficiency improvements can keep up.
I think we need to start being more critical about which problems actually warrant AI solutions. Not every feature should use an LLM. Not every query should hit a large model. The most sustainable AI products will likely be the ones that use AI specifically where it creates asymmetric value, not as a default behavior everywhere.
A Framework I'm Using Now
Here's how I'm thinking about whether to use AI in a project:
Question 1: Does this solve a problem that would otherwise require manual work?
Question 2: Is that manual work expensive (in money or time)?
Question 3: Can I reduce inference cost with caching, batching, or smaller models?
Question 4: Does the customer value justify the marginal cost?
Only proceed if all four are true.
The Question I'm Actually Asking Now
The real conversation happening in boardrooms and engineering teams right now is whether AI can ever achieve the margins that traditional software does. I don't know the answer. But I know I'm going to start asking it before I reach for Claude in my code.
What's your team doing about inference costs? Are you tracking it at all, or is it still magic?
Source: This post was inspired by "The Real Cost of AI: What Anthropic's Explosive Growth Reveals About the Future of Software" by Dev.to. Read the original article
