The Search Everywhere dialog is one of the most important entry points in the IntelliJ Platform. To future-proof this core feature and ensure its optimal performance in remote development, we have completely rewritten the underlying architecture, and we’re introducing a brand-new API for plugin developers.

This is a critical update for anyone contributing custom results to Search Everywhere, particularly for plugins that need to support remote environments.

Why the rewrite? The challenge of remote development

The need for a new API stemmed directly from our ongoing commitment to remote development.

The original SearchEverywhereContributor extension point was designed for the traditional, monolithic (local) IDE architecture. It coupled the search result data with the UI renderer responsible for displaying that data. This tight coupling became a significant blocker for our split-architecture remote solution:

1. The backend/frontend problem: In remote development, search logic often runs on a powerful backend machine, but the results must be displayed on the lightweight frontend.
2. Serialization issue: Because SearchEverywhereContributor coupled data and presentation, it was impossible to reliably serialize third-party search results – both the data and its appearance – and safely send them across the network from the backend process to the frontend client.

To solve this, we initiated a deep rewrite of Search Everywhere to separate data and logic from UI presentation, enabling seamless and performant remote execution for all plugins.

The new API: Separation of data and UI

Frontend components

These components primarily manage the user interface and presentation logic.

• SeTab
  • An interface representing a single tab within the Search Everywhere dialog.
  • Lives on the frontend only.
• SeTabFactory
  • A factory for creating SeTab instances.
  • Serves as an extension point for adding new tab types.

Core data and logic (backend/frontend)

These components are responsible for fetching and structuring the search results.

• SeItemsProvider
  • The conceptual analog of the older SearchEverywhereContributor.
  • Can run on both the backend and frontend.
  • Returns search results that include a serializable presentation – a standardized way to describe the item’s appearance. By ensuring that the results returned by SeItemsProvider include a serializable presentation, we can transmit them over the network and reliably render the results on the client, regardless of which process generated them.
• SeItemsProviderFactory
  • A factory for creating SeItemsProvider instances.
  • Serves as an extension point for adding new result sources.

Migration and compatibility

• SeLegacyItemPresentationProvider
  • A simplified mechanism designed to help existing SearchEverywhereContributor implementations adapt quickly for remote development compatibility.

What this means for your plugin

We have implemented adapters for all existing legacy SearchEverywhereContributor implementations.

• In a monolith (local) environment: Existing plugins should continue to work almost exactly as before, with no immediate changes required.
• In a remote development environment (2025.2 onwards): The new Search Everywhere architecture is now enabled by default. Plugins supporting remote execution must either implement the new API or ensure their legacy results use a serializable presentation format that our adapters can manage. For a simpler, temporary presentation method, you can use SeLegacyItemPresentationProvider.

The path forward – Migration recommended

While the adapters provide a temporary bridge, we encourage all plugin developers to try the new API and provide feedback while it’s in the experimental phase. Once the new API has been refined based on the community’s input, we will start deprecating the old API.

Rollout plan

We are committed to a smooth transition and are rolling out the new Search Everywhere architecture gradually:

1. 2025.2: The new Search Everywhere architecture is enabled by default in remote development.
2. 2026.1 (planned): The new architecture is enabled by default in monolith environments.
3. 2026.2 (tentative): The new API is no longer experimental, and the old API is deprecated

We understand that changing a core API is a significant step, but this rewrite is essential for the future of the IntelliJ Platform and your ability to serve users in modern, remote environments.

We are excited to see the improved performance and remote capabilities this change will bring to your plugins!

The IntelliJ Platform team

The following article originally appeared on Medium and is being republished here with the author’s permission.

This post is a follow-up to a post from last week on the progress of logging. A colleague pushed back on the idea that we’d soon be running code we don’t fully understand. He was skeptical: “We’ll still be the ones writing the code, right? You can only support the code if you wrote it, right?…right?”

That’s the assumption—but it’s already slipping.

You Don’t Have to Write (or Even Read) Every Line Anymore

I gave him a simple example. I needed drag-and-drop ordering in a form. I’ve built it before, but this time I asked Cursor: “Take this React component, make the rows draggable, persist the order, and generate tests.”

It did. I ran the tests, and everything passed; I then shipped the feature without ever opening the code. Not because I couldn’t but because I didn’t have to. That doesn’t mean I always ship this way. Most of the time, I still review, but it’s becoming more common that I don’t need to.

And this isn’t malpractice or vibe coding. The trust comes from two things: I know I can debug and fix if something goes wrong, and I have enough validation to know when the output is solid. If the code works, passes tests, and delivers the feature, I don’t need to micromanage every line of code. That shift is already here—and it’s only accelerating.

Already Comfortable Ceding Control

Which brings me back to site reliability. Production systems are on the same trajectory. We’re walking into a world where the software is watching itself, anticipating failures, and quietly fixing them before a human would ever notice. Consider how Airbus advises pilots to keep the autopilot on during turbulence. Computers don’t panic or overcorrect; they ride it out smoothly. That’s what’s coming for operations—systems that absorb the bumps without asking you to grab the controls.

This shift doesn’t eliminate humans, but it does change the work. We won’t be staring at charts all day, because the essential decisions won’t be visible in dashboards. Vendors like Elastic, Grafana, and Splunk won’t vanish, but they’ll need to reinvent their value in a world where the software is diagnosing and correcting itself before alerts even fire.

And this happens faster than you think. Not because the technology matures slowly and predictably, but because the incentives are brutal: The first companies to eliminate downtime and pager duty will have an unassailable advantage, and everyone else will scramble to follow. Within a couple of years (sorry, I meant weeks), the default assumption will be that you’re building for an MCP—the standard machine control plane that consumes your logs, interprets your signals, and acts on your behalf. If you’re not writing for it, you’ll be left behind.

More Powerful Primitives (We May Not Fully Understand)

I’ll end with this. I majored in computer engineering. I know how to design an 8-bit microprocessor on FPGAs. . .in the late 1990s. Do you think I fully understand the Apple M4 chip in the laptop I’m writing on? Conceptually, yes—I understand the principles. But I don’t know everything it’s doing, instruction by instruction. And that’s fine.

We already accept that kind of abstraction all the time. As Edsger W. Dijkstra said: “The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.” Abstractions give us new building blocks—smaller, sharper units of thought—that let us stop worrying about every transistor and instead design at the level of processors, operating systems, or languages.

Code generation is about to redefine that building block again. It’s not just another abstraction layer; it’s a new “atom” for how we think about software. Once that shift takes hold, we’ll start leveling up—not because we know less but because we’ll be working with more powerful primitives.

Oversharing is one of the most pervasive governance issues in Microsoft 365, and its impact becomes significantly amplified when Copilot is introduced. Copilot does not apply judgment to determine whether access is appropriate. It simply operates within the user’s existing Microsoft 365 permissions. If a user can view a document, Copilot can summarize, interpret, or reference it as contextual data. This makes unintentional access exactly as dangerous as intentional access. Before Copilot begins interpreting content at scale, organizations must address oversharing throughout SharePoint Online and OneDrive for Business.

Oversharing is not a Microsoft 365 problem; it is a permission hygiene problem.

Years of organic collaboration, rushed sharing decisions, inherited permissions, and abandoned sites create a landscape where many users can access far more content than intended.

---

How Oversharing Directly Impacts Copilot

Copilot’s behavior is governed entirely by the user’s access rights. This means oversharing not only exposes content; it also expands what Copilot can see and process. If a broad “Everyone” permission exists on a site, Copilot can summarize that content for every user in the organization.

Oversharing introduces risk in several forms:

