The LLM Isn't the Car. It's the Engine.

The Lotus Elise was one of the most celebrated driver’s cars ever made. The engine inside was a Toyota 2ZZ-GE. Same one they put in a Corolla.

The VW EA888 2.0 turbo sits in both a $35,000 Golf GTI and a $55,000 Audi A5. One’s a hot hatch you take to Bunnings. The other’s a luxury coupe you valet park.

Any car enthusiast knows this. The engine matters, but it’s not what makes the car. The chassis, the suspension, the weight distribution, the way everything comes together around that engine… that’s what creates the experience.

LLMs are the engine. And more and more you’ll swap and upgrade them the way you swap a part. The thing you use every day, the thing that knows how to do the work, your preferences, your context. that stays. Maybe the LLM is Claude today and something else tomorrow. You won’t care. You probably won’t even notice.

Same engine. Completely different car.

Take the best Claude model available. Point it at a codebase. Ask it to build an app.

It’ll try. Generate code. Some of it pretty good. Then it’ll lose track, forget the file structure, contradict itself three messages in, and produce something that doesn’t work. Not because the model is dumb. Because there’s no system telling it how to think through the problem.

Now use that same model with Claude Code.

Same brain. Completely different result. It plans. Checks its own work. Builds files in the right order. Runs tests and responds to failures.

The model didn’t get smarter. The orchestration did.

The competitive advantage shifts to whoever builds the best orchestration.

Where the advantage moves

Good orchestration isn’t generic. It’s built from deep knowledge of the problem space.

Claude Code works because it was built by developers who write code every day. They knew what good looks like. They knew the order to build things. They knew when to run tests, when to check context, when to stop and rethink. They didn’t just wrap an LLM in a loop. They encoded years of judgment about how software actually gets built.

That’s the pattern that will repeat across every vertical. The best legal AI won’t come from a team that’s great at orchestration but knows nothing about law. It’ll come from lawyers who understand how cases are actually built, what matters in discovery, and where junior associates waste time. The best medical AI won’t come from a generic agent framework. It’ll come from clinicians who know the workflow, the edge cases, and the places where mistakes happen.

Domain knowledge is what makes the orchestration effective.

What this means if you’re building

If your product is “we’ve figured out how to make an LLM reliably do X for Y industry, with the orchestration, error handling, and feedback loops to make it actually work”… that’s defensible. You’re selling everything the model can’t do on its own.

As models get better, the harness matters more, not less. More capability means more ways things can go wrong. More intelligence needs more sophisticated orchestration to point it in the right direction.