Cheap Tokens Won’t Make You a Better Engineer
AI usage may become cheaper or more expensive, but engineering value still comes from solving the right problem within real constraints.
I recently watched a video about whether the AI boom is a bubble.
It did not make the simplistic argument that AI is either entirely transformative or entirely overhyped. It compared the current investment cycle with railways, telecom fibre, and the dot-com era — technologies that created lasting value even when capital allocation and pricing became irrational.
One idea stayed with me: the technology can be real while the economics around it are still wrong.
That made me think less about market predictions and more about my own work as a data and AI engineer.
Cheap resources can hide weak engineering
AI tools currently make it easy to consume large numbers of tokens. Individuals experiment with assistants. Teams build agents, copilots, investigation workflows, and automation because trying another prompt or model call feels inexpensive.
But token capacity is only a resource. It is not evidence that the system is useful.
If I throw enough tokens at a problem and eventually produce an impressive demo, I have demonstrated access to compute. I have not necessarily demonstrated that I understood the problem, chose the right design, or created durable value.
The uncomfortable question is:
Am I becoming a better engineer because I can use more tokens, or because I am learning to solve problems better?
Those are not the same thing.
Constraints are part of the job
A good engineer works within the constraints that actually exist.
Sometimes the limiting factor is:
- delivery time;
- money;
- data quality;
- infrastructure capacity;
- latency;
- security and privacy;
- reliability; or
- the attention of the people operating the system.
Tokens may be cheap in one environment and expensive in another. A pricing model can change. A larger model can create unacceptable latency. A regulated workflow may prohibit sending particular data. A provider quota can become the bottleneck during an incident.
The engineering responsibility remains the same: solve the business problem with the resources and constraints available.
Measure outcomes, not consumption
For an AI-assisted workflow, token volume is an input metric. Useful outcome metrics might include:
- incidents resolved correctly;
- investigation time reduced;
- human review effort saved;
- false positives avoided;
- customer requests completed;
- decisions supported with evidence; or
- operational cost per successful outcome.
This changes design conversations.
Instead of asking “How much context can we send?”, we ask “Which context changes the decision?”
Instead of asking “Can the agent call five tools?”, we ask “Which tool call reduces uncertainty?”
Instead of asking “Can we automate the whole process?”, we ask “Where does automation create value without hiding risk?”
More tokens can help. They should still earn their place in the architecture.
Design for changing economics
Systems become fragile when they assume today’s resource price will remain constant.
A cost-aware AI workflow can include:
- Model routing — Use a smaller or cheaper model when the task does not require the strongest one.
- Context discipline — Retrieve the evidence needed for the current decision instead of repeatedly sending everything.
- Caching — Reuse stable results where freshness requirements allow it.
- Bounded loops — Limit retries and agent steps rather than allowing open-ended consumption.
- Observability — Measure cost, latency, quality, and failure modes per workflow.
- Graceful fallback — Preserve a manual or deterministic path for critical tasks.
- Evaluation — Test whether additional model calls improve outcomes before paying for them in production.
These are normal engineering practices applied to a new resource.
Bubbles do not erase useful skills
Investment bubbles can destroy companies without making the underlying technology useless. Telecom infrastructure remained valuable after many telecom businesses failed. The internet remained useful after the dot-com crash.
AI may follow its own version of that pattern. Some products will disappear. Some infrastructure may be overbuilt. Some business models will not survive contact with real costs.
The skill worth building is not the ability to depend on a particular token price. It is the ability to remain useful when the constraint changes.
That means:
- understanding the business problem;
- choosing when an LLM is appropriate and when it is not;
- designing reliable and observable systems;
- explaining trade-offs;
- validating claims with evidence; and
- using available resources deliberately.
If tokens stay cheap, use them well. If they become expensive, use them carefully.
In both cases, the engineer’s job remains the same: solve the right problem and create value.
The same skepticism should apply to the answers models produce, not just what they cost. I explore that in I Stopped Googling. Is AI Search Actually Honest?.