• Legacy “Everyone except external users” permissions
• Unrestricted link types allowing broad internal visibility
• Unmanaged SharePoint site growth without governance
• Folder-level unique permissions that accumulate over the years
• Orphaned sites without responsible owners
• Personal OneDrive files are shared far more widely than intended
• External guest access that was never revoked

From Copilot’s perspective, all of this is legitimate access.

Fixing oversharing is not about restricting AI; it is about correcting the underlying permissions Copilot relies on.

---

Map and Analyze Current Sharing Across the Tenant

Before remediation begins, you need visibility into where sharing risk exists. Discovery should be both technical and behavioral. Microsoft provides several tools that help map your current exposure.

SharePoint and OneDrive can be assessed using:

• SharePoint Admin Center: Built-in external sharing and link visibility reports
• Microsoft Purview: Access Reviews for group membership auditing
• Graph API or PowerShell: Enumeration of unique permissions, link types, and inheritance breaks
• Secure Score insights: Recommendations on anonymous links, sharing patterns, and risk posture

The objective is to create a picture of the tenant’s current sharing state. In particular, focus on:

• Sites with large visitor groups
• Sites with many unique permissions
• Files shared externally or anonymously
• OneDrive folders shared with entire departments or the entire organization
• Sites with no assigned owners
• Sites that have not been accessed for long periods

This visibility allows you to prioritize remediation based on risk and impact.

---

Remove Overshared Links and Transition to Intent-Based Access

Sharing links often results in the most significant oversharing footprint, especially in environments where users frequently collaborate across teams. When you create a sharing link in SharePoint or OneDrive, the link type determines who can access it once the link is redeemed. Copilot acts on the permissions of the user who has redeemed (clicked) the link; it does not have a separate “sharing intelligence.”

What matters is whether a user can open the content; if so, Copilot can process it. Creating a link does not automatically expose content to Copilot; it becomes visible only when a user redeems the link and gains access.

Below is a table summarizing common link types and their impact on Copilot access:

Link Types and Resulting Copilot Access

Link Type	Who Gets Access When Redeemed	Risk Level	Copilot Impact (Post-Redemption)
Anyone with the link	Anyone (authenticated or not, depending on external sharing settings) who has the URL and redeems it	Very High	Copilot may process the content if a valid M365 user opens it.
People in your organization	Any authenticated member of the tenant who redeems the link	High	Copilot may surface or summarize the file for any internal user who redeems and accesses it.
Specific people	Only the explicitly named, authenticated individuals	Very Low	Copilot can only process the content for those specific individuals who have redeemed access.
People with existing access	Only users who already had permissions — no new access granted	Low	Copilot behavior remains as before; no expansion of visibility.

Disclaimer: These link behaviors are based on Microsoft’s official documentation for SharePoint and OneDrive shareable link types and the documented requirement that content must be redeemed (i.e., the link clicked and permissions granted) before it becomes accessible. Copilot does not gain access when a link is generated; it only does so after a user legitimately redeems the link and obtains permissions. As with all permission-based features, organizations should test their configuration to verify that link redemption and permission enforcement behave as expected in their environment (2025).

Here’s how each link type translates into Copilot behavior once redeemed by a user:

• Anyone with the link
  This link requires no authentication. Once someone clicks the link, they immediately have access. If that person is an internal user who also logs into Microsoft 365 (or an external user, depending on sharing settings), Copilot will treat them as a valid user and can process any content they access via that link. Because the link is transferrable and not strictly tied to a user identity, this introduces a high risk: any recipient can redeem it, forward it, and grant Copilot access.
• People in your organization
  This link requires the user to be a member of your Microsoft 365 tenancy. Anyone in the organization who redeems the link and authenticates will be granted the access it provides. Once redeemed by a valid user, Copilot will treat the user’s permission as legitimate, meaning the file becomes part of the user’s accessible content set, potentially enabling summarization or reference by Copilot for any tenant user who obtains the link and redeems it.
