The primitive is the product

For as long as software has existed it’s been principally designed for human consumption. 

Users clicked buttons, navigated workflows, learned new interfaces. They spent years developing muscle memory for products like Excel, Photoshop, Salesforce, Github, Jira, etc. 

And so emerged a simple logic governing software economics: own more workflows, capture more value. 

In this era, features became the currency of software. Every new feature expanded the product's surface area, increased switching costs, and pulled users deeper into the platform.

AI completely subverts this logic.

The most important characteristic of the AI platform shift has less to do with the new technological foundation (e.g. the model) we’re building on, and much more to do with the new type of user (e.g. the agent) we’ve introduced. 

Agents, which are already consuming a rapidly expanding share of software, have a completely different interaction model than humans. They don’t navigate software so much as they intuit and compose it. Because the native language of the agent is code, they don’t see your GUI, but they do consume your API spec. 

More plainly, agents could care less about dashboards, buttons, settings pages, etc. They care purely about capabilities, e.g. the inputs, outputs, and explicit constraints of your program and whether those can be invoked and chained reliably. 

My friend David Crawshaw, founder of exe.dev (and before that Tailscale), put it best: “the best product for an agent is just the best product for a developer.” It's no surprise that agents become dramatically more reliable when a prompt simply begins with ssh!

Suddenly, every software company needs to start thinking like a developer tools company.

The Tao of HashiCorp

Long before LLMs, HashiCorp figured out something many software companies missed.

Users don't want features, they want outcomes. Thus, the job of a product is to collapse complexity into the smallest yet most powerful abstraction that enables those outcomes.

This philosophy became known as the Tao of HashiCorp.

HashiCorp understood that the hardest problem in software is not implementation, rather it's deciding where to draw these lines of abstraction. Where should the system be opinionated vs. where should it remain extensible? Where should complexity be hidden vs. where should it be exposed?

The magic of HashiCorp was never in building the most feature-complete products which provisioned infrastructure or managed secrets. Their genius was in deeply understanding the practitioner and their workflows and identifying the right abstraction for the job to be done. 

Take Terraform. Rather than encoding the logic for every infra management workflow into the product itself, it exposed a lower-level building block: a declarative graph of resources and their dependencies. That primitive was just opinionated enough to get developers productive immediately, yet extensible enough that thousands of providers, modules, and internal platforms emerged around it. The differentiator was in composability.

HashiCorp recognized that technology can be but an implementation detail. What mattered was finding the abstraction that cleanly captures the underlying workflow while hiding unnecessary complexity. The power was not in the product but in the primitive!

And once you get the primitive right, it becomes the building block that everyone else standardizes around. The abstraction ultimately becomes the interface, the interface becomes the ecosystem, and the ecosystem becomes your competitive advantage.

Thinking like a dev tools company: the primitive-first mindset

The philosophy outlined in the Tao of HashiCorp provides a blueprint that every software company will need to internalize in the age of agents. But doing so requires a radical departure from how most products have been designed since the very birth of the software industry.

First and foremost, teams need to stop thinking in terms of features and prescriptive workflows and start thinking in terms of abstractions and capabilities. 

Features are a liability for agents. Every feature expands the decision space an agent must reason about. More features mean more edge cases, more ambiguity, and more failure modes. At best, this translates into higher token spend, and at worst, into busted agent behavior.

Agents naturally gravitate toward the smallest stable abstraction. So, in an agent-first world, the most important question facing product teams is not what features and why, but instead how do I design the right primitive{{primitive-fn-1}}? 

Building great developer tools (e.g. primitives) has always been an exercise in exquisite taste and deep domain expertise because it requires balancing a set of competing, and often contradictory, forces: namely the tension between expressivity and simplicity.

The more opinionated the abstraction, the more delightful the experience can become. But every opinion embeds assumptions which constrain what can be built on top or changed down below. So what you gain in usability, you often lose in flexibility.

The canonical example is EC2 vs. Heroku. EC2 exposed a low-level primitive: the virtual machine. You could install anything, run anything, and compose it however you like. It's powerful precisely because it's minimally opinionated.

