What happens when the guy who profits most from AI acceleration tells you AI should accelerate?
That question sat with me for a while after Nvidia’s Jensen Huang told CBS News in September 2026 that AI should be developed “as fast as we can.” He doubled down at Dreamforce, rejecting calls to slow progress and arguing that market forces are enough to handle AI safety. No new regulations needed. This puts him at odds with other industry leaders, notably Anthropic’s Dario Amodei, who has been considerably more cautious in public.
I review AI tools for a living. I install them, break them, and write down what actually happens instead of what the launch post promised. So my interest in this isn’t philosophical. It’s practical. When the CEO of the company supplying the compute says “go faster,” that pressure lands on my desk in a very specific form: more tools, shipped sooner, tested less.
Speed shows up in the changelog
Here’s what “as fast as we can” looks like from the reviewer’s seat. Agent frameworks that rewrite their core API twice in a quarter. Tools that ship an impressive demo and a broken error-handling path. Documentation that describes version 0.4 while the package manager serves you 0.9. Integrations that work beautifully until a dependency moves and nobody notices for three weeks.
None of that is Huang’s fault directly. Nvidia sells chips, not half-finished agent orchestration libraries. But the argument he’s making — that market forces are sufficient — is worth examining against what the market is actually producing, because I look at that output every week.
The market rewards shipping. It rewards launch threads, waitlists, and benchmark screenshots. What it rewards much less reliably is the boring work: regression tests, stable interfaces, honest limitations in the README, a changelog that tells you when something broke. Those things cost time and generate no announcement. In a race where speed is the stated virtue, they’re the first items cut.
Where the “market solves it” argument holds up
I want to be fair, because Huang isn’t obviously wrong. Markets do punish bad tools. I’ve watched it happen. A framework that corrupts data, loses credentials, or burns through API budget gets abandoned fast. Developers talk. Bug reports pile up. Stars stop climbing. That feedback loop is real and it’s faster in software than almost anywhere else.
His other point — that AI is essential infrastructure — also lands. Infrastructure arguments are how we justify building anything at scale, and if you believe AI is closer to electricity than to a product category, then slowing down looks less like caution and more like self-harm.
The problem is that market correction is reactive. It works after the failure. For a text summarizer, that’s a fine tradeoff. For tools wired into payments, medical records, or anything with write access to production systems, “the market will sort it out” means something users have to live through first.
What this changes about how I test
If the pace stays where it is, the review process has to adapt. A few things I’ve moved to the top of my checklist:
- Version stability over feature count. A tool with six solid features and a stable API beats one with twenty features and breaking changes every sprint.
- How it fails, not just how it works. Bad network, malformed input, rate limits. The demo path is always fine. The failure path tells you whether anyone thought about production.
- Permissions by default. Does it ask before it writes, deletes, or sends? Agentic tools that assume broad access are the category I’ve grown most wary of.
- Documentation honesty. A README that lists what the tool can’t do is a signal about the team behind it.
- Age of the last real maintenance commit. Not a version bump. Actual fixes.
That’s not a critique of speed as such. Fast development has given us genuinely useful tooling in categories that didn’t exist two years ago. My local setup is better than it was, and most of the improvement came from projects moving quickly.
Sitting with the tension
Huang’s position and Amodei’s position can both be partly right, which is the uncomfortable part. Acceleration produces capability. Caution produces reliability. You need both, and the industry has stopped pretending it can optimize for them simultaneously.
What I’d push back on is the framing that this is a debate with one correct answer. It’s a tradeoff with distributed costs. Nvidia’s incentive is volume. Huang has said he expects to sell twice as many chips next year. The people absorbing the reliability cost of a faster cycle are developers wiring these tools into real systems, and their incentives point the other way.
So take the acceleration argument seriously, then test everything as if nobody is coming to save you. That’s not cynicism. That’s just the job.
🕒 Published: