Twice as many chips. That’s what Jensen Huang says Nvidia will sell next year compared to this one, and it’s the number I keep coming back to every time someone asks me whether the AI build-out is slowing down. It isn’t. The company selling the shovels just told everyone to expect double the shovels.
The context matters. In 2026, Huang has repeatedly pushed back on calls to slow AI development, arguing that progress should move as fast as possible and that AI is essential infrastructure rather than an optional experiment. At Dreamforce, in conversation with Salesforce CEO Marc Benioff, he said we don’t need new regulations, and made the case that market forces are enough to keep AI safety on track. That put him at odds with Anthropic’s Dario Amodei and with other industry leaders who’ve argued for guardrails ahead of capability.
I’m not writing this to pick a side in that argument. I build bots for a living. What I care about is what a “fast as we can” posture from the world’s largest chipmaker actually does to the systems I ship next quarter.
Infrastructure framing changes how you architect
When Huang calls AI essential infrastructure, he’s describing something closer to electricity or bandwidth than to a product feature. That framing is worth taking seriously even if you disagree with his regulatory conclusions, because infrastructure has specific engineering properties: it gets cheaper, it gets more available, and you eventually stop designing around its scarcity.
Most bot architectures I see still treat model inference like a rare, expensive resource. Aggressive caching of model outputs. One-shot prompts that try to do six things because each call hurts. Elaborate routing logic to keep the small model handling as much as possible. That’s scarcity thinking, and it’s a reasonable response to today’s bills.
But if chip supply roughly doubles year over year, the cost curve you’re optimizing against is a moving target. Designs that hard-code today’s economics tend to age badly. A few practical adjustments:
- Keep model selection in config, not in code. When the price of the bigger model drops under your threshold, that should be a one-line change.
- Build for multi-call reasoning even if you currently run single-call. Splitting a task into plan, execute, verify costs more calls and produces better results. That trade gets more attractive every quarter.
- Instrument cost per resolved task, not cost per token. Token cost falling is only useful if you can see what it buys you.
The safety argument lands differently at the application layer
Huang’s position is that markets will handle AI safety. Whatever you think of that as policy, notice where it puts the work. If there’s no new regulatory layer specifying what a deployed agent must do, then the constraints live in the application code. Yours. Mine. The person shipping a customer service bot on a Friday afternoon.
That’s not a complaint, it’s a job description. Market forces enforcing safety means users leaving products that embarrass them, enterprises refusing to sign contracts with vendors who can’t explain a failure, and support teams eating the cost of an agent that took a bad action. Those pressures are real. They also arrive after something has gone wrong, which is a lousy feedback loop to rely on as your only one.
So build the loop yourself. The patterns that hold up are unglamorous:
- Permission scoping per action, not per session. An agent with a valid session token and unlimited tool access is a liability waiting for the right prompt.
- Structured logs of every tool call with inputs and outputs. When something goes sideways, “we don’t know what it did” is the worst sentence you can say to a customer.
- Human confirmation on anything irreversible. Refunds, deletions, outbound messages to real people. Reading is cheap, writing is expensive.
- Evaluation suites that include adversarial inputs. Not just does it work, but what happens when someone tries to make it misbehave.
None of that depends on who wins the regulation debate. It’s the same work either way.
What I’d actually change this month
If I were planning a bot roadmap right now, I’d read Huang’s stance as a signal that capability and availability keep climbing and that nobody is coming to define the rules of deployment for me. That points at two concrete moves.
First, stop building around model limitations you’ll outgrow. Abstract the model layer so swapping it is boring. The teams that get stuck are the ones whose prompt engineering is load-bearing architecture.
Second, over-invest in the boring safety scaffolding now, while your user count is small enough that mistakes are survivable. Logging, scoping, confirmations, evals. These are cheap to add early and painful to retrofit.
Huang is building the road as fast as he can. That doesn’t mean everyone driving on it should skip the seatbelts.
🕒 Published: