Claude Code Won't Replace SaaS And Anthropic Shows Us Why

SaaS is dead, so the argument goes. Put your knowledge in GitHub, point Claude Code at it, and build a few dashboards to replace any tool.

I don’t think this is a bad argument, but it’s incomplete. Why do I think that? Because Anthropic itself isn’t stopping at Claude Code.

First they built Claude Cowork, and then they built Claude Design.

If "put it in a repo and use Claude Code" were the answer to every agentic workflow, those products wouldn't need to exist.

The Native Environment Matters

Claude Design is not "Claude for mockups." It reads your codebase and design files to build a design system every project inherits, then lets you refine through inline comments on specific elements, text edits, and adjustment sliders. None of that works natively in a repo. 

You could store design tokens in GitHub and ask Claude Code to generate React components. But you'd lose the native design environment: the canvas. The canvas provides spatial manipulation, visual iteration, and the ability to comment on an object instead of a line of code.

Claude Cowork makes the same point from another direction. It runs on your desktop, working across local files, folders, and whatever applications you have open. You give it a goal, like "prepare a summary of these contracts" or "pull together the research for this memo", and it synthesizes across sources without you coordinating each step. It operates in the messy environment where knowledge work actually happens: documents, spreadsheets, PDFs, browser tabs, and half-finished drafts.

That's different from Claude Code, where the natural objects are files and diffs and the natural actions are commits and PRs. Knowledge work doesn't come in that shape. Cowork meets it where it is.

Claude Code is powerful because programming already has an unusually good agent harness. Code lives in files. Changes are diffs. Quality is checked by tests. Collaboration happens through review. A coding agent dropped into that world can do a lot because the world was already structured for it.

Most work doesn't come pre-shaped that way. Design needed a canvas. Knowledge work needed desktop integration. Almost anything can fit in a repo, but the real question is "what's the right environment for the agent to act in?"

For code, it's the repo. For design, it's the canvas. For general knowledge work, it's the desktop.

Like for design and knowledge work, the answer for everything else is usually something other than a repo.

Go-To-Market Needs More Than A Repo

Take go-to-market (GTM). You can put GTM context in GitHub, but it is not the right environment for it. Yes, you can make files for personas, competitors, and playbooks. You can absolutely use Claude Code to edit them and expose them through MCP so you can push outputs into Salesforce, HubSpot, and Clay. That's a reasonable architecture.

But it's not a GTM operating environment.

The difference is native objects and native actions. In code, the native objects are files, functions, modules. The native actions are edit, commit, test, deploy. The harness knows what those are and what to do with them.

GTM has its own native objects: positioning, personas, competitors, segments, proof points, objections, messaging. And its own native actions: approve, deprecate, attribute, evaluate. A GTM agent needs to know what's current versus stale, what's approved versus draft, what depends on what, etc.

A repo can store all this. But a repo doesn't know it. It sees files and commits. The semantic layer consists of knowledge like "this is a competitor claim, it was approved by product marketing, it powers these three campaigns, and it needs review because the competitor shipped a new feature." If you are building a GTM operating environment from scratch, that all has to be built on top of a repo.

Most importantly, the interfaces have to match the people. Engineers want APIs and MCP, but good luck getting sales and marketing to speak that language. Sales wants context surfaced inside their workflow, not a PR to review. Marketing wants to shape positioning without touching a terminal.

That's not a criticism of repos. The agent environment for GTM is a different thing from the agent environment for code, the same way Claude Design is a different thing from Claude Code.

The Future Of SaaS

This is where I think vertical software either dies or gets much stronger.

The weak version of vertical SaaS was a thin database with a UI. That version probably does get eaten by repos and coding agents.

The strong version is a domain-specific environment where humans and agents can do the work together with native objects, native actions, native permissions, and native feedback loops. Claude Design and Claude Cowork are early evidence of this pattern. They show that once models get good enough, the interface becomes even more important than before. Not because users can't use the general tool, but because the general tool gives the agent the wrong world to act in.

That's the mistake in "just use GitHub and Claude Code." It assumes the important thing is where the knowledge is stored. But the important thing is the environment that best enables agents and humans to collaborate with one another.

When someone says "could we build this with GitHub, Claude Code, MCP, and dashboards?" I say you could. The question is: after you build the domain model, permissions, approvals, evaluations, interfaces, sync logic, and feedback loops, what have you actually built?

Usually, you've built the product you thought you were replacing.

‍