AI Is a Technology, Not a Product: What Devs Should Build Instead

The Electricity Argument

When Gruber writes that “AI” is a technology, not a product, the analogy he reaches for is electricity. You don’t sell “electricity-powered” toasters because every toaster is electricity-powered. The thing you sell is a toaster.

The argument isn’t new — Ben Thompson and others have been pushing similar framings for years — but it lands differently in 2026, after eighteen months of “ChatGPT for X” pitch decks that mostly closed down. The point is structural: when a capability becomes table stakes, branding around the capability becomes incoherent.

For developers, the implication is uncomfortable. If “AI app” is a category in the way “electric app” never was, you’re a few quarters away from your category dissolving underneath you.

Why GPT Wrappers Keep Dying

The “GPT wrapper” critique gets caricatured, but the underlying pattern is consistent: a thin UI sits on top of someone else’s model, charging a subscription for prompts the user could write themselves.

Three things tend to kill them.

The model vendor undercuts you. When OpenAI shipped GPTs and projects, a wave of $20/month “personal assistant” SaaS products went from differentiated to redundant within weeks. The same pattern repeats every time Anthropic ships Projects, Google ships Gems, or Cursor extends its own agent surface.

The switching cost is zero. If your only asset is a system prompt and a tuned UI, a competitor can clone you over a weekend. There’s no data gravity, no integrations, no team workflow lock-in.

The unit economics invert when the underlying API price drops. Wrappers that worked at last year’s token prices stop working as costs fall, because the savings flow to users via competitors, not to your margin.

None of this is fatal in isolation. It’s fatal in combination — and the combination is what defines a wrapper.

What to Build Instead

The framing that survives the electricity test: build something that would still be useful if the AI got much cheaper or much worse, and then use AI to make it better.

A few patterns hold up.

Workflow products with AI features. Notion, Linear, and Figma all shipped AI as a feature, not a positioning. If their AI stopped working tomorrow, you’d still pay for the product. That’s the test.

Tools with proprietary context. Cursor’s edge isn’t “uses Claude” — every editor can do that. It’s the indexing, the agent loop, and the keyboard-native UX that makes a model call feel like an editor command. That’s a product.

Vertical depth. A medical scribe that knows ICD-10 codes, integrates with Epic, and produces HIPAA-clean paperwork is not a wrapper, even if the transcription runs on a foundation model under the hood. The moat is the integration and the compliance, not the model.

Distribution-first plays. If you already have an audience, embedding AI into the thing they’re paying for is durable. Building a new product to seek an audience for an AI feature is brutal.

Where Tools Like Cursor Actually Fit

This framing isn’t an indictment of AI-native developer tools. It’s the opposite — it explains why Cursor, Claude Code, and Copilot work as products while most ChatGPT wrappers don’t.

A developer environment carries decades of accumulated assumptions: file trees, language servers, multi-cursor editing, debugger integration, git plumbing. Slotting an LLM into that surface area is a years-long product problem. The model is one component among many.

Compare that to “ChatGPT for sales emails.” The model is doing nearly all the work. There’s nowhere for engineering work to compound.

When you evaluate a tool for your own stack, the test is the same one you’d apply to your own product: if the underlying model swapped to a competitor tomorrow, would it still be the best thing for the job? For Cursor, yes — the agent loop, the indexing, and the editor surface all stay. For most prompt-engineering SaaS, no.

What This Means for Your Next Project

Two practical takeaways.

If you’re shipping something new, the first question to answer isn’t “what model are you using” — it’s “what would this product be without AI at all?” If the answer is “nothing”, start over. If the answer is “a useful but slower tool”, you’re probably fine.

If you’re shipping AI into an existing product, the cheap wins are usually unglamorous: search that understands intent, summarization at the right grain, automation of multi-step workflows users already do by hand. The high-status moves — “agents that run your business” — almost always ship as demos and stall in production.

The Gruber framing isn’t a prediction about what AI will do. It’s a constraint on what you should call a product. Apply it ruthlessly to your own roadmap and most of the noise of the last two years gets quiet.