The releases, in one paragraph
On May 6, 2026, at Knowledge 2026, ServiceNow made Build Agent generally available — and extended its skills into Cursor, Windsurf, Claude Code, and GitHub Copilot, so developers building from any of those IDEs operate with full ServiceNow AI Platform context and governance. Build Agent connects as an MCP client into Figma (design specs), Miro (requirements), and GitHub (code context). Its App Engine Management Center ships deployment approvals, release management, audit trails, and security/compliance checks at no additional cost; a self-healing test loop validates generated work against organizational quality gates; and Custom Instructions encode the organization's development standards into every agent run. Two days later, on May 8, Opsera announced a parallel partnership embedding DevSecOps Agents directly into Cursor, and Snyk announced an integration of its AI Security Platform with Anthropic's Claude models — both rolling out through 2026. Last June, Gartner projected that over 40% of agentic AI projects will be canceled by the end of 2027 — driven by escalating costs, unclear business value, and inadequate risk controls.
The surprising line across all of this isn't that any one of these governance products shipped. It's that the entire enterprise governance plane is simultaneously consolidating at the IDE, not the deploy gate. ServiceNow, Opsera, and Snyk all reached the same conclusion the same quarter: if the AI coding agent is going to write a meaningful share of the codebase, the place to apply governance is while the code is being written, inside the surface the engineer is already using, before the PR exists. The deploy gate is too late.
Why governance-at-the-IDE is the architecture decision, not the policy document
For three years, enterprise AI governance lived in policy documents — model registry, approved-vendor list, data-residency rules, fair-use principles, retention policies. The policies were mostly correct and mostly unenforceable, because the surface they tried to govern (a developer talking to a chat window) was unobservable to the governance plane. The current wave of releases reframes that: governance is moving into the surface itself, where it's enforceable by construction.
The IDE is the only chokepoint that sees every AI-assisted code change. A policy document on the wiki sees nothing. A deploy gate sees the code only after it's been written, reviewed, and merged — far past the moment the governance decision had a cheap intervention. The IDE sees the agent's prompt, the agent's response, the engineer's accept/reject decision, and the resulting diff, in real time. That is the layer where security scanning, license compliance, organizational standard enforcement, and audit logging actually has a chance to be both effective and cheap. Every product shipping into this space — ServiceNow Build Agent, Opsera DevSecOps Agents, Snyk's Claude integration — recognizes the same chokepoint.
The governance plane has to ship as a native surface, not a wrapper. Engineers route around governance that adds friction. The Build Agent integration into Cursor, Claude Code, and Copilot works because it surfaces as an MCP server the agent already speaks to — it's part of the conversation, not a separate tool the engineer has to context-switch into. Snyk's Claude integration follows the same pattern: scan-on-suggestion, surfaced inline, no extra click. The lesson for internal platform teams is that governance you ship as a separate dashboard is governance engineers will skip; governance you ship as an MCP server the agent consults during code generation is governance that runs by default.
MCP is doing the governance integration work, not just the data-access work. The same protocol that lets an agent reach into Figma to read a design spec lets a governance plane interject in the agent's reasoning to enforce a security policy. That is a non-obvious second use of MCP that the current wave of releases is normalizing. Build Agent's MCP-client integration with Figma/Miro/GitHub is the integration story; the App Engine Management Center is the governance story; they ship as facets of the same protocol layer. Plan your own MCP architecture with both uses in mind.
What the Gartner 40% prediction actually changes
The most operationally useful piece of the current cycle isn't a product release — it's the Gartner number. Over 40% of agentic AI projects will be canceled by end of 2027. The drivers Gartner cites — escalating costs, unclear business value, inadequate risk controls — are the same three failure modes every governance-at-the-IDE product is built to address.
Cancellation isn't failure; it's an absence of governance. A project that lands in production with a runaway cost profile, no measurable business outcome, or an unmanaged risk surface gets canceled not because the agent didn't work, but because nobody could prove it was working in the ways an executive needs proof. The governance layer is what produces that proof — the audit trail, the cost-per-task instrumentation, the per-workload eval scores. Without it, the project gets canceled at the budget review even when the underlying agent is genuinely useful. With it, the project survives the review with data attached.
"Agent washing" is the supply-side version of the same problem. Gartner estimates only about 130 of the thousands of agentic AI vendors are real — the rest are rebranded chatbots, RPA tools, and AI assistants with no actual agentic capabilities. The buyer-side defense isn't a procurement checklist; it's an eval suite that runs every candidate vendor against a representative workload and grades against a rubric a senior engineer authored. The teams that buy on demo-and-deck end up canceled six months later. The teams that buy on eval-and-data end up scaling.
The governance layer is what survives a vendor swap. When the agent vendor changes — and over a three-year horizon, every agent vendor changes — the codebase, the MCP servers, the rubrics, the eval suite, the audit log, and the deploy gates all carry over. The vendor was renting capability against a fixed scaffolding. Teams that didn't build the scaffolding pay a migration tax with every vendor swap; teams that did treat the swap as a one-week reconfiguration.
What it doesn't change
The agent's quality still depends on the model. Build Agent on Claude is a different product than Build Agent on a hypothetical cheaper alternative. The governance layer doesn't make a weak model produce strong code; it makes a strong model's output safe to merge. The model selection conversation and the governance conversation are independent — both matter. A team that picks the wrong model and the right governance ships less, slowly, safely. A team that picks the right model and the wrong governance ships the Amazon-style incident from March.
The senior reviewer is still the bottleneck. Every governance product shipping this quarter automates the first pass of review — the pattern-matching for known security antipatterns, the license compliance check, the organizational-standard enforcement. None of them replace the senior reviewer's judgment on the changes that aren't obvious. The right read is that the governance layer makes the senior reviewer's time more leveraged — they arrive at the PR with the obvious items already flagged. It doesn't reduce the headcount of senior reviewers the org needs. If anything, it raises the bar on what each one is asked to evaluate.
"Governance by default" doesn't mean governance is free. Every governance product is built on a body of rules — security antipatterns, compliance requirements, organizational standards, license rules — and those rules age. The team that adopts Build Agent or Opsera or Snyk and assumes the vendor maintains the rules forever is the team that discovers, eighteen months in, that the rules don't cover the new failure modes the latest agent introduces. The governance layer requires a continuous engineering investment to stay sharp; budget for it.
Where we'd push back on the framing
"Governed by default" is the marketing claim and a partial truth. Build Agent ships with sensible defaults; those defaults are not your organization's policy. Custom Instructions, allow-lists, and per-team configuration are how the vendor's product becomes your organization's governance — and that configuration work is real. A team that turns on Build Agent on Monday and ships the same week without tailoring the rules is governed by somebody else's defaults, which may or may not match what your security team would write if asked.
"40% of agentic AI projects will be canceled" is a prediction, not a prescription. Read it as a base rate: in any portfolio of agentic-AI initiatives, expect a meaningful fraction to fail the budget review, and design your project portfolio so the survivors carry the rest. The right response isn't "don't start agentic projects." It's "start them with measurable value hypotheses, deploy them with governance, and instrument them with the data the budget review will demand." The 60% that survive are the ones with the documentation; the 40% that don't are the ones without.
Vendor consolidation at the governance layer is its own risk. ServiceNow shipping Build Agent into every major IDE is convenient for buyers who already run ServiceNow. It is a structural lock-in concern for buyers who don't, or who don't want a single vendor providing both their workflow platform and their AI-coding governance plane. The right defense is the same as at the model layer: pick the governance layer that fits the workload, keep the integration glue thin, and design the audit trail so it lives in your observability stack as well as the vendor's.
What we'd build differently this week
- Map your current AI-coding governance to the IDE. For each governance concern — security antipatterns, license compliance, organizational standards, secret handling, data-residency rules — answer: is this enforced at the IDE, at the PR, at CI, at deploy, or only on the wiki? Anything still living only on the wiki is unenforceable; move it to the deploy gate this quarter, the PR check next quarter, and the IDE the quarter after.
- Pick one governance-at-the-IDE product and run a four-week pilot. Build Agent, Opsera, Snyk's Claude integration — whichever fits your stack best. Pilot on one team, instrument the catch rate and the false-positive rate, and decide whether the friction-to-coverage ratio is favorable before rolling further. The teams that buy on the keynote pay for the catch rate they didn't measure.
- Build a per-workload value hypothesis before any agentic project starts. "Reduce X-team's PR-review time by Y%" is a value hypothesis; "adopt AI agents for productivity" is not. The Gartner cancellation rate is concentrated in the projects without the first kind of hypothesis. Make it a precondition for project funding; revisit it quarterly.
- Instrument the audit trail in your own observability stack, not just the vendor's. Every AI-assisted code change, every governance event, every deploy gate decision should land in the same Datadog / Grafana / Splunk / Honeycomb instance your platform team already operates. The vendor's dashboard is convenient; your own observability is what survives the vendor swap and what answers the security team's question at incident time.
- Name the engineer who owns governance. Not the platform team that ships the integration — the senior engineer who owns the rule set, signs off on policy changes, and has the authority to halt deploys when the eval suite regresses. Without an owner, the rules age out, the eval suite gathers stale tests, and the project drifts toward the cancellation bucket. With an owner, the governance layer stays sharp as the agents keep changing.
Sonnet Code's take
The Build Agent / Opsera / Snyk releases and the Gartner 40% prediction are the same story told from two directions. The right read isn't "agentic AI is risky; slow down." It's that the engineering teams shipping agentic AI reliably in 2026 and 2027 are the ones who treat governance at the IDE, eval at the workload, and value hypotheses at the project funding as first-class disciplines — owned by senior engineers, refreshed on a cadence, instrumented in their own observability stack. The 60% of agentic projects that survive Gartner's prediction will be the ones with that scaffolding; the 40% that don't will be the ones who shipped on vibes, the keynote, and the demo.
We staff both halves of that work. AI development at Sonnet Code is the engineering that builds the MCP servers behind governance integrations, the rule sets that turn vendor defaults into organizational policy, the eval harnesses that grade catch rate and false-positive rate over time, the audit-trail plumbing that lands governance events in your observability stack, and the value-hypothesis instrumentation that answers the budget-review question before it gets asked. We pair it with AI training engagements where senior practitioners — staff engineers, security architects, compliance leads — author the rubrics, the golden examples, the failure-mode catalog, and the calibration sets that grade what your governance layer actually catches, separate from what the vendor's keynote claimed. If your team is reading the ServiceNow announcement and the Gartner number this week and wondering whether your agentic-AI roadmap survives the budget review six quarters from now, the next conversation isn't about which IDE plug-in to install. It's about who owns the governance layer, where the audit trail lives, and the senior practitioner whose rubric defines whether the agent is producing the value the project was funded against.