• Specific people
  This link is tightly scoped: only the explicitly named, authenticated recipients can use it. When they redeem the link, they obtain access. Copilot’s visibility is then limited to the specific users’ permissions — unlike prior link types, access does not expand when the link is forwarded (to internal or external recipients). This provides the tightest control over what Copilot can see.
• People with existing access
  This is not a “grant new access” link. It simply generates a link for users who already have legitimate permissions. Because it doesn’t expand or change permissions, Copilot’s access is the same as before the link was generated.

Creating a link alone does not make content automatically visible to Copilot.

The content becomes visible only when a user redeems the link, grants permission, and then accesses it. That user’s permissions, not the mere presence of the link, govern what Copilot can do. Remediation involves replacing broad links with more controlled alternatives. In practice, this means:

• Removing “Anyone” and “People in your organization” links
• Replacing them with Specific People links
• Encouraging the use of SharePoint or Teams-backed permissions rather than file-level links
• Applying expiration policies to prevent long-term link drift

This transition ensures that Copilot inherits a much narrower, intentional access range.

---

Repair Site and Library Permissions at Scale

Oversharing frequently originates at the site or library level due to misaligned roles, unique permissions, and outdated structures. The goal is to return sites to predictable permission models.

Key tasks include:

• Restoring inheritance where it was previously broken
• Removing unnecessary unique permissions from libraries or folders
• Ensuring SharePoint groups (Owners, Members, Visitors) reflect real roles
• Replacing ad hoc access entries with Azure AD groups
• Validating site privacy settings (Private vs. Public) for Microsoft 365 Groups
• Assigning two or more site owners to maintain governance accountability

This step ensures the foundation of each site is healthy before applying AI governance.

Here is a simplified model of typical site roles:

Recommended SharePoint Role Model

Role	Intended Audience	Microsoft Permission Level (Actual)
Owners	Individuals responsible for the site	Full Control
Members	Users who contribute content	Edit
Visitors	Users who consume content	Read

Disclaimer: This role model is based on standard SharePoint Online permission levels documented by Microsoft. The described behaviors accurately reflect how permission levels govern user access and, by extension, Copilot’s visibility. Organizations using customized permission levels should validate their mappings to ensure Copilot access aligns with expected governance models.

Applying this structure universally reduces permission drift and makes Copilot’s access predictable.

---

Audit and Control OneDrive Sharing Behavior

OneDrive oversharing often goes unnoticed, yet it is one of Copilot’s most uncontrolled exposure surfaces. Users frequently store sensitive organizational documents in their personal OneDrive and share them widely for convenience.

Key remediation steps include:

• Identifying files shared using “Anyone” or “Organization-wide” links
• Limiting OneDrive external sharing at the user or tenant level
• Enforcing the sharing link expiration
• Automatically revoking old or unused sharing links
• Encouraging users to store team content in SharePoint instead of OneDrive

Because OneDrive behaves the same as SharePoint when Copilot is involved, reducing unnecessary OneDrive sharing significantly reduces unintended AI access.

---

Establish Governance Controls to Prevent Oversharing in the Future

Oversharing will return if not prevented by ongoing governance policies. After cleanup, long-term protection requires enforceable rules across collaboration, permissioning, and sharing.

Key governance controls include:

• Setting SharePoint and OneDrive default link types to Specific People
• Enforcing expiration dates for external shares
• Using Access Reviews to validate group membership regularly
• Applying Sensitivity Labels to SharePoint sites to enforce access boundaries
• Implementing Information Barriers where regulated separation is required
• Defining a standardized site provisioning model to prevent ownerless or misconfigured sites

Good governance creates a predictable access surface, which is essential for predictable AI behavior.

---

Validate Copilot Access After Remediation

Final validation ensures that your cleanup work is effective and that Copilot cannot access content that should now be restricted. Validation should be performed by both IT administrators and test users from different roles.

Recommended validation steps:

