A two person law firm recently posted that they switched from Harvey to Claude Code, and the post promptly went viral.

Harvey is purpose-built legal AI. Well-funded, well-deployed, trained on case law. "AI-native" but largely a subscription software product.

Claude Code is entirely different. It's a terminal interface for a general-purpose model, used by programmers to start, but now increasingly by startup PMs, investors (like me), creators, e-commerce brands (I just met one this weekend), and... lawyers?

Yes, this law firm said Claude Code was better for them than Harvey.

The reason is obvious once you see it.

Harvey is frozen at what Harvey's product team thinks lawyers need. Claude Code is not frozen at anything. It's configured with each firm's specific workflows, document templates, judgment frameworks, and reasoning patterns — encoded in markdown files and slash commands. It evolves every session. The output of good work becomes the input for future work. The configuration compounds.

This is a pattern I keep observing these days: the configuration layer has become a real moat. Not the model. Not the software subscription. Not the API. The accumulated encoding of judgment, process, and domain knowledge into a form that any agent can consume.

The mechanism is simpler than it sounds.

You do good work. You apply good thinking. You notice a pattern in how you approached it — a sequence of questions, a framework you applied, a template that made the output better.

With a simple "hey that worked well, let's encode it", you encode that into a markdown file. Next session, you invoke it with a slash command. Over time, these compound: more frameworks, more templates, more patterns, more tools. Six months in (or even six weeks in), your configuration reflects how you actually think.

How you think, not how some product team assumed you'd think.

The law firm's setup reflects the reasoning patterns of their best lawyers, their specific document conventions, their jurisdictional knowledge. Harvey's product reflects Harvey's product team's assumptions. Two very different directions.

I've been building the same thing on the investment side. Screening logic, evaluation frameworks, memo templates, IC reasoning patterns, thesis-testing heuristics — all encoded in markdown, all invocable with a slash command, all improving as I refine them through actual use.

The equivalent of Harvey for investors exists (lots of them actually), and I haven't come close to buying any of them. Because a horizontal LLM (Claude Code for now) plus a malleable file system stays hyper-customized to me and has infinite capacity to evolve with me.

Second-order: this changes what it means to build good software.

If the customer is increasingly an agent — or a human working through an agent — and their goal is not to use you as a work hub, but to add you to their config, everything changes.

The product interface that matters isn't the UI. It's the API surface, the documentation quality, the GitHub presence. Slick onboarding doesn't matter if no human is doing the onboarding. The companies winning with this generation of users have excellent docs, programmatic access, and active repos. The companies that don't understand this are building for an interaction model that's already changing.

"Developer experience" now has to mean: how easily can an agent configure and use this?

The shorthand test I've started applying: can you describe the entire product in a README and a handful of API calls? If yes, it's built for the new world. If the answer requires a product tour, it probably isn't.

This has an obvious implication for where moats actually live now. It's not in the UI. A beautifully designed interface for a vertically-focused product can be replicated by a sophisticated user with Claude Code and a weekend. The durable moats are the ones that can't be replicated with markdown: proprietary data, integrations with locked supply chains (imagine if your data actually comes from a physical process like a wet lab!), regulatory compliance infrastructure, network effects that require actual users.

At individual scale, the config layer works. You build it, you own it, it compounds with you. But organizations need more.

They need shared configuration with access controls. When a firm updates its investment thesis framing, that change should propagate into every analyst's working system — not get copy-pasted into a Notion doc that nobody updates.

But you do need version control for organizational intelligence, so you know who changed a framework, when, and why. They need role-based config: different reasoning tools accessible to different people based on seniority and context.

None of the existing tools solve this. Notion stores knowledge for humans to read. GitHub stores code for machines to execute. What doesn't exist yet is the layer in between: governed, versioned, agent-consumable organizational intelligence. A system where the firm's accumulated knowledge is stored in a form agents can actually ingest, humans can actually govern, and everyone's setup is always current.

Right now, the configuration is explicit: files you can read, frameworks you can update, tools you can invoke. The model is general; your configuration shapes how it responds. There's actually very questionable moat at the model layer, because you can switch to a new model that can read your local files, and it's good to go.

I think companies like Harvey will be fine. Not everyone will want to deal with the organically evolving chaos that is human-agent collaboratively defined files and frameworks. It's glorious but a mess to manage. Many will prefer the structure of vertical software.