Before Unix, professional operating systems were imposing edifices. They were built by systems programmers for end users who were expected to operate the machine without understanding it. The interfaces were opaque, the internals were hidden behind layers of abstraction, and the design philosophy was fundamentally paternalistic: the user should not need to see how the sausage is made. These systems worked, after a fashion. They ran payroll, they processed transactions, they did what they were told. But they did not compound. Each new capability had to be hand-built by the priesthood that maintained the system, because the system offered no way for its users to extend it on their own terms.
Unix changed this by collapsing the distance between builder and user to zero. Thompson and Ritchie were not building an operating system for someone else. They were building it for themselves, and they were building it with itself. The C compiler ran on Unix. The text processing tools were used to write the documentation for the text processing tools. The shell was both the user interface and the scripting language. This self-referential quality was not an accident or an aesthetic choice — it was the core architectural insight. When the people who build the system are also the people who use the system, tool usability and design goals converge automatically. You do not need a product manager to tell you that grep should be composable with sort, because you felt the pain of it not being composable yesterday afternoon.
The result was not just a good operating system. It was a generative one. Unix did not anticipate every use case. It did not need to. The primitives were honest and combinable, so an ecosystem of unforeseen capabilities emerged from the interactions between simple tools. Nobody at Bell Labs designed the precise pipeline that would, decades later, power a deployment script at a startup they never heard of. They just made cat and pipe and awk work reliably, and the combinatorial explosion took care of itself.
The AI Development Gap
I keep returning to this history because we are at a similar inflection point with AI-assisted development, and we are in danger of repeating the pre-Unix mistake. As I explored in Code Architecture in the Age of AI, most engineers today operate in a split world — collaborating with models in tight feedback loops during development, only to sever that loop entirely when shipping to production. The model never sees the deployment failures, never learns from the error logs.
The Unix lesson says: bring the development experience into production. The people building AI-native platforms should be using those platforms to build them — the same self-referential trick that made Unix compound.
The Laziness Counter-Argument
There is an obvious objection, and it deserves to be taken seriously: most users do not want to be in the loop. The entire history of successful consumer products is a history of removing user involvement. People want a button that says "do the thing," not a composable toolkit that requires them to understand what the thing is. Minimizing user involvement and black-boxing the implementation is not laziness — it is good product design. It respects the fact that attention is scarce and most people have better things to do than supervise their tools.
This is correct, but it is correct for the wrong audience. There are at least two distinct modes of interaction with an AI-native platform. The first is consumption: a user wants a result and does not care how it is achieved. The second is construction: a developer or power user wants to build workflows, customize behavior, extend the platform's capabilities to fit their specific problem. The black-box approach serves consumption well. But construction requires transparency. It requires the kind of tight feedback loop that Unix provided and that pre-Unix systems deliberately prevented. The question is not which mode is better — it is whether a platform can serve both, and whether the construction mode can be first-class rather than an afterthought.
Four Kinds of Value
When you look at what an AI-native CLI platform actually provides to the builder, it breaks down into four distinct categories of value. The first is aggregated access to third-party capabilities — model APIs, media generation services, specialized AI providers — purchased in bulk and offered through a unified interface. This is a procurement function. It saves every individual builder from negotiating their own API contracts and managing their own rate limits. The second is handcrafted applications that speak two languages: a human-readable interface for direct use, and a machine-readable interface — tool calls, structured intermediate representations — that models can invoke programmatically. This dual-interface design is the critical architectural investment. It is what makes the platform usable by both humans and the models that work alongside them.
The third is account integrations: authenticated access to a user's external services, so that agents operating on the platform can read from and write to the user's actual data — their repositories, their cloud storage, their project management tools — without the user having to manually shuttle data back and forth. The fourth is platform capabilities that individual builders would otherwise have to provision themselves: payment processing, persistent storage, collaboration and sharing infrastructure. These four layers together constitute a toolkit designed for models to use, where power users customize their own workflows by composing primitives rather than filing feature requests.
The question is not whether to build tools or to build products. It is whether your tools are designed so that an LLM can compose them into products on behalf of the user.
The Value Capture Problem
There is a strategic tension buried in this design philosophy that is worth being honest about. A platform that wraps other services — that provides the integration layer between a user's models, data, and tools — captures value differently than a platform that is itself wrapped by others. If your AI-native CLI is the outermost layer, the one that orchestrates everything else, you are in a strong position: you control the user relationship, you see the full workflow, you can optimize across the entire stack. But if your tools are consumed as low-level primitives inside someone else's orchestration layer, you become a commodity. A pipeline component. Interchangeable.
The instinct, then, is to build higher up the stack — to offer complete solutions rather than composable parts. But this contradicts the Unix lesson. The power of grep is precisely that it does one thing and does it well, and anyone can put it in any pipeline. If grep had been designed as a "complete document search solution" with its own UI and workflow opinions, it would have been useful to fewer people and replaced sooner. The resolution, I think, is that integration overhead is real and durable. Even in a world where individual tools are commoditized, the work of making them interoperate — handling authentication across services, maintaining consistent state, providing a unified experience — is genuinely valuable.
The deeper point is this: the Unix philosophy worked not because simplicity is inherently virtuous, but because the builders and the users were the same people. The feedback loop between "this tool is hard to use" and "let me fix this tool" was immediate and unmediated. We have an opportunity to recreate that loop in AI-native development — not just between human developers and their tools, but between models and the platforms they operate within. A model that uses a CLI tool and encounters a confusing error message is, in a meaningful sense, a user providing feedback. A platform that captures that feedback and uses it to improve the tool's interface is closing the same loop that made Unix great.
The lazy path is to hide everything behind a black box and hope the model figures it out. The Unix path is to make the tools transparent, composable, and honest — and to trust that capable users, whether human or artificial, will build things you never imagined. I know which bet I am making.