Organizations are using agentic coding tools to build software in-house instead of purchasing it - and nearly a third of respondents to McKinsey's 2026 State of AI survey say their company has done exactly that, declining at least one software product or feature because it could be built internally.
The build-vs-buy question, settled for most of the past decade in favor of buying, is open again - and that matters to anyone selling software, because buyers now have a credible third option that costs a sprint rather than a subscription.
That 32% number has travelled fast. It deserves a closer read before it settles into received wisdom.
What the McKinsey number actually measures
Nearly a third of respondents - 32% - told McKinsey their organizations decided against buying at least one software product or feature because they could build it in-house with agentic coding tools. That is a purchase forgone, not a contract cancelled. The distinction is real. A team that didn't renew a small SaaS tool avoided a line item. A team that decided to build an equivalent from scratch added one - it just doesn't show up on a vendor invoice.
McKinsey's 2026 survey found 32% of organizations skipped a software purchase because agentic coding tools could build it in-house, while the share reporting any EBIT impact from AI stayed flat at 37%. That gap - 80% claiming individual productivity, 37% showing enterprise profit impact - is the real signal buried under the headline. Teams feel faster. The income statement hasn't noticed yet.
The build-instead-of-buy impulse is most pronounced among McKinsey's "high performers" - the 6% of respondents attributing at least 5% of EBIT to AI. Nearly half of these high performers are skipping software purchases, compared to 31% of their peers. That correlation is interesting, but the causal arrow is not obvious. The data does not show that buying coding agents produced the outcome. It shows that one population - high performers - reports doing both, without establishing which came first.
The hidden run cost of building
A team that replaces four mid-tier SaaS subscriptions with four agentic workflows has not returned to zero. The cancelled subscription is a clean, visible line in a budget. What replaces it is not clean, and it mostly stays invisible for two or three quarters.
An arXiv study published in 2026 analyzed 302,600 verified AI-authored commits across 6,299 GitHub repositories and found 484,366 distinct introduced issues, 89.3% of them code smells. Over 15% of AI commits introduced at least one issue, and 22.7% of tracked issues were still present in the latest version of the repository. That is not an argument against using coding agents. It is an argument for pricing in the review and remediation work that follows them - work that SaaS vendors absorb and build teams tend not to budget for.
The old generation of coding tools had a ceiling: they accelerated the act of writing code but left the surrounding work untouched - planning, debugging, security review, deployment, observability. The new generation handles more of that loop. But it does not make the loop disappear. The more autonomous a tool, the more important it is to have strong code review practices in place. High autonomy requires high review discipline.
The OpenClaw case study in moving fast
OpenClaw started in November 2025 as a side project called "Clawdbot." Within a few months, after a rebrand and a burst of viral attention, it had become the fastest-growing open-source repository in GitHub history. It is the most visible example of the build-side of this debate: a self-hosted, open-source agent runtime that teams grab to automate work they'd otherwise buy a SaaS tool for.
On August 30, 2026, the OpenClaw Foundation announced OpenClaw 2.0, featuring usability improvements, faster installation, a redesigned UI, and shared cloud sessions. Shared sessions are genuinely useful - they let multiple team members work with a single agent instance without losing context across the handoff.
The security picture is less tidy. The OpenClaw Foundation states in the 2.0 patch notes that the shared session controls "are not tenant isolation or a security boundary."
The secret store, meanwhile, separates protected values from agent-readable environment values - but "Secret Store values are not encrypted at rest and depend on the filesystem permissions of OpenClaw's state directory."
A January 2026 audit found 512 vulnerabilities, 8 at the highest severity level. A Bitsight scan of over 40,000 public instances found 63% were open to remote attack.
Many deployments grant the OpenClaw agent broad permissions across the operating system, browser sessions, SaaS applications, local files, and cloud environments. While this enables powerful automation, it also creates an extremely large blast radius if the agent is compromised. In enterprise environments, this effectively turns the AI agent into a privileged lateral movement platform for attackers.
None of this means OpenClaw is the wrong choice for the right context. OpenClaw can be safe for one trusted operator, but not as a hostile shared tenant. The problem is that teams treating it as a build-vs-buy answer to a SaaS tool are often not in the "one trusted operator" situation - they're deploying it to a team, connecting it to production credentials, and calling it done.
Beagle in action#engineering, 11:02amThe steelman for building
The case for building is real, and it deserves a fair statement before it gets dismissed.
The tools most at risk from agent-built alternatives are those built around process convenience rather than proprietary data. Systems of record, governance layers, and platforms with deep domain data are far more defensible. If you're paying for a SaaS tool that does one thing your stack could do with a few API calls and a prompt, the calculus genuinely has shifted. The adoption curve for agentic coding tools is steep, and the drivers are practical: developers report 3-5× speed improvements on well-defined tasks - adding features, writing tests, refactoring modules - when using agentic tools compared to traditional autocomplete or even first-generation chat-based assistants.
The recurring sentiment in communities where teams are running these experiments: why pay $800 a month for a platform's native agent when an open-source stack with direct API access performs better for a fraction of the cost? That's a fair question for thin SaaS tools with weak moats.
But it is not a universal answer. Forrester reported in June 2026 that roughly 75% of organizations are adopting agentic AI, but only a small minority have reached meaningful production. The Gartner CIO Survey 2026 found only 17% of organizations have actually deployed agents, and Deloitte's 2026 Tech Trends report places the number of production-ready agentic systems at just 11%. The distance between "we decided not to buy it" and "we shipped a production system that runs reliably" is where the hidden cost lives.
Build vs buy AI software: common questions
What does McKinsey's 32% build-vs-buy figure actually mean?
McKinsey's 32% counts respondents whose organizations declined at least one software purchase because agentic coding tools could deliver the functionality in-house - a purchase forgone, not a cancellation of an existing contract, on a threshold of a single instance. It measures intent and one-off decisions, not a systematic shift of software budgets. Read it as a directional signal, not a replacement rate.
Is building software with AI coding agents cheaper than buying SaaS?
At the point of first delivery, often yes - especially for narrow tools with no compliance or uptime requirements. The cost gap closes quickly when you price in model API spend at scale, review overhead for AI-generated code, and the absence of a vendor support contract. The McKinsey data shows 80% of respondents feel more productive, but only 37% show EBIT impact, which suggests the savings are not yet reliably reaching the bottom line.
Which SaaS categories are most at risk from agentic coding?
The tools most at risk are those built around process convenience rather than proprietary data. Single-workflow automation tools, lightweight reporting dashboards, and internal approval systems with no compliance requirements are the clearest candidates. Vendors with deep data moats, audit trails, or regulated-industry certifications are considerably less exposed.
Is OpenClaw safe to use for team deployments?
OpenClaw's security model was designed for one trusted user. It was not designed for shared use, and thinking otherwise breaks the assumption the whole model depends on. For team deployments, you need separate Gateways per user, a private network, and a minimal toolset with human approval gates - the opposite of the default configuration most teams reach for first.
Should engineering teams build internal tools or buy them?
The honest answer is: it depends on the maintenance contract you're willing to sign with yourself. Build when the tool is narrow, the team owns the domain deeply, and the compliance bar is low. Buy when uptime, security patching, vendor support, or audit trails matter - or when the engineering time has a higher-value use. Your buyer now has a credible third option beside any product and its competitor's, and it costs a sprint rather than a subscription
- but a sprint is not the whole price.