Enterprise spending on generative AI pilots is now measured in the tens of billions, and most of it has bought nothing a chief financial officer can point to. In August 2025, MIT's NANDA initiative published The GenAI Divide: State of AI in Business 2025, built on 150 leader interviews, a survey of 350 employees, and an analysis of roughly 300 public AI deployments. Its headline finding: after an estimated 30 to 40 billion dollars of enterprise investment, about 95 percent of generative AI pilots show no measurable impact on the profit and loss statement. Only around 5 percent cross into production and move a real number.
The pattern is not confined to one report. In June 2025, Gartner predicted that more than 40 percent of agentic AI projects will be cancelled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls. Two research groups, two methods, two different vocabularies, and roughly the same shape of answer. Neither report blames the models for being unintelligent. Both point, in slightly different language, at the same missing piece: context that does not persist, and governance that has nothing solid to govern. This piece is about what that missing piece might actually be, and about a layer of the stack, call it an understanding layer, that a growing but still scattered set of tools seems to be reaching for as an answer, sitting beneath the agents themselves and doing the work of holding, and proving, what a system actually knows.
The pattern underneath the failure rate
Read past the headline number in the MIT report and the explanation is oddly specific for a study that made global news on the strength of one statistic. The researchers name the core issue the learning gap. Generic AI tools are flexible enough to impress in a demo and too generic to survive contact with a real workflow, because they do not retain feedback, do not adapt to how a specific team actually operates, and do not accumulate anything between sessions. Every pilot restarts cold. A system that cannot carry forward what it learned about a business is not going to become infrastructure, no matter how fluent its answers sound in the first five minutes. We have covered why these pilots fail in more detail elsewhere on this site: the metric that was never set, the front-office demo that won the funding meeting and lost the production fight, the build-versus-buy call that went the wrong way. All of that is real. But the learning gap sits underneath most of it, because a system with nothing that persists cannot be scoped narrowly, measured honestly, or trusted with a boundary. There is nothing stable enough to draw the boundary around.
Gartner's numbers point at the same gap from the governance side. Deloitte's 2026 survey of 3,235 business and technology leaders across 24 countries found that 74 percent expect to use agentic AI at least moderately within two years, while only 21 percent report having a mature governance model for it. About 80 percent said they lack the basic governance building blocks agentic AI actually requires: clear boundaries on which decisions an agent may take on its own, real-time monitoring that flags anomalous behavior, and an audit trail that captures the chain of what an agent did and why. Look closely at that list and none of the three items is really a policy problem. Each one is a data problem. An organization cannot set a boundary on what an agent may decide autonomously if nothing in the system can state what the agent currently understands well enough to act on. It cannot build a real audit trail without a record of the reasoning path, not just the output. Governance keeps failing for close to the same reason pilots keep failing: there is no durable, checkable record of what the system knows, only a stream of fluent answers that vanish with the session.
Generation got easy, trust did not follow
None of this is a capability problem in the sense most people mean it. By the measure that matters for coding specifically, models have been improving at a startling pace. METR, a research nonprofit that benchmarks AI agents against the length of task a skilled human would need to complete the same work, found that the task length AI systems can complete at a 50 percent reliability threshold has been doubling roughly every seven months for six straight years. Claude 3.7 Sonnet, tested in early 2025, could complete tasks that took a human expert around an hour. If the trend holds for another two to four years, METR's own extrapolation puts week-long tasks within reach. That is a real, fast, well-measured curve, and it is a curve about generation: how much a model can produce, unsupervised, before a human needs to check in.
Trust in what gets produced is moving the opposite direction. Stack Overflow's 2025 Developer Survey found that developer trust in the accuracy of AI output fell from 40 percent to 29 percent in a single year. Forty-six percent said they actively distrust it, against 33 percent who trust it, and only 3 percent said they highly trust it. The top named frustration, cited by 45 percent, was not a dramatic failure. It was AI output that is almost right and not quite, and 66 percent said they are now spending more time fixing that kind of near-miss code than before. Three out of four still go find a human when they stop trusting the AI's answer, which is an odd place to land after two years of rapid adoption.
GitClear's 2025 research, built from 211 million lines of changed code across repositories at Google, Microsoft, Meta, and a set of enterprise codebases between 2020 and 2024, gives the trust numbers a mechanism. Duplicated code blocks increased roughly eightfold over that period, and for the first time in the data, copy-pasted code outpaced code that was properly moved or refactored. Code churn, the share of new code rewritten within two weeks of being written, rose from 5.5 percent to 7.9 percent, while the share of changes that counted as genuine refactoring fell from 25 percent to under 10 percent. Assistants are generating plausible code faster than teams are integrating it, and the debt shows up exactly where it would be expected: in code nobody understood well enough to reuse, so they generated a new, slightly different copy instead.
Put the three findings together and a specific gap comes into focus. It is not that the model cannot write the code. It is that neither the tool nor the team around it can cheaply answer what a given change actually touches, why the model chose this approach over another, and whether that reasoning is still valid now that the codebase has moved on. Fluency answers a different question than the one an engineering organization needs answered before it hands an agent real autonomy.
The pattern that is emerging: an understanding layer beneath AI agents
One plausible answer, offered here as exactly that and nothing more, is that the competitive question in developer tooling is quietly moving down a layer. For most of the last three years, vendors competed on how well their model or agent could generate: better completions, longer autonomous runs, cleverer tool use. The pattern that is emerging, unevenly and from several directions at once, looks more like competition over which layer beneath the agent can prove, not just assert, what the system understands about the thing it is operating on, and can explain that understanding well enough for a person to check it.
The analogy that keeps surfacing among people building this kind of infrastructure is a database sitting beneath an application. An application does not re-derive durable, consistent storage every time it starts up. It sits on a database that guarantees certain properties, and the application layer gets to focus on behavior instead of re-solving storage from scratch. An understanding layer, if the pattern holds, would sit in roughly the same place: underneath the agent that drafts the pull request, answers the support ticket, or proposes the next action, a separate component whose only job is to hold a structural, checkable model of the system the agent is acting on, and to keep that model current as the underlying thing changes.
What such a layer would need to do is easier to describe than to build, and it is worth listing precisely because none of these properties are solved as a bundle yet, only in scattered pieces. It would need to represent structure, not just similar-sounding text, since a list of passages that resemble a question is not the same as a map of how the underlying pieces actually connect. It would need to persist across sessions, so a system does not re-derive the same understanding from nothing every time a window closes. It would need to be checkable and explainable, able to show the specific chain of facts behind a conclusion rather than asserting the conclusion fluently and hoping it holds. And it would need to be legible to a human auditor, not only to the model consuming it, because a governance policy is unenforceable if the only party who can read the reasoning is the system being governed.
None of that is hypothetical in isolated pieces. GraphRAG is one early, partial answer to the structure problem: it retrieves over a map of how facts connect instead of over passages that merely resemble a question, at the cost of an expensive indexing step and its own brittleness around entity resolution. Agent memory architectures are one partial answer to persistence: extraction, storage, and retrieval loops that let a system carry forward what it learned about a user or a project instead of forgetting on every closed tab, with unsolved problems of their own around what to forget and how to handle facts that go stale. Model Context Protocol answers a different piece entirely, not understanding itself but the wiring: a common interface that lets a specialized layer plug into whichever agent a team happens to be using, rather than every vendor building a bespoke pipe to every model. None of these were built as pieces of one grand design. They read more like several teams independently backing into a similar shape from different starting points, which is a weaker claim than a coordinated trend, but a more interesting one.
Governance is an understanding problem in disguise
Put the understanding layer next to Gartner's own explanation for its cancellation forecast and the two ideas click together more tightly than they first appear to. Gartner names inadequate risk controls as one of three drivers behind the cancellation rate it expects by the end of 2027. Deloitte's leaders name model explainability and governance oversight, at 46 percent each, among their top risk concerns, just behind legal and regulatory compliance at 50 percent and data privacy and security at 73 percent. Read those together and governance stops looking like a separate workstream sitting next to the technical build, arriving late because a compliance team is slow. Governance is downstream of understanding. An organization cannot set a boundary on what an agent may decide autonomously if nothing in the system can state, in a form a person can check, what the agent currently knows and how confident it should be. It cannot build a real audit trail out of an output log, because an output log records what the system said, not what it understood when it said it.
This reframes a debate that usually gets split into two unrelated tracks: ship faster agents, and separately, govern them responsibly. If governance is actually an understanding problem, the two tracks converge. A layer built to make a system's knowledge structural and checkable is, more or less by construction, also the layer that makes the system governable, because the same properties, persistence, structure, and a chain of facts a human can inspect, are what both jobs need. That does not make governance easy. It suggests, tentatively, that the teams solving for trustworthy autonomy and the teams solving for auditability may end up building closely related infrastructure whether they set out to or not.
What this could mean for developer tools specifically
Bring the argument back to the title's claim, since it is the one this piece is willing to be most concrete about without overreaching. Gartner estimates that of the thousands of vendors now marketing agentic AI products, only about 130 are doing anything genuinely agentic, a phenomenon it calls agent washing: existing chatbots, copilots, and robotic process automation relabeled for a hotter category. That gap between marketing and substance tends to close over time, and the METR curve is one reason to expect it will close here too. As raw task-completion capability keeps compounding on the schedule METR has been tracking, competent code generation looks less like a durable differentiator and more like a baseline every serious tool will eventually clear, the way autocomplete and syntax highlighting stopped being features worth marketing decades ago.
If that commoditization keeps going the way the last two years suggest, the more interesting competitive question for a developer tool stops being which one writes the best first draft. It becomes which one can say, specifically and correctly, what a proposed change actually touches elsewhere in the system, why it made that suggestion rather than another, and what it remains uncertain about. Gartner's own forecast still expects 33 percent of enterprise software to include agentic AI by 2028, up from under 1 percent in 2024, so the volume of agent-generated change moving through real codebases is going to keep growing regardless of how this particular question resolves. Whether that change is something a team can trust and safely absorb, rather than something it has to re-review from scratch out of justified suspicion, looks like it depends less on which model sits at the center and more on whether anything underneath that model can actually explain itself.
One current example, not the whole answer
Whether an entire category of tooling organizes itself around an explicit understanding layer, in the tidy way this piece has been describing it, is still an open question, and anyone claiming certainty about it this early should be treated with suspicion. What is not speculative is that at least one narrow, working version of the idea already ships today, applied specifically to source code.
Spiderbrain, built by Perform Digital, parses a codebase into what it calls a brain: a deterministic, source-free context graph of a project, including a real dependency and call graph and blast-radius analysis for a proposed change. Deterministic here means literally that: the same codebase produces the same brain every time, a property backed by roughly 350 automated checks that run green on every release. Parsing happens locally on a developer's own machine, and only the resulting source-free map, not the code itself, goes to Spiderbrain's EU-based servers for scoring. The code never leaves the device. The brain persists across sessions rather than being rebuilt from a blank window each time, and it speaks Model Context Protocol, so it plugs into more than ten MCP clients, including Claude, Claude Code, Cursor, Continue, Cody, and Zed, instead of requiring its own bespoke integration for each one. A public registry of pre-built brains covers a set of public repositories, and a npx spiderbrain command line tool exposes impact, path, and verify checks directly, alongside a GitHub App that can publish a repository's brain through a verified-ownership flow. It runs on Windows and macOS today, with Linux planned but not yet shipped.
Held up against the shape sketched earlier in this piece, deterministic and checkable, structural rather than similarity-based, persistent across sessions, wired through a common protocol, Spiderbrain reads as a deterministic context graph: one concrete, currently shipping instance of the pattern, scoped tightly to code. It is not evidence that the broader pattern is correct, and it is one approach among several a team could reasonably choose, not a claim that it is the only or the best way to close the gap. Other teams are approaching the same problem from memory architectures, from graph retrieval, from observability tooling that traces what an agent saw before it acted. Which of those pieces end up standardized, which stay proprietary, and which turn out to be the same idea wearing different names, is genuinely not settled yet.
The 95 percent and the 40-percent-plus are not, in the end, a verdict on whether AI works. They are closer to a measurement of how much of the stack still has no place to keep and prove what it understands. Fluency turned out to be the easy part, and it kept getting easier on a schedule researchers can already chart a couple of years ahead. What stayed hard, and what the pilot graveyard keeps pointing back at, is the layer that would let an organization check a system's reasoning instead of just reading its output and hoping. Whichever companies end up building that layer, in whatever form it eventually takes, are the ones whose pilots are more likely to survive contact with production. That is worth watching closely, regardless of which product ends up owning any particular piece of it.
Council summary
This post argues that the widely cited MIT NANDA finding that 95 percent of enterprise generative AI pilots show no profit and loss impact, and Gartner's forecast that over 40 percent of agentic AI projects will be cancelled by 2027, point at the same underlying gap: not weak models, but the absence of a durable, checkable layer that holds what a system actually understands about the process or codebase it operates on. It backs the claim with converging data, MIT's own learning-gap finding, Deloitte's governance-maturity numbers, METR's fast-rising capability curve set against Stack Overflow's falling trust numbers and GitClear's code-quality data, and treats the resulting thesis, an understanding layer sitting beneath agent tools the way a database sits beneath an application, as a plausible pattern rather than a proven one, citing GraphRAG, agent memory, and MCP as partial, independent instances of it. It closes by naming Spiderbrain's deterministic context graph as one concrete, narrowly scoped, currently shipping example, not the whole answer. The reader's takeaway: watch for tools that can explain themselves, not just generate fluently, because that is where the next real differentiation is likely to show up.
Comments