AI Is a Technology, Not a Product — and That Changes Everything

What happened

John Gruber published a piece on Daring Fireball this week that crystallizes a debate simmering across the industry: AI is a technology, not a product. The argument is deceptively simple — ChatGPT, Claude, Gemini, and their ilk are products built *on* AI, but AI itself is an enabling technology, the way electricity, the transistor, and the internet were enabling technologies. Nobody bought "electricity" — they bought refrigerators, light bulbs, and factory automation. The companies that won weren't selling the technology; they were selling what the technology made possible.

The piece landed on Hacker News with a score of 368, triggering a sprawling discussion that exposes how differently practitioners and investors think about AI's trajectory. Gruber's framing isn't new — he's been making variations of this argument since Apple's WWDC strategy became legible — but the timing matters. We're 18 months past the initial ChatGPT hype cycle, and the market is starting to sort itself.

Why it matters

The technology-vs-product distinction isn't semantic. It has concrete implications for where venture money flows, how companies architect their products, and what developers actually build day-to-day.

The product trap. Companies that treat AI as the product face a brutal commoditization curve. If your entire value proposition is "talk to our AI," you're one API price cut away from irrelevance. OpenAI, Anthropic, and Google are already in a pricing race to the bottom on API access — the same pattern that turned cloud compute from a premium offering into a commodity in under a decade. The chatbot interface, which felt revolutionary in late 2023, is increasingly a commodity wrapper around interchangeable models. Users don't have chatbot loyalty the way they have tool loyalty.

The HN discussion surfaces this tension directly. Several commenters point out that ChatGPT *is* a product with 200+ million weekly users — it clearly works as a standalone offering right now. But others counter that this looks a lot like AOL in 1998: a product that dominated a transitional moment before the technology it popularized got absorbed into everything else. The AOL analogy is imperfect, but the pattern recognition is sound.

The infrastructure play. Gruber's implicit argument — shaped by years of covering Apple — is that the real leverage comes from embedding AI so deeply into existing products that users never think about "using AI." They just notice that autocomplete got smarter, their photo library organized itself, or their code editor started finishing functions correctly. The best AI integration is the one users don't notice as AI — it just feels like the product got better.

This maps onto what we're actually seeing in the developer tools space. GitHub Copilot didn't ask developers to switch to an AI product. It embedded itself into the editor developers already used. Cursor took it a step further by making the AI *the* editor, but even that framing is "better code editor" not "AI chatbot for code." The tools winning adoption are the ones that meet developers in their existing workflow.

The middleware question. There's a third category that neither Gruber nor most of the HN discussion fully addresses: AI-as-middleware. Companies like Vercel (with v0), Supabase (with AI-assisted schema design), and dozens of devtool startups are using AI not as the product or as invisible infrastructure, but as an accelerant layer in specific workflows. This is arguably the most interesting space for developers right now — AI that handles the tedious 80% of a task while you focus on the interesting 20%. It's visible enough that you know it's AI, but useful enough that you don't care about the abstraction.

What this means for your stack

If you're building a product, the question Gruber's piece forces is: where does AI sit in your architecture? Three practical implications:

1. Don't build an AI product; build a product that uses AI. This sounds obvious, but look at your roadmap. If the word "AI" appears in your feature names more than in your implementation details, you might be selling the technology instead of the outcome. Users don't want AI — they want the thing AI makes possible: faster search, smarter defaults, less boilerplate, fewer manual steps. Frame your features around outcomes, not capabilities.

2. Architect for model swapability. If AI is a technology and not a product, then your specific model provider is an implementation detail. The teams that are tightly coupled to a single provider's API surface (using provider-specific features, fine-tuning without abstraction layers, baking prompt formats into business logic) are accumulating the same kind of technical debt that teams accumulated by coupling to specific cloud provider APIs in the 2010s. Use abstraction layers. Keep your prompts in configuration, not in code. Design your AI integrations so you can swap Claude for GPT for Gemini for Llama in an afternoon, not a quarter.

3. Measure the outcome, not the AI. If your AI feature requires users to understand that it's AI-powered to appreciate it, it's probably not good enough yet. The features that stick are the ones where removing the AI would make the product noticeably worse, but users wouldn't describe the improvement as "AI." They'd say "it just works better now."

Looking ahead

Gruber's framing will age well. The companies that dominate AI's second act won't be the ones with the best model — they'll be the ones that figured out where to embed that model so deeply into an existing workflow that switching away feels like losing a limb. For developers, the takeaway is both liberating and clarifying: stop building "AI features" and start building better features that happen to use AI under the hood. The technology disappearing into the product isn't a failure of marketing. It's the definition of success.