• Ask Copilot to summarize documents that were previously overshared
• Attempt to retrieve content across departments to validate new boundaries
• Confirm Copilot cannot reference content from removed or restricted locations
• Verify that Sensitivity Labels applied at the site level enforce expected access rules
• Validate that OneDrive files no longer appear where they should not

If Copilot still surfaces previously overshared content, additional remediation is required.

---

Closing Thoughts

Fixing oversharing in SharePoint and OneDrive is one of the most important steps in preparing your environment for Copilot. Copilot accelerates access; it does not validate whether that access is intentional. By reducing broad access links, correcting permission drift, enforcing least-privilege models, and applying governance controls, you create a secure environment where Copilot behaves predictably and safely.

Organizations that complete this step properly see a dramatic reduction in unintended data exposure risk once AI is enabled. Copilot becomes a trusted assistant, not a permission amplifier. In the next article, we will build on this foundation by addressing “Strengthen Conditional Access and Session Controls for Copilot Access“, where identity-driven protections become your next enforcement layer.

Running TeamCity in Kubernetes has always been possible, but it often required knowing your way around both systems pretty well.

TeamCity is flexible and easy to tune, and Kubernetes provides excellent tools for running applications at scale. However, bringing the two together smoothly wasn’t always straightforward.

The new TeamCity Operator is designed to change that. It uses custom resources to automate the management of your TeamCity server life cycle. For example, it allows you to automatically deploy new servers and perform zero-downtime upgrades (see the Kubernetes documentation for more details).

Although the TeamCity Operator was originally designed to support internal use cases, interest from users running sizable Kubernetes-based installations encouraged us to make it open source. It’s now publicly available and ready for you to explore.

Why an operator?

The most common way to deploy applications to Kubernetes is through Helm charts. Helm works well for many services, but it has limitations when it comes to applications that require orchestrated, stateful operations, such as controlled upgrades, multi-node setups, or zero-downtime updates.

TeamCity fits squarely into this category. Its life cycle is complex and nuanced. Updates require sequencing, certain states must be preserved, and there are moments when two versions must temporarily coexist.

TeamCity Operator	TeamCity Helm charts
Go application	Collection of templated YAML files
Single object that controls everything needed for TeamCity	No control over the life cycle
Minimal need to think about dependencies in Kubernetes	Updateable fields in objects only

Kubernetes operators exist precisely for these cases. An operator is an application that runs inside a cluster and encodes expert knowledge about how to deploy, upgrade, and maintain a particular system. Instead of asking you to understand every nuance of TeamCity’s Kubernetes behavior, the TeamCity Operator takes on that work.

How it works

The TeamCity Operator introduces a new Kubernetes custom resource that represents a TeamCity installation. When you apply it to the cluster, the TeamCity Operator inspects this object and turns it into a fully configured, running TeamCity instance.

In practice, this means the TeamCity Operator:

• Creates and configures the necessary StatefulSets.
• Ensures the startup and shutdown sequences are executed correctly.
• Applies changes to the TeamCity installation based on updates to the custom resource specification.
• Manages upgrades, including optional zero-downtime ones.
• Coordinates the main and secondary nodes in multi-node setups.

The TeamCity Operator continuously watches the Kubernetes API for changes. When you update the TeamCity custom resource spec (for example, by changing the version or resource settings), the TeamCity Operator reconciles the actual state with the desired one.

In other words, you declare what TeamCity should look like, and the TeamCity Operator makes your vision a reality.

Example: Deploying a TeamCity main node with an external database

To give you a concrete idea of how the TeamCity Operator is used in practice, here is an example of deploying a standalone TeamCity main node that connects to an external database.

This example demonstrates how database configuration is passed via a Kubernetes Secret and how the TeamCity custom resource defines the main node, resources, and storage.

apiVersion: v1
data:
  connectionProperties.password: DB_PASSWORD
  connectionProperties.user: DB_USER
  connectionUrl: DB_CONNECTION_STRING # format jdbc:mysql://DB_HOST:DB_PORT/SCHEMA_NAME
