too cheap to meter

but too expensive to rely on

Intelligence is getting very cheap. Not free yet but its dramatically cheaper than even a few years ago.

Sam Altman argued that the cost of using a given level of AI has been falling dramatically, and that over time the cost of intelligence may converge toward the cost of electricity. And separately, he recently acknowledged that token costs have become a “huge issue” for some companies as usage scales.

The unit cost of intelligence can fall dramatically while total AI spend still rises, because once intelligence gets cheaper, people use far more of it.

At the same time, the barrier to building software has collapsed. A person with little to no coding ability, good taste and enough stubbornness can now stitch together APIs, models, databases, and interfaces that would have required a team not too long ago.

The upsides are great but it also creates a new kind of problem.

As intelligence gets cheaper and software becomes easier to build, the world fills up with systems that look impressive in demos but behave unpredictably in production.

In 2025, Replit’s AI agent reportedly deleted a production database during a coding experiment and misrepresented what had happened afterward. In 2026, a Claude-powered coding agent reportedly deleted a SaaS company’s production database and backups, disrupting real customer operations. A Pizza Hut franchisee later filed a $100 million lawsuit alleging that a mandatory AI delivery-management system damaged operations and customer satisfaction. Deloitte Australia partially refunded the government after a report contained apparent AI-generated errors, including fabricated references.

These are not just funny hallucination stories. They are examples of a deeper deployment problem.

AI systems add a failure mode traditional software handles poorly; they can fail softly, plausibly, and inconsistently. They produce plausible wrong answers and work when the input is clean then struggle with edge cases. sometimes once you fix the obvious edge cases, the less obvious ones become the new edge cases. They sound certain in moments where they should probably pause and the same failure might be harmless in one workflow and catastrophic in another.

The question is no longer just can the model do the task; the better question is how do we know?

How often does it fail? Where does it fail? Which failures matter? Which failures are harmless? Which ones cost money, create legal exposure, or force humans to redo the work? When should the system act automatically, and when should it escalate to a human?

As models improve, these questions matter more, not less. Because the easier it becomes to ship AI-powered software, the easier it becomes to deploy fragile systems into environments where reliability, security and safety actually matters.

That is what this series is about.

I’m writing this to deepen my understanding of eval driven applied AI systems from first principles by taking small AI prototypes and gradually shaping them into systems that are measurable, debuggable, and closer to production-grade software. I’ll be drawing from engineering resources, cookbooks, and repos from OpenAI, Anthropic, Google Deepmind, and others — not to copy them directly, but to understand the deeper ideas behind them.

So this first project is a receipt auditor: a small workflow that takes a receipt image, extracts structured receipt details, applies an audit policy, and eventually evaluates where the system succeeds or fails.

You can read it here:

Part 1: Building an Eval-Driven Receipt Auditor From Scratch

As intelligence becomes cheaper, judgment becomes more valuable and as AI systems become more agentic, evals become less optional.