32% of surveyed organizations skipped software purchases because of coding agents
A coding agent can make an internal tool look cheaper than a subscription. It cannot show the invoice for owning that tool afterward.
That invoice is easy to miss in a notable result from McKinsey's State of AI 2026 survey. Thirty-two percent of respondents said their organizations had decided against buying at least one software product or feature because they could build it internally with agentic coding tools.
The number does not show that 32 percent of companies replaced a major SaaS platform, or that the decisions saved money. It comes from an online survey of 1,719 participants in 97 countries, fielded from May 4 to June 8, 2026 and weighted by each respondent's country's contribution to global GDP. The question also groups products and individual features together. A small approval screen and an enterprise CRM can both qualify.
Still, the finding marks a change in engineering economics. Coding agents reduce the cost of producing a first version. Work that once looked too small for a development queue can now look buildable. Operating, securing, supporting, and eventually replacing the result still costs money.
The survey describes a decision, not a return
McKinsey's other findings warn against treating 32 percent as a success rate. Eighty percent of respondents said AI improved their individual productivity. Only 37 percent attributed any positive EBIT impact to AI, essentially unchanged from the previous year. Twenty percent said AI operating costs, including tokens, had constrained use.
These measures are not directly comparable, but they expose a common accounting error. Faster code generation is not a business case. An engineer may finish the first implementation sooner while the organization picks up extra review, infrastructure, incident, and support work elsewhere.
METR found a sharper example in a randomized trial with 16 experienced open-source developers. Across 246 real tasks in mature repositories, developers using early-2025 AI tools took 19 percent longer. Before the study they predicted a 24 percent speedup; afterward they still believed they had achieved a 20 percent speedup. METR cautioned that this was one setting and did not represent most software work. Its relevant lesson is simple: perceived velocity and elapsed time can disagree.
A software purchase includes work you stop seeing
Part of a software bill pays for recurring work:
- compatibility updates when browsers, operating systems, APIs, or regulations change;
- security patches, dependency upgrades, vulnerability response, and access reviews;
- backups, observability, incident response, and recovery testing;
- documentation, onboarding, user support, and accessibility;
- data export, retention, deletion, and integration maintenance;
- a roadmap and a party responsible for keeping the product usable.
An internal build transfers those jobs. Sometimes that is exactly the point. A vendor may bundle unwanted features, control essential data, or fail to fit a specialized workflow. But the new owner needs a budget and a team, not just a repository.
NIST's Secure Software Development Framework makes this lifecycle visible. Its four practice groups cover preparing the organization, protecting software, producing well-secured releases, and responding to vulnerabilities. The initial implementation addresses only part of the obligation.
The best internal tools have narrow borders
Good candidates are usually small systems with bounded consequences: a team dashboard assembled from existing data, an approval workflow for a stable process, a report generator, or an adapter between two internal APIs.
Five questions help separate a useful tool from a future liability:
- Can the team describe the workflow? Inputs, outputs, and exceptions should be known before the prototype starts.
- Who owns it? One person or team must be accountable for uptime, changes, access, and retirement.
- What happens when it fails? A broken report is different from a broken payroll, identity, medical, or compliance system.
- Can the data leave? Export should use a documented format that does not require reconstructing the tool's history.
- Will maintenance be counted? Support, review, infrastructure, and incident time are not free engineering capacity.
None of these questions asks how quickly the agent can render a dashboard. That is deliberate. Buying still has a strong case when regulations move frequently, integrations multiply, round-the-clock support matters, or a vendor's network and domain expertise are the real product. A commodity interface may be easy to copy. The institution around it is not.
Run a 30-day shadow-price test
Compare build and buy over the same scope and time horizon before canceling a purchase.
Week 1: define the service. List users, critical workflows, data classes, uptime needs, access controls, integrations, export requirements, and an owner. Document what happens if that owner leaves.
Week 2: build the thin version. Use a coding agent where it helps, while keeping changes small enough to review. Instrument failures immediately. The BLOGish guide to traces that explain agent failures is useful when the tool calls models or external services.
Week 3: operate both paths. Run the internal version beside the current product or manual process. Record defects, review time, support requests, latency, model and infrastructure spend, and the hours spent on exceptions. Lines of code are not a value metric.
Week 4: price ownership. Estimate one year of maintenance, security work, integrations, user support, and migration. Put an hourly cost on engineering and operations. Add a retirement plan and the cost of exporting data.
Then choose build, buy, or hybrid. A hybrid can keep a mature system of record while adding a narrow internal interface or automation. If the prototype uses model APIs, a gateway such as api.ish.chat can simplify model comparison. Model access remains one line in the ownership budget.
The first commit is not the product
DORA's 2025 research describes AI as an amplifier of an organization's existing strengths and weaknesses. A 2026 DORA analysis of 1,110 open-ended responses from Google engineers found that time saved during initial generation was often spent later on auditing and verification. It also noted the distance between a quick prototype and production integration.
Coding agents are moving buy-versus-build decisions into a zone where either option can look sensible after a two-day prototype. The decision should turn on the work after generation. An agent can make the first commit inexpensive. The organization still has to decide whether it wants the last pager alert.