kind: Secret
metadata:
  name: database-properties
---
apiVersion: jetbrains.com/v1beta1
kind: TeamCity
metadata:
  name: teamcity-with-database
  namespace: default
  finalizers:
    - "teamcity.jetbrains.com/finalizer"
spec:
  image: jetbrains/teamcity-server
  databaseSecret:
    secret: database-properties
  mainNode:
    name: main-node
    spec:
      env:
        AWS_DEFAULT_REGION: "eu-west-1"
      requests:
        cpu: "900m"
        memory: "1512Mi"
  dataDirVolumeClaim:
    name: teamcity-data-dir
    volumeMount:
      name: teamcity-data-dir
      mountPath: /storage
    spec:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 1Gi

Built-in life cycle management

We’ve spent years refining the life cycle of a TeamCity server (startup, updates, and clean shutdown) for TeamCity Cloud. The new operator brings these practices to self-hosted users.

For upgrades, the TeamCity Operator can perform a quick update with downtime or run an orchestrated, zero-downtime upgrade process, keeping at least one TeamCity node available while switching versions behind the scenes

These workflows go far beyond what a Helm chart can reliably encode.

Configuration as code with the TeamCity Operator, Terraform, and the Kotlin DSL

The TeamCity Operator is focused on life cycle and cluster-level configuration. It gives you a running TeamCity instance but intentionally leaves higher-level configuration to other tools.

You can combine it with:

• The Terraform Provider for TeamCity for managing server-level settings, cleanup rules, VCS roots, project templates, and other global configuration elements.
• The Kotlin DSL or YAML for per-project build configurations.

Together, these create a complete and consistent code-driven setup:

• The TeamCity Operator installs, scales, upgrades, and tears down TeamCity.
• Terraform configures global server behavior.
• The Kotlin DSL or YAML defines the builds themselves.

This allows you to manage every part of TeamCity with code and keep the configuration fully version-controlled.

Why use the TeamCity Operator?

To put it simply, the TeamCity Operator offers a hassle-free way to run TeamCity in Kubernetes.

It gives you:

• A minimal starting manifest for quick setups.
• An extended manifest for more advanced installations.
• An automated life cycle that reduces the risk of misconfiguration.
• Consistent behavior across environments.
• A path toward a fully code-driven, reproducible CI/CD infrastructure.

If you’re running TeamCity as part of your CI/CD setup (especially in a Kubernetes-heavy environment), the TeamCity Operator helps take some of the pressure off. It reduces your day-to-day workload and makes long-term maintenance much easier.

What’s next

We’re preparing official documentation to accompany the TeamCity Operator. In the meantime, you can explore the GitHub repository, which includes solid documentation in the README.

For now, the GitHub repository includes examples and technical notes, and we’ll expand them over time. We also plan to publish migration guides and usage examples, particularly around combining the TeamCity Operator with Terraform and the Kotlin DSL.

You’ll also see the TeamCity Operator featured at industry events such as KubeCon, where our engineers will be available to give a walk-through of the design and answer questions.

👉 Check out the GitHub repository 👈

The tools are available to everyone. The subscription is company-wide. The training sessions have been held. And yet, in offices from Wall Street to Silicon Valley, a stark divide is opening between workers who have woven artificial intelligence into the fabric of their daily work and colleagues who have barely touched it.

The gap is not small. According to a new report from OpenAI analyzing usage patterns across its more than one million business customers, workers at the 95th percentile of AI adoption are sending six times as many messages to ChatGPT as the median employee at the same companies. For specific tasks, the divide is even more dramatic: frontier workers send 17 times as many coding-related messages as their typical peers, and among data analysts, the heaviest users engage the data analysis tool 16 times more frequently than the median.

This is not a story about access. It is a story about a new form of workplace stratification emerging in real time — one that may be reshaping who gets ahead, who falls behind, and what it means to be a skilled worker in the age of artificial intelligence.

