McKinsey’s State of AI 2026 survey has one number that’s going to get quoted a lot this quarter without the number next to it that actually makes it interesting: 32% of organizations skipped buying a software product or feature because agentic coding tools made it viable to build it in-house instead (41% in tech specifically). The number sitting right next to it, though, is that the share of organizations reporting any real EBIT impact from AI stayed flat at 37% year over year. Read together, those two numbers aren’t a success story — they’re a warning about counting the wrong thing.

Build-vs-buy got cheaper on one side of the ledger only

The traditional build-vs-buy calculus weighs upfront build cost against licensing cost, with build usually losing on speed and buy usually losing on flexibility and long-term cost. Agentic coding tools genuinely move that calculus — the upfront cost of standing up a working internal tool has dropped, sometimes dramatically, for the class of software that’s mostly CRUD, internal dashboards, and workflow glue that doesn’t need to be defensible IP. That’s real and I’ve made that call myself this year.

But “upfront build cost” was never the expensive part of software ownership. It’s the part that’s most visible in a demo and least representative of total cost. What agentic coding tools haven’t materially changed:

• Who owns the thing at 2am when it breaks. A vendor’s SLA doesn’t transfer just because your build cost dropped. If anything, the on-call burden went up relative to build cost — you’re now on the hook for a system that took a week to build instead of a quarter, which means less institutional pressure to have documented it properly before it’s someone else’s problem.
• Security and compliance surface. A SaaS vendor’s SOC 2 report is a thing you can point to. An internal tool an agent scaffolded in an afternoon inherits none of that by default — someone still has to review the auth model, the data handling, and the dependency tree, and that review doesn’t get cheaper just because the code got faster to write.
• The maintenance curve past the first six months. This is the one McKinsey’s own high-performer data hints at without stating directly: the 6% of respondents attributing real EBIT impact to AI are disproportionately the ones treating build vs. buy as a total-cost-of-ownership decision, not a time-to-first-version decision. Nearly half of that high-performer cohort skip purchases; the other 94% of respondents skip at a lower, though still meaningful, rate — and the EBIT-flat number suggests a lot of that 94% is capturing dev-velocity gains that don’t survive contact with year-two maintenance cost.

The run-cost question nobody puts in the initial estimate

The build cost that shows up in a Slack message — “the agent had this working in two days” — is never the number that determines whether the build-vs-buy call was correct. The number that determines that is what it costs to run and maintain over the tool’s actual lifetime, and that number is dominated by things agentic coding doesn’t touch:

total_cost_of_ownership = 
    build_cost                      # this is what dropped
  + (maintenance_rate * lifetime)   # this didn't drop, and might have gone up
  + incident_cost                   # unclear — depends on doc/test quality at build time
  + opportunity_cost_of_owner_time  # someone now owns this instead of a vendor

build_cost going from, say, six weeks to three days is the headline. But if maintenance_rate didn’t drop proportionally — and there’s no strong reason it would, since maintenance burden is mostly a function of how well-tested and documented the thing is, not how fast it was typed out — then a tool that used to look like an easy build-vs-buy win on a spreadsheet stops looking easy once you price in eighteen months of “who fixes this when the API it depends on changes.”

Where I’d actually apply the “build it in-house” instinct

Not never — the instinct is right in a specific, narrower band than the 32% figure implies. The cases where building genuinely wins on total cost, not just build cost:

1. The tool is thin glue, not a system. A Slack notification bridge, an internal status dashboard reading from an API you already have — low surface area, low blast radius if it breaks, cheap to rewrite if requirements shift. This is most of what I’ve actually built this year and it’s been a clear win.
2. You already have the on-call capacity and the review discipline for it. If the team maintaining it is the same team that would’ve evaluated the vendor anyway, the ownership transfer is real but not new burden — it’s redirected burden.
3. The vendor’s roadmap doesn’t match your actual need, and you’re not just avoiding a purchase because the demo felt satisfying. This is the one worth being honest with yourself about — a fast agentic build is genuinely fun to watch happen, and that’s a bad reason to skip a $200/month SaaS subscription that would’ve saved forty hours of a future incident.

The cases where I’d override the instinct and buy anyway: anything touching auth, payments, or compliance-scoped data, where the vendor’s cost isn’t the software — it’s the audit trail and liability transfer that comes with it. And anything where “it works” in week one is doing a lot of load-bearing work that “it’s still correct in month eight, after three API changes upstream and two team handoffs” hasn’t tested yet.

The actual read on the McKinsey number

32% skipping a purchase isn’t itself the interesting data point — cheaper build cost was the predictable result of better tooling, and it’s not wrong to take advantage of it. The interesting data point is that EBIT impact didn’t follow, which means a meaningful chunk of that 32% is optimizing the line item that was already visible (upfront build cost) while the line items that actually determine whether a build-vs-buy call was good — maintenance rate, incident cost, who owns it in year two — stayed exactly as expensive as they always were. The organizations closing that gap aren’t the ones building more. They’re the ones pricing what they build the same way they’d price what they’d have bought.

Sources: The Build-vs-Buy Shift: 32% of Enterprises Bet on Agentic Coding Tools, McKinsey — The State of AI: Global Survey 2026