Jason A. Hoffman

Part 10 in the series. Previously: Computational Strategy (Part 9), Model Eats Software (Part 8), On Keeping AI in the Critical Path (Part 7), The Confident Incompetence Problem (Part 6), The Disintermediation Principle (Part 5), Zen of Unix Tools (Part 4).

The Home Is Where The Heart Is

A home is where you have a life with the people you love. It’s where you rest and think. Where you create memories. A home takes effort to get right — and the effort isn’t construction. It’s honesty about what matters, about what you’re avoiding, about whether the thing you’re working on is the thing that actually needs work.

One’s own thinking and principles and tendencies are what get in the way of having a great home. Not the floor plan. Not the fixtures.

You want to build a home. But then you start building a house, which isn’t a home. And then you decide what the world needs is a new hammer — because your hammer broke.

Each step is locally rational and globally wrong. The hammer feels productive. The house feels like progress. But the home requires you to stop building and start living.

Act I: The Cloud

I watched this happen with cloud computing.

AWS and GCP offered the primitive: compute, storage, networking. Direct access, pay for what you use, scale on demand. The home — the thing everyone actually wanted — was to run their applications without managing infrastructure.

Instead, an entire industry formed around not using the cloud directly:

• OpenStack — “We’ll build our own cloud.” It gave you a job managing OpenStack.
• Cloud abstraction layers — “We can’t depend on just one provider.” API aggregators that normalized away the capabilities that made each cloud valuable.
• Internal platform teams — “We need to make cloud easier for our developers.” Another team, another layer, another thing to maintain.

Every one of these was a house. A real structure that solved a real problem at a specific moment. And every one of them got absorbed or abandoned as the cloud platforms matured. The people who built on the primitives directly kept going. The people who built intermediation layers had to migrate.

The instinct was always the same: “We can’t just depend on this external thing.” But the external thing was improving exponentially. The internal layer was improving linearly, maintained by a team that could have been building the actual product.

Act II: Node.js

The same pattern, faster.

Node.js and npm gave you a runtime and a package ecosystem. The home — the thing everyone wanted — was to build web applications.

Instead, people got clever:

• Build tool chains that required their own build tools
• Package wrappers around package wrappers
• Framework abstractions that abstracted away the framework below
• Module systems to manage module systems

Everyone started tooling around the core abstraction instead of using it and moving forward. The JavaScript ecosystem became famous for this — left-pad, the node_modules black hole, Webpack configs that needed their own consultants. The house grew rooms that nobody lived in.

The people who built close to the runtime — who used the primitives, kept dependencies thin, and focused on their application — shipped faster and maintained less. The people who built elaborate tooling spent their time maintaining elaborate tooling.

Act III: AI

Now I’m watching it happen again. Same pattern, highest stakes.

Anthropic releases a model. Google releases a model. OpenAI releases a model. Each release puts startups out of business and drops SaaS valuations. The intermediation layers keep getting absorbed:

• LangChain — “You need an orchestration framework to use LLMs.” Then the models got good enough to reason in one pass, and the chain became overhead.
• Context management tools — “You need to assemble codebase context for the model.” Then Claude Code read the repo directly, and CLAUDE.md gave it institutional memory.
• Multi-agent debate systems — “You need multiple models arguing to get good answers.” Then one frontier model with the right data outperformed the whole ensemble.
• Prompt management platforms — “You need to version and template your prompts.” Then the conversation became the prompt, and the management layer had nothing to manage.

Every one of these solved a real problem at a specific moment. Every one of them is a hammer. And in a landscape where the underlying models are improving exponentially, the moment passes fast.

The Enterprise Reflex

Then we get inside the enterprise and hear the familiar words:

“We can’t just depend on one provider.”

“We need our own layer.”

“What if Anthropic changes their API?”

This is applying linear thinking to exponential change. The model you’re abstracting away from today will be unrecognizably better in twelve months. The abstraction layer you build to protect yourself from change is the thing that prevents you from benefiting from the change.