Everyone has the same tools, but not everyone is using them

Perhaps the most striking finding in the OpenAI report is how little access explains. ChatGPT Enterprise is now deployed across more than 7 million workplace seats globally, a nine-fold increase from a year ago. The tools are the same for everyone. The capabilities are identical. And yet usage varies by orders of magnitude.

Among monthly active users — people who have logged in at least once in the past 30 days — 19 percent have never tried the data analysis feature. Fourteen percent have never used reasoning capabilities. Twelve percent have never used search. These are not obscure features buried in submenus; they are core functionality that OpenAI highlights as transformative for knowledge work.

The pattern inverts among daily users. Only 3 percent of people who use ChatGPT every day have never tried data analysis; just 1 percent have skipped reasoning or search. The implication is clear: the divide is not between those who have access and those who don't, but between those who have made AI a daily habit and those for whom it remains an occasional novelty.

Employees who experiment more are saving dramatically more time

The OpenAI report suggests that AI productivity gains are not evenly distributed across all users but concentrated among those who use the technology most intensively. Workers who engage across approximately seven distinct task types — data analysis, coding, image generation, translation, writing, and others — report saving five times as much time as those who use only four. Employees who save more than 10 hours per week consume eight times more AI credits than those who report no time savings at all.

This creates a compounding dynamic. Workers who experiment broadly discover more uses. More uses lead to greater productivity gains. Greater productivity gains presumably lead to better performance reviews, more interesting assignments, and faster advancement—which in turn provides more opportunity and incentive to deepen AI usage further.

Seventy-five percent of surveyed workers report being able to complete tasks they previously could not perform, including programming support, spreadsheet automation, and technical troubleshooting. For workers who have embraced these capabilities, the boundaries of their roles are expanding. For those who have not, the boundaries may be contracting by comparison.

The corporate AI paradox: $40 billion spent, 95 percent seeing no return

The individual usage gap documented by OpenAI mirrors a broader pattern identified by a separate study from MIT's Project NANDA. Despite $30 billion to $40 billion invested in generative AI initiatives, only 5 percent of organizations are seeing transformative returns. The researchers call this the "GenAI Divide" — a gap separating the few organizations that succeed in transforming processes with adaptive AI systems from the majority that remain stuck in pilots.

The MIT report found limited disruption across industries: only two of nine major sectors—technology and media—show material business transformation from generative AI use. Large firms lead in pilot volume but lag in successful deployment.

The pattern is consistent across both studies. Organizations and individuals are buying the technology. They are launching pilots. They are attending training sessions. But somewhere between adoption and transformation, most are getting stuck.

While official AI projects stall, a shadow economy is thriving

The MIT study reveals a striking disconnect: while only 40 percent of companies have purchased official LLM subscriptions, employees in over 90 percent of companies regularly use personal AI tools for work. Nearly every respondent reported using LLMs in some form as part of their regular workflow.

"This 'shadow AI' often delivers better ROI than formal initiatives and reveals what actually works for bridging the divide," MIT's Project NANDA found.

The shadow economy offers a clue to what's happening at the individual level within organizations. Employees who take initiative — who sign up for personal subscriptions, who experiment on their own time, who figure out how to integrate AI into their workflows without waiting for IT approval — are pulling ahead of colleagues who wait for official guidance that may never come.

These shadow systems, largely unsanctioned, often deliver better performance and faster adoption than corporate tools. Worker sentiment reveals a preference for flexible, responsive tools — precisely the kind of experimentation that separates OpenAI's frontier workers from the median.

The biggest gaps show up in technical work that used to require specialists

The largest relative gaps between frontier and median workers appear in coding, writing, and analysis — precisely the task categories where AI capabilities have advanced most rapidly. Frontier workers are not just doing the same work faster; they appear to be doing different work entirely, expanding into technical domains that were previously inaccessible to them.

