Jason A. Hoffman

Written by AI Staff^†

March 10, 2026

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).

---

Engineers often turn a temporary difficulty with a platform into a permanent tool. The tool works, so its creator mistakes evidence that a workaround was needed for evidence that a product should continue to exist. If the underlying platform improves faster than the workaround, maintenance eventually costs more than the tool saves.

I have watched this happen in cloud computing, JavaScript, and now AI.

Cloud Computing

I watched this happen with cloud computing.

AWS and GCP offered compute, storage, and networking as services. Customers wanted to run applications without owning the underlying hardware.

Many organizations inserted another system between their applications and the cloud:

• OpenStack: operated a private cloud with its own control plane.
• Cloud abstraction systems: normalized provider APIs to reduce dependence on one vendor.
• Internal platforms: presented developers with a company-specific interface to public-cloud services.

Each choice can be justified by regulation, portability, cost, or developer experience. Trouble begins when the organization preserves the intermediate system after its reason has expired. As cloud platforms added managed services and better controls, many teams had to migrate from an internal substitute that had fallen behind.

Avoiding an external dependency had created an internal one: a team now had to match the provider’s development pace while also building the company’s product.

Node.js

Node.js and npm supplied a runtime and package system for web applications. Developers then accumulated tools around them:

• 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

Some of this machinery solved real compatibility and deployment problems. But every dependency added an upgrade surface. Teams that kept the chain short generally had less unrelated code to maintain than teams that treated the toolchain as a product of its own.

AI

AI platforms are repeating the pattern at a faster release cadence. Several categories began as necessary responses to weak model capabilities:

• orchestration frameworks that decomposed work a model could not complete in one pass;
• context tools that assembled the files a model could not inspect itself;
• multi-agent systems that tried to recover quality through debate; and
• prompt platforms that managed behavior unavailable in the runtime.

Native tool use, larger contexts, repository agents, memory, and better reasoning have since moved some of those responsibilities into the model platforms. The outside tools remain useful only where they still provide a capability, control, or record the platform does not.

The Enterprise Reflex

Enterprises respond reasonably:

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

“We need our own layer.”

“What if Anthropic changes their API?”

Provider concentration is a real risk. The response should match the risk. A narrow interface that preserves data and tool portability can reduce switching cost. A lowest-common-denominator reasoning system can instead prevent the application from using the capability that justified the model in the first place.

An internal router, provider-neutral wrapper, or common prompt format creates its own dependency on the team that maintains it. That cost may be justified for resilience, procurement, privacy, or workload-specific model choice. It should be stated and measured rather than hidden inside a general preference for abstraction.

A small internal team cannot reproduce every provider feature. It should protect the parts that must remain portable and expose provider-specific capabilities when they materially improve the work.

The Human Bias

People often productize the difficulty they have just learned to overcome.

Someone spends a week getting codebase context into a model and concludes that the market needs a context-management product. The week’s work proves that access was difficult at that moment. It does not prove that access is the durable customer problem; the customer may need better reasoning about code, while the platform vendor is already improving repository access.

People build what they understand, and the gap they just crossed is vivid. A tool can therefore encode its builder’s former limitation instead of the user’s continuing need.

The Filter

Ask four questions before turning a workaround into a product:

1. Will a better model increase or reduce its value? Data access, deterministic computation, and domain-specific tools usually become more useful. Machinery that compensates for a reasoning or context limit may become less useful.
2. Does it encode a durable constraint? Regulation, proprietary data semantics, reproducibility, and bounded permissions will outlast a model release.
3. Who will maintain parity? Count the ongoing cost of adapting the tool to every provider change it hides.
4. Can a narrow boundary solve the problem? Preserve portable data, evaluations, and tool contracts without normalizing away useful model behavior.

What Survives

Build capabilities whose value rises with model quality: reliable data access, deterministic computation, bounded tools, evaluations, and records of human decisions.

Deterministic programs produce reproducible results. When you need an IRR, compute it. When you need to test 50,000 scenarios, run them and preserve the inputs, code version, and outputs.

Models can formulate questions, interpret results, synthesize evidence, and propose the next calculation. Their output remains probabilistic and needs support from code or sources when a claim must be verified.

Give the model access to both kinds of work. Let it invoke deterministic tools for calculation and query current, governed data for evidence. Keep the calls and results inspectable.

Add orchestration or routing only when it enforces a stated requirement, such as cost, privacy, availability, or an evaluation result. Do not make a fixed workflow a substitute for model reasoning merely because the workflow is easier to diagram.

With stable data and tool contracts, a stronger model can improve the application without forcing a rewrite of its domain capabilities. Provider changes will still require migration work, but that work remains at explicit boundaries.

Present usefulness is insufficient. The tool should increase the value of a better model instead of blocking that improvement.

The Decision

A workaround deserves continued investment when it encodes a durable constraint or capability. Otherwise, treat it as temporary, measure whether the underlying platform has caught up, and be willing to delete it. The discipline is to solve the user’s problem without turning every episode of technical friction into another product to maintain.