The same companies that said “we can’t just depend on AWS” in 2012 and built internal clouds spent years maintaining infrastructure that got worse relative to the thing they were protecting against. The same instinct now produces AI abstraction layers, internal model routers, provider-agnostic wrappers — all of which exist to avoid a dependency and all of which create a bigger one: a dependency on your own team’s ability to keep pace with frontier research labs.

You can’t outrun Anthropic’s research team with an abstraction layer. You can’t outrun Google DeepMind with a routing table. The exponential is not something to hedge against. It’s something to ride.

The Human Bias

The default thing people propose as they work through increasing their own knowledge is usually around their own tooling and understanding gaps. This is a human bias, not a technical one.

Someone spends a week figuring out how to get codebase context into an LLM. They succeed. Their immediate instinct: “I should build a context management tool.” They’ve confused the learning curve with the problem. The problem wasn’t context management — it was reasoning about code. The context difficulty was a symptom of immature tooling, and immature tooling is temporary by definition.

People build what they understand. And what they understand first is the gap they just crossed. The tool encodes the builder’s limitation at the time of building, not the actual problem.

The person building the hammer isn’t delusional — their hammer really did break. But they’ve lost the plot. They’re three layers removed from the home they wanted. And building the hammer feels productive, which is the most dangerous part. The house gets better. The home doesn’t.

The Filter

One question cuts through:

If the model gets 10x better, is this still needed?

Things that survive 10x models:

• Data infrastructure — better models use better data better. APIs, feeds, databases, claims systems. A 10x model with 10x data is 100x.
• Compute primitives — Monte Carlo simulation, optimization solvers, physics engines. The math doesn’t change. numpy doesn’t need a second opinion.
• Tool access — MCP servers, function calling, API integrations. A 10x model with 10x tools does 10x more.
• Human judgment — which questions to ask, which assumptions to challenge, which direction matters. This is the home.

Things that don’t survive:

• Orchestration frameworks — the model handles the chain
• Context management — the model reads the repo
• Multi-agent debate — one model thinks harder
• Prompt management — the conversation is the prompt
• Consensus algorithms — the model reasons directly

Every item in the second list is a hammer. A real hammer that solved a real problem at a specific moment in tooling maturity. But the moment passes.

What Survives

So what do you build?

The things that get better when the model gets better. Not the things that get in the way.

The division is simple: deterministic computation and probabilistic reasoning. They’re complementary. The pipe between them is where the work happens.

Deterministic computation gives you answers that are verifiable, not probable. Simulation, solvers, financial algebra — numpy doesn’t hallucinate. When you need an IRR, you compute it. When you need to test 50,000 scenarios, you run them. The math proves itself.

Probabilistic reasoning gives you interpretation, formulation, synthesis — what the numbers mean, what to model next, what a human would miss because the corpus is too large to hold in one head. This is what frontier models do. This is where they improve every few months.

Give the model tools to do both. Let it call the deterministic side when it needs proof and the probabilistic side when it needs judgment. Let it access live data — not a static document assembled last Tuesday, but the actual state of the world, queryable in real time.

Then stay out of the critical path. No orchestration layer deciding what the model should think about. No routing logic choosing which model gets which question. No consensus algorithm averaging out the intelligence of the best model in the room.

When new models drop, everything built this way gets better automatically. The model reasons over the same data, the same tools, the same compute — but with more capability. No migration. No abstraction layer to update. No hammer to replace.

The question isn’t “is this tool useful today.” The question is “is this tool on the side of the model, or in the way of the model.”

The Home

The home was never the house.

A home takes effort — but the effort isn’t technical. It’s the effort of being honest about what matters and having the discipline not to get distracted by the work that feels productive but isn’t the work.

The same person who builds meta-tooling instead of solving their actual problem is running the same pattern as the person who renovates the kitchen instead of being present at dinner. The house gets better. The home doesn’t.

Build what survives. Skip the hammer. Build a home.