Old Patterns, Fresh Arguments, and Building Products
Fifteen months from founding to GA. That pace is only possible because the underlying technology is moving so fast. Which raises a harder question: when everything around you is changing this quickly, how do you decide what to build?
As a product manager, I think about that more than I think about the Roman Empire. Shocking, I know. This is what I want to cover over the coming weeks. But before I get to how we think about it at Aria, I want to start with a story about what happens when a new technology arrives, and everyone gets the adoption wrong.
In the 1870s and 1880s, electric engines became commercially viable. In the 1920s, factories started replacing steam engines with electric motors. The first thing they did was take the electric motor and bolt it exactly where the steam engine had been: in the basement or on the factory floor, connected to the same system of shafts and belts that distributed power. The result? Almost no productivity gain. For thirty years.
It took a generation for the industry to realize you could place power where it was most efficient for the work, not where belts and pipes from the steam design could reach. Once they redesigned factories to use distributed power, with an individual motor at each workstation, productivity tripled. The technology had been available for decades. The architecture was the bottleneck.
When I look at what’s happening in AI infrastructure, it’s hard not to see the market repeating the 1920s mistake. Vendors are taking large language models and bolting them onto network management systems designed for the cloud era. Same architecture, same data processing, same dashboards. Just with a chat window on top. It’s the electric motor in the basement all over again.
So if the right move is to rebuild, not retrofit, how does a product team decide what to build? Three thinkers have shaped how I approach it.
Two filters and a thesis
Richard Sutton’s “The Bitter Lesson” is a 2019 essay that every AI infrastructure builder should read. His argument, drawn from decades of AI research: general methods that scale with computation always win. Hand-coded domain knowledge, no matter how clever, gets overtaken by models that learn from data. He traces this through chess, Go, speech recognition, and computer vision. The essay has been widely discussed in the AI community, particularly as self-driving and large-scale model training seemed to validate Sutton’s core claim in practice.
For anyone building products in the AI era, Sutton gives you a filter. If what you’re building is a set of hand-written rules that a sufficiently capable model could learn on its own, you’re on the wrong side of history. The model will get there. It’s a matter of when, not if.
Jason Hoffman’s “The Hammer Problem” adds a second filter. Hoffman observes that builders keep pausing the actual work (building the home) to build tooling and abstraction layers for infrastructure that hasn’t matured yet (building the hammer). He traces this pattern through cloud computing, Node.js, and now AI. His test is simple in concept: if the model gets 10x better next year, is this layer still necessary? If not, you’re building a hammer.
These two filters are useful because they’re negative, informing you what you don’t want to build. Don’t encode heuristics that models will learn. Don’t build intermediation layers that will be absorbed by improving infrastructure.
But negative filters aren’t enough. You also need to know where value actually accumulates.
Evan Armstrong’s “Context is King” provides the positive thesis. Armstrong argues that as AI reasoning commoditizes, the institutional knowledge that tells agents what to do, in what order, and whether they’re allowed to do it, becomes where the margin goes. His thesis is that when one layer commoditizes, the adjacent layer captures the margin.
The reasoning layer is commoditizing quickly, with the major AI labs and a growing set of open models converging on similar capability frontiers as the cost per token drops. The context layer, the accumulated operational knowledge that makes a general model useful for a specific job, is what’s left to own.
The tension and the balance
On the surface, Hoffman and Armstrong appear to contradict each other. Hoffman warns against building thick intermediation layers for immature infrastructure. Armstrong says the context layer is the durable asset, and you should invest heavily in building it.
The question that resolves the tension is: Does the layer you’re building become more valuable as models improve, or does it get absorbed by them?
If your context is a set of rules that encode what a model hasn’t learned yet, Hoffman is right. That’s a hammer. The model will absorb it.
If your context is operational knowledge that compounds through execution, knowledge that comes from actually doing the work and recording what happened, then Armstrong is right. Better models don’t replace that knowledge. They make it more valuable because a smarter model with better context produces better outcomes than a smarter model with no context at all.
This is the filter we apply at Aria every time we evaluate what to build next. Does this compound? Does a better model make this more valuable? Or are we building something that next year’s model makes unnecessary?
This is the second in a series of posts about building products for the AI infrastructure era.