Among ChatGPT Enterprise users outside of engineering, IT, and research, coding-related messages have grown 36 percent over the past six months. Someone in marketing or HR who learns to write scripts and automate workflows is becoming a categorically different employee than a peer who has not — even if they hold the same title and started with the same skills.

The academic research on AI and productivity offers a complicated picture. Several studies cited in the OpenAI report find that AI has an "equalizing effect," disproportionately helping lower-performing workers close the gap with their higher-performing peers. But the equalizing effect may apply only within the population of workers who actually use AI regularly. A meaningful share of workers are not in that group at all. They remain light users or non-users, even as their more adventurous colleagues pull away.

Companies are divided too, and the gap is widening by the month

The divide is not only between individual workers. It exists between entire organizations.

Frontier firms — those at the 95th percentile of adoption intensity — generate approximately twice as many AI messages per employee as the median enterprise. For messages routed through custom GPTs, purpose-built tools that automate specific workflows, the gap widens to seven-fold.

These numbers suggest fundamentally different operating models. At median companies, AI may be a productivity tool that individual workers use at their discretion. At frontier firms, AI appears to be embedded in core infrastructure: standardized workflows, persistent custom tools, systematic integration with internal data systems.

The OpenAI report notes that roughly one in four enterprises still has not enabled connectors that give AI access to company data—a basic step that dramatically increases the technology's utility. The MIT study found that companies that purchased AI tools from specialized vendors succeeded 67 percent of the time, while internal builds had only a one-in-three success rate. For many organizations, the AI era has technically arrived but has not yet begun in practice.

The technology is no longer the problem — organizations are

For executives, the data presents an uncomfortable challenge. The technology is no longer the constraint. OpenAI notes that it releases a new feature or capability roughly every three days; the models are advancing faster than most organizations can absorb. The bottleneck has shifted from what AI can do to whether organizations are structured to take advantage of it.

"The dividing line isn't intelligence," the MIT authors write. The problems with enterprise AI have to do with memory, adaptability, and learning capability. Problems stem less from regulations or model performance, and more from tools that fail to learn or adapt.

Leading firms, according to the OpenAI report, consistently invest in executive sponsorship, data readiness, workflow standardization, and deliberate change management. They build cultures where custom AI tools are created, shared, and refined across teams. They track performance and run evaluations. They make AI adoption a strategic priority rather than an individual choice.

The rest are leaving it to chance — hoping that workers will discover the tools on their own, experiment on their own time, and somehow propagate best practices without infrastructure or incentive. The six-fold gap suggests this approach is not working.

The window to catch up is closing faster than most companies realize

With enterprise contracts locking in over the next 18 months, there's a shrinking window for vendors and adopters to cross the divide.The GenAI Divide identified by the MIT report is not going to last forever. But the organizations that figure out a way across it soonest will be the ones that define the next era of business.

Both reports carry caveats. The OpenAI data comes from a company with an obvious interest in promoting AI adoption. The productivity figures are self-reported by customers already paying for the product. The MIT study, while independent, relies on interviews and surveys rather than direct measurement. The long-term effects of this technology on employment, wages, and workplace dynamics remain uncertain.

But the core finding — that access alone does not produce adoption, and that adoption varies enormously even within organizations that have made identical tools available to all — is consistent with how previous technologies have diffused through the economy. Spreadsheets, email, and the internet all created similar divides before eventually becoming universal. The question is how long the current gap persists, who benefits during the transition, and what happens to workers who find themselves on the wrong side of it.

For now, the divide is stark. Ninety percent of users said they prefer humans for "mission-critical work," while AI has "won the war for simple work." The workers who are pulling ahead are not doing so because they have access their colleagues lack. They are pulling ahead because they decided to use what everyone already has—and kept using it until they figured out what it could do.

The 6x gap is not about technology. It is about behavior. And behavior, unlike software, cannot be deployed with a company-wide rollout.