Heroku, by contrast, provided a complete deployment platform (on top of EC2). The developer experience is magical: git push and your application is live. Simplicity! But that elegance comes from making a series of opinionated decisions on behalf of the user. As a result, you sacrifice flexibility and control for that ease of use.

The best-designed primitives feel powerful but deceptively simple, if not outright boring. This is not because the problem itself is simple, but because complexity has been compressed into the abstraction in a thoughtful way. 

Consider S3, one of the most important infrastructure products of the last 20 years. S3 exposes an astonishingly small surface area with three core commands: Put. Get. List. Everything emerges around those operations.

The value, ultimately, isn’t in feature depth, but in the quality of abstraction. 

And so, the foundational philosophy of product development becomes flipped on its head. The old question was: "What feature should we build next?" The new question becomes: "What capability should others build upon?"

Claude vs Pi

My favorite current example of the products vs. primitives debate is Claude and Codex vs Pi.

I've fallen in love with Pi, a coding tool created by Mario Zechner that bills itself as a "minimal agent harness." At first glance, Pi appears less sophisticated than products like Claude or Codex, but that’s precisely the point.

Claude and Codex are vertically integrated products that bundle planning, execution, context management, tool calling, workflow orchestration, and the underlying model into a single unified experience. Anthropic and OpenAI seek to own the entire agentic coding workflow, soup to nuts.

Pi takes the opposite approach: it’s deliberately narrow. Pi is opinionated about execution, but leaves it to the developer (or agent) to decide the particulars of their desired workflow. Rather than shipping a complete coding product, it exposes a simple, pluggable coding agent harness…a set of primitives, if you will. 

If you’ve read this far, you already know the tradeoff inherent in this design. Vertically integrated products can move faster initially because they own the entire workflow and offer users the proverbial easy button to get started. Simplicity! 

Primitives, on the other, are slower to appreciate because they require users to be thoughtful about their workflow up front and then assemble the pieces themselves. You’re likely not getting that “magic moment” for a user within minutes of them trying the product.

But primitives possess several unique advantages that become more obvious over time…like a fine wine. 

First, they are inherently more malleable and adaptable. Claude and Codex users are tied to the opinions, workflows, and, critically, the models chosen by their creators. Pi, by contrast, can evolve with the ecosystem. As new models, tools, and workflows emerge, they can be incorporated without waiting for the platform owner to bless them.

Second, primitives compound. Every workflow built on top of Pi increases its value, as each new integration expands its ecosystem and every new use case further strengthens the abstraction.

This is a pattern we've seen repeatedly throughout the history of infrastructure. The most valuable layer is often not the application itself but the primitives the application depends on (see our earlier EC2 vs. Heroku example).

Products may come and go, but primitives become standards.

Extensibility compounds

It’s worth dwelling more on the concept of compounding extensibility and the role of the ecosystem. Many software companies struggle with this idea because it runs counter to decades of product strategy.

Historically, sharing the ecosystem was dangerous because it gave life to competitors building on your API and potentially cannibalizing features you yourself could monetize. Platforms frequently fenced themselves off once third parties became “too successful.” The incentive was always to absorb the value back into the product, and in a world where humans were the primary consumers of software, this made sense. Look no further than all of the license changes over the past decade from major OSS infra providers as evidence.

But agents fundamentally upend this equation…again!

An agent doesn't care whether functionality comes from one vendor or fifty. It only cares whether the capability exists, and whether it’s meaningfully better than alternatives.

Every third-party integration becomes another tool the agent can leverage. Every extension increases the utility of the underlying primitive. The value of having a community that works on these things, that complements the work your team is doing, can’t be understated.

All of this means the winning products and strategies going forward will look very different from those of the SaaS era. The most valuable companies will allow every use case to emerge instead of trying to solve each one themselves. 

Whereas the old moat was defined by feature breadth, workflow ownership, and data gravity, the emerging moat may be something much simpler: the elegance of the abstraction.