Bitter Pilled SaaS: What the Bitter Rain Grows

There’s a deluge of articles right now about AI eating SaaS. It turns out Sutton’s Bitter Lesson isn’t just about building models. It’s about building with them too. And his lesson is coming down like bitter rain across the entire industry.

Basically, the Bitter Lesson says that general methods that scale with compute will beat out handcrafted cleverness over time. And this isn’t an analogy for what’s happening to SaaS — it’s the same mechanism. A hand-built dashboard is handcrafted cleverness running on almost no compute — a few SQL queries, a couple milliseconds of CPU. The model handling the same problem is a general method running on orders of magnitude more compute. Same lesson, applied to the messiness of the real world.

Anything built to patch the AI’s current weaknesses has a half-life, because providers eat those layers and ship them as defaults. And it’s not just product scaffolding. Distribution dissolves too. Users staying in ChatGPT or Claude instead of visiting the app? Same rain, different surface.

There’s no shortage of writing about what’s washing away. This piece is about planting what grows — and the argument is simple: build generalist SaaS patterns that scale with compute, the same way the models themselves do.

The models will eat your interfaces.

Your job is to make it as tasty as possible. Flavor so rich that every frontier model wants seconds.

The front door moved. The work didn’t change.

So what’s durable? The stuff that uses the bitterness as a tailwind. Claude Code is the clearest example of bitter-pill software strategy. It dissolved the IDE and exploded — not by being smarter than developers, but by cracking the one collaboration surface that mattered: a diff you can read, accept, or reject. The rain did the rest. But code had an unfair advantage. Text is a universal format, and fifty years of version control culture handed it that surface for free.

Most SaaS doesn’t get that for free. The work is heterogeneous — every action has a different shape, touches different systems, and carries different consequences if it goes wrong.

There is no universal diff. (If there were, we’d just show people JSON and call it a day.) Traditionally, we solved this by building bespoke UIs and workflows for every domain. But bespoke UIs are exactly the handcrafted cleverness the Bitter Lesson dissolves. They’re not compatible with a world where users do their work through a generalist front door. So the platform has to build a generative UI layer — collaboration surfaces scoped like bespoke workflows, but generated on the fly.

And right now, most of what passes for AI in SaaS is just paragraphs. A confident summary. Then the user reconstructs what it did, argues about what it meant, and translates it back into action. Most of the time people spend with AI copilots today is just translating paragraphs back into work. A paragraph is a bad collaboration object. A generative collaboration surface is a good one.

A workspace scoped to the problem at hand, with only the actions that make sense. Not a smarter dashboard. You and AI point at the same thing, change the same parameters, converge without forensics. You can’t accidentally blow up something outside the scope. Trust isn’t a vibe here — it’s a byproduct of the design. People can see what’s happening, and the system can’t go rogue. That’s what the diff does for code. That’s what generative collaboration surfaces do for everything else.

Will these surfaces get consumed too? Probably. The front doors will eventually generate their own on top of your tool layer. But you still need your own reference implementation. Without it, you’re blind. You just see raw tool calls hitting your API — you never see how users and the AI are actually collaborating. Your own surfaces are the learning flywheel. They’re how you see what’s working, what’s failing, and what to build next.

And building them is a forcing function for getting the bedrock right. If you have to generate a bounded workspace on the fly, you can’t fake your domain logic, your permission model, or your execution layer. The requirement to generate exposes every shortcoming in your platform. Fixing those shortcomings is the actual investment. Good soil has high water-holding capacity — the same rain that washes away thin scaffolding gets absorbed and creates fertile ground. That’s what you’re building. The ecosystem is already converging on this — Tambo, MCP Apps, Vercel’s AI SDK all point the same direction: tools are callable, interfaces are composable.

And once tools are callable and interfaces are composable, the old playbook flips. We’ve all been potty trained by Ben Thompson to hoard the UX. And in the old world, that was exactly right. But misinterpreting that lesson in this climate is a death sentence. Clinging to your interface is exactly how you drown. The platform that tries to keep users inside its own walls becomes the thing people route around.

Thompson is still right. You just have to reinterpret what “owning the UX” means. A generative collaboration surface that shows up inside Claude or ChatGPT is still your interface. Still your experience, your trust surface, your collaboration design. It just teleports. Owning the UX now means making it portable enough to show up at any front door. Your platform doesn’t need to own the screen anymore. It needs to be worth calling from any screen.

The rain is guaranteed. It will keep washing things away. But it will also keep feeding everything that’s rooted in the right place.