You should probably buy the model.
You should probably build the system around it.
That is the make-versus-buy decision most AI strategy conversations still miss, because the conversations are usually framed as if "buy the tool" and "have an AI strategy" are the same thing. They are not. The tool decision is roughly settled in any organization that is paying attention. The strategy decision — what to build around the tools the team is already using — is where the differentiation lives, and it is the decision most boards have not yet been asked to make explicitly.
Models will continue to improve. Vendors will continue to add features. The competitive landscape at the model layer is moving fast, and the half-life of any specific advantage is short. Whatever model is best this quarter is unlikely to be best two quarters from now, and the version of the model that ships with whatever vendor's IDE is essentially the same version that ships with every other vendor's IDE, because the underlying capability is being commoditized at the foundation-model layer.
None of that is where durable advantage lives. The differentiation that survives multiple model generations is not at the model layer. It is at the layer above the model — the layer that takes the model's probabilistic capability and turns it into a deterministic component of the organization's engineering operation. That layer is the harness, and the harness is what every organization must decide whether to build for itself or attempt to buy off the shelf.
Buy: the utilities
The category of AI capability that should be bought is the category that is genuinely commoditized, where the buying organization gains nothing by reinventing it. Foundation models are the clearest example. Building a competitive foundation model from scratch requires capital, talent, and infrastructure that no organization outside the small handful of model labs can plausibly assemble, and even if it could, the result would not differentiate the buying organization from any other organization that licenses a comparable model. The model is a utility, like compute or storage. It is bought.
Code completion tools fall in the same category. The IDE integrations, the inline suggestions, the chat sidebars that vendors ship are commodity capabilities that every engineering organization is going to use. The differentiation between the leading vendors is real but small, and it is not the kind of differentiation that produces durable competitive advantage for the buying organization. Pick the tool that fits the team's IDE preferences, the security posture, and the budget. Move on.
Standard integrations are similarly bought. The connectors between AI tools and standard infrastructure — git providers, ticket systems, CI pipelines, knowledge bases — are commodity middleware. Building these in-house is rarely worth the cost, because the integrations themselves do not produce competitive advantage and the maintenance burden is real.
The buy decision for these categories is straightforward. The capability is commoditized, the differentiation is small, the build cost is high, and the strategic value of building is low. Buy them. Standardize on them. Move the team's energy to the layer where the work matters.
Build: the harness
The category of AI capability that has to be built — that cannot be bought, no matter how generous the budget — is the harness layer. This is where the make-versus-buy decision is the most important and the most often ignored.
The harness is the engineered substrate around the model. Specifications written in the structured form the organization has standardized on. Validation pipelines that gate output against the organization's actual quality bar. Context assembly that retrieves from the organization's actual corpus, organized in the way the organization has chosen to organize it. Tool registries that scope each agent to the operations the organization has decided are appropriate for the agent's role. Enforceable workflows that codify the engineering process the organization wants to run, with the gates and the handoffs and the failure modes the organization has decided to handle.
None of this is generic. All of it is specific to the organization that operates it. A vendor cannot build the right harness for an organization without first knowing the organization's specifications, validation standards, codebase conventions, knowledge corpus, security posture, audit requirements, and engineering process. The vendor does not know any of those things. The organization that operates the harness knows all of them, and the harness is the artifact in which that knowledge is encoded into running infrastructure.
The components inside the harness — workflow engines, message buses, retrieval libraries, validation frameworks — can be bought. The components are commodity. The harness, which is the integration of those components into a system tuned to the organization's actual engineering operation, is the build. The components are the bricks. The harness is the building. Bricks are bought. Buildings are constructed.
This is why the harness is the durable advantage. A competitor can buy the same models, the same IDE plugins, the same workflow engines, the same retrieval libraries, the same model context protocols. What the competitor cannot buy is the harness that the leading organization has constructed by integrating those components against the leading organization's specs, conventions, corpus, and process. The integration is the work. The work is the asset.
The engine and the car
The metaphor that captures the make-versus-buy decision most cleanly is engine versus car. The model is the engine. The harness is the car. You buy engines from manufacturers who are specialized in producing engines. You do not buy your car as a finished vehicle that happens to have an engine in it, because the car is everything around the engine — the chassis, the transmission, the controls, the safety systems, the body — that turns the engine's raw capability into something a driver can operate at production scale on actual roads.
Carmakers buy engines. They build the car. The car is what the customer experiences. The car is what produces the brand. The car is what the manufacturer is competing on. The engine is critical and the engine has to be good, but the engine is not the differentiation, because every serious carmaker has access to comparably good engines.
AI engineering is the same shape. Foundation models are the engines, and they are all comparably good at the level required for engineering work. The car — the harness, the operating model, the engineering process the harness enforces — is what the engineering organization is competing on. The organizations that have built good cars are operating at a different level than the organizations that bought engines and are trying to drive them on the road without a body around them.
You can buy engines. You do not buy your operating model off the shelf. The reason this metaphor lands harder than the abstract version is that nobody would seriously propose buying a finished car from a third party that did not know which roads the customer drove on, what the customer carried, what the customer's safety priorities were, or what the regulator in the customer's jurisdiction required. A finished car bought without that context would be wrong in dozens of small ways that would matter every day. The harness is the same. Bought from a vendor that does not know the organization's actual context, it would be wrong in ways the organization would discover slowly and painfully, with no easy remediation because the assumptions are baked in.
What "buy only" produces
The organizations that have settled for buying the tools without building the harness end up with a recognizable failure pattern. The pattern has three properties.
The first is high tool spend with diffuse leverage. The organization licenses the AI tools, deploys them across teams, tracks the usage metrics the vendors expose, and reports those metrics as evidence of AI adoption. The spend is real and visible. The leverage the spend produces is variable and not measurable in terms the strategy team can defend, because the leverage depends entirely on whether each engineer happens to be using the tools in a structured way. Some are. Most are not. The aggregate output looks like activity, not effectiveness.
The second property is engineers editing AI output by hand to make it ship. This is the rework loop the harness was supposed to eliminate. The AI produces almost-correct output. The engineer fixes it. The ticket closes. The velocity dashboard reports completion. The hidden cost — engineering hours spent finishing AI's first drafts — does not appear on the dashboard, because no metric is capturing it. The team's effective AI leverage is the difference between what the AI produced and what the engineer had to do, and that difference is not what the vendor's adoption metrics measure.
The third property is the absence of durable advantage. The organization's competitors have access to the same tools, with the same usage metrics, and the same rework cycle. Whatever the organization's engineers are doing on top of the tools is informal, undocumented, and dependent on the specific people who happen to be doing it. There is no asset that survives the engineer leaving the team. There is no compounding capability that the next quarter's investment builds on. The organization is paying tool licenses indefinitely without building anything that competitors cannot equally pay for.
This is what "buy only" looks like when the harness layer is missing. The pattern is consistent across organizations that have made this choice — by default, without examining it explicitly — and the pattern is the reason most AI initiatives plateau in the first year and never produce the strategic return the original investment was supposed to deliver.
What "build the harness" produces
The organizations that have built the harness layer report a different pattern, and the pattern compounds in ways the buy-only pattern does not.
The first property is that the same tools produce dramatically different leverage. The model the organization licenses is the same model the competitor licenses. The IDE integration is the same. The vendor metrics look comparable. What is different is what happens when the engineer hands work to the AI. In the harness organization, the AI receives a structured specification, operates inside a scoped tool registry, produces output that flows through validation gates, and either ships or returns to the spec. The engineer's role is direction and review, not rewriting. The leverage is real and measurable in the metrics that describe effectiveness rather than activity.
The second property is that organizational capability accumulates. The harness gets better month over month, because the team is tuning it against real failure modes. The specifications get tighter, the validation gates get sharper, the conventions in the corpus get more current, the failure handling gets more graceful. Each improvement is durable. Each improvement compounds with the next. A year of harness work produces a system that is materially better than the system the team had at the start of the year, and the work is encoded in artifacts that survive any specific engineer's tenure.
The third property is durable competitive advantage. The competitor cannot buy the harness, because the harness is specific to the organization that operates it. The competitor cannot copy the harness quickly, because the harness encodes years of decisions about specifications, conventions, gates, and processes that were made deliberately. The competitor that wants to catch up has to do the work, in the same sequence, on the same kind of timeline. The lead the harness organization has built is real and not closeable through capital alone.
This is what "build the harness" produces. The same models, the same vendors, the same commodity components, integrated into a system the organization owns, tuned against the organization's actual work, accumulating capability that the organization keeps.
The leadership consequence
The make-versus-buy decision is a leadership decision, not an engineering decision. The engineering organization can build the harness, but it cannot decide whether the harness is worth building. The decision lives at the level of strategic capital allocation, and the decision has to be made explicitly, with full understanding of what is being chosen.
If the choice is to buy only, the organization is choosing to operate AI at the same effective level as every competitor that licenses the same tools. The strategy is procurement. The differentiation is whatever marginal advantage the organization can produce through clever individual use of commodity tools, which is exactly the kind of advantage that does not compound and does not survive personnel changes.
If the choice is to build the harness, the organization is committing to a multi-quarter investment in infrastructure that does not produce visible product features but does produce durable engineering capability. The architect-CEO function — the role that owns the harness, defines the validation gates, curates the corpus, and shapes the engineering process the harness enforces — has to be staffed and chartered. The investment has to be defended against the recurring pressure to redirect the budget toward whatever vendor demo just landed. The pace has to be sustained even when the visible output looks slower than the buy-only competitors are reporting.
If your AI strategy is vendor-led, your differentiation is already gone. You are buying the same capabilities as everyone else and hoping your people use them better. That is not strategy. That is procurement, dressed up in strategy language, with vendor metrics standing in for outcomes.
The strategy question is not "which AI tool should we buy?" It is "what are we building that our competitors cannot?" If the answer is nothing — because the AI work in the organization is entirely tool-shaped and entirely vendor-mediated — the answer to the strategy question is that the organization does not have an AI strategy. It has an AI procurement program. The two are different. The board should know which one it is funding.
The diagnostic question
Look at the AI investment going out the door this year. Categorize each line by build versus buy. Tool licenses, model API costs, IDE plugins, vendor seats — buy. Engineering hours spent on harness construction, specification standards, validation pipelines, context assembly, tool registry design, knowledge corpus curation — build.
If the buy column is large and the build column is small or zero, the organization is operating in procurement mode. The differentiation that AI investment is supposed to produce is not being constructed, because nothing the organization is uniquely doing exists yet. The investment is funding utilities, and the utilities are equally available to every competitor.
If both columns are funded, with the build column receiving the deliberate, multi-quarter investment that real infrastructure requires, the organization is operating in strategy mode. The harness is being constructed. The advantage is accumulating. The competitor that wants to match the position has to do the work, on its own timeline, with its own sequence of decisions, and cannot shortcut to the current position by writing a check.
Which part of your AI infrastructure is yours — and which part is everyone else's too?