AI Moves Fast. Decisions Move Slow.
Still, it is easy to get hooked on token usage. Is it learning, experimentation, or just FOMO? Subscription models trained us to extract as much as possible from a fixed monthly payment. But when more usage creates more code to review, why do we need to max everything out? Are we getting more from AI? Or are we repeating an old consumption habit with a new resource? I was reading and watching Gergely Orosz’s conversation with Dex Horthy, “Context engineering with Dex Horthy”, and it made me think about fast loops, slow loops, token harder, and token smarter. Faster loops do not necessarily accelerate value delivery. Unless the lead time decreases and the value increases, we may be trapped in local optimization.
Are these actually competing choices?
The industry is making two decisions. Fast versus slow describes the agent cadence. Token harder versus token smarter describes how we spend AI computation.
One is cadence. The other is resource strategy.
They are related. They are not the same. Consider this request:
“Build a reconciliation dashboard for our largest customer by Friday.”
It sounds like a coding problem. That is already the first mistake.
We can combine the two dimensions in four ways:
- Fast and hard: many agents, many attempts, constant human steering.
- Fast and smart: one bounded change, clean context, immediate verification.
- Slow and hard: several autonomous agents producing overnight artifacts.
- Slow and smart: deliberate research, fresh contexts, strong gates, one reviewable outcome.
What can the work safely absorb?
What does a fast loop optimize?
A fast loop optimizes interaction latency. Ask. Change. Test. Inspect. Correct. Repeat.
This works for refactorings, failing tests, compiler errors, and local debugging. For our dashboard, an agent could generate the UI, connect an endpoint, and fix bugs before lunch.
It could also build the wrong reconciliation model before anyone defines what “reconciled” means.
Fast loops become dangerous when the human keeps correcting the agent inside the same noisy trajectory. Wrong assumptions become context. The model apologizes enthusiastically and repeats the same class of mistake.
The loop is fast. Learning is not.
IMHO, we may be learning more slowly with AI. How much are we retaining? How much muscle memory are we building? How much can we explain the next morning without opening the chat history?
Fast feedback on the wrong question is wrong faster.
What does a slow loop optimize?
Dex describes slow loops in which nightly agents investigate a bounded problem, implement a change, run verification, and open a pull request for human review the next morning. HumanLayer later ran several loops in parallel, but people still reviewed the PRs.
The important output is not an endless conversation. It is a branch, a diff, evidence, and a decision.
For our dashboard, a slow loop might inspect the schemas, document disputed definitions, identify sensitive fields, prototype the query, and return with a design plus a limited implementation.
Eight hours passed. The developer did not spend eight hours correcting autocomplete.
Slow is not idle. Slow is uninterrupted.
When should we Token Harder?
Token harder means using more agents, sessions, context, stronger models, attempts, and inference.
This works when the problem decomposes cleanly and the verifier is trustworthy.
It fails when we parallelize ambiguity.
Four agents can build four dashboards. They can also encode four incompatible meanings of reconciliation and hand the human a small distributed monolith made of pull requests.
Parallelism multiplies certainty. It multiplies uncertainty too.
Before tokening harder, ask:
- Can the work be divided without shared-state chaos?
- Are the outputs independently testable?
- Is the blast radius bounded?
- Can weak results be rejected cheaply?
- Can humans absorb what the agents produce?
AI throughput is useless when human attention is saturated.
What does Token Smart optimize?
Token smarter optimizes leverage per expensive interaction. Research first. Then design. Then plan. Then the implementation. Then verification.
Compact useful findings into durable documents. Restart poisoned sessions. Remove irrelevant history. Use the strongest model where uncertainty and architecture matter. Use cheaper models when the task becomes mechanical.
For our dashboard, token smarter means spending the first serious interaction defining the business contract—not generating UI components.
The real constraint is rarely token availability. It is directing tokens toward the right problem.
Is software now disposable?
Auren Hoffman argues in “Disposable software: software is now just paper plates” that software created in 2026 may have a shelf life of roughly 3.8 months.
It is a sharp idea, and I partly agree. Software can become more disposable, but it depends on what we build. An isolated app can be replaced or deleted faster. A distributed monolith connected to databases, queues, and critical workflows is not a paper plate.
It is still the dirty kitchen. Enterprises keep software because it accumulates integrations, permissions, audit requirements, exceptions, users, and political ownership.
With agents, it may become easier to kill software. But only when it was designed to die.
Killability is an architectural property. There is also a false assumption hiding here: code was the bottleneck.
Sometimes it was. But often, people did not know what they wanted, what had value, what should be built first, or how deep the solution needed to go.
AI-made implementation cheaper. It did not make ambiguity disappear.
And if we build ten times more applications, we inherit ten times more things to discover, secure, standardize, observe, govern, and eventually remove. More output is not necessarily more progress.
It depends on how much we learn from that output, how much we retain, and how much of it the organization can safely absorb.
The agents may be getting faster. The decisions are still slow.
Paper plates still create garbage.
