When Chasing Speed Costs More Than Tokens
Field notes of building an AI agent tool and pondering about bigger things.
I'm a CEO building an AI agent tool, and lately I've been watching our Claude bill the way you watch your phone battery at 12% with no charger in sight.
It started when we ran out of credits in the middle of an agent run. One moment the pipeline was humming, the next it just stopped. After that, I began refreshing the balance compulsively. In one work week, with less than three hours a day of agent usage, I watched over $400 disappear. Every twenty minutes or so, I'd glance at the balance and find it had dropped another ten or fifteen dollars.
I'm usually generous about paying for good tools. But this didn't feel like being empowered by a good tool. It felt like pumping premium fuel into a race car to cross downtown for groceries. The engine was impressive. It also felt wildly excessive for the errand I was running.
Asking the Tool How to Use the Tool
So I did what I should have done sooner. I slowed down and asked for directions.
Before my real solo session with Claude Code, I went to Claude's chat interface and asked it how to work with itself more efficiently. There is something wonderfully meta about asking a tool to teach you how to stop wasting the tool.
The advice was genuinely useful. Three things I'm now practicing:
Read once and hold. LLMs tend to re-read files they've already consumed, "just to be thorough." Have it read everything once at the start. LLMs remember the beginning and end of a session far better than the middle. Curiously, that pattern resembles a quirk of human memory that psychologists call the serial position effect.[1]
Specify the outcome, not the implementation. This is almost exactly what the Agile community has been saying about user stories for twenty years. Describe what you want and why, not how to build it.
Require clarification before action. Tell it to ask for clarifications before finalizing a plan, and not to touch code until you give explicit permission. Left alone, an LLM behaves like an eager junior developer who starts rewriting your codebase with a half-baked plan before you've finished your sentence.
There was one "how" I did specify: don't use the LLM for deterministic tasks that a traditional API handles just fine. Our AI-generated code had been using agents for things like creating a GitHub repo and branch. The race car had been roaring down the highway to pick up groceries a few blocks away.
Once we switched those tasks to API calls, two things happened. Token usage dropped noticeably. And the flaky, unpredictable agent behaviors I'd written about in my previous two posts subsided.
The engine kept running. It was finally on a road that made sense for what it could do.
The Roundabout Route
Slowing down to learn the tool turned out to be the fastest path forward. It reminded me of something I lived through years ago.
I was leading a project at a large e-commerce company. Tight timeline. The system had to be live in time for the holiday gifting season. The work involved physical warehouse layout changes and a key device from a vendor we'd never worked with. We agreed on a complex workflow. Everyone was aligned. The clock was ticking.
Weeks in, my tech lead said he wanted to revisit the workflow.
My stomach dropped. We did not have time for this. I pushed back. He didn't budge.
So we met again. He walked us patiently through a flaw in the original design that none of us had seen, then proposed a correction. We tried to punch holes in it but couldn't find any. The revised workflow was not only correct, it was simpler to implement and less error-prone than what we'd already agreed to.
The project shipped on time, with no major hiccups. If we'd kept the original workflow to "save time," we'd almost certainly have hit problems in production during the busiest week of the year.
What looked like slowing down was the fastest path. He wasn't blocking progress. He was doing the unglamorous, deliberate work that the rest of us, under pressure, had stopped doing.
In Japanese, there's a proverb for this: isogaba maware (急がば回れ), "if you're in a hurry, take the roundabout route." It dates back to the Muromachi period (15th–16th century), originally about choosing the longer route around Lake Biwa over a quick but dangerous shortcut across a bridge.[2] Five centuries later, the advice still applies. What looks like the speediest path often costs you far more time, money, and trust to repair.
My tech lead had the experience and the courage to slow down when everyone else was pushing to go faster. He had the room to do that. Right now, across our industry, the incentives are pointing in the opposite direction.
Unspoken Assumption
Two moments from recent AI sessions have stayed with me as examples of the industry’s current direction.
In one session, an attendee described their setup with quiet pride: no human reviews their code, and no human tests it. Their argument was that their testing agents test the code, and the agents are self-improving. Human in the loop was only impeding the speed, according to them.
In another session, a different attendee from another company made a related claim. Human readability of code, they said, is no longer important. As long as the LLM understands it, that's all that matters now.
The facilitator pushed back on the second one, pointing out that clean, tight code is in fact easier for an LLM to work with, not just humans. I nodded in agreement.
But what struck me the most was that both speakers sounded certain. These weren't reckless people; They were thoughtful engineers and leaders. Yet, their reasoning seems to have quietly drifted somewhere I found uncomfortable.
Two companies, one unspoken assumption: whatever slows us down must be unnecessary now, because the AI is so fast.
As a user, would you trust a product knowing no human inspected the code before it shipped? As a technical leader, would you ship that product knowing you'll be accountable for whatever goes wrong? As an engineer, would you let AI debug a production issue in a codebase you've never read?
Most of us feel a twinge on all three.
We Are Our Own Enemy
Around the same time, the industry produced a more public example of the same drift. You've probably already read about "tokenmaxxing," the practice of engineers at Meta, Microsoft, Salesforce, and now Amazon inflating their AI token usage to climb internal leaderboards. Meta's leaderboard awarded titles like "Token Legend" before the company quietly took it down after media coverage.[3][4]
Is this just Goodhart's Law again? When a measure becomes a target, it ceases to be a good measure?
Partly. But combined with the two conversations I described earlier, this suggests something deeper is going on. Those speakers weren't gaming a metric. They had genuinely concluded the slow work was unnecessary. That's not measurement gone wrong. That's judgment gone wrong.
Daniel Kahneman, in Thinking, Fast and Slow, distinguishes our thinking process between System 1 (fast, instinctive, effortless) and System 2 (slow, deliberate, effortful).[5] Our biology is wired to conserve energy, which means System 1 wins by default unless we actively resist it. Under pressure, we're even less likely to engage System 2.
When I was checking our billing page every twenty minutes, that was System 1 running the show. When I finally stopped and asked Claude how to use Claude, that was System 2 taking over. My tech lead, reopening a settled workflow under deadline pressure, was pure System 2. The two speakers I described above, confidently waving off code review and code readability, sound to me like very smart System 1, unchallenged.
We are letting AI's speed overstimulate our System 1. The speed is so compelling that it's becoming spellbinding. Unless we actively engage System 2, speed starts to look like competence, and quantity starts to look like quality.
The Asymmetry Nobody Talks About
Andrea Laforgia, a master software engineer whose writing I respect, recently put it this way on LinkedIn. The industry has been on this seesaw before. Speed on one end, quality on the other, and a queue of executives ready to sit on the speed side until the whole thing tips over.[6]
He's right. And the speed side just got a huge AI boulder strapped to it.
But the seesaw metaphor, as much as I love it, understates the real problem. Speed and quality aren't symmetrical opposites on a balance. They're different kinds of things.
Speed is easily quantified. Cycle time, deployment frequency, time-to-market, tokens consumed. It fits on a dashboard. It looks great in a board deck. System 1 instantly loves it.
Quality is almost the opposite. What counts as "quality" depends on the user's specific pain, their values, their context, even their culture. It's continuous and analog. It resists being reduced to a number. Quality is System 2 territory, all the way down.
This asymmetry is the reason "balancing speed and quality" sounds reasonable in a meeting and dissolves the moment anyone tries to actually do it. You're not balancing two weights. You're balancing a number against a judgment. The number always wins the next meeting unless someone with authority and courage insists there is more to the story.
What I'm Trying to Hold Onto
I'm thrilled by what AI agents and LLM tools can do. The tooling, the automation, the iteration cycles, the code generation. They let a small team like mine do things we couldn't have imagined a year ago.
But I also feel a quiet, industry-wide drift toward measuring what's easy (tokens burned, velocity, time-to-market) and neglecting what's hard. Does this product actually work well for the people who use it? Are we building the right thing? Have we earned the trust of the people we're asking to rely on us?
These are System 2 questions. They're slow. They're effortful. They don't fit on a dashboard. And they are the work that turns users into fans, because quality that's woven into a product in a way that meets a real human need, the user feels. They can't always articulate it, but they can feel it. That feeling is what builds trust, and eventually, loyalty.
So as someone building an AI agent tool, here's the discipline I'm trying to hold onto. When the speed of these tools tempts me to skip the slow conversations about what to build, for whom, and why, that's exactly when I need to have them. When a metric looks impressive, that's when I need to ask whether it is measuring what's valuable. When everyone around me is sure, that's when I want to invite the uncomfortable question.
I don't have a tidy framework for this. I have a Japanese proverb from the 15th century, a billing page that taught me humility, and a growing suspicion that the real cost of chasing speed in the AI era won't show up on the token bill. It'll show up much later, in the trust we have to rebuild.
The race car is impressive. The question is whether you're driving it for the right reasons.
More field notes to come, mistakes, surprises, and all.
Footnotes / Sources:
[1] The serial position effect, first described by Hermann Ebbinghaus in the 1880s, demonstrates that items at the beginning (primacy effect) and end (recency effect) of a sequence are better recalled than those in the middle. This is well-documented in cognitive psychology literature.
[2] Isogaba maware (急がば回れ) is a well-known Japanese proverb. It is commonly associated with a poem referring to the choice between a quick but risky boat crossing of Lake Biwa and the longer but safer land route around it. The attribution and exact origin are debated among scholars.
[3] Gergely Orosz, "The Pulse: 'Tokenmaxxing' as a weird new trend," The Pragmatic Engineer, April 23, 2026.
[4] Beatrice Nolan, "'That doesn't sound very healthy': Amazon's reported tokenmaxxing might gamify AI usage, analyst warns," Fortune, May 12, 2026. Based on original reporting by the Financial Times. ‘That doesn't sound very healthy’: Amazon’s reported tokenmaxxing might gamify AI usage, analyst warns | Fortune
[5] Daniel Kahneman, Thinking, Fast and Slow (Farrar, Straus and Giroux, 2011).
[6] Andrea Laforgia, LinkedIn post, 2026. #ai #artificialintelligence #softwaredevelopment #softwareengineering | Andrea Laforgia | 15 comments
