This deep dive expands on the Loop Asia conversation with Uli Hitzel, AI educator and former Microsoft/Axway/Dyson engineer.
Every engineering leader I talk to eventually asks the same question: which AI coding assistant should we standardize on? Copilot, Cursor, Tabnine, Google Code Assist, Claude — pick one, roll it out, done. Uli Hitzel rejects the framing entirely. I think he's right — most enterprise tool-selection processes are solving the wrong problem.
Here's the tell. By the time a typical enterprise finishes proper vendor due diligence for an AI tool — privacy review, procurement, security sign-off, pilot, rollout plan — "that tool may not exist anymore," Hitzel told me. "It may not be in the same shape anymore." AI tooling moves on a cycle measured in months; enterprise procurement is built for eighteen to thirty-six. Plan for a three-year platform and the one you picked will be a different product in six months, possibly an also-ran in eighteen.
Decouple the editor from the model
Hitzel's fix is worth treating as an architecture decision, not a developer-happiness concession. Developers, in his words, are "very opinionated people" — he still codes in VI, others live in Visual Studio, Eclipse, PyCharm, or an IDE nobody outside their team has heard of. Fighting it is a losing battle with no technical upside — most coding assistants integrate into the editor as a plugin. The editor is just the interface. What needs governing is underneath it: the model.
That turns "which tool do we standardize on" into two tractable questions: which model, under what data-handling terms — and how do we surface it inside whatever editor a team already uses, rather than forcing a switch. The model doesn't have to be cloud-hosted; a privately hosted model behind the same plugin interface is what actually satisfies a CISO, not the choice of IDE.
The governance surface nobody puts in the RFP
Style guide conformance is the concern every team leader names first, and it's the least of it. Hitzel's list runs deeper: data governance over what leaves the building, IP exposure — "somebody says the code that you produce is actually part of my GitHub repository that you shouldn't have been using" — and due diligence redone continuously, not once at signing.
For a CTO, that's the actual brief: not which assistant has the best autocomplete, but what the standing process is for evaluating model provenance and data handling on a cadence that matches the market, and where private hosting becomes non-negotiable.
Standardizing on an AI coding tool that might not exist in its current form in six months?
Building a standing evaluation practice instead of a one-time recommendation that expires the moment the market moves is exactly the gap I close.