LeeBoonstra.dev
AI DevelopmentEngineering ManagementDeveloper Workflow

Blaming the Developer for the AI Bill? You’re Managing Software Like It’s 1996.

Lately, my social media feeds have been flooded with a new confusing take on what defines a “pro” software engineer in 2026. The narrative goes something like this: “With modern AI tooling, anyone can spit out code. Therefore, a truly senior developer is a ‘token-aware’ developer—someone who writes prompts carefully to keep the company’s LLM bill low.”

Let’s call this what it is: absolute nonsense.

It’s true, the amount of AI tokens that gets burned creates anxiety. But that fear is born from a cycle of corporate mismanagement that tech executives brought entirely on themselves. Instead of pausing to restructure how software actually gets built in an AI-first world, leadership teams across the industry followed a flawed and outdated playbook.

The playbook goes like this: first, overhire engineering departments during a market boom. Next, hand thousands of engineers a cutting-edge AI toolkit like Claude Code or Antigravity, with no new guardrails. Finally, watch in horror as this unmanaged workforce racks up a million-dollar consumption bill, then launch massive layoffs—scapegoating the very people you just overloaded.

We have watched this exact cycle play out in real-time with tech giants like Meta and Amazon slashing corporate positions explicitly to offset ballooning AI infrastructure and compute costs. It’s a classic case of bad planning: management used AI as a brute-force multiplier for an already bloated org structure, rather than a catalyst to design a lean, modern engineering pipeline. And now? The engineers who survived the layoffs are being told they need to be “token-aware” to save the company money. Trying to blame a developer’s “token hygiene” for these operational costs completely misdiagnoses the problem—and proves that your business is stuck in the past.

The Three Types of Token Bills (And Why Seniors Already Get It)

To understand why this “token-aware developer” narrative is a myth, we have to split the AI bill into three completely distinct buckets:

Blaming the SWE for high AI costs

1. Production API Costs

This is the cost of running AI features inside the application your customers use. The more users interact with your product, the more tokens you consume. This isn’t a new paradigm. Twenty years ago, working with SOAP web services and paid third-party APIs taught senior engineers to treat external calls with care by architecting caching, optimizing payloads, and building guardrails. A senior developer already understands that the core concept of resource management hasn’t changed.

2. Developer Tooling Costs

This is where the real surprise shock is happening. Companies are seeing massive bills from AI-native IDEs and developer tools. But trying to penalize a developer for using tokens in their development tool is fundamentally broken.

Imagine giving a carpenter a brand-new toolbox, only to tell them: “Hey, we’re going to charge the business a dollar every time you swing that hammer. So, try not to use it too often.”

Certain tasks require the hammer. Sometimes you misalign a nail, or the wood splits, and you have to pull it out and do it again. That isn’t sloppiness; that is the messy, iterative reality of craftsmanship. And this is exactly how it works with AI developer tools: usage costs tokens. Coding tools are powered by Large Language Models. They predict the next statistical token based on massive codebases. Expecting a developer to artificially limit their tool usage to save pennies on context windows is asking them to fight the machine. We didn’t ask engineers to go back to steam engines because coal got expensive; we don’t ask 2026 developers to ration their keystrokes.

3. The Agentic Multiplier

What most people miss is that we are in the era of Agentic AI, not just chatbots. Developers now deploy autonomous agents that can, for example, resolve a dependency conflict by interacting with filesystems, calling tools, and spinning up sub-agents. By definition, their core loop—Plan, Act, Observe, Correct—is token-hungry, requiring massive context from codebases and error logs to iterate. A single agent fixing one tricky bug might burn millions of tokens in an afternoon.

To expect a human developer to be “token-aware” of a headless agent’s autonomous reasoning loop is fundamentally absurd. You cannot micromanage a machine’s cognitive process to save pennies while it’s busy saving you weeks of human labor. If an agent spends $50 in tokens to automatically refactor a legacy module while your team sleeps, it didn’t “waste” resources—it traded cheap compute for expensive human time.

Don’t Blame the Tool. Fix Your Business Model.

If the AI bills are extraordinary—and they are—the entity to blame isn’t the developer, and it isn’t the AI vendor. It’s your own business architecture.

Corporate procurement and IT departments are still trying to measure AI usage with outdated rubrics like per-seat licensing or fixed hardware costs. They treat an AI tool as a simple line-item expense, not as the organizational restructuring force it truly is.

Look at the trade-off. With agentic AI and advanced tooling, developers can produce code exponentially faster. If your engineering velocity increases by 10 times, your development math completely changes. Consider the shift in resource allocation. Previously, a feature might have required a five-engineer team for a full month. Today, a single engineer using autonomous agents can ship that same feature in a few days. The cost doesn’t disappear; it simply shifts from being 99% salary to a new blend of salary and compute.

Your AI developer tooling bill might look shocking on paper, but you just saved weeks of human engineering hours. If your management can’t see that the net ROI is massively positive, the problem isn’t the tokens—it’s the accounting.

How to Actually Lower Your AI Bill

If you actually want to go cheaper, the solution isn’t to tell your developers to type shorter prompts or write fewer prompts. The solution is to architect a smart, tiered AI infrastructure. A smart organization builds an ecosystem that uses the right tool for the job.

Task Complexity Recommended Model / Approach Cost Profile
Architectural Planning & Complex Debugging Frontier Models (e.g., Claude 3.5 Sonnet, Gemini Pro) Premium
Routine Code Generation & Standard Linters Small/Medium Models (e.g., Gemini Flash, Claude Haiku) Ultra-Low
Local Autocomplete & Simple Refactoring Local Open-Weights LLMs (via Ollama / Llama 3) Free (On-Device Compute)
Static Logic & Known Syntax Rules Traditional Regex, Linters, and Scripts Zero AI Required

Not every task requires a massive, multi-billion-parameter frontier model. Local open-weights models running directly on developer machines are now incredibly capable at handling inline autocomplete, basic docstring generation, and simple refactoring—costing the company exactly zero tokens.

Furthermore, we need to stop routing every task through an LLM by default. If a task can be solved by a traditional regex expression, a well-written shell script, or a standard linter, it shouldn’t be sent to an LLM at all. True efficiency comes from fallback routing and model switching, not micromanaging human behavior.

When you enable an engineer to drive at warp speed, the problem isn’t how much fuel they’re burning. The problem is whether your tracks can handle the speed. As I wrote about recently in my post, Learning the Hard Way: When Agents Build Agents, accelerating code production doesn’t magically solve software engineering. It simply moves the bottleneck downstream to integration, code review, and architectural alignment.

Stop Counting Tokens, Start Counting Value

The “token-aware developer” is a management cop-out—an attempt to push the anxiety of rising IT bills onto the people hired to build your future. When you measure success by the cost of the tools instead of the velocity of the output, you are missing the entire point of the AI revolution. Stop worrying about the hammer. Start worrying about what you’re building with it.

Lee Boonstra

About the Author

Lee Boonstra is an AI Software Engineer & Advocate in the Google Cloud Office of the CTO (Applied Innovation Factory). They specialize in secure multi-agent systems, frontier LLMs, and voice technology. Lee is the author of reference books for O'Reilly and Apress, and the viral Kaggle/Google Prompt Engineering whitepaper.

Disclaimer: The opinions stated here are my own, not those of my company. • 2026 ® Lee Boonstra • Hexo Blog Design by Lee Boonstra