Image: Illustration only — no featured image available for this story.

The Agentic Development Governance Gap Is Now a Competitive Differentiator

There's a coordination problem brewing in enterprise software development, and most engineering teams don't have a name for it yet.

Mikhail Vink, JetBrains's VP of business development, has a vantage point almost nobody else in the industry shares. His company's IDEs run on 15 million developers' machines — a sample size large enough to see patterns before they become obvious. What he's watching unfold, in aggregate, is an enterprise development landscape that's raced headlong into multi-model AI tooling without building any of the governance infrastructure that makes that sprawl manageable. "This month there's something from Anthropic, next month it's something from Gemini," Vink told theCUBE at Google Cloud Next. "You really, as a developer, need to be top-notch on top of all of those things to get the best from the market." The observation sounds like a product pitch for JetBrains Central, which it is. But the underlying problem is real and getting more urgent by the week.

Here's what the coordination problem actually looks like at scale. Your organization has 500 developers. Some are running Claude Code for architecture work. Some switched to Copilot because their team standardized on GitHub Enterprise. Some are on JetBrains with Gemini built in. A few are running Cursor, which has its own billing model. A subset of your security team is experimenting with Code Agents from Wiz, which has its own spend. Each developer is making independent, locally rational choices about which model to use for which task. Nobody at the organizational level can tell you what the total AI coding spend is, what fraction of suggestions are being accepted without review, or which codebases have the highest defect escape rates from AI-generated changes. That's not a hypothetical failure mode. That's most enterprises in 2026.

The thing about this problem is that individual developers can't see it. A developer running Claude Code in their session has a perfectly coherent local experience. The cost shows up on their seat license. The suggestions feel helpful. The acceptance decisions feel personal and reasonable. The governance problem lives at the organizational level — in finance, in platform engineering, in the engineering manager's dashboard that doesn't exist yet because nobody built it. JetBrains Central is an attempt to build that dashboard: cost tracking, model access monitoring, and acceptance rate analysis for AI-generated suggestions across the entire IDE fleet. The fact that JetBrains can build this at all is a function of their position — they sit in the IDE layer, which is the one place where every developer's AI interaction touches a common surface. That's a structural advantage nobody else in the agentic coding stack currently occupies.

The Context Problem Nobody Is Talking About

There's a second problem layered underneath the governance problem, and Vink name-checked it almost in passing: MCP. "You need to connect them to the Model Context Protocol server to get the context to the agents, because otherwise you're going to be missing out on the real-world data — structured data." This is the most technically specific thing he said, and it's the least covered in the broader agentic coding press.

The framing that dominates AI coding tool coverage is the model arms race: which model scores highest on SWE-bench, which is cheapest per token, which just released a new version. The practitioners actually building enterprise agentic systems are focused on something different: how do you get the right context to the model at the right time, without burning your entire context window on a raw database dump or introducing latency that kills real-time workflows? MCP is the answer — not just a protocol for connecting models to tools, but the mechanism by which agents get structured, real-world data without manual喂食. The teams that have figured out MCP server configuration are the ones whose agents don't ask clarifying questions about repository structure, environment setup, or deployment state every single session. Context flows through automatically.

The practical implication for platform teams is concrete: if you're evaluating AI coding tools purely on model benchmark performance, you're answering the wrong question. The question that determines whether an agent actually helps your team is "does this agent have the right context at the right time?" Answering that requires MCP infrastructure, and that requires someone on your team who understands how to build and maintain it. That's not a developer productivity problem. That's a platform engineering problem, and it's one that most organizations haven't even identified yet.

The Critical Thinking That Can't Be Automated

Vink's most-quoted line from the interview is also the most important: "The most critical thing in quality assurance is critical thinking. It's not just approving what AI gives you, what agents generate — it's going really deep and understanding how the system works." It sounds obvious. It isn't.

The reason it's not obvious is that "approving what AI gives you" is how most developers are actually using AI coding tools today. They run a session, review the output at whatever level of depth their time allows, and accept or request changes. The model produces, the human approves. The human's role is a quality filter on the model's output. What Vink is describing is a more demanding standard: not "did the output look reasonable?" but "do I understand the system-level implications of what was generated?" That's a fundamentally different activity. It's closer to architecture review than code review. It's the difference between checking whether a contract deliverable matches the spec and understanding whether the deliverable creates unintended coupling between systems you didn't know were connected.

The ZDNET piece from yesterday put a name to this dynamic — the contractor analogy. An AI coding agent is a contractor: it produces what you asked for, which may or may not be what you needed. The discipline of managing that contractor is the same discipline that applies to any outside contributor. Define the scope tightly. Verify at each checkpoint. Review the output architecture, not just the output syntax. Never ship what you haven't read carefully. The contractor analogy works at the individual developer level. What JetBrains Central is trying to do is give engineering managers the aggregate view — what percentage of suggestions are being accepted, across which models, in which codebases, at what cost — that lets them manage the contractor workforce at organizational scale.

The Multi-Model Bet Worth Watching

JetBrains made a deliberate choice with Central: open platform, supporting Anthropic, OpenAI, and Google agents alongside JetBrains's own. No lock-in. That's a competitive positioning decision that makes sense given their position — they serve developers regardless of which model those developers prefer, and forcing them onto a single provider would alienate a chunk of their 15 million users. But it also means something more interesting: Central's governance data will be cross-model from day one.

Think about what that means for a large enterprise. You can see cost, acceptance rate, and defect escape rate across Claude Code, Copilot, and Gemini in one dashboard. You can compare whether suggestions from Sonnet 4.6 are being accepted at higher rates than Codex in your JavaScript codebases, and whether acceptance rate correlates with defect escape rate six weeks later. That's not a JetBrains feature — it's a structural data advantage that comes from being the neutral layer that every developer's IDE touches regardless of which model they're running. Nobody else in the agentic stack occupies that position. The hyperscalers have the inference infrastructure. The AI labs have the models. JetBrains has the developer workflow observability, and that turns out to be its own kind of moat.

The governance gap Vink is describing isn't theoretical. It's already visible at organizations that have scaled AI coding adoption without building the organizational infrastructure to match. The teams that figure out token governance, acceptance rate tracking, and multi-model orchestration before their competitors will have a structural advantage — not just in cost, but in the quality signal that comes from knowing what's actually shipping. Critical thinking can't be automated. But governance infrastructure can be built. The teams doing that work now are the ones who'll be able to answer the question every engineering leader will be asking in 18 months: is our AI coding investment actually making our code better, or just making it cheaper to produce?

Sources: SiliconANGLE, JetBrains Blog, The New Stack