Model Context Protocol (MCP), the emerging standard for connecting AI models to external tools and enterprise data, is undergoing its biggest architectural overhaul yet.

The latest release candidate, scheduled for release on July 28, removes protocol-level sessions in favor of a stateless architecture, a change which industry experts say is intended to make MCP easier to deploy across standard cloud infrastructure as enterprises move AI pilots into production.

“The session-based model made sense when MCP servers were local processes on a developer’s laptop. In production, it became an operational tax,” said Muskan Bandta, cloud associate at ZopDev.

“When your infrastructure team asks whether MCP services can scale like other cloud applications, the answer used to be ‘not quite.’ With the move to a stateless architecture, the answer is now yes,” Bandta added.

Earlier versions of the protocol maintained information about every client connection, meaning servers had to keep track of each session throughout an interaction. While that approach worked well for local development, it complicated deployments across multiple servers because requests often had to be routed back to the same machine, limiting scalability and making MCP a less natural fit for modern cloud architectures.

“Under the new stateless design, every request contains the information needed for any available server to process it independently. Applications that need to maintain context across multiple requests can still do so, but developers must now manage that state explicitly rather than relying on the protocol itself,” she said.

This transition to a stateless design goes beyond simplifying infrastructure by fundamentally changing how AI applications manage and share context across tools, according to Amit Jena, AI development manager at IT consulting firm Kanerika.

Instead of keeping application state hidden inside protocol sessions, the new design makes it explicit, allowing AI models to access, reason over, and pass that information between tools, giving developers greater control over how context is preserved and shared across tools, Jena said.

It should also make AI workflows more portable, resilient, and easier to orchestrate across distributed environments, he said.

MCP’s new features

Other changes to MCP include the addition of a Multi Round-Trip Requests (MRTR) mechanism that changes how AI agents request additional information they need to complete a task.

Instead of relying on a persistent connection between the client and server throughout the interaction, the new mechanism lets the server request additional input through a standard request-response exchange before continuing the task, Jena said.

Routable transport headers, another addition, enable API gateways and other networking infrastructure to identify and route MCP requests without inspecting their contents.

They reduce processing overhead, lower latency, and let enterprise teams enforce routing, rate-limiting and security policies more efficiently using existing API management infrastructure, Jena said.

MCP is also getting an updated authorization framework built around OAuth 2.1 and OpenID Connect; interactive MCP Apps; and deterministic caching of tool and resource listings to improve LLM prompt-cache hit rates, potentially saving on token costs.

Rebuilding the trust boundary

The MCP release steering committee also decided to deprecate some legacy features, including Roots, Sampling, Logging, the older HTTP+SSE transport and Dynamic Client Registration, although these will continue to work in this version and any other released over the next year.

The deprecation of Sampling is likely to have the biggest impact because it changes who is responsible for interacting with foundation models, said Jena.

“Sampling let MCP servers invoke the LLM through the client, which meant the server had a callback path into the model without owning that connection. Deprecating it means rebuilding that trust boundary,” Jena said. “Your server now calls the model provider directly. That changes your network architecture, your auth model, and depending on how you’ve built cost attribution, your billing flow.”

The year-long transition period will be enough for teams to audit their sampling dependencies now, said Jena: “The risk is that teams who haven’t implemented sampling themselves won’t know if a third-party MCP server they’re depending on uses it.”

Updated MCP SDKs

To accompany the protocol update, there are updated MCP SDKs for Python, Typescript, Go, and C#. These support both the old and new protocol versions, so new clients can continue communicating with older servers, while updated servers will also support older clients, reducing the risk of immediate disruptions.

That backward compatibility should make the transition largely incremental, except for enterprises that built custom infrastructure around MCP’s earlier session-based architecture, Bandta said.

Identifying and auditing those session dependencies may not be easy, Jena warned.

“Session management complexity tends to be hidden across multiple layers — the gateway config, the deployment scripts, the monitoring dashboards. The code change is small; finding everywhere the assumption lives is what takes time,” he said.

This article first appeared on InfoWorld.

Model Context Protocol (MCP), the emerging standard for connecting AI models to external tools and enterprise data, is undergoing its biggest architectural overhaul yet.

The latest release candidate, scheduled for release on July 28, removes protocol-level sessions in favor of a stateless architecture, a change which industry experts say is intended to make MCP easier to deploy across standard cloud infrastructure as enterprises move AI pilots into production.

“The session-based model made sense when MCP servers were local processes on a developer’s laptop. In production, it became an operational tax,” said Muskan Bandta, cloud associate at ZopDev.

“When your infrastructure team asks whether MCP services can scale like other cloud applications, the answer used to be ‘not quite.’ With the move to a stateless architecture, the answer is now yes,” Bandta added.

Earlier versions of the protocol maintained information about every client connection, meaning servers had to keep track of each session throughout an interaction. While that approach worked well for local development, it complicated deployments across multiple servers because requests often had to be routed back to the same machine, limiting scalability and making MCP a less natural fit for modern cloud architectures.

“Under the new stateless design, every request contains the information needed for any available server to process it independently. Applications that need to maintain context across multiple requests can still do so, but developers must now manage that state explicitly rather than relying on the protocol itself,” she said.

This transition to a stateless design goes beyond simplifying infrastructure by fundamentally changing how AI applications manage and share context across tools, according to Amit Jena, AI development manager at IT consulting firm Kanerika.

Instead of keeping application state hidden inside protocol sessions, the new design makes it explicit, allowing AI models to access, reason over, and pass that information between tools, giving developers greater control over how context is preserved and shared across tools, Jena said.

It should also make AI workflows more portable, resilient, and easier to orchestrate across distributed environments, he said.

MCP’s new features

Other changes to MCP include the addition of a Multi Round-Trip Requests (MRTR) mechanism that changes how AI agents request additional information they need to complete a task.

Instead of relying on a persistent connection between the client and server throughout the interaction, the new mechanism lets the server request additional input through a standard request-response exchange before continuing the task, Jena said.

Routable transport headers, another addition, enable API gateways and other networking infrastructure to identify and route MCP requests without inspecting their contents.

They reduce processing overhead, lower latency, and let enterprise teams enforce routing, rate-limiting and security policies more efficiently using existing API management infrastructure, Jena said.

MCP is also getting an updated authorization framework built around OAuth 2.1 and OpenID Connect; interactive MCP Apps; and deterministic caching of tool and resource listings to improve LLM prompt-cache hit rates, potentially saving on token costs.

Rebuilding the trust boundary

The MCP release steering committee also decided to deprecate some legacy features, including Roots, Sampling, Logging, the older HTTP+SSE transport and Dynamic Client Registration, although these will continue to work in this version and any other released over the next year.

The deprecation of Sampling is likely to have the biggest impact because it changes who is responsible for interacting with foundation models, said Jena.

“Sampling let MCP servers invoke the LLM through the client, which meant the server had a callback path into the model without owning that connection. Deprecating it means rebuilding that trust boundary,” Jena said. “Your server now calls the model provider directly. That changes your network architecture, your auth model, and depending on how you’ve built cost attribution, your billing flow.”

The year-long transition period will be enough for teams to audit their sampling dependencies now, said Jena: “The risk is that teams who haven’t implemented sampling themselves won’t know if a third-party MCP server they’re depending on uses it.”

Updated MCP SDKs

To accompany the protocol update, there are updated MCP SDKs for Python, Typescript, Go, and C#. These support both the old and new protocol versions, so new clients can continue communicating with older servers, while updated servers will also support older clients, reducing the risk of immediate disruptions.

That backward compatibility should make the transition largely incremental, except for enterprises that built custom infrastructure around MCP’s earlier session-based architecture, Bandta said.

Identifying and auditing those session dependencies may not be easy, Jena warned.

“Session management complexity tends to be hidden across multiple layers — the gateway config, the deployment scripts, the monitoring dashboards. The code change is small; finding everywhere the assumption lives is what takes time,” he said.

Model Context Protocol (MCP), the emerging standard for connecting AI models to external tools and enterprise data, is undergoing its biggest architectural overhaul yet.

The latest release candidate, scheduled for release on July 28, removes protocol-level sessions in favor of a stateless architecture, a change which industry experts say is intended to make MCP easier to deploy across standard cloud infrastructure as enterprises move AI pilots into production.

“The session-based model made sense when MCP servers were local processes on a developer’s laptop. In production, it became an operational tax,” said Muskan Bandta, cloud associate at ZopDev.

“When your infrastructure team asks whether MCP services can scale like other cloud applications, the answer used to be ‘not quite.’ With the move to a stateless architecture, the answer is now yes,” Bandta added.

Earlier versions of the protocol maintained information about every client connection, meaning servers had to keep track of each session throughout an interaction. While that approach worked well for local development, it complicated deployments across multiple servers because requests often had to be routed back to the same machine, limiting scalability and making MCP a less natural fit for modern cloud architectures.

“Under the new stateless design, every request contains the information needed for any available server to process it independently. Applications that need to maintain context across multiple requests can still do so, but developers must now manage that state explicitly rather than relying on the protocol itself,” she said.

This transition to a stateless design goes beyond simplifying infrastructure by fundamentally changing how AI applications manage and share context across tools, according to Amit Jena, AI development manager at IT consulting firm Kanerika.

Instead of keeping application state hidden inside protocol sessions, the new design makes it explicit, allowing AI models to access, reason over, and pass that information between tools, giving developers greater control over how context is preserved and shared across tools, Jena said.

It should also make AI workflows more portable, resilient, and easier to orchestrate across distributed environments, he said.

MCP’s new features

Other changes to MCP include the addition of a Multi Round-Trip Requests (MRTR) mechanism that changes how AI agents request additional information they need to complete a task.

Instead of relying on a persistent connection between the client and server throughout the interaction, the new mechanism lets the server request additional input through a standard request-response exchange before continuing the task, Jena said.

Routable transport headers, another addition, enable API gateways and other networking infrastructure to identify and route MCP requests without inspecting their contents.

They reduce processing overhead, lower latency, and let enterprise teams enforce routing, rate-limiting and security policies more efficiently using existing API management infrastructure, Jena said.

MCP is also getting an updated authorization framework built around OAuth 2.1 and OpenID Connect; interactive MCP Apps; and deterministic caching of tool and resource listings to improve LLM prompt-cache hit rates, potentially saving on token costs.

Rebuilding the trust boundary

The MCP release steering committee also decided to deprecate some legacy features, including Roots, Sampling, Logging, the older HTTP+SSE transport and Dynamic Client Registration, although these will continue to work in this version and any other released over the next year.

The deprecation of Sampling is likely to have the biggest impact because it changes who is responsible for interacting with foundation models, said Jena.

“Sampling let MCP servers invoke the LLM through the client, which meant the server had a callback path into the model without owning that connection. Deprecating it means rebuilding that trust boundary,” Jena said. “Your server now calls the model provider directly. That changes your network architecture, your auth model, and depending on how you’ve built cost attribution, your billing flow.”

The year-long transition period will be enough for teams to audit their sampling dependencies now, said Jena: “The risk is that teams who haven’t implemented sampling themselves won’t know if a third-party MCP server they’re depending on uses it.”

Updated MCP SDKs

To accompany the protocol update, there are updated MCP SDKs for Python, Typescript, Go, and C#. These support both the old and new protocol versions, so new clients can continue communicating with older servers, while updated servers will also support older clients, reducing the risk of immediate disruptions.

That backward compatibility should make the transition largely incremental, except for enterprises that built custom infrastructure around MCP’s earlier session-based architecture, Bandta said.

Identifying and auditing those session dependencies may not be easy, Jena warned.

“Session management complexity tends to be hidden across multiple layers — the gateway config, the deployment scripts, the monitoring dashboards. The code change is small; finding everywhere the assumption lives is what takes time,” he said.

This article first appeared on InfoWorld.

G# (GSharp) is moving forward as a programming language for Microsoft’s .NET platform, touted as bringing Go-, Kotlin-, and Swift-style ergonomics to the CLR (Common Language Runtime). The language is described by its creators as modern, simple, and accessible.

Although pre-1.0 and still growing, G# aims to be for people who want a small, predictable language with direct access to the .NET ecosystem. Developers will see imports, func, structs, slices, maps, channels, go, select, and for in iteration. Also important are nullable flow, direct calls into the CLR (Common Language Runtime), and built-in concurrency.

With G#, copyrighted in 2026, developers get value-oriented structs, reference-oriented classes, data structs, and data classes. For concurrency, G# uses scope for structured concurrency, async func and await for task-based asynchrony, and async sequence[T] for asynchronous streams. G# also makes use of the same Task and Task[T] types familiar from the .NET BCL (Base Class Library).

G# documentation is available on the GitHub site of Microsoft software engineer David Obando. “Every .NET type—your packages, third-party NuGet packages, the BCL—is callable from G# with the syntax you already know. CLR generics use G#’s bracket spelling, and method calls, properties, indexers, and for in over IEnumerable[T] all just work,” according to the website.

A Visual Studio Code extension for G3 can be found at marketplace.visualstudio.com. The extension adds syntax highlighting, language server features, build/run commands, and debugger configuration for .gs and .gsproj files. Developers can install the extension from within VS Code (search for “G#” in the Extensions view) or from the command line.

GitLab has released GitLab 19.2, an update to the company’s devsecops platform that allows teams to fix vulnerable dependencies automatically, use Security Review Flow to catch logic flaws that scanners miss, and run AI agents straight from the terminal, the company said.

Highlights in GitLab 19.2 include the following:

• Dependency Scanning Auto-Remediation, in public beta, uses AI to fix build-breaking changes and iterates until your pipeline passes, with every change governed by your existing gates and audit trail.
• Security Review Flow, also in public beta, analyzes code changes as a security engineer would and catches authorization gaps, business-logic errors, and race conditions that static scanners structurally cannot see.
• GitLab Duo CLI, now generally available, gives developers access to agents and multi-step agentic flows for all software life cycle tasks without leaving the terminal. 
• Custom Flows, now generally available, let teams replace manual multi-step workflows with agentic automations for software development, triggered by GitLab events.

“Coding agents made it possible to generate far more code and moved the bottleneck downstream to reviews and security,” said Manav Khurana, chief product and marketing officer at GitLab, in a statement. “GitLab 19.2 puts agents to work on that bottleneck: fixing vulnerable dependencies, catching the flaws scanners miss, and automating the steps in between with a person still approving what ships.”

Microsoft and Mistral are betting that the future of enterprise AI is in sovereign infrastructure and model choice, rather than with one locked-in system. 

The companies have announced a “significant expansion” of their strategic partnership, which includes a multibillion dollar commitment from Microsoft. Mistral will add to its GPU infrastructure in Europe and extend access to its frontier multilingual models, while Microsoft will expand its sovereign cloud capabilities. The companies will also align on a joint go-to-market plan and will pursue enterprise opportunities together across Europe and globally, as well as funding proofs of concept (PoCs), offering Azure credits, and leading workshops to drive AI innovation with customers.

The partnership between the tech giant and the three-year-old French startup might seem an odd combination at first glance, analysts note, as both develop enterprise AI models and offer access as-a-service. But it reflects changing AI market dynamics.

“It’s possible to be both a competitor and a partner at the same time,” noted technology analyst Carmi Levy. Large cloud providers are becoming AI marketplaces in their own right, he pointed out, and are drifting away from exclusively promoting their own models. Building Mistral support into their infrastructure avoids platform lock-in and removes a “key objection for customers looking for options.”

“As much as Microsoft would want everybody standardizing on Copilot and Phi, it recognizes the simple fact that customers increasingly want to choose their own models,” said Levy.

Expands model access, sovereign cloud capabilities

As part of the agreement, Mistral will expand its Europe-based capacity with thousands of Nvidia Vera Rubin GPUs.

Mistral CEO and co-founder Arthur Mensch described a “slight gap” in compute capacity in Europe, noting that this expansion will provide more compute capability and support Microsoft’s cloud and AI services, providing a “shared platform for training, inference and large-scale deployment.” The companies call it a critical step to allow Microsoft customers to benefit from Mistral’s “scientific and compute innovations.”

In addition, Mistral Medium 3.5 and OCR 4 models are now available in Microsoft Foundry, and Mistral Medium 3.5 can be used in Microsoft Copilot Studio.

The partnership also extends Microsoft’s sovereign cloud infrastructure as well as combining Mistral’s frontier models with Microsoft’s security, compliance, and cloud-to-edge platform. This gives enterprises, particularly those in regulated markets, the ability to deploy AI where they see fit, while maintaining control over their data and workloads, according to the companies.

Further, customers will be able to build AI using the same models, tools, APIs, and workflows they’re used to, across Microsoft Foundry, Foundry Local, and Azure Local, and opt for fully Azure-hosted cloud environments; cloud-connected, controlled Azure Local environments that only use cloud-based Azure when necessary; and fully-disconnected environments that can operate independently for more sensitive scenarios.

“Europe should have access to the world’s most capable AI without compromising control over their data, operations or digital future,” said Brad Smith, vice chair and president, Microsoft, noting that with this partnership, the company is honoring its European digital commitments and giving customers a foundation for AI so they can “operate on their own terms.” Customers with “heightened sovereignty needs” will be able to exercise more control with “resilience and assurance” and continued access to Mistral’s open-weight models.

Enterprise credibility

Gartner distinguished VP analyst Arun Chandrasekaran noted that there’s no doubt that this agreement strengthens Microsoft’s sovereignty messaging and its position in regulated industries, and the tech giant benefits by expanding its AI portfolio with a “credible European frontier model provider”

He pointed to key differences from the initial partnership struck by the two companies in 2024; whereas originally Microsoft was hosting Mistral’s models, it is now consuming capacity built by Mistral in Europe.

Ultimately, the deal emphasizes European data centers, customer-controlled deployments, Azure Local, and fully-disconnected environments, addressing many of the concerns that surrounded the original Azure cloud only relationship, Chandrasekaran explained.

For Mistral, the partnership provides “enterprise credibility, and repeatable infrastructure revenue” that can fund continued AI platform development, he said. The combination of Microsoft’s enterprise AI platform with Mistral’s models and European AI infrastructure will give joint customers more deployment flexibility and expand options around data residency, sovereign AI deployments, and disconnected/on-premises environments.

“It also gives customers more model choice, reducing dependence on a single AI provider,” said Chandrasekaran.

A complementary partnership

Mistral continues to innovate with its frontier AI models and its chat and coding agent, Vibe (formerly Le Chat), yet it doesn’t attract as much attention as Claude or ChatGPT.

One of the company’s key differentiators is its targeted business model. Levy pointed out that not every workload requires “full-flight GPT.” For customers trying to rein in costs and limit exposure with on-premises deployments, Mistral’s “more focused capabilities can represent a cost-effective alternative.”

Chandrasekaran pointed to Mistral’s combination of high-performance open-weight models, strong multilingual capabilities, and a “focus on efficient inference that lowers deployment costs.”

Unlike many frontier AI companies, it offers customers greater flexibility to self-host and customize models; this makes it particularly attractive for enterprises and governments with sovereignty or regulatory requirements, he said. Its European roots also position it as the leading alternative for organizations seeking cutting-edge AI outside the US and Chinese ecosystems.

Bill Wong, research fellow at Info-Tech Research Group, also pointed to Mistral’s high-quality models and “adeptness as a sovereign AI leader.” There is growing demand for AI companies that comply with regional laws and data residency, and Mistral is established as “one of the most prominent European players.”

“Such a strategic position makes it a great partner for Microsoft to further expand its AI offerings beyond just being a single-model provider,” he said. Customers get freedom of choice while complying with data sovereignty and regulatory limitations without having to execute a separate AI deployment, while Mistral, for its part, can go beyond Europe and gain more visibility with international businesses.

Mistral brings both “technological and political advantages,” Levy noted. The startup’s European roots give Microsoft more credibility “at a fraught time for geopolitical relationships.” Customers in Europe and beyond are concerned about US exposure, and Mistral can provide a safer choice.

Meanwhile, Microsoft can deploy European-developed AI models running on European infrastructure, thus maximizing regulatory compliance while offering next-level enterprise marketing scale that Mistral “simply couldn’t achieve on its own,” said Levy. Mistral-based workloads deployed on Azure will also benefit from Microsoft’s “comprehensive security certifications, governance frameworks, and monitoring.”

Bottom line: Both companies can maximize their unique roadmaps through the partnership, he said. “As the rules of the AI economy continue to evolve, expect more eyebrow-raising deals like this to be signed.”

AWS has updated AWS Data Exports, its service for generating and managing cost and usage Reports (CURs), to include standardized Amazon Bedrock product metadata, making it easier for enterprise engineering teams to analyze AI usage and spending as they scale AI deployments spanning multiple foundation models.

The update extends billing exports with normalized fields for model provider, model name, inference type, inference mode, billing unit and Bedrock product family, and will enable enterprises to identify which models generated costs and compare spending across providers without relying on custom parsing or normalization of billing records, AWS wrote in a blog post.

That reduced reliance on custom parsing will reduce the engineering effort required to analyze billing data, analysts said.

“Before the update, a data engineer would typically need to maintain a model ID registry, write regex against usage type strings, or join AWS CloudTrail with CUR to figure out which provider generated which cost,” said Bhupendra Chopra, chief revenue officer at IT consulting firm Kanerika.

The new standardized fields “can be the difference between a billing pipeline that needs constant babysitting and one that doesn’t,” Chopra added.

That’s because custom parsing logic is more prone to break down or require maintenance when AWS adds new models or updates pricing in Bedrock, said Pareekh Jain, principal analyst at Pareekh Consulting.

Richer billing data to boost enterprise AI cost governance

Beyond reducing engineering overhead, the update could also help enterprises improve AI cost governance.

Before this update FinOps teams struggled to identify which model Bedrock related to because usage type fields were inconsistent, and there was no unified product family name that captured all Bedrock costs in one place, Chopra said.

“Now those attributes — model provider, model name, inference type, inference mode, pricing unit — are standardized and available by default. That’s the plumbing work no one talks about, but it’s what makes downstream reporting actually reliable,” Chopra added.

This, said Jain, makes it easier to build dashboards showing cost by model, provider, token type or inference mode while also identifying expensive workloads, unusual token growth and opportunities to move to cheaper models or batch processing.

It’s a timely update, especially in light of last week’s AWS billing issue that caused some customers to see incorrect cost estimates of services consumed in the AWS Management Console, said Muskan Bandta, cloud associate at FinOps services providing firm ZopDev.

“Anything that gives customers clearer, more granular and more trustworthy billing data is welcome when confidence in the numbers has just been shaken. It does not fix what went wrong, but better visibility into where spend is going is exactly what teams want more of after an episode like that,” Bandta added.

This article first appeared on InfoWorld.

AWS has updated AWS Data Exports, its service for generating and managing cost and usage Reports (CURs), to include standardized Amazon Bedrock product metadata, making it easier for enterprise engineering teams to analyze AI usage and spending as they scale AI deployments spanning multiple foundation models.

The update extends billing exports with normalized fields for model provider, model name, inference type, inference mode, billing unit and Bedrock product family, and will enable enterprises to identify which models generated costs and compare spending across providers without relying on custom parsing or normalization of billing records, AWS wrote in a blog post.

That reduced reliance on custom parsing will reduce the engineering effort required to analyze billing data, analysts said.

“Before the update, a data engineer would typically need to maintain a model ID registry, write regex against usage type strings, or join AWS CloudTrail with CUR to figure out which provider generated which cost,” said Bhupendra Chopra, chief revenue officer at IT consulting firm Kanerika.

The new standardized fields “can be the difference between a billing pipeline that needs constant babysitting and one that doesn’t,” Chopra added.

That’s because custom parsing logic is more prone to break down or require maintenance when AWS adds new models or updates pricing in Bedrock, said Pareekh Jain, principal analyst at Pareekh Consulting.

Richer billing data to boost enterprise AI cost governance

Beyond reducing engineering overhead, the update could also help enterprises improve AI cost governance.

Before this update FinOps teams struggled to identify which model Bedrock related to because usage type fields were inconsistent, and there was no unified product family name that captured all Bedrock costs in one place, Chopra said.

“Now those attributes — model provider, model name, inference type, inference mode, pricing unit — are standardized and available by default. That’s the plumbing work no one talks about, but it’s what makes downstream reporting actually reliable,” Chopra added.

This, said Jain, makes it easier to build dashboards showing cost by model, provider, token type or inference mode while also identifying expensive workloads, unusual token growth and opportunities to move to cheaper models or batch processing.

It’s a timely update, especially in light of last week’s AWS billing issue that caused some customers to see incorrect cost estimates of services consumed in the AWS Management Console, said Muskan Bandta, cloud associate at FinOps services providing firm ZopDev.

“Anything that gives customers clearer, more granular and more trustworthy billing data is welcome when confidence in the numbers has just been shaken. It does not fix what went wrong, but better visibility into where spend is going is exactly what teams want more of after an episode like that,” Bandta added.

Chinese tech giant Huawei is reportedly entering the DRAM manufacturing business in a bid to cash in on the insane profitability of memory sales.

Three firms – Micron Technology, SK hynix, and Samsung Electronics — account for 95% of the DRAM on the market worldwide. The rest is small players, mostly in China. One of them, CXMT, is gearing to make a run for the market and try and take a little bit of their business. But it is a small player, especially compared to Huawei.

Huawei’s strategy is complex. It is working with various entities to circumvent the U.S. trade sanctions specifically targeting it. According to SemiconductorInsider on X.com, the Chinese government and DRAM chip maker Swaysure (formed in 2022) are planning to introduce a DRAM manufacturing plant with a capacity of 140,000 wafers per month.

For perspective, Samsung manufacturers approximately 500,000 wafers per month, and Micron makes about 250,000 wafers per month.

It all fits in perfectly with Beijing’s drive for semiconductor self-reliance uh especially after all of the U.S. sanctions. And it would be US interference, not Huawei’s inexperienced with making memory that will be its greatest challenge, says one analyst.

“Their biggest problem will be tooling up, since the US has a lot of sway over the world’s semiconductor equipment makers, and it’s using that sway to prevent tools from being shipped to China,” said Jim Handy, president of Objective Analysis.

Handy said he hears that Huawei and Swaysure are working to produce DRAM starting at 28nm.  With that process they ought to be able to make 8Gb chips that yield reasonably but he doubts that they will be able to make HBM with that process, though.

Since he doesn’t know how far along they are in the process, Handy doesn’t know when something could come to market.  “They may be on the cusp of shipping something, or they may be a couple of years away, but I don’t think they will wait any longer than that, so let’s say 2028.  If there’s still a shortage in 2028, they are likely to ramp as hard as they can to get to something like 2-5% of the market by 2030.  If the shortage ends before then, they will probably take a much longer time,” he said.

Microsoft has released TypeScript 7.0, a native port of the company’s strongly typed version of the JavaScript language based on the Go programming language.

With this new codebase, TypeScript 7.0 brings native code speed, shared memory multithreading, and a number of new optimizations that typically yield speedups between 8x and 12x on full builds, Microsoft said in a July 8 announcement. This port of TypeScript to native code was done as faithfully as possible, writing new code while maintaining the structure and logic of the original codebase to keep results consistent and compatible between the two compilers, according to Microsoft. 

TypeScript 7.0 is available via npm:

npm install -D typescript

To help with the TypeScript 6.0 to TypeScript 7.0 transition process, Microsoft has published a new compatibility package, @typescript/typescript6. This package provides an executable named tsc6, so that if needed, a developer can install TypeScript 7.0 (which ships its own tsc binary) side-by-side with TypeScript 6.0 without naming conflicts. The new package also re-exports the TypeScript 6.0 API, so that a developer can use tsc for TypeScript 7, while other tooling can continue to rely on TypeScript 6.0.

TypeScript 7.0 is a major milestone in the TypeScript project, Microsoft said. This port has been the primary focus for Microsoft’s team for more than a year. With TypeScript 7.0 now out, the team will return to new feature work, ergonomic improvements, more performance wins, and implementing a new API for the broader ecosystem. Microsoft expects a fairly similar timeline to releases prior to TypeScript 7.0, with new versions published every three to four months.

TypeScript 7.0 was announced as a release candidate on June 18.

This is Part 2 of a series on tech worker unionization. See Part 1: “A brewing battle: More IT workers want unions. The industry doesn’t.”

The best time for tech workers to unionize was 20 years ago, when they had plenty of leverage. The second-best time is now, when they don’t.

Mass layoffs, AI-driven displacement, corporate surveillance, workplace disillusionment have created conditions that have made organizing compelling for tech professionals. But the federal labor board that has historically protected workers’ right to organize has been weakened, and the companies that once feared it are openly defying it.

Here’s how organizers and labor experts describe the pros and cons to organizing — and how you can get started.

What unions can — and can’t — do for you

The single biggest benefit of a union contract for most tech workers isn’t pay — it’s protection against arbitrary termination, especially in the wake of recent mass layoffs in tech. In the United States, nonunion “at-will” workers can be fired at any time without a stated reason, while unionized workers negotiate protections written into their contracts.

“That fear of the company letting you go for anything at any time…with a union they just can’t do that,” says Zak Thompson, a senior software engineer at Kickstarter and union steward at Kickstarter United. Now that Kickstarter employees are unionized, people are less worried that saying something negative will result in termination.

“I’ve been shocked at the willingness of my co-workers to speak up against what they see as poor or controversial business decisions,” Thompson says.

Beyond job security, unions can deliver concrete material gains. Kickstarter United was formed in 2020, although getting there wasn’t easy: two employees were fired during the organizing campaign — which itself became a galvanizing event. And while the union hasn’t been able to prevent layoffs, it did negotiate better terms: four months of severance pay and four to six months of continued health insurance, versus the two to three weeks per year of work that management had initially proposed.

Other benefits include a four-day work week; AI protections; a minimum pay floor; and standards for raises, promotions, and time off for the company’s 59 employees.

Unions can give tech workers a voice in decisions that affect their daily work — including how AI tools are deployed. “Nobody I’ve spoken to is against new technology or getting trained in it,” says Max Belasco, a business systems analyst at the University of California Los Angeles School of Law and co-chair of the UCLA chapter of the University Professional and Technical Employees/Communications Workers of America (UPTE-CWA) Local 9119.

“But when new technology is being implemented, we want to know: what’s the five-year vision, the 10-year vision? Are we implementing this in a way that betters staffing, increases efficiency, or eases the lives of people already working? Or are we trying to take away jobs, automate people out of their pension or paycheck?” Belasco says.

The challenges are real. Tech professionals are less inclined to leave their jobs in the current market because wages haven’t been increasing as fast as they once were, and it can take longer to land another job.

“Tech moved from a very tight labor market in 2022 (1.85% unemployment rate) to a noticeably weaker one in 2024–2026 (3.49%),” although that’s still better than the national unemployment rate of 4.36% through May of this year, says Liya Palagashvili, senior research fellow and director of the Labor Policy Project at the Mercatus Center at George Mason University.

Flexibility is a concern. The more substantive challenge, raised by economists including Palagashvili, is that traditional union contracts impose uniform terms across an entire bargaining unit, limiting the flexibility that many tech workers — and their employers —currently enjoy. Tech firms need to move fast, adjusting teams, products, and roles on the fly.

“Collective bargaining agreements can make those adjustments much more difficult, whether by making them slower, costlier, or inconsistent with the contract,” she says.

Workers skeptical of unions in a survey of 1,900 tech professionals conducted by the career site Blind cited specific concerns: that unions are “not meritocratic,” “prevent innovation,” and “hold back earnings of top performers.”

Thompson from Kickstarter United pushes back: “We have nothing in our contract about ‘you can’t bend down and pick up a piece of trash because that’s someone else’s job.’ The company is free to give bonuses and individual raises as much as they like. This is all just up to the people who are bargaining the contract from the union side.”

Organizing carries potentially serious personal risks. During negotiations for a second three-year contract in 2025, Kickstarter United went on strike for 42 days. A few months later, the company announced layoffs.

“They let go strong union leaders, including a person who had bargained our last contract,” Thompson says. The union appealed, and the issue is now going to arbitration.

If you form a union, don’t expect much support from the National Labor Relations Board, the agency that certifies US labor unions and protects workers’ right to organize, in terms of prosecuting complaints of unfair labor practices, Thompson warns. “We’re in a political moment in this country with a pretty weakened NLRB. You have to be ready to organize and withhold worker power without any guarantee of safety.”

Organizers are up against an enormous union avoidance industry. Organizers can expect fierce pushback as soon as the business discovers that organizing is underway.

“There’s a multi-billion-dollar industry in union avoidance,” says Alan McAvinney, a Google software engineer and organizing chair, Alphabet Workers Union-CWA, a 1,400-member minority union of Alphabet employees. (Google is a subsidiary of Alphabet.)

US employers spend roughly $1.7 billion a year on union avoidance consultants and law firms, according to a May 2026 report by the Economic Policy Institute and LaborLab.

Expect hardball tactics. Management may play hardball during the time between when organizers announce their intention to unionize and the actual vote. For example, management can threaten to fire foreign-born workers in the US on H-1B visas if they support the union. Those workers would then have just 60 days to find a new sponsoring employer or lose their H-1B status, according to a recent Tech Workers Coalition blog post.

And at venture capital-backed startups, investment agreements sometimes require management to attest there is no union activity — meaning a public organizing drive can trigger funding withdrawal. Or, if a unionized company is acquired, the new management can dissolve the union overnight by reclassifying unionized workers as new hires.

With these sobering facts in mind, here is how organizers who have done it describe the process of creating a union.

Step 1: Start a conversation with your co-workers

At the University of California, a two-tier system had evolved where some tech workers were unionized and some weren’t, Belasco says. Management created new titles that fell outside the union even though they had similar job descriptions and responsibilities to those in the union. Those nonunion employees received lower pay and benefits than their unionized peers, which created resentment and instability.

Belasco and other organizers wanted to eliminate that division by bringing everyone under the same contract. But when they began their unionization drive, “the biggest barrier we faced wasn’t management opposition — it was that people felt this was just the best-case scenario realistically available: ‘We have this job at the university, we have concerns about automation and layoffs, but what can we really do about it?'” he says.

The antidote to that fatalism, organizers say, is simple: “Just start talking to your immediate co-workers. Are they experiencing the same challenges you are experiencing?” says McAvinney. “There’s no need to start talking about a union at this point.”

Just get a consensus and start building a group of like-minded individuals, Thompson advises. “Always start with one-on-one conversations, and that’s what you should do the whole time. That’s the key to organizing,” he says.

Tech workers often think they’re a special case, says Thompson, and therefore that unionization isn’t a good fit. “You’re not special. You are a company of workers, you are organizing, and there is a playbook for that. Trust the process, because it tends to work pretty well,” he says.

Step 2: Who’s on board, and who’s not? Map your workplace, but keep it quiet

Once there’s a consensus, continue to grow your network. Keep a list of everyone you’ve spoken with and note their disposition: “Is this person union-friendly or anti-union? Would they be a strong organizer?” Thompson says.

Maintaining secrecy early on is essential, because anti-union tactics will start immediately, and that can stop union organizing before it can gain momentum.

“Generally, employers do not want to share power with their workforce,” McAvinney says. Employers will deploy every means at their disposal to stop organizing efforts and peel away potential yes votes.

“If you look at historical examples, having 70% approval before the employer finds out about you results in a high percentage of wins when you actually cast the vote. Historically, that’s an effective buffer,” he says.

There’s a real threat of firing and layoffs. The traditional tech worker belief that job mobility makes collective action unnecessary is now being tested by a tighter job market, McAvinney says, noting that workers who many believe were fired for speaking out back in 2019 were a galvanizing factor in his union’s formation.

“You generally don’t want to be in a situation where the employer feels comfortable firing everyone. Part of that is thinking from a cynical standpoint about what the consequences would be to the employer if they did fire everyone,” he says.

One-on-one conversations that include personally asking co-workers to keep conversations confidential are key to keeping things quiet, Belasco says. When 2,100 UC tech workers voted to unionize in May, 96% voted in favor. To stay out of earshot of managers, avoid employee surveillance tools, and sidestep conference calls that could be recorded, organizers met with workers in their homes.

“That tactic is probably what made the difference between winning the election and getting the majority we got,” he says.

Step 3: Find the right union affiliation or go it alone

“Running a campaign against major employers requires the resources and expertise of the larger labor movement, even if workers publicly present as independent,” says Kate Bronfenbrenner, director of labor education research and senior lecturer emeritus at Cornell University’s School of Industrial and Labor Relations.

Options include the Communications Workers of America (CWA), Service Employees International Union (SEIU), and the Office and Professional Employees International Union (OPEIU), among others. Another resource, the Tech Workers Coalition (TWC), provides training on organizing tactics, AI-in-workplace issues, and contract negotiation, and can match workers to the right unions for their needs.

The Alphabet Workers Union decided early on to affiliate with CWA. “They gave us a bunch of support early on in our campaign with no strings attached,” McAvinney says.

Kickstarter is organized through OPEIU, Thompson says. “They’ll usually have resources and staff that can help you through the next steps: collecting signatures in support of a union, bringing that to management, holding a vote — the more formalized things that interact with US labor law. They’ll also help with organizing along the way,” he says.

For workers at institutions where a union already exists, there may be a faster path. Organizers at UCLA did what’s called a “unit modification,” aligning with UPTE. By organizing under UPTE, the workers didn’t have to negotiate a new contract from scratch — they joined an already-negotiated contract covering existing UPTE tech members, which put them in “a much stronger position” than starting fresh, Belasco says.

Step 4: Choose your union model: majority vs. pre-majority or minority

Assess what’s practical for your organizing effort. In a majority union, more than 50% of all workers in a defined bargaining unit must vote to join the union through an NLRB-supervised election in the private sector, or a Public Employment Relations Board (PERB)-supervised election for public sector workers.

The NLRB must certify the union, which then operates under its legal protections. This means, for example, that the employer must bargain, negotiated contracts are enforceable, violations must go to the NLRB or arbitration, and workers can’t be dismissed without just cause.

A pre-majority or minority union is a minority labor organization operating without NLRB protections or collective bargaining agreements. “Pre-majority means that workers are able to demonstrate majority support — through signed cards, petitions, a walkout, or everyone wearing solidarity T-shirts — without going through a formal election,” Bronfenbrenner says.

The Alphabet Workers Union-CWA (AWU-CWA) formed as a pre-majority union because achieving majority status across a globally distributed workforce of over 100,000 was not a realistic near-term goal. “An underground model where you try to reach 70% support across a workforce of over 100,000 people isn’t realistic,” McAvinney says.

A pre-majority union can still make a difference, he says. For example, the Alphabet Workers Union-CWA convinced management to offer voluntary exit packages — buyouts — prior to announcing layoffs.

For smaller organizations, a majority union may be the more practical option — it’s more attainable, McAvinney says. “I don’t think [the pre-majority union model] is the correct thing to do in all situations. I certainly would not recommend it to a 200-person shop.”

Kickstarter, which had fewer than 100 employees, was able to form a majority union, with 55% voting to organize.

Ultimately, says McAvinney, “there’s no inflection point where you go from being able to win nothing to winning everything, even with a contract and a supermajority. But the more people you have who are willing and able to fight for what they want, the more you’ll be able to get.”

Step 5: Who should — and should not — be in your union?

Belasco’s situation at UCLA illustrates a broader strategic choice that every organizing campaign must make. He had been in a union position in educational technology when he was told his role would be reclassified as a non-union position.

“I was given a choice: apply to the new non-union position to continue doing the work I’d trained for, or stay in my union position doing service desk work I wasn’t used to,” he says. “Essentially, it was a choice between job security and career progression.”

Belasco joined a “wall-to-wall” union, which represents a broad range of university professional and technical employees across the UC system rather than a single job category, such as engineers or tech professionals.

Kickstarter United is another example of a wall-to-wall union. “It’s not just the engineers who are unionized, but also customer support, designers — everyone,” Thompson says.

Wall-to-wall unions are more powerful, but they’re also more difficult to achieve. Under US labor law, “professionals have to vote separately on whether they want to be combined with other workers,” says Bronfenbrenner. “You can never have a wall-to-wall unit without giving professionals the chance to decide whether they want to be separate.”

The law’s “professional employees” category includes roles like software engineers and developers but not necessarily others. For example, customer support specialists and QA analysts would fall into the “non-professional workers” category.

“For decades, the pattern was either to organize everybody except the engineers, or manage to organize the engineers and fail to bring in everybody else — neither of which builds real worker power,” says Simone Robutti, an organizer with Tech Workers Coalition Global, an international branch of TWC based in Berlin.

Step 6: You won the vote. Get ready for what comes next

Winning a union vote means having a seat at the table, says Thompson. “Once the workers have come together and agreed they want that seat, you bring that to management, and they have a chance to voluntarily recognize a union,” he says.

But in most cases employers contest the results, which must be certified by the NLRB or PERB. That process, in which the employer uses various tactics to challenge the legitimacy of the outcome, can take weeks or months.

Unfortunately, the legal framework that is supposed to protect workers during this process has been significantly weakened in the last few years. In a potentially more ominous development, SpaceX, Amazon, Trader Joe’s, Starbucks, and the University of Southern California have in separate legal actions challenged the constitutionality of the NLRB, arguing that the agency’s structure violates the separation of powers. The Fifth Circuit Court of Appeals upheld injunctions against the NLRB in SpaceX’s case in August 2025 — a serious challenge to the agency’s authority.

In the meantime, some companies may disregard negotiated contracts, which can lead to lengthy legal appeals or extended arbitration.

“The NLRB can still force an election, but it can’t force a contract, and companies are saying they simply won’t comply,” Bronfenbrenner says. This is where the expertise and resources of affiliation with a major union can help, she adds.

As a result, contract negotiations can take far longer than workers might expect. At Kickstarter, for example, two years and four months elapsed from the time of the union vote to the first contract, and that was at a 59-person company with a relatively cooperative employer. At larger companies with more aggressive legal teams, the timeline will be longer.

Forming a union is hard work, Robutti says. “It’s not a service you pay for and they protect you. It doesn’t happen spontaneously, and it doesn’t happen magically. It’s the choice to take responsibility for improving your workplace.”

Spring is a reliable and popular framework for building web and enterprise Java applications. In this article, you’ll learn how to unit test each layer of a Spring MVC application, using built-in testing tools from JUnit 5 and Spring to mock each component’s dependencies. In addition to unit testing with MockMvc, Mockito, and Spring’s TestEntityManager, I’ll also briefly introduce slice testing using the @WebMvcTest and @DataJpaTest annotations, used to optimize unit tests on web controllers and databases.

Also see: How to test your Java applications with JUnit 5.

Overview of testing Spring MVC applications

Spring MVC applications are defined using three technology layers:

• Controllers accept web requests and return web responses.
• Services implement the application’s business logic.
• Repositories persist data to and from your back-end SQL or NoSQL database.

When we unit test Spring MVC applications, we test each layer separately from the others. We create mock implementations, typically using Mockito, for each layer’s dependencies, then we simulate the logic we want to test. For example, a controller may call a service to retrieve a list of objects. When testing the controller, we create a mock service that either returns the list of objects, returns an empty list, or throws an exception. This test ensures the controller behaves correctly.

We’ll use Spring MVC to build and test a simple web service that manages widgets. The structure of the web service is shown here:

Steven Haines

This is a classic MVC pattern. We have a widget controller that handles RESTful requests and delegates its business functionality to a widget service, which uses a widget repository to persist widgets to and from an in-memory H2 database.

Get the source: Download the source code for this article.

Unit testing a Spring MVC controller with MockMvc

Setting up a Spring MVC controller test is a two-step process:

• Annotate your test class with @WebMvcTest.
• Autowire a MockMvc instance into your controller.

We could annotate all our test classes with @SpringBootTest, but we’ll use @WebMvcTest instead. The reason is that the @WebMvcTest annotation is used for slice testing. Whereas @SpringBootTest loads your entire Spring application context, @WebMvcTest loads only your web-related resources. Furthermore, if you specify a controller class in the annotation, it will only load the specific controller you want to test. Testing a single “slice” of your application reduces both the amount of compute resources required to set up the test and the time required to run a test.

For example, when we test a controller, we’ll mock just the services it uses, and we won’t need any repositories at all. If we don’t need them, then we needn’t waste time loading them. Slice tests were created to make tests perform better and run faster.

Here’s the source code for the Widget class we’ll be managing:

package com.infoworld.widgetservice.model;
import jakarta.persistence.Entity;
import jakarta.persistence.GeneratedValue;
import jakarta.persistence.GenerationType;
import jakarta.persistence.Id;

@Entity
public class Widget {
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;
    private String name;
    private int version;

    public Widget() {
    }

    public Widget(String name) {
        this.name = name;
    }

    public Widget(String name, int version) {
        this.name = name;
        this.version = version;
    }

    public Widget(Long id, String name, int version) {
        this.id = id;
        this.name = name;
        this.version = version;
    }

    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public int getVersion() {
        return version;
    }

    public void setVersion(int version) {
        this.version = version;
    }
}

A Widget is a JPA entity that manages three fields:

• id is the primary key of the table, annotated with @Id and @GeneratedValue, with an automatic generation strategy.
• name is the name of the widget.
• version is the version of the widget resource. We’ll use this value to populate our eTag value and check it in our PUT operation’s If-Match header value. This ensures the widget being updated is not stale.

Here’s the source code for the controller we’ll be testing (WidgetController.java):

package com.infoworld.widgetservice.web;

import java.net.URI;
import java.net.URISyntaxException;
import java.util.List;
import java.util.Optional;
import com.infoworld.widgetservice.model.Widget;
import com.infoworld.widgetservice.service.WidgetService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.DeleteMapping;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.PutMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestHeader;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class WidgetController {
    @Autowired
    private WidgetService widgetService;
    @GetMapping("/widget/{id}")
    public ResponseEntity getWidget(@PathVariable Long id) {
        return widgetService.findById(id)
                .map(widget -> {
                    try {
                        return ResponseEntity
                                .ok()
                                .location(new URI("/widget/" + id))
                                .eTag(Integer.toString(
                                               widget.getVersion()))
                                .body(widget);
                    } catch (URISyntaxException e) {
                        return ResponseEntity
                          .status(HttpStatus.INTERNAL_SERVER_ERROR)
                          .build();
                    }
                })
                .orElse(ResponseEntity.notFound().build());
    }
    @GetMapping("/widgets")
    public List getWidgets() {
        return widgetService.findAll();
    }
    @PostMapping("/widgets")
    public ResponseEntity createWidget(@RequestBody Widget widget)
    {
        Widget newWidget = widgetService.create(widget);
        try {
           return ResponseEntity
                   .created(new URI("/widget/" + newWidget.getId()))
                   .eTag(Integer.toString(newWidget.getVersion()))
                   .body(newWidget);
        } catch (URISyntaxException e) {
            return ResponseEntity
                    .status(HttpStatus.INTERNAL_SERVER_ERROR)
                    .build();
        }
    }

    @PutMapping("/widget/{id}")
    public ResponseEntity updateWidget(@PathVariable Long id,
                                          @RequestBody Widget widget,
                         @RequestHeader("If-Match") Integer ifMatch) {
        Optional existingWidget = widgetService.findById(id);
        return existingWidget.map(w -> {
            if (w.getVersion() != ifMatch) {
                return ResponseEntity.status(HttpStatus.CONFLICT)
                                     .build();
            }

            w.setName(widget.getName());
            w.setVersion(w.getVersion() + 1);

            Widget updatedWidget = widgetService.save(w);
            try {
                return ResponseEntity.ok()
                        .location(new URI("/widget/" + 
                                      updatedWidget.getId()))
                        .eTag(Integer.toString(
                                      updatedWidget.getVersion()))
                        .body(updatedWidget);
            } catch (URISyntaxException e) {
                throw new RuntimeException(e);
            }
        }).orElse(ResponseEntity.notFound().build());
    }

    @DeleteMapping("widget/{id}")
    public ResponseEntity deleteWidget(@PathVariable Long id) {
        Optional existingWidget = widgetService.findById(id);
        return existingWidget.map(w -> {
           widgetService.deleteById(w.getId());
           return ResponseEntity.ok().build();
        }).orElse(ResponseEntity.notFound().build());
    }
}

The WidgetController handles GET, POST, PUT, and DELETE operations, following standard RESTful principles, so we’re going to write tests for each operation.

The following source code shows the structure of our test class (WidgetControllerTest.java):

package com.infoworld.widgetservice.web;

@WebMvcTest(WidgetController.class)
public class WidgetControllerTest {
    @Autowired
    private MockMvc mockMvc;

    @MockitoBean
    private WidgetService widgetService;
}

I omitted the imports for readability, but the important thing to note is that the class is annotated with the @WebMvcTest annotation, and that we pass in the WidgetController.class as the controller we’re testing. This tells Spring to only load the WidgetController and no other Spring resources. The @WebMvcTest annotation includes other annotations, but the important one for our tests is @AutoConfigureMockMvc, which will cause Spring to create a MockMvc instance and add it to the application context. That lets us autowire it into our test class using the @Autowired annotation.

Next, we use the @MockitoBean annotation to use Mockito to create a mock implementation of the WidgetService, after which Spring will autowire it into the WidgetController class. This lets us control the behavior of the WidgetService for the WidgetController test cases we’re writing. Note that starting in Spring Boot version 3.4, @MockitoBean replaced @MockBean. Everything you know about @MockBean translates to using @MockitoBean—with some improvements.

Unit testing GET /widgets

Let’s start with the easiest test case, a test for GET /widgets:

@Test
void testGetWidgets() throws Exception {
    List widgets = new ArrayList();
    widgets.add(new Widget(1L, "Widget 1", 1));
    widgets.add(new Widget(2L, "Widget 2", 1));
    widgets.add(new Widget(3L, "Widget 3", 1));

    when(widgetService.findAll()).thenReturn(widgets);

    mockMvc.perform(get("/widgets"))
            .andExpect(status().isOk())
            .andExpect(jsonPath("$.length()").value(3))
            .andExpect(jsonPath("$[0].id").value(1L))
            .andExpect(jsonPath("$[0].name").value("Widget 1"))
            .andExpect(jsonPath("$[0].version").value(1));
};

The testGetWidgets() method creates a list of three widgets and then configures the mock WidgetService to return the list when its findAll() method is called. The WidgetControllerTest class statically imports the org.mockito.Mockito.when() method that accepts a method call, which in this case is widgetService.findAll(), and returns a Mockito OngoingStubbing instance. This OngoingStubbing instance exposes methods like thenReturn(), thenThrow(), thenCallRealMethod(), thenAnswer(), and then().

Here, we use the thenReturn() method to tell Mockito to return the list of widgets when the WidgetService’s findAll() method is called. The @MockitoBean annotation causes the mock WidgetService to be autowired into the WidgetController. So, when the getWidgets() method is called in response to a GET /widgets, it calls the WidgetService’s findAll() method and returns our list of widgets as a web response.

Next, we use MockMvc’s perform() method to execute a web request. This diagram shows the various classes that interact with the perform() method:

Steven Haines

The perform() method accepts a RequestBuilder. Spring defines several built-in RequestBuilders that we can statically import into our tests, including get(), post(), put(), and delete(). The perform() method returns a ResultActions instance that exposes methods such as andExpect(), andExpectAll(), andDo(), and andReturn(). Here, we invoke the andExpect() method, which accepts a ResultMatcher.

A ResultMatcher defines a match() method that throws an AssertionError if the assertion fails. Spring defines several ResultMatchers that we can statically import:

• status() allows us to check the HTTP status code of response.
• content() allows us to check the content headers of the response, such as Content-Type.
• header() allows us to check any of the HTTP header values.
• jsonPath() allows us to inspect the contents of a JSON document.

After MockMvc performs a GET to /widgets, we expect the HTTP status code to be 200 OK. We can then use the jsonPath matcher to check the body results, using the following JSON path expressions:

• $.length(): The $ references the root of the JSON document. If the response is a list, then we can call the length() method to get the number of elements in the list.
• $[0].id: JSON path expressions for a list use an array syntax starting at 0. This expression gets the ID of the first element in the list.
• $[0].name: This expression gets the name of the first element and compares it to “Widget 1”.
• $[0].version: This expression gets the version of the first element and compares it to 1.

Unit testing the GET /widget/{id} handler

Here’s the source code to test the GET /coffee/{id} widget:

@Test
void testGetWidgetById() throws Exception {
    Widget widget = new Widget(1L, "My Widget", 1);          
    when(widgetService.findById(1L))
           .thenReturn(Optional.of(widget));

    mockMvc.perform(get("/widget/{id}", 1))
            // Validate that we get a 200 OK Response Code
            .andExpect(status().isOk())

            // Validate Headers
            .andExpect(content()
                      .contentType(MediaType.APPLICATION_JSON))
            .andExpect(header().string(HttpHeaders.LOCATION,
                                       "/widget/1"))
            .andExpect(header().string(HttpHeaders.ETAG, "\"1\""))

            // Validate content
            .andExpect(jsonPath("$.id").value(1L))
            .andExpect(jsonPath("$.name").value("My Widget"))
            .andExpect(jsonPath("$.version").value(1));
 }

This test method is very similar to the testGetWidgets() method, but with some notable changes:

• The GET URI is defined using a URI template. You can specify any number of variables enclosed in braces in the URI template and then send a list of arguments that will replace those variables in the order they appear in the template.
• We check that the returned Content-Type is “application/json”, which is a constant in the MediaType class. We access the content using the content() method, which returns a ContentResultMatchers instance that provides various methods, including contentType(), which allows us to validate the content headers.
• We check for specific header values using the header() method. The header() method returns a HeadersResultMatchers instance, which can check for header String, long, and date values, as well as checking to see whether or not specific headers exist. In this case, we use constants defined in the HttpHeaders class to check the location and eTag header values.
• We check the body of the response using JSON path expressions. In this case, we do not have a list of objects, so we can access the individual fields in the JSON document directly. For example, $.id retrieves the id field value in the root of the document.

Unit testing a GET /widget/{id} Not Found code

Next, we test the GET /widget/{id}, passing it an invalid ID so that it returns a 404 Not Found response code:

@Test
void testGetWidgetByIdNotFound() throws Exception {
   when(widgetService.findById(1L)).thenReturn(Optional.empty());

   mockMvc.perform(get("/widget/{id}", 1))
            // Validate that we get a 404 Not Found Response Code
            .andExpect(status().isNotFound());
}

The testGetWidgetByIdNotFound() method configures the mock WidgetService to return Optional.empty() when its findById() is called with a value of 1. We then perform a GET request to /widget/1, then assert that the returned HTTP status code is 404 Not Found.

Unit testing POST /widgets

Here’s how to test a Widget creation:

@Test
void testCreateWidget() throws Exception {
    Widget widget = new Widget(1L, "Widget 1", 1);
    when(widgetService.create(any())).thenReturn(widget);

    mockMvc.perform(post("/widgets")
            .contentType(MediaType.APPLICATION_JSON)
            .content("{\"name\": \"Widget 1\"}"))

            // Validate that we get a 201 Created Response Code
            .andExpect(status().isCreated())

            // Validate Headers
            .andExpect(content().contentType(
                                      MediaType.APPLICATION_JSON))
            .andExpect(header().string(HttpHeaders.LOCATION, 
                                       "/widget/1"))
            .andExpect(header().string(HttpHeaders.ETAG, "\"1\""))

            // Validate content
            .andExpect(jsonPath("$.id").value(1L))
            .andExpect(jsonPath("$.name").value("Widget 1"))
            .andExpect(jsonPath("$.version").value(1));

The testCreateWidget() method first creates a Widget to return when the WidgetService’s create() method is called with any argument. The any() matcher matches any argument and, because the createWidget() handler will create a new Widget instance, we will not have access to that instance when the test runs. We then invoke MockMvc’s perform() method to the ”/widgets” URI, sending the content body of a new widget named “Widget 1”, using the content() method. We expect a 201 Created HTTP response code, an “application/json” content type, a location header of “/widget/1”, and an eTag value of the String “1”. The body of the response should match the Widget we returned from the create() method, namely an ID of 1, a name of “Widget 1”, and a version of 1.

Unit testing PUT /widget

This code runs three tests for the PUT operation:

@Test
public void testSuccessfulUpdate() throws Exception {
    // Create a mock Widget when the WidgetService's findById(1L) 
    // is called
    Widget mockWidget = new Widget(1L, "Widget 1", 5);
    when(widgetService.findById(1L))
                      .thenReturn(Optional.of(mockWidget));

    // Create a mock Coffee that is returned when the 
    // CoffeeController saves the Coffee to the database
    Widget savedWidget = new Widget(1L, "Updated Widget 1", 6);
    when(widgetService.save(any())).thenReturn(savedWidget);

    // Execute a PUT /widget/1 with a matching version: 5
    mockMvc.perform(put("/widget/{id}", 1L)
                    .contentType(MediaType.APPLICATION_JSON)
                    .header(HttpHeaders.IF_MATCH, 5)
                    .content("{\"id\": 1, " +
                             "\"name\": \"Updated Widget 1\"}"))

            // Validate that we get a 200 OK HTTP Response
           .andExpect(status().isOk())

            // Validate the headers
           .andExpect(content()
                        .contentType(MediaType.APPLICATION_JSON))
           .andExpect(header().string(HttpHeaders.LOCATION, 
                                      "/widget/1"))
           .andExpect(header().string(HttpHeaders.ETAG, "\"6\""))

           // Validate the contents of the response
           .andExpect(jsonPath("$.id").value(1L))
           .andExpect(jsonPath("$.name")
                               .value("Updated Widget 1"))
           .andExpect(jsonPath("$.version").value(6));
}

@Test
public void testUpdateConflict() throws Exception {
   // Create a mock coffee with a version set to 5
   Widget mockWidget = new Widget(1L, "Widget 1", 5);

    // Return the mock Coffee when the CoffeeService's 
    // findById(1L) is called
    when(widgetService.findById(1L))
                      .thenReturn(Optional.of(mockWidget));

    // Execute a PUT /widget/1 with a mismatched version number: 2
    mockMvc.perform(put("/widget/{id}", 1L)
                    .contentType(MediaType.APPLICATION_JSON)
                    .header(HttpHeaders.IF_MATCH, 2)
                    .content("{\"id\": 1, " + 
                             "\"name\":  \"Updated Widget 1\"}"))
             // Validate that we get a 409 Conflict HTTP Response
            .andExpect(status().isConflict());
}

@Test
public void testUpdateNotFound() throws Exception {
   // Return the mock Coffee when the CoffeeService's 
   // findById(1L) is called
   when(widgetService.findById(1L)).thenReturn(Optional.empty());

   // Execute a PUT /coffee/1 with a mismatched version number: 2
   mockMvc.perform(put("/widget/{id}", 1L)
                    .contentType(MediaType.APPLICATION_JSON)
                    .header(HttpHeaders.IF_MATCH, 2)
                    .content("{\"id\": 1, " + 
                             "\"name\":  \"Updated Coffee 1\"}"))

           // Validate that we get 404 Not Found
           .andExpect(status().isNotFound());
}

We have three variations:

• A successful update.
• A failed update because of a version conflict.
• A failed update because the widget was not found.

In RESTful web services, version management is handled by the entity tag, or eTag. When you retrieve an entity, it has an eTag value. When you want to update the entity, you pass that eTag value in the If-Match HTTP header. If the If-Match header does not match the current eTag, which is the Widget version in our implementation, then the PUT handler returns a 409 Conflict HTTP response code. If you get this error, it means that you need to retrieve the entity again and retry your operation. This way, if two different clients attempt to update the same entity simultaneously, only one will succeed.

In the testSuccessfulUpdate() method, we return a Widget with a version of 5 when the WidgetService’s findById() method is called. We then pass an If-Match header value of 5 and then validate that we get a 200 OK HTTP response code and the expected header and body values. In the testUpdateConflict() method, we do the same thing, but we set the If-Match header to 2, which does not match 5, so we validate that we get a 409 Conflict HTTP response code. And finally, in the testUpdateNotFound() method, we configure the WidgetService to return an Optional.empty() when its findById() method is called, so we execute the PUT operation and validate that we get a 404 Not Found HTTP response code.

Unit testing DELETE /widget

Finally, here is the source code for our two DELETE /widget tests:

@Test
void testDeleteSuccess() throws Exception {
    // Setup mocked product
    Widget mockWidget = new Widget(1L, "Widget 1", 5);

    // Setup the mocked service
    when(widgetService.findById(1L))
                      .thenReturn(Optional.of(mockWidget));
    doNothing().when(widgetService).deleteById(1L);

    // Execute our DELETE request
    mockMvc.perform(delete("/widget/{id}", 1L))
            .andExpect(status().isOk());
}

@Test
void testDeleteNotFound() throws Exception {
    // Setup the mocked service
    when(widgetService.findById(1L)).thenReturn(Optional.empty());

    // Execute our DELETE request
    mockMvc.perform(delete("/widget/{id}", 1L))
            .andExpect(status().isNotFound());
}

The DELETE handler first tries to find the widget by ID and then calls the WidgetService’s deleteById() method. The testDeleteSuccess() method configures the WidgetService to return a mock Widget when the findById() method is called and then configures it to do nothing when the deleteById() method is called. The deleteById() method returns void, so we do not need to mock a response, though we do want to allow the method to be called. We execute the DELETE operation and validate that we receive a 200 OK HTTP response code. The testDeleteNotFound() method configures the WidgetService to return Optional.empty() when its findById() method is called. We execute the DELETE operation and validate that we receive a 404 Not Found HTTP response code.

At this point, we have a comprehensive set of tests for all of our controller operations. Let’s continue down our stack and test our service.

Unit testing a Spring MVC service

Next, we’ll test a WidgetService class, shown here:

package com.infoworld.widgetservice.service;

import java.util.List;
import java.util.Optional;

import com.infoworld.widgetservice.model.Widget;
import com.infoworld.widgetservice.repository.WidgetRepository;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class WidgetService {
    @Autowired
    private WidgetRepository widgetRepository;

    public List findAll() {
        return widgetRepository.findAll();
    }

    public Optional findById(Long id) {
        return widgetRepository.findById(id);
    }

    public Widget create(Widget widget) {
        widget.setVersion(1);
        return widgetRepository.save(widget);
    }

    public Widget save(Widget widget) {
        return widgetRepository.save(widget);
    }

    public void deleteById(Long id) {
        widgetRepository.deleteById(id);
    }
}

The WidgetService is very simple. It autowires in a WidgetRepository and then delegates almost all its functionality to the WidgetRepository. The only business logic it implements is that it sets the Widget version to 1 in the create() method, when it is persisting a new Widget to the database.

While Spring supports slice testing for our controller and (as you’ll soon see) our repository, it doesn’t have a slice testing annotation for our service. We could use the @SpringBootTest annotation, but then Spring would load all the controllers, repositories, and any other Spring resources in our application into the Spring application context. We can avoid by using Mockito directly.

Here is the source code for the WidgetServiceTest class:

package com.infoworld.widgetservice.service;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertTrue;
import static org.mockito.Mockito.when;

import java.util.Optional;

import com.infoworld.widgetservice.model.Widget;
import com.infoworld.widgetservice.repository.WidgetRepository;

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.junit.jupiter.MockitoExtension;

@ExtendWith(MockitoExtension.class)
public class WidgetServiceTest {
    @Mock
    private WidgetRepository repository;

    @InjectMocks
    private WidgetService service;

    @Test
    void testFindById() {
        Widget widget = new Widget(1L, "My Widget", 1);
        when(repository.findById(1L)).thenReturn(Optional.of(widget));

        Optional w = service.findById(1L);
        assertTrue(w.isPresent());
        assertEquals(1L, w.get().getId());
        assertEquals("My Widget", w.get().getName());
        assertEquals(1, w.get().getVersion());
    }
}

JUnit 5 supports extensions and Mockito has defined a test extension that we can access through the @ExtendWith annotation. This extension allows Mockito to read our class, find objects to mock, and inject mocks into other classes. The WidgetServiceTest tells Mockito to create a mock WidgetRepository, by annotating it with the @Mock annotation, and then to inject that mock into the WidgetService, using the @InjectMocks annotation. The result is that we have a WidgetService that we can test and it will have a mock WidgetRepository that we can configure for our test cases.

Also see: Advanced unit testing with JUnit 5, Mockito, and Hamcrest.

This is not a comprehensive test, but it should get you started. It has a single method, testFindById(), that demonstrates how to test a service method. It creates a mock Widget instance and then uses the Mockito when() method, just as we used in the controller test, to configure the WidgetRepository to return an Optional of that Widget when its findById() method is called. Then it invokes the WidgetService’s findById() method and validates that the mock Widget is returned.

Slice testing a Spring Data JPA repository

Next, we’ll slice test our JPA repository (WidgetRepository.java), shown here:

package com.infoworld.widgetservice.repository;

import java.util.List;
import com.infoworld.widgetservice.model.Widget;
import org.springframework.data.jpa.repository.JpaRepository;

public interface WidgetRepository extends JpaRepository {
    List findByName(String name);
}

The WidgetRepository is a Spring Data JPA repository, which means that we define the interface and Spring generates the implementation. It extends the JpaRepository interface, which accepts two arguments:

• The type of entity that it persists, namely a Widget.
• The type of primary key, which in this case is a Long.

It generates common CRUD method implementations for us to create, update, delete, and find widgets, and then we can define our own query methods using a specific naming convention. For example, we define a findByName() method that returns a List of Widgets. Because “name” is a field in our Widget entity, Spring will generate a query that finds all widgets with the specified name.

Here is our WidgetRepositoryTest class:

package com.infoworld.widgetservice.repository;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertNotNull;
import static org.junit.jupiter.api.Assertions.assertNull;

import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;

import com.infoworld.widgetservice.model.Widget;

import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.orm.jpa.DataJpaTest;
import org.springframework.boot.test.autoconfigure.orm.jpa.TestEntityManager;

@DataJpaTest
public class WidgetRepositoryTest {
    @Autowired
    private TestEntityManager entityManager;

    @Autowired
    private WidgetRepository widgetRepository;

    private final List widgetIds = new ArrayList();
    private final List testWidgets = Arrays.asList(
            new Widget("Widget 1", 1),
            new Widget("Widget 2", 1),
            new Widget("Widget 3", 1)
    );

    @BeforeEach
    void setup() {
        testWidgets.forEach(widget -> {
            entityManager.persist(widget);
            widgetIds.add((Long)entityManager.getId(widget));
        });
        entityManager.flush();
    }

    @AfterEach
    void teardown() {
        widgetIds.forEach(id -> {
            Widget widget = entityManager.find(Widget.class, id);
            if (widget != null) {
                entityManager.remove(widget);
            }
        });
        widgetIds.clear();
    }

    @Test
    void testFindAll() {
        List widgetList = widgetRepository.findAll();
        assertEquals(3, widgetList.size());
    }

    @Test
    void testFindById() {
        Widget widget = widgetRepository.findById(
                               widgetIds.getFirst()).orElse(null);

        assertNotNull(widget);
        assertEquals(widgetIds.getFirst(), widget.getId());
        assertEquals("Widget 1", widget.getName());
        assertEquals(1, widget.getVersion());
    }

    @Test
    void testFindByIdNotFound() {
        Widget widget = widgetRepository.findById(
            widgetIds.getFirst() + testWidgets.size()).orElse(null);
        assertNull(widget);
    }

    @Test
    void testCreateWidget() {
        Widget widget = new Widget("New Widget", 1);
        Widget insertedWidget = widgetRepository.save(widget);

        assertNotNull(insertedWidget);
        assertEquals("New Widget", insertedWidget.getName());
        assertEquals(1, insertedWidget.getVersion());
        widgetIds.add(insertedWidget.getId());
    }

    @Test
    void testFindByName() {
        List found = widgetRepository.findByName("Widget 2");
        assertEquals(1, found.size(), "Expected to find 1 Widget");

        Widget widget = found.getFirst();
        assertEquals("Widget 2", widget.getName());
        assertEquals(1, widget.getVersion());
    }
}

The WidgetRepositoryTest class is annotated with the @DataJpaTest annotation, which is a slice-testing annotation that loads repositories and entities into the Spring application context and creates a TestEntityManager that we can autowire into our test class. The TestEntityManager allows us to perform database operations outside of our repository so that we can set up and tear down our test scenarios.

In the WidgetRepositoryTest class, we autowire in both our WidgetRepository and TestEntityManager. Then, we define a setup() method that is annotated with JUnit’s @BeforeEach annotation, so it will be executed before each test case runs. Next, we define a teardown() method that is annotated with JUnit’s @AfterEach annotation, so it will be executed after each test completes. The class defines a testWidgets list that contains three test widgets and then the setup() method inserts those into the database using the TestEntityManager’s persist() method. After it inserts each widget, it saves the automatically generated ID so that we can reference it in our tests. Finally, after persisting the widgets, it flushes them to the database by calling the TestEntityManager’s flush() method. The teardown() method iterates over all Widget IDs, finds the Widget using the TestEntityManager’s find() method, and, if it is found, removes it from the database. Finally, it clears the widget ID list so that the setup() method can rebuild it for the next test. (Note that the TestEntityManager removes entities directly; it does not have a remove by ID method, so we first have to find each Widget and then remove them one-by-one.)

Even though most of the methods being tested are autogenerated and well tested, I wanted to demonstrate how to write several kinds of tests. The only method that we really need to test is the findByName() method because that is the only custom method we define. For example, if we were to define the method as findByNam() instead of findByName(), then the method would not work, so it is definitely worth testing.

Conclusion

Spring provides robust support for testing each layer of a Spring MVC application. In this article, we reviewed how to test controllers, using MockMvc; services, using the JUnit Mockito extension; and repositories, using the Spring TestEntityManager. We also reviewed slice testing as a strategy to reduce testing resource utilization and minimize the time required to execute tests. Slice testing is implemented in Spring using the @WebMvcTest and @DataJpaTest annotations. I hope these examples have given you everything you need to feel comfortable writing robust tests for your Spring MVC applications.

Despite many worthy contenders, React remains the most popular front-end framework, and a key player in the JavaScript development landscape. React is the quintessential reactive engine, continually innovating alongside the rest of the industry. A flagship open source project at Facebook, React is now part of Meta Open Source. For developers new to JavaScript and web development, this tutorial will get you started with this vital technology.

React is not only a front-end framework, but is a component in full-stack frameworks like Next.js. Newer additions like React server-side rendering (SSR) and React server components (RSC) further blur the line between server and client.

Also see: Is the React compiler ready for primetime?

Why React?

React’s prominence makes it an obvious choice for developers just starting out with web development. It is often chosen for its ability to offer a smooth and encompassing developer experience (DX), which distinguishes it from frameworks like Vue, Angular, and Svelte. It could be said that React’s true “killer feature” is the perks that come with longstanding popularity: learning resources, community support, libraries, and developers are all plentiful in the React ecosystem.

Installing React

Real-world React requires running on the server with a build tool, which we will explore in the next section. But to get your feet wet, we can start out with an online playground. There are several high-quality playgrounds for React, including full-blown environments like StackBlitz or Codesandbox. For a quick taste, we will use PlayCode React.

When you first open it, PlayCode React gives you a basic layout like the one shown here:

Matthew Tyson

The menu on the left is the file explorer, at the top is the code window, and at the bottom are the console (on the left) and the preview pane (on the right).

From this screenshot, you can see how the content of the code is displayed on the preview pane, but this basic layout doesn’t use any variables (or “state,” as it’s known in React). It does let you see some of the plumbing, like the React library import and the exported App function.

Modern React is functional. The App function has a return value that is the actual output for the component. The component’s return is specified by JSX, a templating language that lets you use HTML along with variables and JavaScript expressions. Right now, the app just has some simple markup.

The classic example you see next is a “Counter” that lets you increase and decrease a displayed value using buttons. We’ll do a slight “Spinal Tap” variation of this, where the counter only goes to 11 and displays a message:

Matthew Tyson

You can take a look at the running example here, and the full code for the example is below:

import React, { useState } from 'react';

export function App() {
  // 1. The State
  const [volume, setVolume] = useState(0);

  return (
    

      
Spinal Tap Amp 🎸
     
      {/* 2. The "View" (Displaying the state) */}
      

        {volume}
      

      

        {/* 3. The Actions */
         setVolume(volume - 1)}>Down
       
         {
          if (volume 
          Up
        
      

      {/* 4. Conditional */}
      {volume === 11 &&
        
"Why don't you just make ten louder?"
      }
    
  );
}

If you play with the example, you’ll see that moving the buttons changes the value, and the display automatically reflects the change. This is the essential magic of a reactive engine like React. The state is a managed variable that React automatically updates and displays. State is declared like so:

const [volume, setVolume] = useState(0);

The syntax is a bit funky if you are coming from straight JavaScript, but most developers can adapt to it quickly. Basically, useState(0) says, with a default value 0, give me a variable, volume, and a function to set it, setVolume.

To display the value in the view, we use: {volume}.

To modify the value, we use button event handlers. For example, to increment, we’d do:

To modify the value, we use buttons event handlers.  For example, to increment:

onClick={() => setVolume(volume + 1)

Here we’ve directly modified the volume state, and React will update accordingly. If we wanted to, we could call a function (for example, if the logic were more involved).

Finally, when the value reaches 11, we display a message. This syntax is idiomatic React, and uses an embedded JavaScript equality check:

{volume === 11 &&
  
"Why don't you just make ten louder?"
}

The check says, if volume is 11, then display the

Using a build tool with React

Once upon a time, when NVIDIA was nothing but a graphics card, it was quite a bit of work assembling a good build chain for React. These days, the process is much simpler, and the once ubiquitous create-react-app option is no more. Vite is now the standard choice for launching a new app from the React terminal, so that’s the approach you’ll learn here.

With that said, there are a few alternatives worth mentioning. VS Code has extensions that will provide you with templates or scaffolding, but what’s becoming more common is using an AI coding assistant. A tool like Copilot, ChatGPT, or Gemini can take a prompt describing the basics of the application in question, including the instruction to use React, and produce a basic React layout for you. AI assistants are available in both command-line and VS Code extension flavors. Or, for an even more forward-looking option, you could use something like Firebase Studio.

But enough about alternatives—Vite is the standard for a reason. It is repeatable, capable, and fast. To launch a new Vite app, you just enter the following in your command line:

$ npm create vite@latest

The interactive tool will walk you through the process, starting with selecting React as your technology:

Matthew Tyson

Use your own preferences for the other options (like using TypeScript versus JavaScript) and accept the option to install and launch the app immediately. Afterward, you’ll see a simple demo like this one:

Matthew Tyson

The demo app has a counter component like the one we built earlier. If you Ctrl-c (or Cmd-c) to kill the Vite process running in the terminal, you can cd into the new directory. From there, you can see where the counter component is defined, in src/App.jsx (or App.tsx if you have selected TypeScript like I have).

It’s worth looking at that file to see how React appears on the server:

src/App.tsx
import { useState } from 'react'
import reactLogo from './assets/react.svg'
import viteLogo from '/vite.svg'
import './App.css'

function App() {
  const [count, setCount] = useState(0)

  return (
    
      

        
          
        
        
          
        
      
      
Vite + React
      

         setCount((count) => count + 1)}>
          count is {count}
        
        

          Edit src/App.tsx and save to test HMR
        
      
      

        Click on the Vite and React logos to learn more
      
    >
  )
}

export default App</code>

Notice we export the App as a module, which is used by the src/main.tsx file to display the component in the view. That file creates the bridge between the respective worlds of React and HTML:

import { StrictMode } from 'react'
import { createRoot } from 'react-dom/client'
import './index.css'
import App from './App.tsx'

createRoot(document.getElementById('root')!).render(
  
    
  ,
)

Don’t worry too much about the details of how React bootstraps itself with createRoot and the render call (which you won’t have to interact with on a regular basis). The important thing is how the App component is imported and then used with the JSX.

Note

Strict mode adds warning during dev mode to help you catch component bugs early.

There are a few rules to bear in mind when using JSX, the templating language of React:

• HTML elements are lowercase (
  , ), but components are uppercase (, ).
• You can’t just type “class” in JSX; instead, use className; e.g.,
  .
• To access the realm of JavaScript (and the application state) from within JSX, use curly braces: {2 + 2 != 5}.

React components and props

The main organizational concept in React is the component. Components are used to contain the functionality for a part of the view within a self-contained package. We’ve seen a component in action already with but it might be a little obscure, so let’s add another simple component to enhance the demonstration. This component also lets us explore another key part of React: Props.

To start, let’s create a display of the counter value influenced by the Rob Reiner movie This Is Spinal Tap. To start, we create a new file at src/VolumeDisplay.jsx:

// src/VolumeDisplay.jsx

export function VolumeDisplay({ level }) {
  return (
    

      {/* The Dial */}
      
= 11 ? '#d32f2f' : '#f0f0f0',
        color: level >= 11 ? 'white' : 'black',
        transition: 'all 0.2s ease'
      }}>
        {level}
      

      {/* The Message */}
      {level >= 11 && (
        

          "These go to eleven." 🤘
        
      )}
    
  );
}

This is a simple display but there are a couple of things worth noting about it.

One is that we accept a prop (a property) “from above” with VolumeDisplay({ level }). This tells whatever parent component uses this one that VolumeDisplay accepts a single property, called level. VolumeDisplay uses the property by displaying it (though it adds a bit of fancying up using conditional logic like we have already seen).

The way we define the CSS values, inside the double braces, {{ }}, and as a map of value is idiomatic React. (It isn’t essential at this point to grasp why it works that way, but basically, it is the JSX token { } with a JavaScript map of CSS values using JavaScript-friendly camel-cased names, like justifyContent.)

Now, to utilize this component, we can go to App.jsx, and make two changes:

import { useState } from 'react'
import reactLogo from './assets/react.svg'
import viteLogo from '/vite.svg'
import './App.css'
// 1. Import our new component
import { VolumeDisplay } from './VolumeDisplay'

function App() {
  const [count, setCount] = useState(0)

  return (
    
      

        
          
        
        
          
        
      
      
Vite + React
      

         setCount((count) => count + 1)}>
          count is {count}
        
        {/* 2. Pass the 'count' state into the 'level' prop */}
      
        

          Edit src/App.tsx and save to test HMR
        
      
      

        Click on the Vite and React logos to learn more
      
    >
  )
}

export default App</code>

Here, we’ve done two things: imported the new component and used it in the view.

Notice, also, that the line passes the existing count state variable into VolumeDisplay as a prop. React will do the work of ensuring that whenever count changes, the VolumeDisplay will also be updated, including any dependent logic such as the conditional statements.

Now, if we run the code like so:

$ npm run dev

We get what you see in the screenshot below:



Matthew Tyson

Conclusion

The world is now your oyster, at least within the realm of JavaScript web development. Not only is React wildly popular, its basic ideas are applicable to a host of other innovative frameworks, including Svelte and Solid. (To get some idea of the alternatives, just type npm create vite@latest and look at all the available technologies.) Now that you have a basic introduction, a good next step for learning would be to add an control that allows typing in the volume manually. Happy coding!

Angular is a cohesive, all-in-one reactive framework for web development. It is one of the larger reactive frameworks, focused on being a single architectural system that handles all your web development needs under one idiom. While Angular was long criticized for being heavyweight as compared to React, many of those issues were addressed in Angular 19. Modern Angular is built around the Signals API and minimal formality, while still delivering a one-stop-shop that includes dependency injection and integrated routing.

Angular is popular with the enterprise because of its stable, curated nature, but it is becoming more attractive to the wider developer community thanks to its more community engaged development philosophy. That, along with its recent technical evolution, make Angular one of the most interesting projects to watch right now.

Why choose Angular?

Choosing a JavaScript development framework sometimes feels like a philosophical debate, but it should be a practical decision. Angular is unique because it is strongly opinionated. It doesn’t just give you a view layer; it provides a complete toolkit for building web applications.

Like other reactive frameworks, Angular is built around its reactive engine, which lets you bind state (variables) to the view. But if that’s all you needed, one of the smaller, more focused frameworks would be more than enough. What Angular has that some of these other frameworks don’t is its ability to use data binding to automatically synchronize data from your user interface (UI) with your JavaScript objects. Angular also leverages dependency injection and inversion of control to help structure your application and make it easier to test. And it contains more advanced features like server-side rendering (SSR) and static-site generation (SSG) within itself, rather than requiring you to engage a meta-framework for either style of development.

While Angular might not be your top choice for every occasion, it’s an excellent option for larger projects that require features you won’t get with a more lightweight framework.

Also see: Catching up with Angular 19.

Getting started with Angular

With those concepts in mind, let’s set up Angular in your development environment. After that, we can run through developing a web application with Angular. To start, make sure you have Node and NPM installed. From the command line, enter:

$ node -v
$ npm -v

Next, you can use the Angular CLI to launch a new app:

$ ng new iw-ng

You can use the defaults in your responses to the interactive prompts shown here:

Matthew Tyson

We now have a basic project layout in the new directory, which you can import into an IDE (such as VS Code) or edit directly.

Looking at the project layout, you might notice it is fairly lean, a break from Angular projects of the past. The most important parts are:

• src/main.ts: This is the main entry point. In older versions of Angular, this file had to bootstrap a module, which then bootstrapped a component. Now, it avoids any verbose syntax, calling bootstrapApplication with your root component directly.
• src/index.html: The main HTML page that hosts your application. This is the standard index.html that serves all root requests in a web page and contains the tag where your Angular component will render. It is the “body” that the “spirit” of your code animates.
• src/app/app.ts: The root component of your application. This single file defines the view logic and the component metadata. In the new “standalone” world, it manages its own imports, meaning you can see exactly what dependencies it uses right at the top of the file. (This is the root element that appears in src/index.html.)
• src/app/app.config.ts: This file is new in modern Angular and replaces the old AppModule providers array. It is where you configure global services, like the router or HTTP client.
• angular.json: The configuration file for the CLI itself. It tells the build tools how to process your code, though you will rarely need to touch this file manually anymore.

Here is the basic flow of how the engine renders these components:

1. The arrival (HTML): The browser receives index.html. The tag is there, but it’s empty.
2. The unpacking (JavaScript): The browser sees the tags at the bottom of the HTML and downloads the JavaScript bundles (your compiled code) from src/app/app.ts.
3. The assembly (Bootstrap): The browser runs that JavaScript. The code “wakes up,” finds the tag in the DOM, and dynamically inserts your title, buttons, and lists.

This flow will be different if you are using server-side rendering (SSR), but we’ll leave that option aside for now. Now that you’ve seen the basic architecture, let’s get into the code.

Developing your first web app in Angular

If you open src/app/app.ts (more info here) the component definition looks like this:

import { Component, signal } from '@angular/core';
import { RouterOutlet } from '@angular/router';

@Component({
  selector: 'app-root',
  imports: [RouterOutlet],
  templateUrl: './app.html',
  styleUrl: './app.css'
})
export class App {
  protected readonly title = signal('iw-ng');
}

Before we dissect the code, let’s run the app and see what it produces:

$ ng serve

You should see a page like this one at localhost:4200:

Matthew Tyson

Returning to the src/app.ts component, notice that there are three main parts of the definition: the class, the metadata, and the view. Let’s unpack these separately.

The class (export class App)

Export class App is vanilla TypeScript that holds your component’s data and logic. In our example, title = signal(‘iw-ng’) defines a piece of reactive state. Unlike older versions of Angular where data was just a plain property, here we use a signal. Signals are wrappers around values that notify the template precisely when they change, enabling fine-grained performance.

The metadata (@Component)

The @Component decorator tells Angular it is dealing with a component, not just a generic class. There are several elements involved in the decorator’s communication with the engine:

• selector: 'app-root': Defines the custom HTML tag associated with any given component. Angular finds in your index.html and renders the component there.
• imports: In the new Angular era, dependencies are explicit. You list exactly what a component needs (like RouterOutlet or other components) here, rather than hiding them in a separate module file.
• templateUrl: Points to the external HTML file that defines the view.

The view (the template)

This is the visual part of the component, defined in app.html. It combines standard HTML with Angular’s template syntax. (JSX handles this part for React-based apps.)

We can modify src/app/app.html to see how these three elements work together. To start, delete the default content and add the following:

Hello, {{ title() }}

The double curly braces {{ }} are called interpolation. Notice the parentheses in title(). We are reading the “title” signal value by calling its function. If you were to update that signal programmatically (e.g., this.title.set('New Value')), the text on the screen would update instantly.

Angular’s built-in control flow

Old-school Angular required “structural directives” like *ngIf and *ngFor logic control. These were powerful but required importing CommonModule and learning a specific micro-syntax. Modern Angular uses a built-in control flow that looks like standard JavaScript (similar to other Reactive platforms).

To see the new control flow in action, let’s add a list to our component. Update src/app/app.ts as follows, leaving the rest of the file the same:

export class App {
  protected readonly title = signal('iw-ng');
  protected readonly frameworks = signal(['Angular', 'React', 'Vue', 'Svelte']);
  protected showList = signal(true);

  toggleList() {
    this.showList.update(v => !v);
  }
}

While we’re at it, let’s also update src/app/app.html to render this new list (don’t worry about for now; it just tells Angular where to render the framing template):

Toggle List

@if (showList()) {
  

    @for (tech of frameworks(); track tech) {
      
{{ tech }}
    }
  
} @else {
  
List is hidden
}

The app will now display a list that can be toggled for visibility:

Matthew Tyson

This syntax is cleaner and easier to read than the old *ngFor loops:

• @if conditionally renders the block if the signal’s value is true.
• @for iterates over the array. The track keyword is required for performance (it tells Angular how to identify unique items in the list).
• (click) is an event binding. It lets us run code (the toggleList method) when the user interacts with the button.

Services: Managing business logic in Angular

Components focus on the view (i.e., what you see). For the business logic that backs the application functionality, we use services.

A service is just a class that can be “injected” into a component that needs it. This is Angular’s famous dependency injection system. It allows you to write logic once and reuse it anywhere. It’s a slightly different way of thinking about how an application is wired together, but it gives you real organizational benefits over time.

To generate a service, you can use the CLI:

$ ng generate service frameworks

This command creates a src/app/hero.ts file. In modern Angular, we define services using the @Injectable decorator. Currently, the src/app/hero.ts file just has this:

import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root',
})
export class Frameworks {
  
}

Open the file and add a simple method to return our data:

import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root', // Available everywhere in the app
})
export class Frameworks {
  getList() {
    return ['Angular', 'React', 'Vue', 'Svelte'];
  }
}

The providedIn: 'root' metadata is important, it tells Angular to create a single, shared instance of this service for the entire application (you might recognize this as an instance of the singleton pattern).

Using the service

In the past, we had to list dependencies in the constructor. Modern Angular offers a cleaner way: the inject() function. Subsequently, we can refactor our src/app/app.ts to get its data from the service instead of hardcoding it:

import { Component, inject, signal } from '@angular/core';
import { RouterOutlet } from '@angular/router';
import { Frameworks } from './frameworks'; // Import the service

@Component({
  selector: 'app-root',
  imports: [RouterOutlet],
  templateUrl: './app.html',
  styleUrl: './app.css'
})
export class App {
  private frameworksService = inject(Frameworks); // Dependency Injection
  
  protected readonly title = signal('iw-ng');
  
  // Initialize signal with data directly from the service
  protected readonly frameworks = signal(this.frameworksService.getList());
  protected showList = signal(true);

  toggleList() {
    this.showList.update(v => !v);
  }
}

Dependency injection is a powerful pattern. The component doesn’t need to know where the list came from (it could be coming from an API, a database, or a hard-coded array); it just asks the service for what it needs. This pattern adds a bit of extra work up front, but it delivers a more flexible, organized codebase as the app grows in size and complexity.

Routers and routes

Once your application grows beyond a single view, you need a way to navigate between different screens. In Angular, we use the built-in router for this purpose. In our example project, src/app/app.routes.ts is the dedicated home for the router config. Let’s follow the steps for creating a new route.

First, we define the route. When you open src/app/app.routes.ts, you will see an exported routes array. This array contains the available routes for your app. Each string name resolves to a component that handles rendering that route. In effect, this is the map of your application’s landscape.

In a real application, you’d often have “framing template” material in the root of the app (like the navbar) and then the routes fill in the body content. (Remember that by default, Angular is designed for single-page apps, where navigation does reload the screen, but swaps content.)

For now, let’s just get a sense of how the router works. First, create a new component so we have a destination to travel to. In your terminal, run:

$ ng generate component details

This will generate a simple details component in the src/app/details directory.

Now we can update src/app/app.routes.ts to include this new path. We will also add a “default” path that redirects empty requests to the home view, ensuring the user always lands somewhere:

import { Routes } from '@angular/router';
import { App } from './app'; // Matches src/app/app.ts
import { Details } from './details/details'; // Matches src/app/details/details.ts

export const routes: Routes = [
  { path: '', redirectTo: '/home', pathMatch: 'full' },
  { path: 'home', component: App },
  { path: 'details', component: Details },
];

Now if you visit localhost:4200/home, you’ll get the message from the details component: “Details works!”

Next, we’ll use the routerLink directive to move between views without refreshing the page. In src/app/app.html, we create a navigation bar that sits permanently at the top of the page (the “stationary” element), while the router swaps the content below it (the “impermanent” element):

And with that, the application has a navigation flow. The user clicks, the URL updates, and the content transforms, all without the jarring flicker of a browser reload.

Parametrized routes

The last thing we’ll look at is handling route parameters, where the route accepts variables in the path. To manage this kind of dynamic data, you define a route with a variable, marked by a colon. Open src/app/app.routes.ts and add a dynamic path:

export const routes: Routes = [
  // ... existing routes
  { path: 'details/:id', component: Details }, 
];

The :id is a placeholder. Whether the URL is /details/42 or /details/108, this router will receive it because it matches the path. Inside the details component, we have access to this parameter (using the ActivatedRoute service or the new withComponentInputBinding). We can use that value to retrieve the data we need (like using it to recover a detail item from a database).

Conclusion

We have seen the core elements of modern Angular: Setting up the environment, building reactive components with signals, organizing logic with services, and tying it all together with interactive routing.

Deploying these pieces together is the basic work in Angular. Once you get comfortable with it, you have an extremely powerful platform at your fingertips. And, when you are ready to go deeper, there is a whole lot more to explore in Angular, including:

• State management: Beyond signals, Angular has support for managing complex, application-wide state.
• Forms: Angular has a robust system for handling user input.
• Signals: We only scratched the surface of signals here. Signals offer a powerful, fine-grained way to manage state changes.
• Build: You can learn more about producing production builds.
• RxJS: Takes reactive programming to the next level.

At Amazon Web Services (AWS), artificial intelligence is already compressing security work that once took months into minutes.

In the old world, human red teams would find vulnerabilities, write reports, refine those reports, and eventually hand them to defenders, who would then begin building detections or fixes, Steve Schmidt, chief security officer at AWS, tells CSO. That process could take “two, four, six, eight, 10 months,” Schmidt says.

“Now with proper application of AI, we can have the detections built for the problems the red team finds in 15 minutes-ish,” he says. “I think the outside is about four hours.”

That kind of workflow offers a glimpse of what AI could make possible for the most sophisticated security organizations: AI agents testing systems, other agents generating defenses, and human security engineers validating results and refining the feedback loop.

But it also raises a more uncomfortable question for the rest of the cybersecurity industry: What happens to organizations that cannot build anything close to that?

The concern has become significant enough that the Trump administration recently directed agencies to expand access to AI-enabled cybersecurity capabilities for resource-constrained organizations, including rural hospitals, community banks, and local utilities.

The order reflects a growing fear that AI could deepen a divide that has existed in cybersecurity for years: the divide between organizations with money, expertise, and engineering depth, and those struggling to keep pace with basic security demands.

Yet security leaders and practitioners suggest the impact of AI will be more complicated than a simple widening gap. Some experts say AI is merely adding a new layer to a long-standing security poverty problem. Others argue AI could democratize capabilities once reserved for elite organizations. Still others see today’s divide as real, but potentially temporary, as models become cheaper, more open, and easier to run.

The class divide was already here

For Matt Warner, co-founder and CTO of Blumira, the premise that AI is creating a cybersecurity class divide misses a key point: The divide already exists.

“I would go even a step further and say that there has been a class divide for the last 10 to 15 years,” Warner tells CSO.

What AI changes, he argues, is not necessarily the existence of the divide but how stark it becomes. Larger organizations have money, people, and time to experiment with AI. Smaller organizations often do not.

“The big differences that we’re seeing, especially from where we sit in the world, is the difference is getting starker in having the resources to leverage AI and the time to leverage AI more than anything else,” Warner says.

That distinction matters because many smaller organizations are already overwhelmed. Warner pointed to resource-constrained local governments and small or midmarket organizations that are still far behind large enterprises in basic IT and security maturity.

“I can find you a county in Michigan with two IT people for 2,000 employees,” Warner says. “Those people don’t have time to leverage AI and even learn how to use AI because they’re mostly just trying to put out fires.”

That problem is not unique to AI. Smaller organizations have long struggled to patch systems, prioritize vulnerabilities, monitor environments, and respond to incidents with limited staff. AI may help eventually, but only if those organizations have enough capacity to adopt it.

Wendy Nather’s framework gets an AI layer

Anton Chuvakin, security advisor in the office of the CISO for Google Cloud, sees the AI divide as part of a much older problem.

“I feel like it sends me back to when Wendy Nather invented the security poverty line,” Chuvakin tells CSO, referring to Nather’s 2011 concept describing organizations that lack the money, expertise, capability, or influence to implement effective security.

Chuvakin is skeptical that AI fundamentally changes that model. “I don’t think AI necessarily breaks that model,” he says. “I think it just adds another dimension.”

Cybersecurity has always been shaped by unequal access to top talent, tools, and services, Chuvakin argues. Large organizations could afford better SIEM deployments, advanced DLP programs, threat hunters, application security experts, and incident response retainers. Smaller organizations often could not.

AI may become another scarce resource, but Chuvakin cautions against overstating the role of model cost alone. In his view, the bigger structural issue may be talent rather than tokens.

“Prices for people won’t drop, but prices for LLMs may drop,” he believes.

That means the organizations with the greatest advantage may not simply be those that can afford the most expensive models. They may be the ones that can afford the people who know how to use them — and, as the frontier-access debate below suggests, that talent gap may prove more durable than any gap in model access itself.

AI creates new costs — and new uncertainties

Nather herself, now senior research initiatives director at 1Password, sees AI affecting every dimension of the security poverty line: money, expertise, capability, and influence.

The financial challenges are not limited to whether an organization can pay for an AI tool. In some cases, organizations that cannot afford enterprise licensing may end up making tradeoffs around privacy.

“If an organization can’t afford an enterprise license for the models they’re using, then they can’t keep their data private,” Nather tells CSO. “So, they have to give up privacy because they can’t afford privacy.”

That’s a new twist on an old dimension of the poverty line: It’s not just that under-resourced organizations lack a capability, but that the capability they can afford comes bundled with a risk wealthier organizations don’t have to accept.

Token-based pricing adds another problem: unpredictability. “At this point, nobody knows how much they’re going to burn in tokens at any given time,” she says.

That makes budgeting difficult for organizations that cannot absorb surprise costs. Nather also warns that usage-based pricing is controlled by providers and can change over time, leaving customers with limited leverage.

“The charging practice is in the hands of the providers, and they can change it at any time,” she says.

For organizations already operating below the security poverty line, that uncertainty could make AI adoption harder, even if the technology itself becomes more capable.

Access to frontier models may be a temporary divide

Dave Baggett, SVP/GM of the security suite at Kaseya, agrees there is security class divide dynamic playing out today, particularly around access to frontier models.

“There’s definitely a haves and have-nots issue around Mythos specifically because most people don’t have it,” Baggett tells CSO. But he doesn’t think the divide will have a long-term impact. Open-weight models, quantization, mixture-of-experts architectures, and increasingly powerful commodity hardware, he argues, are closing the gap faster than most people expect.

While not every organization will build a frontier model, he says, more organizations may be able to run capable models locally or use cheaper systems that approximate what today’s elite models can do.

“What it says for finding vulnerabilities is at that point, open-source people can run this stuff,” Baggett says. “Then you’re back to having a symmetrical opportunity where the defenders who are writing the open source can run the same tools the attackers would and have them fix the issues.”

His bottom line is that the divide may be real but short-lived. “Right now, there certainly is a have, have-not schism, but it may not be there for long,” Baggett says — a view Chuvakin shares, though he frames it in terms of the model market rather than open source specifically.

“I don’t think it’s the lowering prices example, but it’s more like you’re a top-tier model maker, I’m a second-tier model maker. My model in a year would do what your model did a year ago,” Chuvakin says.

The real advantage is operational depth

Schmidt’s description of AI use at AWS points to another kind of divide: not access to AI, but the ability to operationalize it.

AWS uses multiple models for different tasks, Schmidt says. One model may discover vulnerabilities, while other models validate results or help build defenses. Humans remain accountable for evaluating what the systems produce.

“Because we believe really strongly in human accountability for the use of AI from end to end, we still have humans take a look at what the systems come up with to determine whether they are reasonable and appropriate,” he says.

That workflow requires more than a model. It requires corporate data, secure infrastructure, feedback loops, security engineers, data scientists, and AI specialists who can work together.

Schmidt also pushes back on the idea that running AI locally on powerful consumer hardware is a substitute for production-grade security infrastructure. “Often the value of the model is also dependent on its proximity to data so that the model can ingest, use, and reason about data,” he says. “As a security person, I do not want that to be on your laptop.”

Experimentation on a laptop is useful, Schmidt says, but it is not the same as a secure production environment.

“I want the data to be somewhere safe that I can control, that I can see, that I can reason about, not sitting on your laptop,” he says. “Experimentation in there, awesome. That’s great. But it is not a production infrastructure component.”

That distinction may define the emerging AI security gap. Many organizations may be able to access AI tools. Far fewer may be able to safely integrate them into real security workflows.

The democratization argument

Phil Venables, a partner at Ballistic Ventures and former CISO of Google Cloud, takes the most optimistic view.

Asked whether AI is widening the gap between well-resourced and under-resourced security organizations, Venables tells CSO, “No, I actually think it’s the exact opposite.”

The reason, he argues, is that AI packages expertise and automation in ways that can be delivered broadly. “One of the fantastic things about AI, and we’re already starting to see this, is [that it’s] a great democratizer of capabilities,” he says. “AI packages up expertise and automation capabilities at a level beyond what prior waves of technology have done, and it makes it available at scale into organizations that have not previously been able to afford these things.”

He points to red teaming as an example. Nearly every organization would like a world-class red team, but few can afford one.

“Pretty much every organization on the planet would love to have a world-class red team to constantly test their security to find and fix things before attackers do,” Venables says. “But very few organizations have ever been able to afford to build a high-end red team.”

AI agents, he argues, could make that kind of capability available more economically. The same pattern could apply to insider threat; third-party risk; software security; governance, risk and compliance; and security operations.

“So even the smallest and resource-constrained organizations can now have access to a higher-end capability,” he maintains.

Venables does see a danger zone, however: under-resourced security teams inside organizations with aggressive AI ambitions. Those teams may struggle to keep up as the rest of the business adopts AI rapidly. But for many small and midsize organizations, he believes AI could improve access to security capabilities they never had before.

A divide over AI — or over readiness?

For elite organizations, AI is already becoming a force multiplier. Security teams with deep engineering talent, mature data infrastructure, and strong governance can use AI to accelerate testing, detection engineering, vulnerability discovery, and risk management.

For smaller organizations, the picture is less clear. AI may eventually package scarce expertise into affordable services. Open models may reduce dependence on expensive frontier systems. But organizations below the security poverty line still face familiar constraints: too few people, too little time, limited expertise, unpredictable costs, and weak leverage over vendors.

The emerging divide may therefore be less about who has access to AI and more about who can turn AI into durable security outcomes.

That makes the question facing cybersecurity more complicated than whether AI will create haves and have-nots. The industry already had them.

The real question is whether AI becomes another technology that rewards the organizations already best positioned to use it — or the first major security advance in years that helps those below the poverty line finally catch up.

A security hole within AI dev tools has allowed attackers to escape sandboxes by misleading the humans in the loop who were supposed to knowingly approve the tool’s actions, according to cybersecurity research firm Wiz.

“We discovered GhostApproval, a systematic vulnerability pattern affecting six of the top AI coding assistants: Amazon Q Developer, Anthropic Claude Code, Augment, Cursor, Google Antigravity, and Windsurf [now known as Devin Desktop],” the Wiz report said. “In each case, a malicious repository can trick the agent into accessing arbitrary files outside the workspace sandbox, potentially achieving remote code execution on the developer’s machine.”

The first report of the hole came earlier this month from Cato Networks, but was limited to one platform, Cursor, whereas Wiz found that its impact was far wider. 

The underlying security problem, symbolic links (symlinks), is well known and has been leveraged for decades. But GhostApproval, Wiz noted, goes well beyond their historic use as an attack vector. 

Symbolic links are special files that act as shortcuts to other files or directories. In attacks, they typically resolve to a target outside of the intended control sphere, which allows a threat actor to operate on unauthorized files in a less- or uncontrolled environment, outside of a secure sandbox, or even an air-gapped system.

“In several cases,” Wiz noted, “the agent’s internal reasoning explicitly recognizes the dangerous target, yet the confirmation prompt shown to the user conceals this information entirely. This is CWE-451 – UI misrepresentation of critical information – layered on top of the symlink vulnerability. The user approves what they believe is a harmless local edit. The agent then writes to a sensitive file outside of the project workspace.”

Wiz said it reported the issue to the six vendors initially impacted; AWS, Cursor and Google “fixed the issue promptly,” Augment and Windsurf/Devin “acknowledged receipt but went silent,” and Anthropic had already fixed the problem before it was contacted by Wiz.

Potentially massive exposure

But analysts and consultants said the AI dev tool problem that Wiz described illustrates a far greater security risk: enterprises are trusting these tools and the information they report far too much, which is what may give attackers a big opportunity.

Katie Norton, senior research manager for DevSecOps at IDC, noted that the Wiz report pointed out a disturbing fact. “The safety check people rely on to catch these actions doesn’t actually stop anything. That’s a real way for an attacker to break into a developer’s machine,” she said. “The scope is bounded by one condition: the attack requires a developer to clone and operate on an untrusted or malicious repository. That concentrates the risk in workflows touching external contributors, forked repositories, and third-party or open source dependencies, rather than in internally authored code.”

Norton said the exposure from this flaw, along with similar holes in other AI dev tools, is potentially massive. “Since March 2025, security vendors and researchers have disclosed comparable issues in nearly every major AI coding assistant. That pattern: a mitigation ships, then a new bypass of that same mitigation surfaces within months. That is worth watching and reflects how new this category’s threat model still is across the board, it’s not a gap specific to any one vendor’s practices.”

That means, she said, that agentic coding tools need multilayered defense, because the risk isn’t confined to the code an agent generates. “The tools themselves sit within the software supply chain and can be attacked directly. GhostApproval makes that point clearly,” she noted.

“The vulnerability has nothing to do with code quality or insecure output. It’s a flaw in how the agent handles files and represents its own actions to the user, introduced by the tool’s design rather than a bad prompt or a compromised dependency. Failure to account for the coding tools’ own attack surface is what leaves this kind of gap unaddressed.”

Rethink policies and procedures

Noah Kenney, principal consultant at Digital 520, agreed; enterprise CISOs need to potentially rethink many of their AI dev tool policies and procedures. 

“The significant part is that the agent’s own reasoning identified the malicious target and the approval dialog hid it anyway. The tool knew it was writing to SSH keys and still asked a human to approve an edit to a config file, giving the human an illusion of control over the model,” Kenney said. “Many considered human in the loop to be the answer to agent risk, but this report shows that the loop can be fed bad information by the very agent it is supposed to be supervising.”

Because of this, Kenney advised adjusting the way tool management is enforced.

“Treat AI coding assistants as privileged software with filesystem access, not as editor plugins. That means patch discipline, version pinning, and knowing which tools in your environment write to disk before authorization,” Kenney said. “Then sandbox the blast radius. These agents should run against trusted repositories in isolated environments where a write to authorized_keys goes nowhere. Do not rely on the tool’s own dialog as your control or governance solution.”

A category-wide design issue

Justin Greis, CEO of consulting firm Acceligence, added that this security hole is a much bigger enterprise security strategy problem than most CISOs realize. 

“Six different vendors independently arrived at a very similar trust model. That suggests we’re looking at a category-wide design challenge rather than a collection of isolated implementation bugs. If vulnerabilities like this remained uncorrected, they would represent a meaningful enterprise risk, particularly for organizations that allow AI coding assistants to interact with untrusted repositories or production development environments,” he said.

“The immediate concern isn’t simply remote code execution. It’s that these agents operate with a level of filesystem access, tool access, and developer trust that traditional IDE extensions never had. Once an AI agent becomes an active participant in software development, every trust boundary it crosses becomes part of the organization’s attack surface.”

A security hole within AI dev tools has allowed attackers to escape sandboxes by misleading the humans in the loop who were supposed to knowingly approve the tool’s actions, according to cybersecurity research firm Wiz.

“We discovered GhostApproval, a systematic vulnerability pattern affecting six of the top AI coding assistants: Amazon Q Developer, Anthropic Claude Code, Augment, Cursor, Google Antigravity, and Windsurf [now known as Devin Desktop],” the Wiz report said. “In each case, a malicious repository can trick the agent into accessing arbitrary files outside the workspace sandbox, potentially achieving remote code execution on the developer’s machine.”

The first report of the hole came earlier this month from Cato Networks, but was limited to one platform, Cursor, whereas Wiz found that its impact was far wider. 

The underlying security problem, symbolic links (symlinks), is well known and has been leveraged for decades. But GhostApproval, Wiz noted, goes well beyond their historic use as an attack vector. 

Symbolic links are special files that act as shortcuts to other files or directories. In attacks, they typically resolve to a target outside of the intended control sphere, which allows a threat actor to operate on unauthorized files in a less- or uncontrolled environment, outside of a secure sandbox, or even an air-gapped system.

“In several cases,” Wiz noted, “the agent’s internal reasoning explicitly recognizes the dangerous target, yet the confirmation prompt shown to the user conceals this information entirely. This is CWE-451 – UI misrepresentation of critical information – layered on top of the symlink vulnerability. The user approves what they believe is a harmless local edit. The agent then writes to a sensitive file outside of the project workspace.”

Wiz said it reported the issue to the six vendors initially impacted; AWS, Cursor and Google “fixed the issue promptly,” Augment and Windsurf/Devin “acknowledged receipt but went silent,” and Anthropic had already fixed the problem before it was contacted by Wiz.

Potentially massive exposure

But analysts and consultants said the AI dev tool problem that Wiz described illustrates a far greater security risk: enterprises are trusting these tools and the information they report far too much, which is what may give attackers a big opportunity.

Katie Norton, senior research manager for DevSecOps at IDC, noted that the Wiz report pointed out a disturbing fact. “The safety check people rely on to catch these actions doesn’t actually stop anything. That’s a real way for an attacker to break into a developer’s machine,” she said. “The scope is bounded by one condition: the attack requires a developer to clone and operate on an untrusted or malicious repository. That concentrates the risk in workflows touching external contributors, forked repositories, and third-party or open source dependencies, rather than in internally authored code.”

Norton said the exposure from this flaw, along with similar holes in other AI dev tools, is potentially massive. “Since March 2025, security vendors and researchers have disclosed comparable issues in nearly every major AI coding assistant. That pattern: a mitigation ships, then a new bypass of that same mitigation surfaces within months. That is worth watching and reflects how new this category’s threat model still is across the board, it’s not a gap specific to any one vendor’s practices.”

That means, she said, that agentic coding tools need multilayered defense, because the risk isn’t confined to the code an agent generates. “The tools themselves sit within the software supply chain and can be attacked directly. GhostApproval makes that point clearly,” she noted.

“The vulnerability has nothing to do with code quality or insecure output. It’s a flaw in how the agent handles files and represents its own actions to the user, introduced by the tool’s design rather than a bad prompt or a compromised dependency. Failure to account for the coding tools’ own attack surface is what leaves this kind of gap unaddressed.”

Rethink policies and procedures

Noah Kenney, principal consultant at Digital 520, agreed; enterprise CISOs need to potentially rethink many of their AI dev tool policies and procedures. 

“The significant part is that the agent’s own reasoning identified the malicious target and the approval dialog hid it anyway. The tool knew it was writing to SSH keys and still asked a human to approve an edit to a config file, giving the human an illusion of control over the model,” Kenney said. “Many considered human in the loop to be the answer to agent risk, but this report shows that the loop can be fed bad information by the very agent it is supposed to be supervising.”

Because of this, Kenney advised adjusting the way tool management is enforced.

“Treat AI coding assistants as privileged software with filesystem access, not as editor plugins. That means patch discipline, version pinning, and knowing which tools in your environment write to disk before authorization,” Kenney said. “Then sandbox the blast radius. These agents should run against trusted repositories in isolated environments where a write to authorized_keys goes nowhere. Do not rely on the tool’s own dialog as your control or governance solution.”

A category-wide design issue

Justin Greis, CEO of consulting firm Acceligence, added that this security hole is a much bigger enterprise security strategy problem than most CISOs realize. 

“Six different vendors independently arrived at a very similar trust model. That suggests we’re looking at a category-wide design challenge rather than a collection of isolated implementation bugs. If vulnerabilities like this remained uncorrected, they would represent a meaningful enterprise risk, particularly for organizations that allow AI coding assistants to interact with untrusted repositories or production development environments,” he said.

“The immediate concern isn’t simply remote code execution. It’s that these agents operate with a level of filesystem access, tool access, and developer trust that traditional IDE extensions never had. Once an AI agent becomes an active participant in software development, every trust boundary it crosses becomes part of the organization’s attack surface.”

This article originally appeared on CSOonline.

It has been a year or so since Microsoft announced its plans to move TypeScript to a new, native runtime based on the Go language. Those first releases were unfinished (you had to compile them yourself) but showed promise, getting close to the expected 10x speed-up. That year has been one of steady progress, with Microsoft recently announcing the delivery of a release candidate build.

This release candidate is ready for use. It installs from npm like previous versions, and like earlier builds it works in much the same way as previous versions of TypeScript, checking types in your code, compiling it to run on ECMAScript-compliant JavaScript engines, and running just about anywhere. In addition, a native preview of the TypeScript language server for Visual Studio Code is available to help you write new TypeScript code and guide you through updating existing applications to the new language features.

All you need to do is enable the TypeScript 7 extension through the Visual Studio command palette and start coding. There’s a lot of work going on to get the new tooling ready for the final release of TypeScript 7, and new versions of the language server are being released almost daily. It’s certainly popular, too, with nearly half a million downloads at the time of writing.

What makes TypeScript 7 so much faster?

So how is this new TypeScript so much faster? Key to the improvements is a shift to a new native compiler built in Go. This has allowed the team to change how it operates, adding parallelization where possible. In some cases, this isn’t easy, such as when type checking large codebases split across many files.

Here TypeScript spawns a small number of checker workers that run across your codebase. They work independently, so can duplicate the work — though the output will be the same. You can choose your own number of checkers, but the more you use, the more memory and CPU will be required.

Large monorepos with many projects require a similar approach with independent builder workers. You’ll need to balance this with the number of checkers in use, as this can cause significant resource issues.

There are some significant language and configuration changes from TypeScript 5 (TypeScript 6 has the same changes, which makes it a useful tool for experimenting with migrations). It’s well worth reading the release candidate documentation to understand how these will affect your code, as well as using the TypeScript 7 extension for Visual Studio Code to identify where you need to make changes.

Working with users to build language tools

One important aspect to the development of TypeScript 7 has been collaboration with existing users of the language and its tooling, as well as using the existing suite of TypeScript test tools that have been used to evaluate other versions. As this update is primarily a port of existing code, rather than a bottom-up rewrite, the underlying language semantics and structure are the same as those used in the original JavaScript codebase, ensuring that code will quickly port from old to new versions.

A major internal collaborator was the Visual Studio Code team, who have been using TypeScript to develop the familiar cross-platform development tool. It’s an important partnership between tool and language, as VS Code is a key TypeScript development tool, hosting TypeScript’s language server and using its compiler to provide debugging and code completion features.

The VS Code team published a long blog post detailing how it has been working with the Go-based TypeScript. The team is both helping to develop the language and beginning the process of moving its codebase to the newer, faster, native platform.

How the VS Code team migrated is a useful case study, one that can help you move your TypeScript development more efficiently and with minimal risk. The team began working with extensions, using daily builds of TypeScript to ensure that bugs and issues could be reported as they occurred and would only have a limited impact as fixes could be rolled out quickly. At the same time, the VS Code team began using a preview version of the TypeScript 7 extension for VS Code, which was being built around the new compiler in parallel with its development.

Bridging development with TypeScript 6

The development of TypeScript 6 as a bridge between TypeScript 5 and TypeScript 7 allowed the VS Code team to transition to code that targeted a newer version of ECMAScript and provided more powerful checks. By moving code from TypeScript 5 to TypeScript 6, developers could validate it with what would become TypeScript 7 language features and get speed and performance boosts while doing so (though nowhere near what TypeScript 7 promised). By completing this first migration of the VS Code codebase, it was possible for developers to be confident that they were ready to shift to the Go-based version when it shipped.

The parallel development of the new language server and extension ensured that by late 2025 it was possible for VS Code development to shift to TypeScript 7, with TypeScript 6 used as a fallback if there were any issues. Those cases could then be reported back to the TypeScript team and used to prioritize development.

As the platform evolved, the use cases for the VS Code team changed. By early 2026 TypeScript 7 was stable and nearly feature-complete, so the team began to use it to build all of their own built-in extensions. This allowed them to rethink their toolchain, changing the bundler from webpack to the one built into esbuild, giving them another speed up. Once that process was tested and working, they could switch all development to TypeScript 7.

Having such a big project take on TypeScript 7 early reaped big rewards, as the resulting virtuous cycle allowed both VS Code and TypeScript to move forward together, fixing issues as they arose and providing valuable feedback. The results speak for themselves. Type checking the entire VS Code codebase is now 7x faster, with most extensions checked in under a second. The only exception was GitHub Copilot, which is almost as big as the editor itself, which type checked in 2.5 seconds.

Compilation has been sped up, dropping from 80 seconds to around 20 seconds. This may not seem a lot, but when you’re compiling and rebuilding and debugging, each change in your code now takes a lot less time. That improves developer productivity and ensures they stay in flow, rather than switching away to check email or Teams each time they start a new build. The same goes for using the language server, where loading the entire project (necessary for error detection and refactoring) now takes 10 seconds rather than a minute.

Lots of little time savings like this add up across a big project and a large team, helping developers stay focused and able to solve problems more effectively. The VS Code blog post notes that it cuts down on coffee runs, which take longer than the load or build that inspire a quick cuppa!

Getting ready for TypeScript 7 in your build pipeline

Microsoft is quick to point out that, while the TypeScript 7.0 release will be production ready, TypeScript 7 won’t have a full programmatic API until the release of TypeScript 7.1. As this won’t be for some time, Microsoft is providing a way to run TypeScript 7 side-by-side with TypeScript 6.

Installing the @typescript/typescript6 compatibility package alongside TypeScript 7 adds a new executable, tsc6, that allows you to modify code that uses the TypeScript 5 API to run using TypeScript 6, by renaming the calls to tsc in your scripts to tsc6. This should allow you to keep building to the latest releases at the same time as starting to experiment with using the new runtime.

It’s not a perfect fix. You do need to do some work to implement npm aliases that allow linters and other low-level tools to work with both versions. You can also provide two different dependencies in your package.json to allow TypeScript 6 (tsc6) and TypeScript 7 (tsc) to run side-by-side. The result is a way to help migrate TypeScript code to the newer platform, delivering more efficient code that runs on a more modern ECMAScript in the meantime.

TypeScript 7 will be a big upgrade, though it has taken surprisingly little time to deliver. With users like the Visual Studio Code team already building on the new release, it’s clear that beginning your own migration should be easier than you might have thought.

The final release is due sometime in July 2026. If you haven’t started looking at TypeScript 7, now is the time to start.

Power consumption worldwide for data centers is projected to grow to 565 terawatt hours (TWh) in 2026, up 26% from 447 TWh in 2025, with AI-oriented data centers taking up an increasing amount of the pie.

Worldwide data center power demand is expected to rise 27% in 2026 and reach 133 gigawatts (GW), up from 105GW in 2025. It is projected to reach 291GW by 2030, which reflects the unprecedented scale and pace of GenAI boosting demand.

Those figures consider variables like parts and supply shortages, delayed or cancelled data center projects, and the impact of the conflict with Iran, said Linglan Wang, director analyst and lead economist at Gartner.

AI-optimized servers are a relatively new phenomenon but they have rapidly gained uh traditional data centers in terms of power use. Gartner estimates AI-optimized server adoption will account for 31% of data center power consumption in 2026, and that by 2027 their power consumption will surpass that of conventional servers.

“Surging demand for compute-intensive AI workloads is driving unprecedented data center power growth, while AI capacity is now constrained by power availability, making data center power security the new battle ground for scaling and protecting margins in the global AI race,” said Wang in a statement.

Wang said of the 565TWh consumed this year, the U.S. will account for about 204TWh, or 36% of the total amount consumed. And of the 204TWh consumed this year, dedicated AI data centers will consume 68TWh, or one-third of the total. So in just five years, AI data centers have gone from zero to of the total power consumption in the US.

Non-AI data center growth has been minimal by comparison.

The difference in growth of power consumption between conventional servers and AI-optimized servers is remarkable. Worldwide, conventional servers consumed 193 terawatt hours (TWh) of power in 2025 and are projected to rise 1.2% to 195 TWh in 2026 and another 2.4% in 2027 to 200 TWh This 3% basic growth will continue to 2030.

Now compare that to the AI-optimized servers. They consumed 95 TWh of power in 2025, rose 84.2% to 175 TWh in 2026 and another 47.8% to 258 TWh in 2027. By 2030, Wang estimates AI-optimized servers will account for near half of all power consumed by data centers worldwide.

With data center power electricity consumption estimated to reach over 1,200TWh by 2030, grid supply will be insufficient to meet the demands of future data center construction, affecting all data center users.

“Infrastructure and operations leaders must prioritize efficiency upgrades and secure grid access. They also need to invest in high-efficiency cooling systems and edge computing to mitigate power constraints and ensure sustainable, scalable growth,” Wang said.

The key ingredient for successful AI deployment is largely becoming the talent available, not the AI tools installed, putting pressure on IT leaders to upskill their workforces.

With AI skills both the highest in demand and the hardest to hire for, many IT leaders and their C-suite colleagues are rolling out comprehensive AI training programs for employees, both for the IT pros who build AI tools and the business users who will use them.

Smart companies will need to invest heavily in upskilling, says Chris Campbell, CIO at DeVry University. “The pace of change is simply too fast to rely solely on external hiring,” he says. “Organizations that develop AI capabilities across their existing workforce will have an advantage over those trying to win a bidding war for a relatively small pool of experts.”

Moreover, the key elements of what leads to a beneficial AI deployment has changed over time, he says.

“Early on, everyone was worried about access to AI tools,” Campbell adds. “Today, the tools are everywhere. What I see organizations struggling with is figuring out how to apply them to real business problems and integrate them into how work actually gets done.”

At DeVry, some of the strongest AI advocates don’t come from traditional AI backgrounds, but from software engineering, business analysis, cybersecurity, project management, and operations, he says.

“They understand the business, know where the friction points are, and can see where AI can create value,” he adds. “Those skills are often more important than deep expertise in a particular model or tool.”

Experienced AI talent is difficult to find, especially when IT leaders seek candidates who have successfully transitioned AI initiatives from experimentation to production.

“I don’t think every company needs to build a large team of AI specialists,” Campbell says. “In many cases, the people best positioned to drive AI adoption are already inside the organization.”

Upskilling for an AI builder culture

Professional services and accounting firm KPMG is addressing its AI talent challenge by providing widespread AI training to employees, says Rema Serafi, vice chairwoman for tax operations there. Many organizations’ major AI problem in 2026 is a lack of talent, not a lack of technology, she adds.

Forty percent of CIOs surveyed for this year’s State of the CIO report cited lack of in-house talent as a top impediment to implementing their AI strategies.

To address this, KPMG has piloted a six-week AI training program, with the goal of enabling all employees to deploy their own AI tools, Serafi says. The program familiarizes employees with Python and other technologies that serve as building blocks for internal AI tools, she says.

KPMG also revamped its team structures to ensure that three categories of employees — AI power users, makers, and builders — work closely together, says Serafi.

“Everyone’s going to have access to our tools, and everyone’s going to be a power user,” she says, “to the extent that those professionals who didn’t come in with AI capabilities, who didn’t come in as engineers or technologists, if they want to learn, we’re going to certify them to build tools as well.”

Deploying sophisticated, best-in-class AI tools without training employees is like buying an F1 racing car but not hiring a professional driver, she says.

“If we don’t have professionals who know how to use it, they’re not going to be able to maximize the benefit of what’s available to them,” Serafi adds.

KPMG commissioned a study with the University of Texas and found that employees who use AI regularly produce higher-quality work and feel less stressed. Employees who are expert users of AI will progress faster in their careers, she suggests. One challenge for training programs, though, is keeping up with how fast AI is evolving.

“The roles are actually changing in a short period of time,” she says. “When you used to see traditional engineers working with AI, now you see professionals who can actually guide, shape, and direct AI in their client work.”

Retraining: ‘The only realistic path forward’

Another fan of comprehensive AI training for employees is Elmer Morales, founder and CEO of agentic AI coding startup koder.com. Finding outside AI talent has become extremely difficult for most companies, he says.

“Retraining isn’t optional anymore,” he says. “It’s the only realistic path forward for most organizations. The external talent market can’t supply what every company simultaneously needs, and waiting for universities to catch up isn’t a strategy.”

Companies that succeed with AI treat upskilling as a core investment, not just an HR initiative, Morales adds.

“The talent gap is the single most concrete ceiling on AI ambition right now,” he says. “Companies can buy the best models, the best infrastructure, and the best tooling, and still produce nothing of value because they don’t have the people who know how to wire it all together into something that actually works in production.”

Morales suggests that IT leaders look to their existing engineering team to build AI deployment talent.

“The engineers already obsessed with this on nights and weekends, who are shipping personal projects and experimenting with new models, those people just need permission, resources, and a real problem to solve,” he says. “The best AI teams I’ve seen weren’t built by recruiting, but by creating the conditions for the right people to step forward.”

Higher education has consolidated its entire academic operation into a handful of massive SaaS platforms. The LMS manages instruction, grading and communication. The SIS owns enrollment, records and financial aid. Identity and productivity live in a small number of cloud providers. These are not peripheral tools — they are the operational infrastructure of the institution. As IT stewards, we manage platforms we do not own, cannot restore ourselves and cannot directly control — which makes contingency planning not optional, but fundamental to the role.

The contracts are in place. The SLAs are signed. The compliance certifications are current. None of that matters to a student who cannot reach her instructor three days before finals. None of it matters to a faculty member who has no roster, no grade book and no way to document the work his students submitted before the platform went dark. SLAs govern vendor response timelines. Keeping academic operations running during that response window is IT’s responsibility.

The disruption hit during finals week 2026, and I was doing what every CIO in higher education was doing — monitoring. A major learning management system had been breached. The disruption spread fast. Finals were canceled. Exams were postponed. Students and staff were stranded without access to coursework, rosters or grade books. The costs — in academic disruption, extended contracts, emergency response — were substantial and widely reported. My institution was not directly impacted. But watching peer institutions in my own state go dark during the highest-stakes moment of the academic calendar was not reassuring. It was a confirmation of something I had been thinking about for a long time.

The disruption proved something IT professionals have relearned in every decade of their careers. Mark Twain observed that history does not repeat itself, but it does rhyme. This is a verse we have heard before: Dependence on a single point of failure, without a tested contingency plan, is not a strategy — it is a risk that has simply not yet been called. Whether the failure comes from a cyberattack, a vendor outage, an infrastructure collapse or a cloud provider’s bad deployment, the result is the same. The institution stops. And no SLA, contract or compliance certification prevents that moment from arriving.

Vigilance is not optional. Technologies are evolving faster than any IT team can fully anticipate. New platforms, new integrations, new dependencies emerge constantly — and with each one comes a new potential failure point. That is not an argument against adopting new technology. It is an argument for the one principle that never becomes obsolete: Reliance on any single critical system, whether it is a connectivity provider, an identity platform or a SaaS solution, is a proven strategy for failure. The question is never whether that system will fail. The question is whether the institution is prepared when it does.

Single points of failure fail — inevitably, and at the worst possible time. IT professionals have known this for thirty years. The SaaS layer is not exempt.

This is not a new lesson. Azure has gone down. AWS has failed. Google Workspace has had outages that took organizations dark globally. No campus runs a single ISP connection — we provision redundant circuits, preferably from independent providers, because we learned long ago that the connection will sometimes fail and the institution cannot afford to stop when it does. Financial services, government and multinational enterprises applied that same logic to every dependency in their stack. Their response to platform risk was not to demand better SLAs. It was to architect around the dependency. Redundancy. Failover. Independent continuity capability. The massive disruptions from Canvas demonstrate that effective contingency solutions for these critical platforms have not kept pace with our dependence on them. We cannot get fooled again.

That omission is what made the 2026 attack so damaging. Not the sophistication of the breach — the entry point was a peripheral free-tier environment that wasn’t even within the vendor’s primary certification scope. The damage was catastrophic because institutions had no fallback. Faculty had no rosters. Administrators had no enrollment data. There was no continuity layer. A single point of failure, at institutional scale, with no plan for when it fails.

And now the economics have shifted in the worst possible direction. PowerSchool paid a ransom in December 2024 after attackers stole data on 60 million students — and was re-extorted anyway, with individual school districts receiving separate demands months later using the same stolen data. Instructure’s CEO publicly confirmed the extortion payment. Anyone who has paid a ransom only to be hit a second time at double the cost can tell you — paying the attackers resolves nothing and instead invites more attacks. The sector has now proven twice, publicly, and at scale, that it will pay. That changes the threat calculus entirely. Higher education stops being a target of opportunity and becomes a target of strategy. Criminal groups share that intelligence. Banner serves over 1,400 institutions. Blackboard reaches tens of millions of users across thousands of campuses. Every major higher education SaaS platform is now on active threat actor priority lists — not because they are newly vulnerable, but because the sector has proven it will pay, that academic calendar pressure creates maximum leverage, and that IT has not yet built the operational alternative that our dependence on these platforms demands — and therefore the failure is ours to own, especially if we allow it to happen a second time.

The sector has proven it will pay. Every ransomware group operating today just received the same market signal. What follows is not unpredictable — it is documented, underway and aimed directly at the platforms carrying your institution’s academic operations.

As a CIO, my approach to this is not a spreadsheet or a stack of printed reports. IT is responsible for identifying critical failure points and countering them — that is not optional; it is the job. Accepting failure as inevitable without a mitigation strategy is not viable. Redundancy and continuity solutions are standard practice everywhere else in our infrastructure. There was no reason the SaaS layer should be different.

A leader’s first job isn’t to be right — it’s to be responsible.

The solution I implemented is a secure, read-only, centralized repository — a continuity strategy that ensures students, staff and faculty can continue to function whether the issue is a power outage, a cyberattack or a SaaS platform going dark. It is not a replacement for Canvas or Banner. It is the independent fallback that allows the institution to keep operating while the primary system is restored. I have learned the hard way that accepting failure without a plan is not a posture any CIO can defend.

Watching the frustration across the industry during and after the 2026 attack — institutions paralyzed, peer CIOs improvising, faculty working from personal spreadsheets, boards asking questions no one could answer — the logic of extending this capability to other institutions became unavoidable. The solution is not complex. The architecture is straightforward. The discipline behind it is thirty years old. The discipline is established. The responsibility to apply it is our field of expertise in IT.

To be precise about scope: An ACR does not prevent vendor breaches, replace cyber insurance or remove notification obligations. When an incident hits, legal counsel, security teams and institutional leadership still manage the response. What the ACR changes is what they have to work with — a governed, auditable record of what data was accessed, what manual actions were taken and how operations continued while the vendor worked to restore service.

Redundancy, disaster recovery, continuity of operations — the discipline is not new. The SaaS platforms carrying academic operations deserve the same standard we hold everywhere else.

The solution to this problem exists. A SaaS third-party continuity of operations strategy requires an independent data layer — one the institution controls, synchronized on a regular scheduled cycle from source systems, and accessible when those systems are not. Platform-agnostic across Canvas, Banner, Blackboard and PowerSchool. Read-only by design. Auditable by requirement. Independent by architecture. That last word is the one that matters — independent of the platforms whose availability you cannot guarantee.

Every CIO in higher education knows what a single point of failure looks like. Every one of us has built around them at every other layer. Servers, networks, data centers — we do not accept the single-point risk, and we do not wait for the failure to motivate the fix. The SaaS layer is not an exception.

The question is not whether your institution will face it. The question is whether you will have a continuity strategy in place when it arrives — or be explaining to your board why you did not.

Leaders don’t rent accountability — they own it outright.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Microsoft

Azure Linux 4.0 – ein Open-Source-Betriebssystem auf Linux-Basis – wurde auf der Entwicklerkonferenz Build 2026 von Microsoft vorgestellt. Im Gegensatz zu früheren Versionen soll Microsofts Linux-Distribution nun kostenlos verfügbar sein.

Technisch basiert Azure Linux 4.0 auf Fedora 43 und nutzt dasselbe RPM-basierte Paketverwaltungssystem. Berichten zufolge wurde das Linux-Derivat optimiert, um Workloads auf dem Azure-Cloud-Dienst auszuführen. Um Fehlerbehebungen und Sicherheits-Updates will sich Microsoft kümmern.

Azure Linux 4.0 ist nicht für Endverbraucher konzipiert und deshalb textbasiert. Deswegen beträgt die Größe auch nur knapp unter 300 Megabyte.

Es kann ab sofort über den Microsoft Marketplace heruntergeladen werden. (tf)

Dieser Artikel ist im Original bei unserer Schwesterpublikation Computersweden.se erschienen.

In the wake of AI, the early-talent job market is in decline across all jobs and industries, with a 10% drop since 2021, according to a recent report from SAP. When isolated for the top 10 most common entry level job titles, including software engineer, customer support, and data analyst, job openings declined 35% from 2024 to 2025.

AI is already impacting entry-level and task-based roles, leaving the question of what will happen to the future talent pipeline of IT leadership.

“Our research suggests that organizations create a gap in their future leadership pipeline if they continue reducing entry-level hiring without rethinking how early-career talent develops,” says Autumn Krauss, chief scientist for Future of Work Research Lab at SAP SuccessFactors. “Historically, people built business acumen, technical expertise, and leadership skills through the first few years of their careers. As AI becomes embedded in workflows, organizations need to be intentional about creating new ways for employees to build those skills.”

Companies have traditionally followed hierarchal processes that encourage employees to advance up the career ladder via promotions, with many taking a leadership path to IT director, CIO, or CTO. However, this process has always relied on workers starting with entry-level and routine work to create a natural first step for future leaders. But now, more companies are automating the work that entry-level and mid-level employees used to cut their teeth on, says Maruf Ahmed, CEO of IT staffing and consulting company Dexian.

For example, a junior engineer might start in QA and testing on the technical side, getting hands-on experience with how systems work. As they progress in their career, that knowledge continues to stack, creating future leaders who deeply understand the technology and the business.

“Maintaining a strong succession path starts with being honest about what AI removed from someone’s development, and then being intentional about replacing it,” says Ahmed. “Senior leaders need to spend more time actively teaching, and people need exposure to complex decisions earlier in their careers. Day-to-day work used to build that foundation on its own, and it doesn’t anymore.”

Redesigning jobs for AI and leading in uncertainty

As many have discovered, it’s not always easy to decipher quality AI outputs, especially as the technology has become renowned for hallucinating results. Current and future IT leaders need the foundational knowledge to have confidence when evaluating AI outputs, especially if they’re expecting employees to use AI. The most valuable leaders are the ones comfortable making decisions with incomplete information, and who can make calls on the spot about automated processes, no matter what may arise.

“We often see AI doesn’t stay contained in one function for long,” Ahmed adds. “Once an organization automates in one area, there’s an expectation to extend that more broadly, and leaders who built their careers inside a specific function are suddenly being asked to weigh in on AI use in areas they’ve never directly managed.”

According to recent research from Deloitte, 84% of companies haven’t done the work to redesign jobs around AI despite high expectations for automation, and 36% expect at least 10% of their jobs to be fully automated within a year, and 82% say within three years. Even with those results, fewer than half are making significant adjustments to talent strategies, with 53% saying they’re simply focusing on educating employees to raise AI fluency.

That leaves entry-level workers and those in task-aligned roles in somewhat unknown territory as automation replaces time-consuming tasks, and managers shift to overseeing human-AI teams. Deloitte points to a potential shift toward flatter structures, with more than half of businesses considering pod-based or non-hierarchal models, while 16% have already started to make a shift.

IT leaders will likely find themselves relying more on others in the company to make judgment calls around AI, opening communication and transparency as job roles evolve and structures begin to flatten. With AI adoption happening at a rapid pace, organizations need to evaluate how it’ll impact talent and leadership structures, and what the future of leadership will look like with automation.

Investing in early talent to maintain a leadership pathway

IT leaders need to avoid the trap of treating AI adoption as a technology rollout rather than a workforce development project, says Ahmed. Leaders will continue to invest heavily in new tools, services, hardware, and technology, and then expect employees to become self-taught on these platforms in their downtime.

“Our research found that leaders don’t often feel confident or equipped with the skills to lead that level of transformation. Instead, organizations often fall back on the tactic of giving employees AI tools and expecting them to figure out how best to use them on their own,” says Krauss.

If current IT leaders feel unequipped to lead through AI transformation, it’s imperative companies step back and reevaluate training and future leadership talent pools. Investments in AI should be weighed alongside the necessary investments for employee upskilling and training, and to redefine long-standing organizational structures.

Investment in early talent development programs can also be beneficial for tackling potential future leadership gaps left by AI adoption, with 86% of employees saying that an early talent program helped set them up for career success, according to the SAP report. But despite the beneficial nature of such programs, only 32% of early talent report participating in an early talent program, and 49% say their organization doesn’t offer one. Plus, only 35% of early talent employees say they’ve been given sufficient transparency into which roles in their organization may be automated in the future, while one in three express concerns their job may one day cease to exist due to AI advancements.

“As roles change, organizations need to give employees a clearer picture of where opportunities are emerging and what skills will be most important,” says Krauss. “Many employees are already uncertain about how technology will affect their careers, and that uncertainty can make it harder to stay engaged. People are more likely to invest in their growth when they see a path forward. That visibility is becoming increasingly important.”

Microsoft has announced a release candidate (RC) of TypeScript 7.0. A port of JavaScript-based TypeScript that is based on the Go language, TypeScript 7.0 is often about 10 times faster than TypeScript 6.0, Microsoft said, thanks to native code speed and shared memory parallelism.

Developers can get the new compiler by installing it from the typescript package on npm:

npm install -D typescript@rc

Unlike TypeScript 6.0, TypeScript 7.0 performs many steps in parallel, including parsing, type checking, and emitting, Microsoft said. Some of these steps, such as parsing and emitting, can mostly be done independently across files. For that reason, parallelization automatically scales well with larger codebases with relatively little overhead. However, not every step in a TypeScript build is easily parallelizable, Microsoft said.

With TypeScript 7.0 RC now available, Microsoft plans to release TypeScript 7.0 within the next month. The company said it will focus on release coordination and logistics, reported regressions, and future API capabilities in TypeScript 7.1.

Because a stable programmatic API will not be available until TypeScript 7.1, Microsoft has made it a priority to ensure TypeScript 7.0 can be run side-by-side with TypeScript 6.0 without conflicts over which tsc is which. A compatibility package, @typescript/typescript6, provides an executable named tsc6, allowing TypeScript 7.0 to be installed side-by-side without tsc naming conflicts. The @typescript/typescript6 package also re-exports the TypeScript 6.0 API, so that tsc can be used for TypeScript 7.0 while other tools can continue to rely on TypeScript 6.0.

Kotlin 2.4.0, an update to JetBrains’s statically typed language for building JVM, native, Wasm, and web applications, introduces experimental improvements to compile-time constants, making support for numeric and string types more consistent and easier to use, JetBrains said.

Kotlin 2.4.0 was released June 3. Its experimental improvements to compile-time constants include support for unsigned type operations; standard library functions for strings, such as the .lowercase(), .uppercase(), and .trim() functions, and evaluation of the .name property of enum constants and the KCallable interface. To make it clear which functions are evaluated at compile time, Kotlin 2.4.0 introduces the IntrinsicConstEvaluation annotation.

JetBrains warned that some functions are evaluated at compile time but do not have the annotation yet. Later releases will add the annotation to the remaining functions.

Also in Kotlin 2.4.0:

• Kotlin 2.4.0 improves export to JavaScript and TypeScript, including support for exporting value classes, interfaces, and type variance, as well as ES2015 features when inlining JavaScript code.
• The Kotlin compiler can generate classes containing Java 26 bytecode.
• Experimental support is highlighted for the WebAssembly Component Model. The proposal defines a way to build components from Wasm modules through standardized interfaces and types. This approach helps Wasm evolve from a low-level binary instruction format into a system for composing reusable, language-agnostic components.
• Kotlin 2.4.0 has been included in the IntelliJ IDEA and Android Studio IDEs.

An update to Kotlin 2.4.0 will arrive soon. Beta1 of Kotlin 2.4.20 was released on June 24, adding the StackTraceRecoverable interface to the standard library. This interface improves integration with the kotlinx.coroutines library because it lets users define how to create exception instances for stack trace recovery without adding a dependency onkotlinx.coroutines, according to JetBrains.

A build tools API in the Kotlin 2.4.20 beta adds support for the Kotlin/JS, Kotlin/Wasm, and Kotlin metadata targets.

It is tempting to date cloud computing from the launch of Amazon S3 in 2006 and the rise of infrastructure as a service (IaaS) that followed. That was certainly the moment the market changed in a visible, irreversible way. But the truth is that cloud began earlier, in the 1990s, when software as a service (SaaS), application hosting, managed services providers, and various forms of remote subscription computing started to reshape how enterprises thought about owning and operating technology. Even then, the core value proposition was familiar: Let someone else run the infrastructure, abstract the complexity, deliver capability as a service, and allow the business to consume only what it needs.

What AWS changed was the scale, accessibility, and precision of the execution. Amazon turned infrastructure into a programmable utility. It made compute and storage available in ways that were elastic, self-service, API-driven, and globally reachable. That was the breakthrough. Enterprises had outsourced pieces of technology before, but now they could rent raw infrastructure with unprecedented speed and flexibility. The launch of Amazon S3 was especially important because it provided a durable, scalable storage foundation that became one of the building blocks for modern digital business.

AWS changed everything

Technology markets are rarely transformed by the first company to think of an idea. They are transformed by the first company to make that idea operationally real, economically viable, and broadly consumable. AWS did exactly that. It built a model for infrastructure as a service that allowed enterprises, startups, and eventually governments to rethink the entire life cycle of IT delivery.

Looking back from 2026, it is difficult to remember how radical this concept once seemed. At the time, many enterprise leaders considered public cloud too risky, too immature, too uncontrolled, or simply too foreign for conventional IT governance. There were concerns about security, compliance, vendor dependency, performance, data residency, and reliability. Many of those concerns were valid. Early cloud adoption often ran ahead of cloud maturity, and many organizations discovered that moving quickly did not always mean moving wisely.

Still, the economics of agility overwhelmed the inertia of the old model. Provisioning that once took months could be done in minutes. Capital expenditure gave way, at least in part, to operating expenditure. Experimental workloads became easier to justify. Digital businesses could scale without building data centers first. AWS led that transition, and the rest of the industry followed, including competitors that helped mature the market.

Cloud’s strengths and liabilities

If the first decade of cloud was about acceleration, the second decade was about correction. Enterprises learned that cloud was not automatically cheaper, not automatically simpler, and not automatically better. It was better when used with discipline. It was more cost-effective when architected intelligently. It was more resilient when governance, operations, and security were designed into the system rather than added later.

This is when the industry grew up. We learned about cloud financial management because too many organizations assumed elasticity would control cost, only to discover that unused resources, poor workload placement, and fragmented accountability could drive spending far beyond expectations. We learned that public cloud could provide extraordinary innovation and reach, but also that not every workload belongs there. Latency, sovereignty, compliance constraints, legacy integration challenges, and predictable high-volume workloads all forced a more nuanced view.

We also learned about concentration risk. As enterprises standardized on a small number of hyperscalers, questions emerged around resilience, lock-in, and strategic dependency. The answer was never simplistic multicloud posturing for its own sake. It was architectural realism. Use the public cloud where it creates a clear advantage. Keep options open where business risk requires it. Understand portability, but do not romanticize it. In other words, cloud became less ideological and more practical.

Cloud is now an assumption

Perhaps the most important shift of all is that we no longer debate whether cloud is real or whether enterprises should use it. That argument is over. Cloud is baked into the cake. It is part of enterprise operating reality. The modern enterprise assumes on-demand infrastructure, platform services, automation pipelines, managed databases, identity fabrics, observability stacks, and globally distributed application delivery. Even when workloads remain on-premises or at the edge, they are often built, governed, or operated with cloud-native thinking.

This is maturity. Cloud is not a project or a trend. It is not even a strategy by itself. It is an enabling model that now underpins enterprise strategy. Businesses no longer ask whether to adopt cloud in the abstract. They ask how much cloud, which cloud services, under what governance model, at what cost profile, and in support of which business outcomes.

That may sound less exciting than the early days of disruption, but it is actually the mark of success. The most powerful technologies eventually disappear into standard practice. Electricity, networking, virtualization, and mobile platforms all went through this process. Cloud has done the same.

How cloud supports the AI race

As enterprises move aggressively into AI, cloud has entered another pivotal phase. AI is not replacing cloud. It is intensifying the importance of cloud while also changing how value is measured. Training, tuning, deploying, and governing AI systems require immense computational scale, specialized infrastructure, distributed data access, and operational consistency. Public cloud providers are well positioned to offer those capabilities, particularly with GPUs, AI platforms, managed model services, and data integration tools.

But this is not a repeat of the early cloud era. Enterprises are more sober now. They know the importance of cost, latency, and data gravity. They know that governance and accountability matter more in AI than perhaps anywhere else in modern IT. The role of cloud in the AI race is therefore foundational, but not absolute. Some AI workloads will run in public cloud. Some will be distributed across edge computing environments. Some will remain in private environments for reasons of sovereignty, economics, or control. The key is not to force a universal answer. The key is to create an architecture that aligns AI ambitions with operational reality.

Cloud should play the role it has gradually earned: not as a religion, but as a strategic utility. For AI, the cloud is where many enterprises will source scale, experimentation speed, global reach, and managed innovation. The winning organizations understand where cloud creates leverage and where other operating models make more sense.

Changing how enterprises think

The real story of the past 20 years is not just that AWS launched S3 and helped popularize infrastructure as a service. It is that cloud changed enterprise behavior. It normalized service consumption over asset ownership. It moved architecture toward abstraction, automation, and modularity. It forced IT organizations to broker capability rather than build everything from scratch. It redefined speed as a core competitive requirement.

And now, as AI becomes the next forcing function, cloud stands less as a novelty and more as the platform on which the next era will be built. That is a remarkable outcome for something that, in many ways, started with the old idea that computing could be delivered remotely on a subscription basis. We have been heading here for longer than many people realize. In the past two decades, led in large measure by AWS and the broader hyperscale movement it accelerated, cloud has evolved from a gamble to an indispensable foundation.

Hard to believe? Yes. But also inevitable in retrospect.

Microsoft

Am 20. November 1985 veröffentlicht die damals noch kleine Softwarefirma Microsoft mit Windows 1.0 die erste grafische Benutzeroberfläche für ihr Betriebssystem MS-DOS. Zunächst nur als Erweiterung des Betriebssystems programmiert, legt Windows 1.0 den Grundstein für eine beispiellose Erfolgsgeschichte. Anwendungen auf MS-DOS-Rechnern lassen sich nun endlich mit der Maus bedienen und machen die grauen Kisten somit auch für den Consumer-Markt attraktiv.

Die Anfänge von Windows

Um die erste grafische Oberfläche für die Benutzung von PCs entbrennt vor 30 Jahren allerdings zunächst ein Wettlauf gegen die Zeit. Personal Computer werden zu dieser Zeit in der Regel in Unternehmen eingesetzt. Bill Gates wird schnell klar, dass eine grafische Oberfläche (Graphical User Interface, GUI) notwendig sein würde, damit der Computer eines Tages auf jedem Schreibtisch seinen Platz findet.

Unter Microsofts erstem Betriebssystem MS-DOS müssen Anwender schon über ein gewisses technisches Know-how verfügen, um den Rechner bedienen zu können. Grundkenntnisse in der Programmiersprache Basic sind damals von Vorteil. Die erste Version von Windows hat allerdings noch recht wenig Ähnlichkeit mit den grafischen Oberflächen, wie man sie heute kennt. Die Software ist sperrig, langsam und wird nur von wenigen Anwendungen überhaupt unterstützt. Will man ein kleines Programm wie den Taschenrechner starten, muss die dafür erforderliche Datei (calc.exe) erst in den Tiefen des Betriebssystems gesucht und anschließend über die Kommandozeile gestartet werden.

Die anfangs rudimentäre grafische Oberfläche ist damals revolutionär – von Microsoft stammt die Idee allerdings nicht. Bereits zwei Jahre zuvor – 1983 – bringt Apple-Gründer Steve Jobs mit der Lisa einen der ersten Computer mit grafischer Oberfläche auf den Markt. Das Gerät ist jedoch teuer und spricht schon deshalb nur einen kleinen Kreis von Computer-Enthusiasten an. Doch die Richtung ist vorgegeben, der Wettlauf beginnt.

Jobs und die Programmierer bei Apple lassen sich bei ihrer Entwicklung der GUI von der Arbeit am legendären kalifornischen Forschungszentrum Xerox PARC inspirieren. Dort wird die Idee der grafischen Benutzeroberfläche für PCs geboren. Bereits in den 1970er Jahren entsteht dort der Xerox Alto für Forschungszwecke. Nachdem 1981 der Xerox Star als erster kommerzieller Rechner floppt, gibt das Unternehmen sein Vorhaben auf.

Microsoft, Apple und das Urheberrecht

Durch Apple unter Zugzwang geraten, kündigt Bill Gates im November 1983 auf der Computermesse Comdex in Las Vegas sein Windows 1.0 an – lange bevor die Software überhaupt fertig ist. Als Anekdote ist überliefert, dass Gates’ Vater bei seinem Vortrag am Diaprojektor stand. Fast zwei Jahre braucht Microsoft anschließend, bis die erste Windows-Version auf den Markt kommt. In der Zwischenzeit stellt auch Apple seinen ersten PC auf die Beine: den Macintosh.

Gates nimmt sich für Windows relativ unverhohlen die Oberfläche des Jobs und die Programmierer bei Apple lassen sich bei ihrer Entwicklung der GUI von der Arbeit am legendären kalifornischen Forschungszentrum zum Vorbild. Die Anwälte der Apfel-Company kann er sich nur vom Hals halten, weil er für Apple dringend benötigte Mac-Anwendungen liefert. Als Microsoft aber Anfang 1988 mit dem nächsten größeren Versionssprung, Windows 2.03, auf den Markt stößt, reicht Apple wegen Verstoßes gegen das Urheberrecht Klage gegen seinen Rivalen ein. Den über Jahre erbittert geführten Rechtsstreit verliert Apple letztendlich im Jahr 1994 – auch deshalb, weil es sich in den 1980er Jahren selbst bei Xerox bedient hatte.

Erst im Sommer 1997 normalisiert sich die Beziehung zwischen Apple und Microsoft langsam wieder, als der zu Apple zurückgekehrte Steve Jobs die Hilfe von Microsoft in Anspruch nimmt, um das in Schwierigkeiten geratene Unternehmen wieder profitabel zu machen. Nichtsdestotrotz nimmt Apple seinen “Lieblings”-Kontrahenten und dessen “Kopierleidenschaft” auch Jahre später noch aufs Korn – mit Vorliebe in Form ironischer Werbespots.

Durchbruch und Millenium-Fluch

Zum Start von Windows 1.0 gibt es weltweit eine Basis von “lediglich” sechs Millionen Personal Computer. Erst rund fünf Jahre später, im Jahr 1990, gelingt der Software-Schmiede aus Redmond mit Windows 3.0 ein erster Erfolg. Den endgültigen Durchbruch beschert dem Unternehmen dann weitere fünf Jahre später der Release von Windows 95. Unter Windows 95 lassen sich Peripheriegeräte wie Drucker deutlich einfacher anschließen und in Betrieb nehmen. Ohne umständliche Installation von Treibersoftware kommen die Nutzer dennoch nur selten aus. Erstmals kommt Windows 1995 auch mit einem virtuellen Papierkorb auf der Schreibtischoberfläche daher – ein Icon, das Macintosh-Nutzer der ersten Stunde zu dieser Zeit längst kennen. Auch eine Verbindung zum Internet können Nutzer mit Windows 95 erstmals herstellen: mit dem Internet Explorer.

Das 1998 erschienene Windows 98 wird im Vergleich zu seinem Vorgänger nur in Details weiterentwickelt. Bei diesen Details handelt es sich konkret um die standardmäßige Einbindung des Internet Explorers in das Windows-Betriebssystem, sowie die Einführung der Schnellstartleiste und die Unterstützung der damals neuen USB-Schnittstelle. Mit der im Jahr 2000 erschienenen Windows Millenium Edition (ME) kann Microsoft bei PC-Nutzern dagegen nicht punkten. Das auf Multimedia-Support optimierte Betriebssystem soll Windows-User mit mehr Benutzerfreundlichkeit verwöhnen, in der Praxis “besticht” es vor allem mit Instabilität und mangelhafter Performance.

Foto: Microsoft

XP-Kult und Vista-Fehlschlag

Mit Windows XP erneuert Microsoft im Jahr 2001 die optische Präsentation von Windows. Und auch technisch halten viele Neuerungen Einzug. Insbesondere auf Notebooks macht Windows nun eine deutlich bessere Figur. Das weiß auch die schreibende Gilde zu schätzen: Pünktlich zum Release erhält Windows XP auch von der Presse gute Noten. Anwender schätzen insbesondere die Navigation über das Startmenü. Windows XP gibt es auch als Tablet PC Edition – aus gutem Grund: Im Jahr 2002 startet Microsoft in Kooperation mit einigen OEMs eine große Tablet-Offensive. Die Windows-Tablets können sich jedoch nur in vertikalen Märkten wie dem Gesundheitswesen etablieren.

Der Support von Windows XP endet im Jahr 2014 nach 13 Jahren. Dennoch können sich viele Unternehmen, Institutionen und Privatpersonen nur schwer vom äußerst beliebten Windows-Betriebssystem trennen. Für Microsoft ist Windows XP in diesen Jahren eines der meistverkauften Produkte. Der XP-Nachfolger Windows Vista wird dagegen von vielen Experten nicht gerade als Erfolgskapitel der Windows-Geschichte angesehen. Das Windows-OS soll zunächst bereits 2003 auf den Markt kommen, fertiggestellt wird das Projekt mit dem Codenamen “Longhorn” allerdings erst Ende 2006. Mit der umfangreichen, visuellen Neugestaltung von Windows Vista will Microsoft auch ein Zeichen setzen: Apples Betriebssystem Mac OS X macht zu diesem Zeitpunkt einen deutlich frischeren, moderneren Eindruck als Windows XP. Die neue “Aero”-Oberfläche, ein neu designtes Startmenü und zeitgemäß inszenierte Icons sowie viele technische Neuerungen zeichnen Windows Vista aus. Trotzdem kommt diese Windows-Version bei vielen Kunden nicht an – Stabilität und Performance können mit den Erwartungen vieler User nicht mithalten. So landet Vista oft nur bei Endkunden, die es mit neuen Systemen erwerben. Insbesondere im Unternehmensumfeld bleibt XP das Maß der Dinge.

Windows 7 und die Solidarität mit dem Start-Button

Windows 7 gilt entsprechend als der eigentlich legitime Nachfolger von Windows XP. Gegenüber Vista kann Windows 7 in Sachen Stabilität, Performance und Nutzerfreundlichkeit bei den Nutzern schnell punkten. Auch kurz vor dem Erscheinen von Windows 10 verzeichnet Windows 7 immer noch die höchsten Marktanteile unter den Windows-Betriebssystemen.

Mit Windows 8 ändert sich die Bedienung des Betriebssystems grundlegend: Die neue Kacheloberfläche lässt sich auf touch-fähigen Geräten zwar gut bedienen, stößt aber viele Desktop-Anwender vor den Kopf, die die Änderung der Benutzerführung oft als zu radikal empfinden. Drittanbieter-Tools die die beliebte Windows-Leiste mit Start-Button zurückbringen, haben zu diesem Zeitpunkt Hochkonjunktur. Nur ein Jahr später muss Microsoft reagieren und renoviert Windows 8 grundlegend. Das Ergebnis nennt man kurzerhand Windows 8.1. Der Startbildschirm ist unter Windows 8.1 nun flexibler konfigurierbar, auf Wunsch ist nun auch wieder die klassische Windows-Desktop-Ansicht verfügbar – inklusive Startknopf. Abseits der Diskussionen um das Für und Wider der Kachel-Oberfläche geht oft unter, dass Windows 8 – und insbesondere auch Windows 8.1 – einige spannende Neuerungen an Bord haben, wie etwa Speicherpools oder Arbeitsordner.

Windows 10 und das “neue” Microsoft

Mit Windows 10 veröffentlichte Microsoft Ende Juli 2015 nicht nur einfach eine neue Windows-Version. Das aktuelle Windows-OS verkörpert die neue “One-Platform”-Strategie des Redmonder IT-Konzerns, der mit Windows 10 und Windows 10 Mobile künftig eine geräteklassenübergreifende Plattform etablieren will. Windows 10 läuft also nicht nur auf PCs, sondern auch auf Tablet-PCs, Notebooks, Windows Phones, der Spielkonsole Xbox One und dem kommenden AR-Device Hololens. Weitergeführt werden soll diese Strategie von plattformübergreifenden “Universal”-Apps. Doch auch sonst ändert sich Einiges: Windows 10 wurde als erstes OS der Windows-Geschichte allen Nutzern von Windows 7, 8 und 8.1 als kostenloses Upgrade zur Verfügung gestellt und wird kontinuierlich über Software-Updates erweitert. Das heißt bei Microsoft “Windows-as-a-Service” – und sorgt dafür, dass der traditionelle Patch-Day endgültig Geschichte ist. Dass Microsoft mit Windows 10 neue Wege beschreitet, zeigte sich bereits während des Entwicklungsprozesses: Über das “Insider Program” waren beziehungsweise sind Millionen von Anwender mit ihrem Feedback in die Entwicklung des Betriebssystems involviert.

Mit Windows 10 beschreitet Microsoft auch beim Thema Open Source neue Wege und öffnet sich der Community. So soll das Win 10 Anniversary Update auch mit integriertem Ubuntu Bash kommen, während Windows Server 2016 weitergehende Linux-Virtualisierungen erlaubt. Doch nicht nur Linux, auch andere Open-Source-Projekte werden künftig unterstützt: Sowohl das .NET-Framework, als auch die Entwicklungsumgebung Visual Studio stellt Microsoft für Entwickler kostenlos zur Verfügung.

Windows 10 Creators Update

Ende Oktober 2016 kündigt Microsoft das nächste umfassende Update für sein Betriebssystem an. Das Creators Update soll im Frühjahr 2017 gewichtige Neuerungen auf alle Windows-10-Geräte bringen – insbesondere was die Bereiche Mixed- und Virtual-Reality angeht. Geht es nach den Redmondern, soll künftig jeder Windows 10 User ganz einfach und schnell eigene 3D-Inhalte erstellen und bearbeiten können. Das soll in erster Linie über eine Erweiterung von Paint funktionieren, das künftig Paint 3D heißt. Auch beliebige, abfotografierte Objekte sollen künftig per App auf Knopfdruck in 3D-Modelle verwandelt werden können. Konsumiert werden sollen die MR- und VR-Inhalte zum einen über Microsofts Hololens, zum anderen auch über VR-Brillen diverser Partnerhersteller, etwa Lenovo, Dell und HP. Auch die Windows 10 Community soll künftig noch stärker zusammenwachsen, wenn es nach Microsoft geht. Deswegen stellen die Redmonder im Rahmen des Creators Update auch eine Schnittstelle zur Verfügung, die zahlreiche Kommunikationstools miteinander vereinen soll.

Windows 10 S und Creators Update, Part 2

Anfang Mai 2017 stellte Microsoft mit dem Surface Laptop nicht nur ein weiteres Gerät der Surface-Reihe vor, sondern enthüllte auch soll im Frühjahr 2017 gewichtige Neuerungen auf alle Windows-10-Geräte bringen – insbesondere was die Bereiche Mixed- und Virtual-Reality angeht. Geht es nach den Redmondern, soll künftig jeder Windows 10 User ganz einfach und schnell eigene 3D-Inhalte erstellen und bearbeiten können. Das soll in erster Linie über eine Erweiterung von Paint funktionieren, das künftig Paint 3D heißt. Auch beliebige, abfotografierte Objekte sollen künftig per App auf Knopfdruck in 3D-Modelle verwandelt werden können. Konsumiert werden sollen die MR- und VR-Inhalte zum einen über. Die cloudbasierte Version von Windows 10 läuft ausschließlich mit Apps aus dem Windows Store, ist jedoch upgrade-fähig. Die abgespeckte Windows-Version ist mit dem eingestellten RT vergleichbar und richtet sich in erster Linie an Bildungseinrichtungen. Schließlich will Microsoft dieses Feld nicht alleine den , zum anderen auch über VR-Brillen diverser Partnerhersteller, etwa Lenovo, Dell und HP. Auch die Windows 10 Community soll künftig noch stärker zusammenwachsen, wenn es nach Microsoft geht. Deswegen stellen die Redmonder im Rahmen des Creators Update auch eine Schnittstelle zur Verfügung, die zahlreiche Kommunikationstools miteinander vereinen soll. überlassen.

Auf der Entwicklerkonferenz Build 2017 kündigte Microsoft den Nachfolger zum Creators Update an: das Fall Creators Update. Unsere US-Kollegin Melissa Riofrio klärt Sie über die besten, neuen Features auf:

Seit April 2018 verzichtete Microsoft auf besondere Nomenklatur bei Windows 10 Updates, verbessert sein Betriebssystem aber konsequent weiter und liefert dazu im Regelfall zwei große Updates pro Jahr. Die aktuelle Version (20H2) wurde im Okotober 2020 veröffentlicht.

Aufmerksame Leser werden bemerkt haben, dass in diesem Text nicht auf jede Windows-Version eingegangen wird. Natürlich haben wir auch Windows NT, 2000 und wie sie alle heißen nicht vergessen – in unserer Bildergalerie bekommen Sie einen umfassenden Überblick über die wichtigsten Windows-Versionen.

Windows 11 21H2

Es begann mit einer überraschenden Ankündigung von Microsoft-CEO Satya Nadella auf der Entwicklerkonferenz Build 2021: “Wir werden bald eines der bedeutendsten Updates für Windows des letzten Jahrzehnts vorstellen. Ich selbst habe es in den letzten Monaten schon ausprobiert und bin unglaublich aufgeregt, was die nächste Generation von Windows betrifft.” Damit befeuerte der Manager eine regelrechte Flut an Spekulationen rund um ein neues Windows. Am 24. Juni lösten sich dann alle bis dahin noch bestehenden Rätsel. Microsoft stellte mit Windows 11 offiziell eine neue Generation seines Betriebssystems vor und erklärte, damit eine neue Ära einläuten zu wollen.

Die Idee, ein neues Windows zu bauen, entstand wohl in der Corona-Pandemie. Die vergangenen 18 Monate hätten die Art und Weise, wie Menschen den PC nutzen, komplett verändert, konstatierte Panos Panay, Chief Product Officer für den Bereich Windows und Devices bei Microsoft. Der PC habe das Leben in der Krise maßgeblich mitbestimmt. Man habe Windows 11 darauf ausgelegt, auf verschiedenen Gerätetypen zu laufen und unterschiedliche Bedienmodi zu unterstützen, hieß es von Seiten Microsofts. Beispielsweise sei der Abstand zwischen den Icons in der Taskleiste vergrößert worden, um eine Touch-Bedienung auf Tablets zu erleichtern. Auch die Erkennung von Spracheingaben sei Microsoft zufolge verbessert worden. Alle aktuell im Handel verkauften PCs und Notebooks sollen Windows-11-tauglich sein, hieß es. Wie schon beim Umstieg auf Windows 10 will Microsoft Anwendern mit der PC Health Check App ein Tool anbieten, um zu prüfen, ob ihr Rechner für das neue Windows-System geeignet ist.

Microsoft hat bei Windows 11 vor allem Design und Bedienerführung vereinfacht. Mithilfe neuer Tools wie “Snap Layouts”, “Snap Groups” und “Desktops” sollen Nutzer ihren Arbeitsplatz besser organisieren können, verspricht der Softwarehersteller. So ließen sich beispielsweise mehrere separate Arbeitsoberflächen einrichten und mit Apps und Tools bestücken – etwa für die Arbeit, den Privatbereich oder die Schule. Darüber hinaus verzahnt Microsoft Windows 11 enger mit dem in der Pandemie so erfolgreichen Communication- und Collaboration-Tool Teams.

Wieder zurück in Windows 11 sind die aus der Version 7 bekannten Widgets. Damit können Nutzer personalisierte Feeds mit beispielsweise Nachrichten oder Wetterinformationen einrichten. Der Redmonder Konzern bewirbt sein neues Betriebssystem darüber hinaus als besonders sicher. Die Architektur sei als Zero Trust angelegt, zudem sei das System Secure by Design. Wichtige Sicherheits-Features wie zum Beispiel Verschlüsselung seien von Haus aus aktiviert.

Überarbeitet hat Microsoft auch den Windows-Appstore, der laut Panay nun übersichtlicher und auch einfacher zu nutzen sein soll. Darüber hinaus ließen sich künftig auch Android-Apps über den Amazon Appstore in Windows herunterladen. App-Entwicklern winken mit Windows 11 laut Panay mehr Freiheiten. Sie könnten beliebige App-Frameworks für ihre Entwicklungen nutzen. Apps ließen sich beispielsweise als Win32-, Progressive-Web-App (PWA) oder Universal-Windows-App (UWA) in den Store einstellen.

Um mehr Entwickler auf die Windows-Plattform zu locken, hat Microsoft auch seine Abrechnungsmodalitäten angepasst: Bringt ein Entwickler seine eigene Abrechnungs-Engine mit in den Windows-Store, will der Konzern keine Gebühren verlangen. Wird die im Windows-Store von Microsoft angebotene Commerce-Service genutzt, werden 15 Prozent vom Umsatz fällig. Die erste Version von Windows 11 – 21H2 – wurde im Oktober 2021 veröffentlicht.

Windows 11 22 H2

Im September 2022 erfolgte schließlich mit der Version 22H2 das erste große Update des neuen Microsoft-Betriebssystems, das zahlreiche Überarbeitungen beziehungsweise Optimierungen beinhaltete, sowohl auf Design- als auch auf Funktionsebene. Hervorzuheben ist dabei vor allem die von den Nutzern lange herbeigesehnte Möglichkeit, innerhalb des Windows Datei-Explorers Registerkarten zu öffnen. Unsere Kollegen von der PC-Welt haben das erste Windows-Update, beziehungsweise dessen Betaversion, ausgiebig getestet und erklärt.

Windows 11 23H2

Ende Oktober 2023 veröffentlichte Microsoft schließlich die Version 23H2. Diese zeichnet sich in erster Linie durch die Integration generativer KI-Funktionen auf GPT-4-Basis aus – Stichwort Copilot. Das wirkt sich vielfältig auf diverse Bereiche des Windows-Ökosystems aus, wie eine Microsoft-Expertin in diesem Videobeitrag ausführlich erklärt.

Windows 11 24H2

Seit Oktober 2024 ist das 2024er-Update von Windows 11 allgemein verfügbar. Mit 24H2 halten zahlreiche Neuerungen in Windows 11 Einzug – insbesondere neue KI-Features (bei Copilot+-PCs). Darüber hinaus verspricht 24H2 auch WiFi-7-Support, einen optimierten Datei-Explorer sowie verbesserte Konnektivität. In der Praxis hat sich dieses Windows-Update leider vor allem dadurch ausgezeichnet, dass es bei der Nutzerbasis für umfassende (teilweise nur manuell zu lösende) Probleme gesorgt hat.

Knapp vier Jahre nach seiner Veröffentlichung ist der Erfolg von Windows 11 mit Blick auf die Nutzerakzeptanz noch ausbaufähig. Immerhin hat Win 11 seinen Vorgänger inzwischen nach Marktanteil überholt. Aktuell (Stand: Februar 2026) steht Windows 11 bei 62 Prozent. Der Vorgänger Windows 10 bringt es noch auf 36 Prozent.

Windows 11 25H2

Seit dem 30. September 2025 steht Windows 11 25H2 zur Verfügung und zeichnet sich durch diverse neue, teilweise Hardware-exklusive Features aus. Letztere beinhalten vor allem neue KI-Funktionen für Copilot+-PCs. Darüber hinaus bietet 25H2 auch Support für WLAN-7-Zugriffspunkte, Windows-Sicherung für Organisationen sowie zahlreiche Optimierungen für Datei-Explorer und Task Manager. Die vollständige Auflistung finden Sie direkt bei Microsoft.

Windows 11 26H1

Bei Win 11 26H1 handelt es sich um eine Version, die am 10. Februar 2026 veröffentlicht wurde und speziell auf neue, ARM-basierte Windows Devices abgestimmt ist, die laut den Redmondern Anfang 2026 auf den Markt kommen. (dpa/tc/mje/fm/ba)

While enterprise IT leaders have spent the past two years focusing AI infrastructure discussions on GPUs, cloud platforms, and data centers, new Cisco research suggests that enterprise networks may not be ready for the next phase of AI adoption.

A Cisco and Foundry survey of 3,472 IT and networking leaders across 15 countries found AI is already changing traffic patterns across campus and branch environments and exposing capacity, security, and visibility gaps that many organizations aren’t prepared to address.

“We have entered a networking supercycle, because the network is so central to all the AI infrastructure the world is building now,” said Jeetu Patel, Cisco president and chief product officer, in a statement.

The findings reveal that enterprises may need to expand AI readiness planning beyond data centers and cloud environments and pay more attention to the networks connecting employees, applications, and devices. This issue will become more significant as enterprise organizations move beyond generative AI pilots and begin deploying AI agents that communicate continuously with other systems and applications, according to the report.

The Cisco survey found:

• Organizations reported a 34% increase in AI-related campus and branch network traffic over the past 12 months.
• Traffic is projected to climb 209% over the next three years, with companies broadly deploying AI expecting total network traffic to triple.
• 73% already face, or expect to face, campus and branch network capacity constraints within the next two years.
• 67% said AI workloads are increasing east-west traffic between internal systems and applications.
• 80% said AI has expanded their attack surface.
• 61% said they are delaying additional AI deployments until they gain more confidence in their security posture.
• 85% expect moderate or significant growth in AI agent deployments over the next two years.

Changing traffic patterns inside enterprise environments are causing additional pressure for enterprise network teams. (See also: AI traffic is radically reshaping WANs)

“Usually, networks are designed for consistent traffic, like SaaS and CRM traffic, and there aren’t a lot of unpredictable traffic patterns,” said the head of AI strategy for global IT and network engineering operations at a large U.S. technology company who participated in the research. “Suddenly, three AI agents are trying to talk to each other and solve a problem. That is going to be a big thing … how do we support increased east-west traffic?”

Cisco defined aggressive AI adopters as organizations with broad generative AI deployments across the enterprise, but only 30% of those organizations said they are fully prepared to support projected AI growth across their networks. As a result, 93% of IT decision makers said they are accelerating network modernization efforts.

The report also highlighted an observability challenge that could complicate future deployments. As employees and business units increasingly experiment with AI tools, IT organizations may not know what is actually running on their networks.

“Right now, we don’t even know what the AI-driven demand is,” the AI strategy executive said. “Observability is a huge gap. There is experimentation going on all over the place, and there is no way for us to really identify if somebody is deploying some kind of service on our network, whether it is a genAI solution or an agentic solution.”

Security is also emerging as a barrier to AI expansion as organizations struggle to govern rapidly growing numbers of AI tools and workloads.

“The issue from a security standpoint is that it’s hard to create the guardrails for every possible AI tool that your organization must use,” said the vice president of infrastructure, network, and end-user services at a U.S. retail enterprise interviewed for the report.

The AI readiness conversation has often centered on data centers, but AI applications operate where employees work, devices connect, and business processes run. That means campus and branch environments may become just as important to AI success as the infrastructure supporting AI models.

The Cisco research shows that AI infrastructure planning can no longer focus only on back-end systems if enterprises expect to scale AI deployments over the next several years. Patel said in the statement: “Eventually there will be only two kinds of companies: those that are AI companies, and those that are irrelevant.”

For more Cisco news, see our coverage from Cisco Live 2026:

• How Jeetu Patel made Cisco unrecognizable
• Cisco sees quantum networking as the future of networking
• What is Cisco Cloud Control and why should customers care?
• Cisco Live: The network is back, and AI rewrote the rules
• Cisco brings agentic ops platform and security overhaul to Cisco Live
• How Cisco IT cut observability costs by 86% and eliminated major network outages

Well, hey, how ’bout that? Here we are, on a random quiet-seeming week in June, and a new Android version is officially making its way into the wild and onto our favorite Googley gizmos.

Yes, indeed: Google announced the launch of Android 17 this week, and the rollout is getting underway as we speak. As usual, the software will show up for current, still-supported Pixel devices right away, over the next few to several days. (As for everyone else — well, you know the drill by now, right? It’s up to each individual Android device-maker to process and send out its software updates, and outside of Pixels, that support is exasperatingly unreliable. But odds are, if you aren’t palming a Pixel, you’ll be waiting for a while — maybe even a long while, if you have a phone by a certain manufacturer whose name rhymes with Boatorola.)

As always, some of Android 17’s most important elements are the under-the-hood privacy, security, and performance enhancements that you won’t explicitly see but that will make a critical difference in your device’s ability to operate efficiently and advisably. But this latest Android release also packs an impressive punch of interesting surface-level touches that’ll bring an instant boost to your day-to-day productivity and all-around Android-enjoying experience.

As is often the case, many of the most useful elements are things you might not ever even notice or think to tap into if you don’t know where to look.

Here are the four Android 17 features I’ve found most noteworthy so far and how you can start putting ’em to use this second.

[Psst: Don’t let the learning stop here. Check out my free Pixel Academy e-course to discover all sorts of advanced intelligence lurking within whatever Pixel you’re using!]

Android 17 Pixel feature #1: Bubbles multitasking magic

Our first Android 17 addition on its way to Pixel owners this week is something that’s been in the works for many a moon now — and that’s a handy new multitasking mode known as Bubbles.

Bubbles first came into the Android picture way back in 2019, but at that point, it was limited mostly to messaging and never came close to reaching its full promised potential. At long last, now, Bubbles are back, baby, and becoming everything we’d always wanted them to be.

The simplest way to think about Bubbles is as a way to turn any app you’re using into a floating, collapsible window — so you can pull it up on demand when you want it, then minimize it back down into a small icon (a “bubble” — get it?!) to get it out of your hair but keep it nearby for easy ongoing access.

It’s an interesting way to multitask without having to commit to a full-fledged split-screen setup. It can be quite useful for keeping things like lists, documents, emails, chats, or anything else you’re coming back to regularly at your fingertips — so you can pop into it as needed, without any real effort, but also without having it in your face all the time.

JR Raphael, Foundry

In Android 17, Bubbles is easy to launch with any app in front of you. The only catch is that as of now, at least, it can be triggered only from the standard stock Pixel Launcher — not a custom Android launcher like Smart Launcher or Niagara.

Provided you’re using the standard Android home screen setup, though, all you’ve gotta do is:

• Press and hold any app’s icon on your home screen or in your app drawer.
• In the menu that pops up, tap the option that says “Bubble.”
• Then tap the bubbled app icon to expand or minimize the app, or press and hold it to move it around to any position on your screen or dismiss it.

JR Raphael, Foundry

You can also add additional bubbled apps into that same view via the plus icon next to the first app’s icon when a bubble is open. Pretty nifty, wouldn’t ya say?

Android 17 Pixel feature #2: Smarter location access

Allowing apps access to your location inevitably requires a certain amount of compromise when it comes to the ever-prickly subject of privacy — and it demands a certain level of trust that the apps in question won’t abuse the privilege or use it for reasons beyond their intended purposes.

Android 17 makes it meaningfully easier to accept that bargain and rest easy knowing your info isn’t being misused, thanks to a pair of related new privacy protection measures:

• First, whenever any app is accessing your location, you’ll now see a blue dot appear in the upper-right corner of your screen — and if you swipe down once from the top of your screen to open your notification panel, you can actually tap on the location icon that appears in its place to get detailed info about exactly which app or apps are involved. With another tap from there, you can opt to force-close the app in question, view all of its recent location access attempts, and manage its location access ability, too, in case anything ever seems amiss.

JR Raphael, Foundry

• And second, when an app asks to access your precise location, Android 17 adds in the option to allow such access only temporarily — for that one brief moment and purpose — without giving the app the permanent permission for ongoing use.

Hey, we’ll take it. Just remember to keep tabs on the permissions Google itself is claiming these days, too, as those don’t always come with a prominent pop-up.

Android 17 Pixel feature #3: More dynamic dark mode

Dark mode may be one of the more divisive interface adjustments of our modern mobile moment, but if you’re a fan of the dimmer, less glary view across your Android experience, you’re bound to appreciate the added option Android 17 affords you in that area.

It’s a simple one-tap checkbox that forces apps to adjust and comply with your dark mode preference, when it’s active — even if they don’t natively support such a setting. That means those pesky apps that’d typically maintain the same standard light interface even when you activate dark mode will now turn dark along with the rest of your setup whenever Android’s dark mode is on.

All it takes it quite literally one tap on the freshly added Android 17 option:

• Head into the Display section of your Pixel system settings.
• Tap “Dark theme” — the actual words, not the toggle alongside ’em.
• And change the setting from “Standard” to “Expanded.”

JR Raphael, Foundry

Now, one note: By forcing apps to adapt to dark mode even if they aren’t designed for it, it’s possible some programs may end up lookin’ a little funky. If that ever happens and you aren’t thrilled with an app’s adaptation, go back to that same settings screen we were just starin’ at and tap the gear-shaped icon alongside the “Expanded dark theme” option. That’ll let you create exceptions and select specific apps that don’t get dark mode automatically applied.

JR Raphael, Foundry

But everything else will now be in the dark when you want it — just like your dark, brooding heart desires.

Android 17 Pixel feature #4: A more comfy all-around view

Whether you’re a prince/princess/dutchess/middle-manager of darkness or not, Android 17’s new Comfort View may be just the thing for you.

Comfort View is an off-by-default addition to your Pixel that applies a softer, more pastel-oriented filter to the display with automatic adjustments based on your current viewing environment — in other words, how bright it is around you at any given moment. Ooh, ahh, etc.

To try it out, march your way back into those Display settings, and this time, tap the line labeled “Comfort Filters.” Flip the switch next to “Comfort View,” make sure the “Dynamic” checkbox is active, and see how you feel about your newly optimized screen-color view as you move throughout your day.

JR Raphael, Foundry

If you find the filtering to be too extreme or not enough to make a difference, you can also try disabling the “Dynamic” option there and then manually adjusting the “Intensity” slider to suit your specific peeper preferences. But I suspect if you give it enough time, you’ll find the automatic adjustments to be one of those things that just works for you and makes your device a little easier on the eyes, relative to each and every viewing environment — without being something you actively think about or pay much mind.

That, if you ask me, is the sign of an effective feature. And it’s a welcome addition to Android and the ever-evolving Pixel experience.

Don’t let yourself miss an ounce of Pixel magic. Come check out my free Pixel Academy e-course to find tons of hidden features and time-saving tricks for your Googley gizmo.

I recently spent some time reflecting on the announcements from Google Cloud Next 2026, as well as a series of vendor briefings and a handful of enterprise architecture engagements, where the same question kept coming up across different venues: once an organization has agents, who governs them? For two years, the enterprise AI conversation has been a conversation about models — whose is largest, whose is cheapest, whose context window stretches furthest.  Virtually no one was talking about data and semantic context.

After getting some perspective, I was forced to consider that model obsession might have finally fizzled out under the grim reality of non-existent ontologies and limited to no semantic context for enterprise data. The interesting question is no longer which model an enterprise runs. It is who controls the connective context layer — the agentic control plane — that decides what those agents know, what they are allowed to do and who is accountable when a thousand of them are running at once. Whoever owns that layer owns the next decade of enterprise AI and judging by the “marketecture” of every major vendor at Next 2026, the industry has reached the same conclusion.

The urgency here is clearly not a slide-ware exercise. Gartner has reported an exponential surge in enterprise inquiries about multi-agent systems and predicts that 40% of enterprise applications will embed task-specific agents by the end of 2026, up from less than 5% a year earlier. Yet the same analysts deliver an equally important counterweight: Gartner also expects more than 40% of agentic AI projects to be canceled by the end of 2027, citing escalating cost, an expanded risk surface and governance that no one built in advance. The 2026 Gartner Hype Cycle for Agentic AI makes the diagnosis plain — governance, security and FinOps capabilities are proliferating precisely because enterprises are alarmed about accountability and control as agents grow more autonomous and interconnected. Exponential demand colliding with non-existent guardrails is the environment Google walked into. So, what is the path forward to a control plane an enterprise can actually trust?

What Google actually brought to Next 2026

I’m not ardent supporter of single-ecosystem architectures.  That’s not the world we live in and interoperability has always prevailed as the final arbiter of truth.  Beneath all the agent drama, however, Google’s message was fundamentally architectural. The company repositioned Gemini less as a standalone model and more as the connective and contextual tissue binding data systems, applications and agent runtimes, and assembled Big Query, Alloy DB, Spanner and its managed Spark service into a new category it calls the Agentic Data Cloud. As Constellation Research observed, the standardization of data on Apache Iceberg has put the data layer itself in play, and Google responded by stacking its assets into a cross-cloud lakehouse and a knowledge catalog, complete with migration tooling pointed squarely at Snowflake and Databricks.

Three pillars define the offering. The first is a federated data layer built on the principle of reach, not relocation. By integrating Cross-Cloud Interconnect directly into the data plane and pairing it with the Apache Iceberg REST Catalog, Google lets agents query data residing on AWS or Azure as though it were local, with no egress fees and extends bi-directional federation in preview to Databricks’ Unity Catalog, Snowflake’s Polaris and the AWS Glue Data Catalog, according to Google’s own technical briefings and independent analysis. Google data cloud managing director Yasmeen Ahmad summarized in Google’s Next ’26 announcement with characteristic economy: you don’t move the data, you connect it.

The second pillar is a semantic layer — the Knowledge Catalog, an evolution of Dataplex — which uses Gemini to tag assets, infer relationships and map business meaning so that agents are grounded rather than, as one analysis put it, fast but blind. Critically, its retrieval is permission-aware, meaning agents can only retrieve and act on assets they are explicitly authorized to see — a design choice that fuses context delivery and access control into a single operation. The third pillar is a build layer, the Data Agent Kit, which ships as portable skills, MCP tools and IDE extensions that drop into VS Code, Claude Code, Gemini CLI and Codex, deliberately declining to impose a new proprietary interface.

This is a credible and, to Google’s credit, a mostly real offering.  A control plane, however, is a claim, not a feature, and the term deserves more focus and detail than vendors typically provide.   An agentic control plane is not a product it is a semantically governed set of domain services and underlying structured and unstructured data.   How we federate agentic access and data with intention and governance means everything.

What an interoperable control plane requires

A control plane governs how a system behaves rather than performing the work itself. For agents, a genuine control plane must deliver at least five functions, and an interoperable one must deliver them across vendor, model and cloud boundaries rather than only within a single domain or scope.

The first is identity. Agents are a new class of non-human actors, and an enterprise must be able to authenticate them and manage their actions. Microsoft’s competing Agent 365, unveiled at Ignite 2025, is built explicitly around a registry of which agents exist, plus access control and security — as an Ignite 2025 industry analysis noted, that identity is foundational. The second is context and semantics, the half of the problem the data clouds have collectively rushed toward. The third, and the most consistently underplayed, is action governance — control not merely over what an agent can read, but over what it can do: the writes, the state changes, the transactional operations. The fourth is observability and lifecycle management, the simulate-evaluate-monitor-optimize loop across an agent fleet, where Google’s integrated offering is, by most accounts, the most complete a hyperscaler has yet shipped. The fifth is economics; the reason so many projects are forecast to fail is partly cost, and FinOps for agentic AI is now an expressly named discipline on Gartner’s Hype Cycle.

Interoperability cuts across all five, and here the industry has done something genuinely impactful and useful: it has agreed on protocols. The Model Context Protocol, originated by Anthropic and since donated to the Linux Foundation under multi-vendor governance, standardizes how an agent connects to tools and data. The Agent2Agent protocol, originated by Google and likewise moved to the Linux Foundation, governs how agents discover and delegate to one another across organizational boundaries. Forrester predicts that 30% of enterprise app vendors will launch their own MCP servers in 2026, and Gartner’s Anushree Verma positions standardized protocols as the enabler of the seamless interoperability that, by 2028, will let networks of specialized agents collaborate dynamically across applications.

What is key here — and what enterprise leaders miss — is that open protocols deliver portable messages, not a portable control plane. Two agents can exchange tasks across clouds in A2A all day long, but identity, semantics, action governance, observability and cost remain platform functions.  A2A and MCP have ensured that the communication protocol has been commoditized.  The final frontier and the competitive moat is not the communication and access protocol, it is the semantic context and the business ontology

Where Google is strong, and where leaders should look twice

Google deserves real credit for embracing open standards where it counts. It adopted MCP across its own services, repositioned Apigee as an MCP bridge that turns any standard API into a governed agent tool and built its federation story on the open Iceberg REST Catalog rather than a proprietary format. Technology Business Research (TBR) characterized this as a meaningful strategic shift: a company historically defensive about keeping data inside BigQuery now signals that it cares less about where data physically resides than about ensuring Gemini is the semantic context layer generating value on top of it.

That repositioning is exactly the lock-in risk an enterprise must carefully consider, and two limitations matter significantly and deserve an architect’s attention. The first is that federation is not the same as unified control. In my view, TBR’s analysis is totally on point: The Knowledge Catalog addresses upper-stack governance but is not an operational catalog in the way that Databricks’ Unity Catalog, Snowflake’s Polaris and AWS Glue are — those systems govern the underlying Iceberg tables. Google reads into them; it does not replace them. The second is that the focus of lock-in has simply moved up the stack to the semantic context and ontology layers.  Moor Insights & Strategy and others all have cautionary tales that exiting Google-managed semantics, Gemini agents or BigQuery abstractions may prove harder than migrating the data itself. The semantics and the orchestration are now the sticky layer. I think this is a logically coherent and impressive strategy, but for every gain, something is lost.  That loss is exactly the moment where an enterprise either preserves its independence or succumbs to lock-in for convenience and expedience.

There is a maturity gap also worth mentioning here as well. One widely-circulated analysis of Next 2026 carried its verdict in the title — the agent stack is ready, the semantic engine isn’t — arguing that the Knowledge Catalog, however promising, is not yet the governed business-context layer a true enterprise operating system demands and remains more aspirational than operational. With much of the federation and catalog functionality still in preview, optimism is the right approach from my perspective, not “all-in” commitment.

Meanwhile, the competition is playing a different game

The competitors are not building the same artifact, and the differences are instructive. The data-cloud catalogs — Databricks Unity Catalog, Snowflake Polaris and Cortex, AWS Glue, Microsoft Fabric — govern data and, increasingly, semantics; the entire field now accepts that agents need context, not merely access, as industry analysis of the field documents. Their structural limit is that catalog constraints are frequently informational rather than strictly enforced, and metric-oriented semantic layers model measures rather than actions or state changes. They excel at conversing with data and remain weaker at agents that act. The agent-management planes, exemplified by Microsoft’s Agent 365, approach the problem from fleet control — registry, identity, observability — and are excellent for organizations living inside Microsoft 365, bounded by that same dependence.

Palantir Foundry represents a genuinely different category. Where catalogs register tables and semantic layers define metrics, Foundry is built around an ontology that models entities, their typed relationships and the actions that can be taken against them — semantics in service of operational execution, not merely analytics.  That distinction is the single most important idea for anyone designing an agentic control plane today. As Atlan frames it, a semantic layer hands agents governed metrics, which solves half the problem; agents that reason across domains and act need a knowledge-representation layer underneath — what things are, how they relate and what operations are possible. A control plane that governs reads but not writes, metrics but not actions, is fundamentally limiting for agents, and semi-autonomous action is the entire point.    It is also worth noting, the semantic layer itself is now standardizing: the Open Semantic Interchange initiative, launched in late 2025 by Snowflake, dbt Labs, Salesforce and a coalition of partners under an Apache 2.0 license, finalized its v1.0 specification in early 2026. Just as MCP and A2A commoditized the agent communication protocols, OSI aims to commoditize semantic portability.

A blueprint for enterprise leaders

As always, the path forward is clear enough to state but extremely demanding to execute. An interoperable agentic control plane is not a product an enterprise purchases from a single vendor; it is an architecture it composes — open standards at the commoditized layers, owned assets at the differentiating one. Drawing on both the Next 2026 announcements and recent architectural engagements, I would urge leaders to prioritize four design commitments.

First, standardize on open formats at the storage layer. Apache Iceberg and its REST Catalog deliver genuine data portability, and this is the one element of Google’s model worth adopting wholesale, precisely because the broader industry already has. Second, standardize on open protocols at the agent layer— A2A between agents and MCP to tools and systems — so that a Gemini agent, a Claude agent and a partner’s agent can interoperate without any one of them owning the others. Third, own the semantic and ontology layer in the middle. Don’t just model metrics but entities, relationships and the typed actions agents may perform; this is what delivers semantic portability and keeps the vendor lock-in at bay and in the enterprise’s own hands rather than a vendor.   Fourth, own the control-plane core components — identity, registry, observability and policy — so that governance remains independent of any single platform.

Any vendor relationship that requires managed semantics will make it intentionally harder to migrate data.   The architectural response should never be to place those semantics in any single vendor’s control in the first place. Federation buys data portability; an owned ontology buys semantic portability; open protocols buy agent portability. Composed together, they close the gap that the analysts identified.

The vendors will continue to make the case that the control plane is a product. The analysts — Gartner on governance and failure rates, Forrester on protocol proliferation, TBR and Moor on the limits of federation — are collectively telling enterprise leaders something more useful: it is an architectural decision, and the organizations that treat it as one, that build adaptive governance before their agentic minions outpace them and that preserve the option to change their minds, will be the ones still in command of their AI a decade from now.

Google Cloud Next 2026 is a genuinely strong architecture, and there is no doubt that it is the most complete agentic control-plane offering any hyperscaler has yet shipped. It is also the clearest illustration to date of why no enterprise should outsource its control plane to anyone. The shift from owning models to owning the control plane is not just underway; for organizations serious about operating at the speed of an agent-driven business, it is inevitable. The winning move at this point is to show up with an architecture, not a purchase order.

This article was made possible by our partnership with the IASA Chief Architect Forum. The CAF’s purpose is to test, challenge and support the art and science of Business Technology Architecture and its evolution over time, as well as grow the influence and leadership of chief architects both inside and outside the profession. The CAF is a leadership community of the IASA, the leading non-profit professional association for business technology architects. 

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Most generative AI tools know less about R than languages like JavaScript and Python, thanks to how much training data is available for each. However, with a little extra setup, you can give a large language model (LLM) the knowledge it needs to improve its R skills.

Here are 10 ways to help generative AI write R code like a pro.

Use a coding agent

AI coding agents have more power, flexibility, and coding-focused tools than general-purpose chatbots.

Anthropic’s Claude Code and OpenAI’s Codex agents have versions that run in a terminal, IDE extensions, desktop and mobile apps, and other integrations.

R users may also be interested in Posit’s Posit Assistant, which is designed for data analysis in both R and Python. It needs less setup for R than general-purpose coding agents, and it has more built-in knowledge about data science, R package development, and Shiny apps. Plus, it can read objects in your R and Python environments by default, which can be useful in some situations (although perhaps not if you’re working with sensitive data). There are versions of Posit Assistant for RStudio, the Positron IDE, and the terminal. Setup info is here.

Note: Posit Assistant is not the same as the older Positron Assistant that was demo’d at last year’s posit::conf(). The older assistant will eventually be superceded by Posit Assistant. Posit Assistant comes pre-installed with RStudio but not pre-activated, so you don’t need to use it unless you want to.

Google’s original entry in this space, Gemini CLI, is being retired in favor of a new “Antigravity CLI” starting June 18.

There are other IDE platforms with built-in agents, including Cursor and Windsurf, and terminal + subscription coding agents such as Warp, which was open-sourced in April. However, I won’t be covering those here.

You may be limited at work by what your employer allows you to use, but you can still experiment on your own with public data — and then lobby for a new agent if a different one better meets your needs. Whatever you choose, though, moving to one of these from a web-based chatbot should produce better code.

“The shift from chatbot to agent is the most important change in how people use AI since ChatGPT launched,” says Ethan Mollick, co-director of the Wharton School’s Generative AI Labs at the University of Pennsylvania.

Set up CLAUDE.md, AGENTS.md, or GEMINI.md knowledge files

All the major coding agents look for knowledge files to load each time you start a session, and you can easily edit those files. The files can include things like your proficiency in various languages and how you like to document projects. For example, I tell my LLMs that I’d like a README.md in every project with info on how to use the project and technical info on how the project was coded.

Most coding tools let you have both an overarching main file that’s loaded into every session, and an additional file per project.

If you’re adding Claude or Codex to an existing code base, the /init slash command will create one of those .md project files after scanning and analyzing the code. You can also ask an LLM to interview you to create or add to one of those files.

Claude Code looks for a user-level main CLAUDE.md file at ~/.claude/CLAUDE.md and then a project-level file at ./CLAUDE.md or ./.claude/CLAUDE.md. The /memory slash command shows where those files are located. Codex uses AGENTS.md files. Antigravity docs say it looks for a main GEMINI.md file plus GEMINI.md and/or AGENTS.md files in your working directory.

Positron Assistant is set up to read AGENT.md, AGENTS.md, POSITRON.md, CLAUDE.md, GEMINI.md, and LLMS.txt in a workspace root directory, according to the docs. See the Positron docs for more on custom instructions.

Use agent skills

Agent skills can turn an LLM with questionable R knowledge into an expert that understand how you want it to write code. You can develop your own skills, work with your LLM to create skills, or download skills written by others. Claude even has a skill to help you build skills. This is one of the best ways to stop having to repeat the same instructions over and over. Instead, the LLM will “remember” what’s in your skills files by loading them when they’re needed.

What’s the difference between the knowledge .md files mentioned above and a skill? I like to think of CLAUDE.md or AGENTS.md files as important background info that’s always available, while skills are more specific instructions that are useful at certain times. Or, as Claude Opus 4.7 put it: “Skills are for triggered workflows (‘when user asks X, do Y’). A standing rule that applies to every project isn’t trigger-based; it’s a directive I should always follow.” Standing rules should go in CLAUDE.md.

“Create a skill when you keep pasting the same instructions, checklist, or multi-step procedure into chat, or when a section of CLAUDE.md has grown into a procedure rather than a fact,” according to Anthropic’s Claude Code docs. “Unlike CLAUDE.md content, a skill’s body loads only when it’s used, so long reference material costs almost nothing until you need it.” Only skill descriptions are loaded at the start of each session, so the LLM knows what skills are available.

Anthropic originally created skills for Claude in October 2025 and then published the concept as an open standard a couple of months later. Most coding agents now use them.

Anthropic has an easy-to-folllow guide to creating custom skills here if you want to try your hand at building your own.

Posit Assistant comes with several R-related skills built in and allows users to add more. You’ll find them here.

If you’re not using Posit Assistant, you can add Posit-developed skills to another coding agent. Posit published a GitHub repository with skills for creating R packages, Shiny apps, and Quarto documents; for creating and resolving GitHub pull requests; for open-source R and Python package releases; for code reviews (R, Python, JavaScript/TypeScript, SQL); and for creating architectural documentation for a codebase. Browse them all here.

Read and edit the skills you download

Skills are just a folder with one or more markdown text files that have a structured YAML header. That folder can include optional resources and scripts, too. Skill instruction files are easy to read and edit, so you can make sure they do what you want. Tweak them as desired.

For example, Claude helped me write my own customized R skill. Claude leans toward tidyverse packages, but there are other packages I like a lot, too, such data.table. I made sure the R skill knows my package preferences, and under what circumstances I prefer each.

If one of your preferred procedures changes, remember to update the associated skills. Or, ask an LLM to update it for you. Keeping skills up to date will make your coding agent more useful.

Keep your CLAUDE.md or AGENTS.md files updated, too. Maybe you started off with a CLAUDE.md file that said you’re an experienced Python programmer who is just learning R. Three months from now, you might want to update your R skill level. Or, perhaps you told an AGENTS.md file that you like thoroughly documented code, but now you’d prefer a lighter touch. You may want to have your coding agent go over those files with you from time to time and ask you about the main points and whether they need updating.

Use the btw R package and its MCP server

It’s frustrating when an LLM writes code based on an ancient R package version in its training data, or when it doesn’t know about a relatively recent package at all. btw solves this problem by letting your coding agent access info about all the R packages installed on your system. That means it can write code based on your specific R environment. Plus, btw lets an LLM access variables in your current R environment via a Model Context Protocol (MCP) server.

MCP servers are a standardized way for LLMs to access external data — in this case, your running R session (external doesn’t have to mean cloud). Like skills, MCP was created by Anthropic as an open standard and has since been adopted by most major AI platforms. The btw R package includes an MCP server, which you can install for Claude Code by running the following code in a terminal window (not R console).

claude mcp add -s "user" r-btw -- Rscript -e "btw::btw_mcp_server()"

btw comes with a lot of tools. It’s not a great idea to overload your LLM with tools it may never use. If you just want to register btw tools for accessing your R session and looking up package documentation, you can run a command like this instead:

claude mcp add -s "user" r-btw -- Rscript -e "btw::btw_mcp_server(tools = btw::btw_tools('btw_tool_run_r', 'docs', 'env'))"

You only need to do this once.

To connect Claude Code to your open R session, you also need to run btw::btw_mcp_session() in every new R session. (I sometimes forget this part until I’m puzzled why Claude can’t read my R variables or even see what packages I have installed.)

You can see a demo of btw in this Posit video that compares Claude Code and Posit Assistant.

Foundry

You don’t need to do this setup for Posit Assistant, since tools for accessing your R session and variables are built in.

Use plan mode for your projects

I cannot stress this enough. Just as humans benefit from having a plan before starting to implement a project, LLMs benefit from working through a plan before beginning to generate code. Plus, it can be useful at times to “brainstorm” with an LLM about structures and features, ask it for alternatives, or even have another LLM review a plan before implementing it.

Anthropic advises starting with plan mode. “Letting Claude jump straight to coding can produce code that solves the wrong problem. Use plan mode to separate exploration from execution,” they wrote in a best practices doc.

Claude, Codex, Gemini, and Posit Assistant all have a plan mode in their CLI versions that can be activated with the /plan slash command.

Foundry

Foundry

Make sure your coding agent learns from its mistakes

This is one of the best tips I read first from Joe Amditis, associate director of operations at the Center for Cooperative Media at Montclair State University: If your coding agent makes a mistake and you work together to fix it, make sure to save that memory so it doesn’t make the same error again.

Your agent may have an auto memory system that’s supposed to do some of this (I’ve used Claude Code’s), but you can instruct any coding agent to keep a separate lessons learned file for each project, too, or ask it what’s the best way to ensure it doesn’t make the same error again. This isn’t a guarantee, any more than you can be assured an LLM will follow all the rules in a CLAUDE.md or AGENTS.md file or all the steps in a skill. But it has definitely cut down on my agents making the same errors over and over.

Have your agent write tests and do code reviews

Tests and code reviews done by a coding agent aren’t a substitute for a human checking that software works. Review an LLM’s results yourself any time a task is important! However, agent-generated tests are still a good way to head off some problems and cut down the time you spend as your LLM’s debugging partner. If you don’t know where to start to help your agent know how to test and review code, see Posit’s testing-r-packages and critical-code-reviewer skills. Your agent may also have built-in code review skills, such as Claude Code’s /code-review slash command.

Code review skills are available from many sources. For example, Sentry has a code review skill in its repository. Aimed specifically at its project’s needs, it can be a useful sample for similar skills. And superpowers is a popular set of general-purpose programming skills that’s billed as “a complete software development methodology for your coding agents, built on top of a set of composable skills and some initial instructions that make sure your agent uses them.” I don’t use superpowers, but a lot of other people clearly do given its more than 227,000 GitHub stars and 20,000 forks.

Another tip: Several experts suggest using a different LLM — maybe even from a different provider — to conduct a code review, since each model has its own strengths and weaknesses.

Don’t forget general prompting good habits

Whatever programming language you’re using, being clear will improve your outputs. Keep your requests targeted, and don’t expect the LLM to read your mind.

“Codex handles complex work better when you break it into smaller, focused steps,” OpenAI says in its developer docs. “Smaller tasks are easier for Codex to test and for you to review. If you’re not sure how to split a task up, ask Codex to propose a plan.”

“Take time to make your prompts as relevant as possible, just as you would when helping a new teammate scope a task,” Google advises in its Five Best Practices for Using AI Coding Assistants. “Consider what details you need to share for a person to succeed, and provide all those details to your AI tool.”

And, don’t load up your context window to the LLM’s published limit. Performance often degrades as you get close to the maximum token limit.

Take advantage of open LLMs, particularly if you have budget and token limits

Open-weight models — especially ones small enough to run on a desktop computer — may never rival frontier LLMs like Claude, GPT, or Gemini. But for a lot of R coding, they don’t need to.

To see how well an LLM can write R code, it should have the same kind of harness that Claude Code, Codex, or Posit Assistant gives larger LLMs. “The harness is the product,” argues Mallory Mejias at Sidecar, an AI education company. “The model is the engine inside it — important, but increasingly interchangeable.” I wouldn’t go that far, since I still find the LLM to be a critical piece of this equation, and models differ. But the same LLM will perform differently depending on the tools and context it has.

Posit recently added Google’s open-source Gemma 4 26B to Assistant’s existing options of larger, closed-source LLMs. “Up until this point, models of this size — small enough to run comfortably on high-end consumer laptops — were on our radar but not yet capable enough to drive an agent harness like Posit Assistant,” Posit senior software engineer Simon Couch wrote on the Posit blog. “This has changed in the last few months with releases like Gemma 4.” However, to use it in Posit Assistant in RStudio, you still need to run it through a Posit AI subscription, not locally. It uses 1/10 the budget that the same session with Claude Sonnet would consume.

Several projects can use Claude Code to run local LLMs. Ollama, open-source software for running LLMs locally, does this with the terminal command ollama launch claude --model , such as:

ollama launch claude --model gemma4:26b

The makers of Unsloth, an open-source framework for running and training models, say running local LLMs inside Claude Code can be very slow due to a cache invalidation issue. They say this can be fixed by adding "CLAUDE_CODE_ATTRIBUTION_HEADER" : "0" to ~/.claude/settings.json under “env”.

Unsloth can also use Claude Code to run local models, but it’s somewhat more involved to install and set up than Ollama. See this Unsloth tutorial.

Open-source coding agent Open Code runs LLMs from OpenAI, Anthropic, Google, Kimi, Alibaba’s Qwen, and others. I haven’t warmed up to it yet compared with commercially backed CLI tools I’ve tried, but it has 174,000 GitHub stars so clearly a lot of fans.

AI consultant Thomas Wiegold, who switched from Claude to Open Code, said “OpenCode covers everything I need for my daily workflow. It’s fast, the provider flexibility is genuinely useful rather than theoretical, and the TUI is better for extended sessions…. That said, I’m not going to pretend it’s all smooth sailing.” He noted some stability issues and a remote code execution vulnerability earlier this year.

Wiegold’s suggestion? “Install both. Try others. Stay flexible.”

In summary

Large language models remain imperfect and unpredictable tools, but they’re improving rapidly — as are the harnesses around them. Even frontier LLMs in commercial coding agents can ignore instructions at times and otherwise behave in unpleasantly surprising ways. However, you’ll vastly improve your chances of generating quality code if you use coding agents, take time to set them up with quality instructions, and remember good prompting techniques. Good luck!

—

Coding agent info

Claude Code – Anthropic’s coding agent is available in the terminal and as an IDE extension, a desktop app, mobile apps, Slack app, and a cloud version that can work directly in your repos on GitHub. Arguably the first breakthrough coding agent, it now includes an elegant remote-control option where you can start a session on your desktop and then continue it on a phone or tablet. While designed for Claude LLMs, you can use it to run local LLMs via tools like Ollama or Unsloth Studio. When using Claude models, it tends to offer less usage than other vendors’ options. Anthropic has posted the terminal version’s code on GitHub, with usage governed by Anthropic’s commercial terms of service. You can use Claude Code via API pay per use or as part of a Claude subscription.

Codex – OpenAI’s answer to Claude Code is available via terminal, app, IDE extension, or cloud, with integrations for GitHub, Slack, and Linear. The CLI tool is open source under an Apache license, available on GitHub, and works via API pay per use or as part of a ChatGPT subscription.

Posit Assistant – The Posit (formerly RStudio) coding agent is designed for data work in R and Python, although Posit senior software engineer Simon Couch told me it would do fine for programming work for other uses and in other languages. It is available for the RStudio IDE (via a Posit AI subscription in RStudio), Positron IDE, and as a stand-alone CLI terminal app, although the CLI tool currently doesn’t feel as full-featured as the IDE integrations (that may change). As of this writing, you can also use API keys from Anthropic, OpenAI, and Snowflake Cortex and a GitHub Copilot account in Positron. Posit Assistant is being updated quite frequenty, Couch told me. If you tested it a month or two ago, it has more capabilities now.

Antigravity CLI – Google’s terminal-based tool will be replacing the Gemini CLI for unpaid and Google One users this month. There’s also an Antigravity IDE, SDK, and platform for orchestrating multiple agents. One advantage of Antigravity: Google offers a free plan with access to Gemini 3.5 Flash, Gemini 3.1 Pro, Gemini 3 Flash, Claude Sonnet 4.6, Claude Opus 4.6, and gpt-oss-120b, and what it describes as “generous” but undefined weekly rate limits based on “the degree we have capacity.”

Under-the-hood AI changes and efficiency improvements at the OS layer across Apple’s platforms are certainly the highlights at WWDC 2026. But there have also been significant changes IT admins will need to prepare for, particularly around Declarative Device Management (DDM). 

The Intel age is over

Apple warned us this was coming, but macOS 27 will not support Intel at all. The company will deliver three more years of security updates for those devices, and you will still be able to use Rosetta to get Intel app binaries to run legacy apps on Apple Silicon. But if you still rely on any Intel apps or Macs, it really is time to plan your upgrade.

DDM becomes the present

It was the future once, but when it comes to Declarative Device Management (DDM) that future is now. Apple is removing all its legacy MDM mechanisms to replace them with DDM. “For IT admins, WWDC 2026 is a migration year,” wrote Fleet. “Apple is removing legacy MDM mechanisms and replacing them with Declarative Device Management (DDM). Some of it is urgent. Some of it just needs a plan.”

It’s a great step, though IT admins will need to ensure they aren’t relying on legacy MDM to handle any of their device fleets. That’s a particular issue around software and security update management. In most cases, your MDM provider has probably already introduced DDM support. But if you aren’t certain, now is the time to find out before your systems fail.

Apple has also added new DDM tools across various systems, apps, identities and more. Some of the highlights include:

• VPN and Network configurations can be provisioned using DDM; they also become credential-reliant, which should make management more streamlined.
• Apple Intelligence, Siri, and keyboard settings can also be configured via DDM, and admins can manage individual Apple Intelligence tools. 
• Web content filter and content caching both become controllable with DDM.
• A new privacy key lets IT manage things like camera or microphone access.
• Apple has added a device system health reporting function to verify that hardware components on iPhone and iPad are genuine.
• IT will be able to detect whether a device is in Lockdown Mode.

“One of the new features I’m most excited about is the ability to set permission defaults for managed apps and websites viewed in Safari,” said Adam Henry, senior product manager at Iru. “While the user is still prompted to allow these permissions, we can now present those requests as a unified prompt immediately upon app launch, along with a custom explanation as to why those permissions are important — think a teleconferencing app or website that always needs access to camera and microphone.

“Overall, I think this is a much more user-friendly solution that will likely increase permission compliance.”

Siri and AI

Although, Apple has introduced new management tools for AI, it’s important to remember some advice from Joel Rennich, senior vice president for product management at JumpCloud: “Traditional IAM models assume users directly interact with applications, but agentic systems change that assumption. AI intermediaries can now retrieve data, execute workflows, and make decisions across systems. Enterprises will need identity frameworks that govern both human and non-human actors consistently.”

He also noted: “The separation between where data lives and where it is used becomes increasingly invisible to the user. Intent becomes the primary input, not app selection.”

At the same time, the evolution of AI on Apple’s devices promises a lot for enterprise users. Matt Vlasach, Jamf senior vice president, enterprise products and solutions engineering, told me: “Most notable for me was Siri AI and the push towards on-device and more capable models that can do more with user context. While obvious for consumer use cases as illustrated in the keynote, the opportunity to evolve this to the work context using a more advanced Apple Intelligence framework is an exciting evolution.”

Farewell AFP

Apple has finally eradicated Apple Filing Protocol (AFP) in macOS. This will be an issue for any business that uses legacy Time Capsule or NAS storage devices, though in most cases those products are already obsolete and should be replaced. This is unlikely to be a huge challenge for most, given that Apple began using SMB as its primary file sharing protocol back in 2013 and support for AFP server disappeared in 2020. (Time Capsule fans might want to take a look at the TimeCapsuleSMB open-source project.)

Hello AppleCare log collection

Apple will introduce a new remote log collection capability that integrates directly with the company’s support infrastructure. So, when AppleCare support engages with an organization’s IT team, they can provide an enhanced logging token which can be shared to get the device to collect diagnostic logs to upload to AppleCare. You just know this will expedite remedy.

Single Sign-On improvements

As I noted here, there are some significant Single Sign-On (SSO) updates; two that caught my eye include:

• IT can now insist on biometric as well as password ID on managed devices.
• Authenticated Guest Mode with Platform SSO allows users to quickly and securely login to a shared Mac in a temporary session.
• Platform SSO on macOS 27 adds web-based authentication.

Network and more

Another change affects the system processes used in device management at a network level. Apple now requires that you use TLS 1.2 or later. If you or your MDM systems are not doing so, get ready for things to break. (Apple has published a support article to help IT test their network environments in preparation for this change.)

Apple also announced that IT admins will be able to purchase and manage app subscriptions directly in Apple School Manager and Apple Business Manager. And it introduced a managed migration feature that should help migrate data, while preserving device management enrollment and settings. 

More information

I’ve really only offered a flavor of some of the IT improvements introduced at WWDC. To find out more, watch the Apple sessions on “What’s new in managing Apple devices” and take a look at the Apple Platform Deployment guide; it should be updated before the new operating systems ship this fall 

You can follow me on social media! Join me on BlueSky,  LinkedIn, Mastodon and subscribe to The Core.

AI has quickly become a top skill on the IT talent market, with 91% of IT leaders prioritizing AI expertise when hiring this year, according to recent survey from AI analytics vendor Reveal. Eight in 10 of tech leaders reported using AI in software development and 77% said expanding AI use throughout the organization is a top strategic goal for 2026.

However, as typically happens when there’s a rush to adopt any emerging tech, the talent market often can’t keep pace, creating a talent gap around these new, in-demand skills. According to Reveal, 50% of organizations already cite difficulties in “recruiting and retraining skilled technical staff,” while 80% say the shortage is directly impacting the organization’s operations and ability to act on AI projects — a challenge confirmed by CIO.com’s 2026 State of the CIO Survey.

While the talent market takes time to meet the demand, leaders will likely be looking to prioritize candidates who show a mix of technical, business, and communication skills as that can help “bridge the gap between AI output and actual results,” says Kareem Osman, VP and market director of technology talent solutions at Robert Half.

Highlighting valuable technical skills for AI

While concerns around AI-related layoffs and job displacement are rising, 48% of Reveal survey respondents say they have instead seen AI-related job creation, while 18% reported layoffs — further indication that AI is reshaping the job landscape in conflicting ways.

As these new jobs arise, filling them requires a flexible understanding of the concept of AI experience, which can range from proven hands-on experience with AI tools and services, to AI-adjacent knowledge of relevant programming languages, cybersecurity, or other relevant skills.

“Many companies are still experimenting with AI, so ‘experience’ can come from a mix of formal credentials and hands-on use cases — that could be examples of saving time, improving decision-making, or creating more effective outputs. What stands out right now is the ability to interpret AI results and apply judgment. It’s not just about the tools you’re familiar with but more about how you’ve used it to improve real work,” says Osman.

Job descriptions and listings will give a better idea of what a company is looking for, but according to Reveal, the most sought-after technical skills include Python (56%), machine learning (47%), Java (34%), and cybersecurity (33%), along with C/C++, SQL, .NET, JavaScript frameworks, and web development. The report points out that smaller organizations tend to look for C/C++ and cybersecurity skills for infrastructure needs, whereas larger organizations are more likely to emphasize a need for Python and AI-specific skills.

“Tech roles today are much more connected and less siloed, so drawing a clear line between past IT experience and AI applications can really strengthen a resume,” says Osman.

Demonstrating AI or AI-adjacent experience

Despite being a relatively new technology, companies are eager to hire talented workers with experience or expertise with AI and AI-powered tools. The hardest-to-fill tech role, according to Reveal’s data, is AI engineer (39%), followed by cybersecurity engineers (38%) as AI raises concerns around privacy and compliance.

If you aren’t an AI engineer or you don’t have cybersecurity experience, there are other opportunities to highlight relevant skills on your resume that translate well to AI skills or demonstrate you are eager to upskill. Robert Half’s Osman recommends highlighting any projects or workflows where you’ve used AI, explaining what the problem was, how you and your team used AI to address it, and the ultimate results.

“When it comes to AI, employers are placing more value on practical application and clear thinking than just years of experience. Even one strong example of AI application in your work can go a long way, so it’s worth digging into if it aligns with the role,” he says.

Emphasize work experience that shows you know how to improve workflows, translate technical concepts, communicate across teams, or solve business problems strategically. Demonstrate instances where you’ve helped your organization save time, improved outputs or decision-making, refined processes, met or reduced budgets, collaborated across different business units, and other similar examples to show that you understand the overall goal of AI implementation is to improve productivity and efficiency.

“Highlight the things that make a recruiter want to find out more. That could be examples of saving time, improving decision-making, or creating more effective outputs. What stands out right now is the ability to interpret AI results and apply judgment. It’s not just about the tools you’re familiar with but more about how you’ve used it to improve real work,” says Osman.

The need for a central data repository for enterprise analytics and gen AI has made the data lakehouse the default choice for enterprise data. Meanwhile, the emergence of open table standards makes the shift easier and reduces vendor lock-in for enterprises while also allowing for better integration between lakehouses and other enterprise systems and service providers.

Data lakehouses combine the structure of data warehouses with the flexibility of data lakes, making them versatile tools to make the most of any data the enterprise collects, whether it’s for business analytics, integration with other systems, or providing relevant context to LLMs.

The idea behind the data lakehouse is to merge together the best of what data lakes and data warehouses have to offer, says Gartner analyst Adam Ronthal.

Data warehouses also enable companies to store large amounts of structured data with well-defined schemas, as they’re designed to support a large number of simultaneous queries and deliver results quickly to many simultaneous users.

Data lakes, on the other hand, enable companies to collect raw, unstructured data in many formats for data analysts to hunt through. These vast pools of data have recently grown in prominence thanks to the flexibility they provide enterprises to store massive data streams without first having to define the purpose of doing so. 

According to Gartner, data lakehouses are the next step in the evolution of data architectures, merging these two capabilities into a single platform to overcome limitations of previous architectures, reducing complexity, streamlining data management, and supporting diverse workloads.

In late 2025, Gartner also released the first market guide for data lakehouse platforms. “The lakehouse is now firmly established as the architecture that most organizations will seek to standardize on,” wrote Ronthal and his co-authors in the report.

Meanwhile, data lakehouses themselves are also standardizing on the Apache Iceberg data table format, first created by Netflix in 2017, and donated to the Apache Software Foundation the following year. It hit the tipping point in 2024 with adoption by companies like Apple, LinkedIn, Adobe, and all the major cloud vendors. Even Databricks, which created the competing Delta Lake standard, now supports Iceberg natively.

Lakehouse vendors are opening their architecture more to allow better access to the data by third parties, says Gerry Szatvanyi, chief AI officer at consulting firm OSF Digital. “That wasn’t the case a few years ago,” he says.

And other enterprise service providers have been taking advantage of this, he says. For example, Salesforce Data Cloud can connect directly to Iceberg-formatted data.

“Salesforce has a Zero Copy access format, so it can connect its own data platform to another data lake without copying data into Salesforce,” says Szatvanyi.

And of course, as with everything else in the enterprise today, gen AI is having a big effect. Data lakehouses are particularly good for LLMs because they can provide critical business context for RAG embeddings and MCP access, the two most common ways to feed data into LLMs.

“Lakehouses are being accessed more by AI agents,” Szatvanyi says. “It’s the main thing I see happening.”

Even traditional business analytics is now increasingly handled via AI interfaces, he adds, democratizing user access to enterprise data.

In a recent IDC report, the leading vendors in the data platform space are Databricks, Google, Oracle, and Snowflake, with other major players including Microsoft, IBM, and Cloudera. IDC also listed Amazon SageMaker as a lakehouse platform to watch, but it only became widely available in early 2025, so wasn’t yet included among the top vendors.

Gartner includes Databricks, Google, Oracle, Snowflake, Microsoft, IBM, Cloudera and Amazon SageMaker on its list of representative vendors for data lakehouse platforms, among other firms.

The business benefits of data lakehouses

Docusign opted to go with Snowflake for the data platform used to train an internal agent for sales, and is training its ML models in order to serve customers more accurately. Information is pulled from Salesforce, and they’re also exploring Atlassian and ServiceNow, as well as other internal custom tools.

The information also goes out to LLMs using RAG embedding pipelines, and MCP connectivity is also being explored as the technology matures.

Other companies use data lakehouses for the flexibility of the data sources it supports and the volume of data they can handle.

Sega Europe, for example, began using the Amazon Redshift data warehouse to collect event data from its Football Manager video game back in 2016. At first this event, data consisted simply of players opening and closing games.

“But there was so much more data we could collect,” says Felix Baker, the company’s head of data services. “Like what teams people were managing, or how much money they were spending.”

Because of the data structures needed for inclusion in the data warehouse, data was coming in batches and it took too much time to analyze.

“We wanted to analyze the data in real-time,” Baker adds, but this functionality wasn’t available in Redshift at the time. “Databricks offered an out-of-the-box managed services solution that did what we needed without us having to develop anything,” he adds. In addition, the data lakehouse architecture enabled Sega Europe to ingest unstructured data, such as social media feeds.

The cost efficiencies enabled by providing a source for all of an organization’s structured and unstructured data is a value driver for data lakehouses, says Steven Karan, AI transformation lead at Capgemini, and it’s helped implement data lakehouses at leading organizations in financial services, telecom, and retail.

Moreover, data lakehouses store data in a way that it’s readily available for use by a wide array of technologies, from traditional business intelligence and reporting systems to ML and AI. “Other benefits include reduced data redundancy, simplified IT operations, a simplified data schema to manage, and easier to enable data governance,” Karan says.

Helping data emerge

One particularly valuable use case for data lakehouses is in helping companies get value from data previously trapped in legacy or siloed systems. For example, one Capgemini enterprise customer, which had grown through acquisitions over a decade, couldn’t access data related to resellers of their products.

“By migrating the siloed data from legacy data warehouses into a centralized data lakehouse, the client could understand at an enterprise level which of their reseller partners were most effective, and how changes such as referral programs and structures drove revenue,” he says.

One company capitalizing on the benefits of data lakehouses is life sciences, analytics, and services company IQVIA, which began using data lakehouses several years ago.

Before the pandemic, pharmaceutical companies running drug trials used to send employees to hospitals and other sites to collect data about things such as adverse effects, says Wendy Morahan, senior director of product management for clinical data analytics at IQVIA. “That’s how they make sure the patient is safe.”

Once the pandemic hit and sites were locked down, however, pharmaceutical companies had to scramble to figure out how to get the data they needed — and to get it in a way that was compliant with regulations, and fast enough to enable them to quickly spot potential problems.

Snowflake and Databricks gave the company the ability to store the raw data in any format, including images and audio, all in a single platform.

Lakehouse adoption growth

In a February report from Research and Markets, the data lakehouse market has been growing exponentially.

In 2025, it totaled $10.3 billion and is predicted to hit $12.6 billion by the end of this year, a compound growth rate of 22%. By 2030, this will be up to $27.3 billion, the research firm projects.

And according to a recent survey from Dremio, a lakehouse vendor, 63% of companies run most analytics on a lakehouse rather than a traditional warehouse, up from 55% in 2024.

Data lakehouses are also increasingly being used for IT and security workloads, says Ed Bailey, field CISO at telemetry vendor Cribl. “Previously, lakehouse providers were the realm of business data with a focus on structured data and SQL.”

Lakehouses can handle IT and security data at a lower cost, and this is a critical issue given the volumes of data in this space. “Even mid-sized companies produce much more IT and security data than business data,” he says. “Lakehouse vendors are finally starting to push into the market.”

But it’s still early, and initial solutions are immature and an awkward fit for this kind of data. “IT and security data are very different from business data,” he adds. For example, business data tends to be more predictable and well-structured. Plus, business users are more familiar with using data analytics tools than IT and security users. “This mismatch has been a serious obstacle to adoption,” he says.

Data lakehouses are also evolving in another way. Gartner says the lakehouse isn’t the ultimate solution but a transitional architecture on the way to more advanced systems, such as data fabric. The difference between the two is data lakehouses contain data from disparate systems, while data fabrics simply contain pointers to where the data is natively located.

An advantage of data fabrics is that the original security access controls and metadata are preserved and used, there’s no duplication of data, and no need to reconcile disparate standards.

“But it comes with some performance issues, and access isn’t that seamless,” says OSF Digital’s Szatvanyi.

A data fabric might be a good place for smaller companies to start, he says, or you can use both. “You can have a big chunk of data in a lakehouse and have a fabric for two or three secondary systems,” he says. “But I’d say the data lakehouse is the gold standard.”

The first mobile application user interfaces were often scaled-down versions of what was already available on the web. Then, user experience (UX) designers recognized that the different smartphone form factor created new business opportunities and greater utility compared to what people were doing on their desktops. UX designers created mobile-first experiences tailored to the job to be done and other design thinking principles. The underlying agile development practices, along with the emergence of app stores, paved the way for explosive growth in smartphones and mobile applications.

Today’s AI experiences seem to be following a similar path, with basic, sometimes bolted-on user experiences.

• First-gen chatbots appeared as pop-ups with text entry-and-response user interfaces (UIs) overlaid on the application’s screens.
• The primary UI for large language models (LLMs) is often a text box that accepts a prompt followed by a response that includes text and other media.
• Early AI agents were embedded in workflows, allowing users to prompt for information rather than point and click.

In a recent Coffee With Digital Trailblazers LinkedIn Live event, we discussed AI-first UX and planning for the evolution of customer journeys. Joanne Friedman, CEO of ReilAI, remarked, “A UX must be tailored to the persona and the role of the human being. Intent, perspective, authority to make decisions, and even judgment are elements of the human context that surround a role. That also means that context is now tied to security. What a person can and can’t see, or what they have access to now, makes it a design consideration and one that agentic AI is well-suited to enable.”

What is AI-first UX?

I expect that the evolution of how SaaS embeds AI agents will provide a model for how AI-first UX should look and behave. You can also see how AI is embedded in ecommerce experiences by selecting “I’m looking for ideas” in the Marriott Homes and Villas AI search experience, reviewing Perplexity Shopping, or trying out Rufus, Amazon’s new shopping AI.

“AI-first UX is the collapse of the app sprawl that’s defined enterprise software for the last decade,” says Vishal Sood, president of R&D at Typeface. “We’re moving from users bouncing between disconnected tools to orchestrated systems where agents carry context across workflows, and canvases and editors let humans steer the output. The winners will be hybrid environments that blend conversational interfaces, visual workspaces, and agentic orchestration into a single coherent experience.”

SaaS sprawl is a real issue. Large enterprises average more than 600 SaaS applications and spend $280 million annually on SaaS. Some SaaS solutions are embedding data fabrics and zero-ETL capabilities, enabling their AI agents to use data outside their environments. The results are not just a shift from clicks to conversations; it’s an evolution toward integrated experiences.

Hector Ouilhet Olmos, vice president of design for AWS Solutions at Amazon Web Services, says agentic AI demands a fundamental shift from the “desktop metaphor” to designing interfaces that mimic human collaboration dynamics rather than physical objects. “Instead of forcing fluid, conversational intelligence into rigid buttons and chat panels, we must dismantle traditional user interfaces and build human ones. These will translate millennia-old human collaboration patterns like negotiation, interruption, and escalation into native digital experiences where AI functions as a teammate, rather than a tool,” says Olmos.

Many of today’s traditional user experiences can be deconstructed into forms, reporting dashboards, and workflows. Let’s consider how AI-first UX may evolve away from these structures.

Conversations and interviews replace forms

Will entering data into forms and using them to make edits become obsolete? AI-first UX will provide alternatives when people must enter information into systems of record to get their work done.

“Instead of navigating screens or filling out static forms, users simply describe what they want to accomplish,” says Chris Mayor, vice president of architecture at Coupa. “Forms evolve into adaptive conversations that prefill known information and dynamically gather the rest. This transforms enterprise software from systems of record into systems of action.”

One UX metaphor, based on conversations, works when the user has a job in mind. A second occurs in reverse, where an AI agent prompts users for recommended actions or decisions. “Every platform shift begins by replicating the old model, but real transformation happens when workflows are redesigned,” says Preetpal Singh, group managing director and global head of product and platform engineering at Xebia. “In this model, forms evolve into adaptive interviews that prefill known data, ask contextual follow-up questions, and accept natural language or images, while still preserving clarity and compliance.”

AIs generate reports and dashboards

Many IT departments used to have reporting functions with teams developing dashboards and writing custom SQL queries to retrieve data. Much of that work shifted out of IT, as many CIOs promoted citizen data science, established data visualization best practices, and deployed advanced analytical solutions to help departments build dashboards and move away from manual spreadsheets.

As organizations deployed more self-service business intelligence tools, they adopted practices for applying design thinking in data science and integrating analytics into workflows. But there was a significant challenge: Designers, data scientists, and engineers had to anticipate users’ questions about customers, finances, and other business functions and then implement data visualizations to answer them.

AI-first user experiences will turn reporting and dashboarding around. Instead of people generating relevant data visualizations, AIs will.

“The definition of ‘user-friendly’ has changed forever, and ‘AI over UI’ has become a new calling when it comes to building enterprise products, says Maksim Ovsyannikov, chief product officer at SugarAI (formerly SugarCRM). “This emphasis on conversational user experience focuses on a user’s ability to ask questions and compose prompts rather than their ability to understand workflow and build reports. Users now simply ask for the report or insight they need instead of spending hours building a report or a dashboard that becomes stale and outdated in a matter of days.”

Singh of Xebia adds, “Reporting [is shifting] from static dashboards to narrative copilots that explain what changed, why it matters, and what actions to consider next, combining visual metrics with interpretation and foresight.”

Workflows become agentic AI collaborations

Simple workflows live in one system of record and connect people through a linear process. Examples include editing website content in a content management system, recording new information about a prospect in a customer relationship management program, or performing basic accounting functions in an enterprise resource planning system. More complex workflows are non-linear, involve multiple departments performing different responsibilities, and require integrating several systems of record. Examples include employee onboarding, quote-to-cash processes, and contract management. 

Now imagine all the underlying systems are API-enabled, have AI agents in place to perform basic functions, are integrated with Model Context Protocol servers, and have an AI orchestration platform to facilitate work. What was a workflow becomes a collaboration between people and AI agents that can perform multiple steps through a single user interface.

“An AI-first UX replaces rigid, screen-driven workflows with intent-driven interaction, where users query the system, and AI agents orchestrate the underlying processes,” says Avi Greenfield, vice president of digital enterprise products at Quadient.

A typical employee onboarding process involves steps performed by people in HR, finance, and IT across many systems. In an agentic AI experience, HR initiates the process, and work is coordinated through AI agents, with decisions and approvals sent to the appropriate managers.

“Agentic workflows begin to resemble coordinated teamwork, where AI agents execute multistep processes across systems, surface their reasoning, and escalate to humans when judgment is required,” says Singh of Xebia. “The goal is augmentation over replacement and choosing the right interaction model at the right moment, grounded in strong UX discipline, transparency, and trust.”

Enterprise platforms are enabling the transformation from the workflow they support to agentic AI experiences. For example, Workday recently announced Sana with a new AI user interface and over 300 skills to automate many HR and finance workflows. “Most AI projects today live in pilots and browser tabs. They look impressive in demos, but they don’t change how work actually gets done,” said Gerrit Kazmaier, president of product and technology at Workday. Another example is Anthropic’s release of Claude Cowork with plug-ins for legal, marketing, and other business functions. Example workflows include contract reviews, product documentation, and financial journal entries.

How AI-first UX impacts development

The opportunity to create scalable mobile user experiences drove devops teams to build APIs, use low-code mobile development platforms, and expand continuous testing to cover mobile applications. Vibe coding and other code-generation tools are just the start of what will support the development and testing of agentic AI experiences.   

“AI-first UX is moving beyond chatbots into embedded, ambient intelligence where AI becomes an invisible layer that anticipates customer needs and translates intent into action,” says Amit Patel, senior vice president of consulting services at Consulting Solutions. “This requires a shift from feature-driven design to intent-driven experiences, supported by strong data foundations, APIs, and governance so AI can act responsibly. The companies that win will treat AI not as a bolt-on assistant, but as a core experience layer that reduces friction, personalizes at scale, and builds trust through measurable value.”

In larger companies, developing AI experiences will require orchestrating work across multiple AI agents, both from SaaS providers and from internally developed systems. Developers will need to update observability standards, automate AI agent testing, define release-ready criteria, review multiagent frameworks, and consider orchestration platforms.

Andrew Filev, CEO and founder of Zencoder, says, “Just as platforms exist to coordinate human teams, AI demands a new orchestration layer: interfaces designed not to do the work, but to visualize, steer, and direct outcomes across multiple agents.”

We’re only in the early stages of how people and AI agents will collaborate, so expect to see evolutions in platforms and capabilities. Looking to the future, expect that voice, augmented reality/virtual reality, and other physical AI will further transform how we develop AI-first user experiences. 

As the DRAM shortage continues with no end in sight, China-based ChangXing Memory Technologies (CXMT) is taking advantage of an opportunity to grow its base.

Until now, CXMT has sold its products in China to lesser-known brands of memory sticks. But recently, its memory was found on a DDR5 DIMM from Corsair, a major consumer memory brand. And the company is preparing to go public, hoping to raise as much as $5 billion.

CXMT is the number four memory maker in the world, behind Micron, Samsung, and SK Hynix. Its market share is believed to be somewhere around 8% of the worldwide market, with most of its customers in its native China.

CXMT does not make the High Bandwidth Memory (HBM) that is in such high demand for AI accelerators these days, but it does make DDR5 memory, and that is in very short supply as well. So, buyers will take whatever they can get.

On the financial side, CXMT has turned around its fortunes in recent months. Its first-quarter revenue was 50.8 billion yuan, or USD$7.5 billion, which represents a 719% increase from the same period last year. Operating profit swung from a 2.8 billion yuan (USD$390 million) loss in the first quarter of last year to a 35.4 billion yuan (USD$5 billion) gain with a 70% profit margin.

CXMT expects to use its IPO funds for aggressive expansion and investment in advanced processes. Monthly wafer production is projected to increase from 100,000 wafers in early 2024 to 300,000 wafers by the end of this year. The company is also expected to invest in production lines to enter the HBM market.

And in a stroke of good luck, CXMT and another memory maker, YMTC, have been removed from the Pentagon’s list of restricted suppliers and can now sell their products in the US. That means that they can not only sell to the US commercial market but also bid on US government contracts.

So, can CXMT have an impact on the memory industry?

Memory analyst Jim Handy of Objective Analysis says it already has. CXMT got into DDR4 in 2023 while the majors were focusing on their DDR5 ramps, and it has undercut the big three memory makers, he said.

DDR4 prices got so low that the majors all phased out of DDR4 production. Then CXMT learned to make DDR5 and dropped out of DDR4 to make more DDR5. For a while, this made DDR4 prices rise higher than DDR5. “Everyone in the industry was surprised when this happened,” Handy said.

“Now the majors are making 80% — give or take — gross margins on DRAM. Even a company whose cost to manufacture was twice that of its competition would make a 60% gross margin in this case, so the market is greatly favoring CXMT —  for the time being,” he added.

But there is risk for CXMT. DRAM is a commodity, which makes it subject to the typical glut and shortage patterns that are driven by supply and demand imbalances.

“Today’s AI-driven shortage will reverse at some point. When it does, the majors will see prices drop to cost. If CXMT’s costs remain higher than everyone else’s, the company will hemorrhage money during that period,” said Handy.

There is a governance gap at the center of enterprise AI infrastructure strategy. Most organizations cannot see it because they have not yet been forced to look. Neoclouds have moved from early-adopter experiments to mainstream enterprise deployments. The risk frameworks required to govern those deployments have not kept pace. The CIOs who close it first will define responsible AI infrastructure leadership for the next decade. No published framework combines a scored vendor evaluation tool, a contract gate, and a quantified governance ROI. This article does.

The speed of adoption has outrun the risk community

The enterprise cloud market is moving faster than enterprise risk frameworks can track it. Neoclouds, GPU native infrastructure platforms from providers such as CoreWeave, Lambda Labs, and Nebius, are capturing AI workloads at a pace that Forrester projects will reach $20 billion in 2026. The Barclays CIO Study, which surveyed 250 enterprise technology leaders, found that 86 percent plan to repatriate at least some public cloud workloads. IDC projects cloud infrastructure spending will exceed $200 billion in 2026. Synergy Research Group reports  neocloud revenues exceeded $23 billion in 2025, a 200% year-over-year increase. Gartner forecasts neoclouds will capture 20 percent of the $267 billion AI cloud market by 2030, and enterprise contracts signed in 2024 and 2025 come up for renewal in the second half of 2026, when evaluation criteria shift to production standards: sovereignty, resilience, and compliance. The frameworks built before that window closes determine who leads and who reacts.

The operational maturity gap

The gap between neocloud capitalization and operational readiness is a fundamental capability failure: Many have secured GPU capacity; few have demonstrated the incident response, SLA enforcement, and operational transparency enterprise clients require. Gartner projects worldwide AI spending will reach $2.52 trillion in 2026, committed to providers whose behavior under genuine stress is entirely unknown. Deloitte’s 2026 survey of 3,235 leaders found only 43 percent rate their technical infrastructure as highly prepared for AI. Whether operational maturity has kept pace is the central CIO question.

Tracking 400+ incidents at whencloudsfail.opey.org shows two patterns: disruption duration correlates with provider concentration, and organizations with exit provisions recover faster at materially lower cost. A Tier 2 European financial institution that committed 80 percent of its AI inference workload to a single neocloud provider faced a mandatory migration when that provider was acquired in early 2025. The enterprise had no portability clause. This institution, running $1.5 million annually in neocloud compute, incurred a $3 million remediation bill that appeared on no budget, plus an estimated $300,000 to $600,000 in revenue disruption above the migration cost itself. A peer organization that had tiered workloads across two providers and maintained contracts with exit provisions completed the same transition in 31 days at 12 percent of the cost. The difference was contractual: MECT Exit Architecture clauses requiring 30-day portability and 90-day migration support turned an unplanned crisis into a managed transition.

The compute capacity trap

The structural risk deepens as compute capacity dynamics evolve. GPU supply remains the most constrained commodity in enterprise technology, reinforced by NVIDIA’s $2 billion investment in CoreWeave and the resulting capital expenditure race. McKinsey’s neocloud analysis identifies the central risk: Providers that secured GPU capacity before building enterprise-grade operations management are structurally fragile, and consolidation will accelerate when demand softens. Enterprises focused on failing providers will face migrations comparable to repatriation exercises that many are still completing. That is evidence that the risk community has not yet been forced to price it. McKinsey identifies the structural reason:  BMaaS margins collapse to 14-16 percent after labor, power, and depreciation, and if utilization slips below 80 percent, returns flatline. The financial distress signals are public: CoreWeave’s Q4 2025 earnings set Q1 2026 guidance of $1.9 to $2 billion, below analyst consensus of $2.29 billion, with 2026 CapEx projected at $30 to $35 billion. The company has an Altman Z-Score of 0.52, below the 1.8 distress threshold, and its top customer accounts for nearly 70 percent of revenue while building competing infrastructure.

The GPU assets collateralizing that debt have depreciated 60 to 75 percent from peak, compressing the collateral base as repayment obligations accelerate. Even a 10 percent consolidation scenario results in $2 billion of enterprise workloads being moved in unplanned migrations.

The hyperscaler counter move

AWS European Sovereign Cloud and Microsoft Foundry Local represent deliberate moves into the territorial advantage that neoclouds built on sovereignty. Forrester has predicted at least two major multiday hyperscaler outages in 2026, driven by AI infrastructure complexity, sustaining pressure to rethink cloud concentration across all provider categories. For CIOs, this creates genuine optionality only for organizations that have built evaluation frameworks to exercise it. A second exposure: hyperscalers are subcontracting AI compute to neocloud providers, meaning an enterprise running workloads through a hyperscaler endpoint may be running on neocloud infrastructure with no MECT protections and no visibility into the underlying provider’s financial condition.

The MECT framework: Maturity, Exit, Classification, Threshold

Those frameworks have four components, and organizations executing well implement all of them before the first workload is placed.

Component 1: Maturity scoring

Before contract signature, require documented evidence of incident response procedures, historical availability data across the provider’s production enterprise workloads, SLA penalty structures that carry a minimum 15 percent service credit per breach, and references from enterprise clients who have lived through a significant production incident with that provider. Providers with Series C or later funding and more than two years of enterprise deployments represent the upper maturity tier; Deloitte confirms only 43 percent of organizations rate their AI infrastructure as highly prepared. Any provider with fewer than 18 months of enterprise history scores zero on availability data by definition, setting the outcome band before the first reference call. The absence of an incident history is not a positive signal. It is a data gap that should trigger deeper diligence, not accelerated commitment.

Component 2: Exit architecture

Every neocloud engagement must be reviewed through an exit lens from day one. Contracts must require data portability standards with a 30-day full export window, prohibit proprietary API lock-in at the API layer, and specify a minimum 90-day obligation for migration assistance. If leaving is contractually expensive or technically complex, the organization has accepted an unpriced risk it has almost certainly not reported to its board.

Component 3: Classification by criticality

A practical tiering model distinguishes three classes: exploratory workloads that can tolerate interruptions, operational workloads where degradation is recoverable within 4 hours, and mission-critical inference, where failure carries immediate financial or regulatory consequences. The sovereignty risk is specific to this category: the majority of neocloud providers are US-headquartered, meaning CLOUD Act authority gives US law enforcement compelled access to all data they process, regardless of where the physical data center sits. A CIO selecting a US-headquartered neocloud for EU sovereign AI has not achieved data sovereignty but has accepted a compliance liability that EU AI Act enforcement under Article 5 and Annex III high-risk system obligations can impose penalties of up to 7 percent of global annual turnover. The EU Digital Operational Resilience Act requires documented vendor oversight and board accountability for critical third-party technology dependencies.

Mission-critical inference workloads with data residency or sovereignty requirements must run on infrastructure whose legal structure aligns with the governance promise made to regulators and boards. This category is the fastest growing: ABI Research projects inference at 80 percent of neocloud GPUaaS demand by 2030, making the highest risk tier the fastest scaling one.

Component 4: Threshold monitoring

The Basel III framework caps single counterparty exposure at 25 percent of eligible capital. Applied to AI infrastructure, no single neocloud provider should carry more than 25 to 30 percent of mission-critical AI inference capacity without a tested failover architecture. CIOs must report quarterly: provider share by workload class, recovery timeline for a multiday outage, and the rebalancing threshold that triggers action.

MECT vendor readiness index: Score your provider before contract

SCORE BANDS:  0-4 = DO NOT PROCEED  |  5-8 = CONDITIONAL  |  9-12 = CLEARED
Score each criterion: 0 = not present, 1 = partially documented, 2 = fully verified. Total out of 12.

MECT contract gate: Required clauses before signature

Any FAIL = contract not ready for signature. Escalate to General Counsel.

The sovereignty intention gap

Gartner projects worldwide sovereign cloud IaaS spending will reach $80 billion in 2026, driven by what Gartner terms geopatriation: the deliberate shift of workloads from global providers to local infrastructure for regulatory and geopolitical reasons. Deloitte’s 2026 State of AI survey of 3,235 leaders across 24 countries found that 83 percent view sovereign AI as strategically important, 77 percent factor country of origin into vendor selection, and 66 percent are concerned about foreign-owned AI infrastructure. McKinsey confirms the gap: Widespread interest, almost no executable action plans. Organizations declaring sovereign AI as a board priority without completing workload classification are making commitments their infrastructure cannot honor. The MECT Framework closes that gap before a provider incident makes it a crisis response.

The competitive consequence of waiting

The financial case is in the incident record: the organization without exit provisions absorbed a $3 million remediation bill on a $1.5 million annual compute base, while the organization with MECT disciplines completed the same transition at 12 percent of that cost, a $2.64 million difference. Forrester documents that enterprise deployments in this category are tripling year over year while governance frameworks remain at their starting point. Organizations with a governance architecture in place compress decision cycles and capture the neocloud cost advantage: up to 66 percent savings versus hyperscaler GPU rates, without the unpriced risk that erodes those savings on the first unplanned migration. That combination of risk reduction and cost capture is the governance ROI the board has been waiting for a CIO to quantify.

The board conversation about AI infrastructure risk is coming for every organization. The only question is whether CIOs are leading it or responding to it.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Drowning in hype and under pressure from top leadership, CIOs are racing to operationalize strategic AI initiatives in an effort to demonstrate — and more importantly, deliver — measurable ROI from this equally disruptive and transformative technology.

The perpetual pipeline of AI pilots and rampant experimentation are giving way to a new mandate to prioritize and scale AI solutions with the greatest propensity to deliver business value and impact the bottom line.

Yet the ability to achieve quantifiable ROI from AI projects remains somewhat elusive for many CIOs as they spearhead AI’s next chapter. According to CIO.com’s 25th annual State of the CIO survey, which canvassed 662 IT leaders and 249 line of business users, less than a fifth (19%) of respondents say AI initiatives have met or exceeded business goals, and 18% admit fewer than a third of AI use cases are meeting defined expectations.

CIO.com / Foundry

Lack of clarity around business strategy and metrics is proving to be a major barrier to advancing CIOs’ AI agendas. Almost a third (32%) of this year’s State of the CIO respondents called out ill-defined ROI metrics as a hurdle to scaling AI, along with murky corporate AI strategy (31%) and a lack of in-house expertise, cited by 40% of this year’s respondents.

“No one is measuring ROI on an ongoing basis because we are facing counterpressures from every vice president and line-of-business domain looking to implement AI for their own optimization,” notes Andrea Ballinger, CIO at Rensselaer Polytechnic Institute (RPI). “We are saying yes to everyone without stepping back and focusing on the business cases that show real value.”

CIO.com / Foundry

Creating the infrastructure to achieve AI ROI

The dynamic is starting to shift as organizations prioritize targeted use cases and lay the groundwork for scalability and ROI. Cross-functional steering committees and specialized task forces are emerging as critical building blocks to identify, prioritize, and align use cases to enterprise goals. Eighty-three percent of IT leaders surveyed confirmed their organizations either have such structures in place or are planning to implement them within the year. IT is the dominant player on these committees with other functional areas well represented, including corporate leadership and security and risk teams, and to a lesser degree, business-oriented domains such as finance, legal, and HR.

Formal processes for approving AI projects are far less evolved. Slightly more than half (53%) of 2026 State of the CIO respondents have established some type of official approval process, with 28% planning to activate something within the next 12 months.

KPIs, another critical milestone for AI success, are also not well defined in most enterprises. Less than half (47%) of respondents have established formal metrics, with another 34% planning to do so within the year. For those measuring AI success, operational efficiency and process improvement rank as the top metric, cited by 40% of respondents, followed by employee productivity (34%) and cost reduction (30%). AI’s impact on revenue or growth is less of a factor today, cited by only 27% of respondents.

CIO.com / Foundry

First Student, a leading provider of school bus transportation services, has stood up a well-defined innovation framework and AI-specific council — two moves CIO Sean McCormack credits to the firm’s early success scaling AI initiatives aligned to key business goals. The AI council, with representation across business leaders and the C-suite, meets regularly to review AI use cases and identify those with most potential for payback.

“We have more discipline around business cases than most companies,” says McCormack. “Everything is metrics-driven and dependent on proving value. By the time we put something into production, it’s been through a series of proof of concepts, there’s been a deep dive on financials, and we are able to move quickly and demonstrate value.”

Three years into its AI journey, TIAA has a rich stable of generative AI and agentic AI use cases spanning fraud detection and prevention along with call center companions and a litany of other tools. The majority (85%) of the financial services firm’s workforce uses TIAA Gate, its internal AI platform. Yet even with all the right structures in place — investment in training, robust governance frameworks, steering committees, an AI center of excellence (CoE), and an enterprise mandate for strategic use of AI as part of everyone’s performance goals — ROI remains a challenge.

“What’s on paper sometimes doesn’t turn into real ROI given the reality of operational costs,” notes Sastry Durvasula, TIAA’s chief operating, information & digital officer. “Something may prove to be a successful pilot, but you need to understand the full cost of operations — for example, the efficiencies of running tokens or how you’re handling traffic or RAG [retrieval augmented generation].”

Thomas Prommer, a longtime CTO, CIO, and CAIO, makes three recommendations to facilitate the quest for AI ROI. First, establish joint accountability at the project level with a named technical and business sponsor for each project, both of whom co-own outcomes. His firm had success replacing a centralized AI CoE with embedded AI squads that live inside individual business units. The CoE model created a clearinghouse that nobody owned, whereas embedded teams force accountability at the point of business impact, he explains.

Prommer’s third recommendation is to implement stage-gated funding tied to outcome milestones, not deliverable milestones. “We don’t fund ‘build a model,’ we fund ‘reduce returns by 8% on this category’ with checkpoints at 90, 180, and 270 days,” he explains. “Projects that miss two checkpoints gets killed. We kill roughly a third of what we start and that’s healthy.”

Developing a keen understanding of business workflows and engineering the experience layer for the people tasked with executing AI-enriched workflows is essential to creating value and effective adoption at scale.

“If someone on the data science team builds a great model that provides insights on improving manufacturing efficiency, but it’s so far removed from what the shop floor supervisor does in day-to-day life, it will never be used at scale,” says Sriram Krishnasamy, the former chief digital information and transformation officer at FedEx.

The CIO as chief AI orchestrator

Who better than the CIO to usher in the organizational structures and business practices that help identify the right AI use cases and establish metrics for success. IT leaders’ in-depth knowledge of AI and the broader technology stack is a plus. But the reason top executives are leaning on CIOs as critical orchestrators of AI is their proven ability to work effectively across business functions and serve as change management champions.

Almost half (46%) of this year’s respondents view the CIO as a business leader who proactively identifies business needs and opportunities and follows up with technology and provider recommendations that align with stated business goals. The vast majority (83%) view CIOs as a changemaker.

Much like last year, the top CEO priority for IT leaders is to research and implement AI products and projects, cited by 27% of respondents. IT leaders are meeting the mandate by working far more closely with lines of business on AI applications, according to 79% of respondents.

“AI requires so much executive engagement — in our case, it made the most sense for me to lead the charge,” says First Student’s McCormack, also a member of CIO.com’s Hall of Fame.

This year’s IT leader respondents expect to accelerate and expand involvement with AI/machine learning (76%) and agentic AI (70%), as well as cybersecurity (63%). Responding organizations anticipate a boost in investments across the full complement of AI technologies, including generative AI (67%), machine learning (66%), and agentic AI (65%) over the coming year.

CIO.com / Foundry

First Student is currently running AI in production at scale across multiple use cases, including for predictive maintenance, fleet and driver safety, contract development, automated hiring, agentic software development, and agentic voice bots that assist internal users with help desk and HR issues. As the company builds out its portfolio of AI-enabled use cases, McCormack says it’s critical to ground everything in a flexible architecture.

“It’s such a changing landscape; it’s difficult to pick a solution,” he explains. “We’re building our own architecture so we can quickly switch models” and not be dependent on one system, he says.

The rest of the IT agenda

While AI commands an all-hands-on-deck approach, it’s not the only CEO directive for CIOs this year. Cyber and data security remain top-of-mind in the C-suite, with a quarter of State of the CIO respondents noting it as a top CEO priority for 2026, up from 20% last year. CEOs are also looking for CIOs to strengthen IT and business collaboration, cited by 23% of 2026 respondents.

To achieve those directives, CIOs are expanding technology initiatives in areas such as business process and IT automation (56%), security and risk management (55%), and data and business analytics (54%).

CIO.com / Foundry

Building a solid data and governance foundation is the most important agenda item at RPI, primarily in preparation for more extensive AI deployment and adoption. Ballinger, 70 days into her tenure as RPI CIO, concedes the educational institution is not aiming to be on the first adopter wave of AI innovation. Rather, its strategy is to adapt, grow, and transform organizational structures and its data ecosystem in pursuit of maximizing AI’s promised advantages.

Ballinger is currently shopping an RFP that encompasses a data fabric layer, secure containerization, and a data factory approach. “We are designing the ecosystem with strategy and KPIs in mind,” she says. “The entire process is predicated on deciding what business cases are valuable before they hit the data ecosystem. We’re not looking to put something into the ecosystem and hope it gets a return.”

With the pace of change growing more intense and the stakes surrounding AI innovation soaring higher, the CIO role continues to be more business-oriented and less straight technology focused. Eighty-four percent of this year’s IT leader respondent pegged the CIO position as more digital and innovation focused while 82% confirmed that CIOs are more likely to actively lead digital transformation efforts compared to their business counterparts.

With the average CIO now juggling 1.6 positions, including chief security officer, CISO, CAIO, and other business-related posts, the job continues to become more expansive, highly strategic, and more fulfilling, especially for leaders willing to close the door on the traditional “keeping the lights on” CIO model and embrace new challenges.

“The CIO of 2026 is a hybrid — half operating architect, half risk officer,” Prommer says. “The technology choices are getting easier, but the business and ethical choices are getting harder. CIOs who only know the tech stack will be reporting to CIOs who know both.”

Foto: RossHelen | shutterstock.com

Den (richtigen) Technologie-Stack auszuwählen, ist eine der diffizilsten Herausforderungen in Sachen Softwareentwicklung: Ohne Framework kein Development – allerdings zeigen sich die wahren Stärken und Schwächen eines Rahmenwerks erst in der Praxis. Für Developer eine Zwickmühle, aus der auch Prototyping nur bedingt befreien kann. Schließlich besteht die allgemeine Tendenz dazu, Technologien zu vertrauen, die sich in der Vergangenheit bewährt haben. So können allerdings auch innovative Entwicklungen durch die Lappen gehen. Das ist speziell mit Blick auf den Bereich der JavaScript-Frameworks wahrscheinlich, da deren Entwicklung besonders rasant voranschreitet. Dass qualitativ hochwertige Rahmenwerke im Überfluß zur Verfügung stehen, macht die Sache nicht besser.

In diesem Artikel werfen wir einen Blick auf die führenden JavaScript-(Frontend-)Frameworks und vergleichen diese auf Feature-Ebene miteinander. Folgende Frameworks werden dabei behandelt:

• React

• Vue

• Angular

• Preact

• Lit

• Svelte

• AlpineJS

• SolidJS

• HTMX

• Qwik

Es gibt diverse Möglichkeiten, sich der Entscheidung über ein JavaScript-Frontend-Framework anzunähern. Ein Faktor, den Sie dabei fokussieren sollten, ist Vertrautheit: Wenn Sie und Ihr Team mit einer bestimmten Technologie wirklich vertraut sind, sollten gute Gründe vorliegen, um davon abzuweichen. Diesbezüglich könnten folgende Fragen relevant sein:

• Entspricht die Technologie nicht mehr den Anforderungen des Projekts?

• Besteht die Gefahr, dass das von Ihnen verwendete Framework eingestellt wird?

• Sind interessante Funktionalitäten nicht existent?

Wenn Sie alle Fragen mit ‘nein’ beantworten können, sollten Sie sich lieber zweimal überlegen, auf ein neues Framework umzusteigen. Dennoch ist es allgemein von Vorteil, neuen Frameworks offen gegenüberzustehen, die projektspezifische Benefits in den Bereichen Developer Experience, Performance oder Community Support realisieren können. Dazu kommt, dass JavaScript und speziell Frontend-Frameworks miteinander interagieren und sich gegenseitig stark beeinflussen. Sich mit einem Rahmenwerk zu befassen, kann deswegen oft zu synergetischen Insights führen. Anders ausgedrückt: Ein Frontend-Framework-Deepdive kann niemals schaden.

Die 10 wichtigsten JavaScript-Frameworks

Um einen Überblick über die führenden reaktiven Frameworks zu bekommen, werfen wir einen Blick auf die populärsten Abkömmlinge. Diese haben wir auf Grundlage ihrer jeweiligen Download-Zahlen auf dem Open Source Repository NPM ermittelt. Ein Klick auf den Link führt Sie zur jeweiligen NPM-Download-Seite inklusive der aktuellen Statistiken.

1. React

2. Vue / Vue 3

3. Angular (CLI)

4. Preact

5. Lit

6. Svelte

7. AlpineJS

8. SolidJS

9. HTMX

10. Qwik

Obwohl Popularität kein besonders guter Indikator für Qualität ist, sagt sie doch viel darüber aus, wie es um die Verfügbarkeit von Developern steht, die mit dem Framework arbeiten können. Das könnte speziell für größere Teams und Projekte einen entscheidenden Faktor darstellen.

Zu beachten ist mit Blick auf die Top Ten, dass es sich bei allen “Kandidaten” um reine Frontend-Frameworks handelt. Einige dieser Projekte beinhalten auch ein Fullstack-Framework – etwa Next oder SvelteKit, was Backend-Funktionalitäten wie Server-seitiges Rendering ermöglicht. Das ist für einige Teams und Projekte unter Umständen ein weiterer bedeutender Auswahlfaktor in Sachen JavaScript-Framework. Im Folgenden ein detaillierter Blick auf die führenden reaktiven Frameworks. Ein Klick auf die Verlinkung im Titel führt Sie direkt zum jeweiligen GitHub Repository beziehungsweise der Projekt-Webseite.

React

Das Flaggschiff der reaktiven Frameworks ist im Jahr 2013 bei Facebook respektive Meta entstanden und wird bis heute vom Social-Media-Konzern verwaltet. Wie auch die Download-Zahlen von React zeigen, ist das Framework mit großem Abstand das populärste der hier vorgestellten – und quasi die Standardwahl unter den Frontend-Rahmenwerken. Trotz seines Alters wurde React kontinuierlich von Meta auf dem aktuellen Stand gehalten. Dabei könnte auch eine Rolle spielen, dass Facebook immer noch auf dem Framework aufbaut.

Das größte Argument gegen React: sein gewaltiger Umfang. Das kann den Einsatz beschwerlich gestalten, insbesondere wenn Sie an einem Projekt arbeiten, für das die meisten React-Features erst gar nicht nötig sind. Einige der nachfolgenden JavaScript-Frameworks sind nicht nur leichtgewichtiger, sondern bieten auch andere Ansätze.

Vue

Auch bei Vue handelt es sich um ein ausgereiftes Framework, das in Sachen Support gut aufgestellt ist. Im Vergleich zu React ist Vue deutlich leichtgewichtiger und schneidet auch bei Performance-Tests besser ab.

Vue steht in erster Linie im Ruf, eine moderate Lernkurve aufzuwerfen. Darüber hinaus kann das Framework mit einer ausgezeichneten Dokumentation und einer offenherzigen Community punkten. Einige Entwickler bevorzugen Vue auch wegen seines ausgeprägten Fokus auf die Developer Experience. Wenn Sie und Ihr Team gerne mit Vue arbeiten, kann das Framework langfristig dazu beitragen, die Benutzerfreundlichkeit und Mitarbeiterzufriedenheit zu erhöhen.

Von den “Big Three” unter den JavaScript-Frontend-Frameworks (React, Angular und Vue) ist Vue das basisorientierteste, was seinen Reiz haben kann.

Angular

Von allen hier gelisteten Frameworks bietet Angular die wohl ausgeprägteste All-in-One-Entwicklungserfahrung. Das Framework ist als durchgängige Lösung konzipiert, die verspricht, alles nötige in einem konsistenten Paket zu liefern. In der Vergangenheit galt Angular vor allem als komplex – sowohl in der Theorie als auch in der Praxis. Zudem war ein Hauch von Overengineering bei Angular zu verspüren – eine Entwicklung die in erster Linie dem Design geschuldet war.

Das hat sich inzwischen allerdings grundlegend geändert: Die Entwickler hinter dem Projekt haben das Framework (mit Version 17) in diversen Aspekten simplifiziert und die Entwicklererfahrung optimiert – zudem steht nun auch eine effektive Rendering-Engine für Server-seitige Tasks zur Verfügung. Darüber hinaus wurden auch die Dokumentation und die offizielle Webseite modernisiert.

Ein wesentlicher Unterschied zu React und Vue: Angular ist eher “rechthaberisch” – für die meisten Dinge gibt es klar definierte Vorgaben. Das kann es erschweren, mit Angular Applikationen anzupassen oder unkonventionelle Wege zu gehen. Ob das von Vor- oder von Nachteil ist, hängt im Wesentlichen von Ihrem persönlichen Programmierstil ab.

Preact

Die Nomenklatur deutet es bereits an: Bei Preact handelt es sich um ein von React inspiriertes Framework – quasi eine abgespeckte Version desselbigen mit ähnlichen aber kleineren APIs. Einer der wesentlichen Unterschiede besteht dabei darin, dass Preact kein eigenes Eventing-System implementiert. Stattdessen nutzt es die in den Browser integrierten Event Listener.

Im Vergleich mit React entwickeln Sie mit Preact schneller und schlanker – dafür müssen Sie auf einige Funktionalitäten des “Originals” verzichten. Sie können Preact allerdings mit einem zusätzlichen Layer ausstatten und so nahezu vollständige React-Kompatibilität erreichen. Diverse Komponenten aus dem React-Ökosystem funktionieren dann auch mit Preact.

Wenn Sie auf kleinere APIs Wert legen, sich dabei aber weitgehend im React-Ökosystem bewegen möchten, ist dieses reaktive Framework möglicherweise eine gute Wahl.

Lit

Das Alleinstellungsmerkmal von Lit: Es nutzt den Web-Components-Standard als Grundlage. Das hat zur Folge, dass die API und das Bundle selbst sehr klein sind. Der Fokus liegt darauf, die integrierten Web Components zu unterstützen. Darüber hinaus fußt Lit auf einer minimalistischen Entwicklungsphilosophie, die Ihnen maximale Flexibilität ermöglicht: Es gibt nur wenige festgeschriebene Wege, um Dinge mit Lit zu erledigen.

Das Framework weist – gemessen an seiner Größe und Popularität – ein sehr umfangreiches Ökosystem auf.

Svelte

Dieses reaktive Framework zeichnet sich in erster Linie dadurch aus, dass es einen Compiler zum Einsatz bringt. Der transformiert die Svelte-Syntax in ein kleines und performantes JavaScript-Bundle. Das ermöglicht dem Framework, einige Optimierungen bereits im Vorfeld vorzunehmen – und mit interessanten Syntax-Elementen zu experimentieren.

Mit Blick auf die “Big Three” ist Svelte am ehesten mit Vue vergleichbar, weil es sich gut für unabhängige Experimente eignet. Die Dokumentation von Vue ist gut ausgestaltet und das Framework erfreut sich in der Open-Source-Community wachsender Beliebtheit.

AlpineJS

Von allen hier vorgestellten Frameworks ist AlpineJS das utilitaristischste. Es bietet eine kompakte Reactive-Bibliothek – das war’s. Trotz seines überschaubaren Footprints steckt in diesem reaktiven Framework jedoch eine ganze Menge Power.

Wie HTMX (dazu später) will auch AlpineJS Komplexität beseitigen, dabei jedoch die Grundlagen moderner Frontend-Funktionalität gewährleisten. Um diese Funktionalität “auf die Straße zu bringen”, nutzt das JavaScript-Framework spezielle HTML-Eigenschaften.

SolidJS

Im Vergleich zu den anderen hier gelisteten JavaScript-Frontend-Frameworks ist Solid ein Vertreter der jüngeren Generation. Nichtsdestotrotz konnte SolidJS bereits (im positiven Sinn) für Furore sorgen und erfreut sich einer wachsenden Nutzerbasis.

Das Framework fußt auf Signals (Reactive Primitives), die ihm eine flexible Grundlage verschaffen. Um die Funktionalität zu erweitern, können sowohl das Framework selbst als auch der Anwender-Code auf dieselben Features zugreifen. In Sachen Performance-Tests schneidet SolidJS gut ab.

HTMX

Einen völlig anderen Ansatz, um Web-Frontends zu entwickeln, wirft HTMX auf: Es versucht, so viel Komplexität wie möglich zu eliminieren, REST wie beabsichtigt einzusetzen und “reines” HTML (mit einigen grundlegenden Verbesserungen) zu nutzen, um modernen Anforderungen wie AJAX- und DOM-Interaktionen gerecht zu werden.

HTMX kann eine lohnende Option sein, wenn Sie auf Dinge wie Server-seitiges Rendering verzichten können. Einer der größten Pluspunkte des Frameworks: Es ist relativ einfach zu erlernen. Wir können nur empfehlen, sich zumindest mit diesem Projekt zu beschäftigen – und sei es nur wegen der zugrundeliegenden Idee.

Qwik

Unter der Haube ist Qwik eine exotische Implementierung, die die Performance in den Mittelpunkt rückt. Das Framework zerlegt Applikationen in unterscheidbare Elemente und orientiert sich dabei an “Grenzen” wie Eventing oder Komponenten – entlang derer aggressives Lazy Loading zum Einsatz kommt. Das Ergebnis: schnelleres Rendering.

Reactive Frameworks im (Feature-)Vergleich

Nachdem Sie die zehn wichtigsten Reactive-Framework-Optionen kennengelernt haben, geht es nun darum, die wichtigsten Funktionen und Merkmale miteinander zu vergleichen. Zunächst haben wir die reaktiven Rahmenwerke noch einmal in einer Übersicht zusammengetragen, die auf einen Blick Auskunft über die jeweiligen Lernkurven und Funktions-Highlights gibt.

Wenn Sie nun Wert auf ganz spezielle Funktionen legen, bringt Ihnen diese Tabelle natürlich wenig. Deswegen haben wir auch noch einen umfangreichen Feature-Vergleich der gelisteten JavaScript-Frontend-Frameworks für Sie erstellt. Diesen können Sie auch direkt über GitHub als PDF-Datei herunterladen (inklusive klickbarer Links).

Foto: Matthew Tyson | IDG

Playgrounds

Um sich einen schnellen ersten Eindruck von einem Framework zu verschaffen, empfiehlt sich, es in einem Online-REPL respektive Playground zu testen. Dazu ist kein Tooling-Setup erforderlich – ein Webbrowser reicht, um mit der Syntax experimentieren zu können. Sämtliche hier vorgestellten Frameworks können das bieten. React hostet zwar keine eigenen REPLs, diese Lücke wird jedoch von Drittanbietern geschlossen.

Dieser Artikel ist im Original bei unserer Schwesterpublikation Infoworld.com erschienen.

Microsoft is previewing a new automatic device isolation capability in Defender for Endpoint’s auto attack disruption tool to help security pros contain cyber attacks in progress on their IT networks.

The company announced the capability earlier this month in a column about new features in Defender. There’s no word on when automatic device isolation will be in full production.

However, a new SANS Institute research paper warns that, in certain conditions, an attacker could leverage the new function to disable all user accounts.

The lesson, said Johannes Ullrich, the institute’s dean of research, is that autonomous AI action tools have to be tuned and tested like any other automation capability.

“Automatic isolation and attack disruption are not new concepts,” Ullrich said in an email, “but ideas like these have been used in the past in open source and commercial tools. This feature is most important in organizations with under-resourced IT security teams, as it automates attack response. However, these features must be carefully tuned. If they are left unconfigured, attackers can use them to delay response by disrupting accounts used by administrators.”

Nonetheless, in today’s environment, tools like these are important. Robert Enderle, IT consultant and head of the Enderle group, noted that modern automated malware and ransomware attacks move at machine speed, which means human response times are effectively obsolete.

By the time an analyst even sees a red flag, he said, the attacker has already established persistence or started encrypting files. Microsoft’s automatic device isolation acts as “a rapid, logical air gap. It instantly severs the device’s network connections, cutting off the attacker’s command and control (C2) and halting data exfiltration dead in its tracks. You have to bring an automated defense to an automated fight.”

He said a secondary benefit, often the more critical one for enterprise survival, is containing the blast radius. Attackers invariably use a compromised PC as a beachhead to move laterally across the corporate network, hunting for higher-value targets like domain controllers, he pointed out.

“By instantly quarantining that initial endpoint, you trap the threat where it stands. You ensure a single compromised laptop doesn’t metastasize into an enterprise-wide catastrophe,” he said.

There’s also is a massive forensic advantage, Enderle added. “In the old days, the instinct was often to literally pull the power plug, which destroys critical volatile memory, or physically yank the network cable, which completely blinds your remote security team. Logically isolating the device while maintaining a secure lifeline to security services preserves the crime scene. It prevents the attacker from deploying wiper malware or destroying logs, and it gives the Security Operations Center (SOC) the breathing room they need to safely investigate and remediate the machine without the panic of an actively spreading infection.”

How automatic attack disruption works

Automatic attack disruption is offered to organizations that subscribe to Microsoft Defender XDR, a unified cloud-based security suite that detects and investigates cyberattacks against PC, server, and IoT endpoints. It also manages hybrid identities and protects email and collaboration tools. As such, it correlates data to identify and respond to attacks.

The soon-to-be-delivered auto-isolation capability blocks most network traffic while keeping the device connected to security services. The action is time-limited and scoped to the incident, Microsoft said; security operators can release isolation at any time.

The broad automatic attack disruption capability uses AI to limit attackers’ lateral movement. “Attack disruption uses the full breadth of our extended detection and response (XDR) signals, taking the entire attack into account to act at the incident level,” Microsoft said in a detailed column describing the tool. “This capability is unlike known protection methods such as prevention and blocking based on a single indicator of compromise.”

To use automatic attack disruption, IT has to, at the least, enable Microsoft Defender for Endpoint Plan 2. It becomes more effective if Defender for Identity, Defender for Office 365 and Defender for Cloud apps are also deployed. Admins also have to configure appropriate permissions and monitoring.

Possible operational disruption

The SANS Institute’s academic paper by student Marcio Enriquez noted that AI systems that perform autonomous decisions like containment do improve response times and scalability. But they also rely on threshold-based logic derived from telemetry. “Even when operating on enterprise-wide data, they do not consistently account for system-level impact in their enforcement decisions,” the paper said, and thus can cause unintended disruptions when activated at scale. “This creates a gap between the need for rapid defensive actions and the organization’s ability to maintain operational continuity.”

It examined that gap by evaluating how threshold-driven autonomous containment actions can result in what it refers to as “large-scale operational disruption.”

Enriquez saw an example of this during a real security incident in the spring of 2025. A user in an organization was fooled by a phishing message and entered their credentials on a malicious website. Defender detected this, and within minutes initiated automated containment measures, including disabling the affected account, forcing a password reset and restricting logins across multiple managed devices.

However, because security analysts didn’t realize this was automated enforcement, they initially thought there had been lateral movement or widespread compromise. That triggered an emergency escalation involving security leadership, until further investigation realized that the propagation of containment controls was due to Defender.

“The event demonstrates the effectiveness of autonomous containment in rapidly interrupting active threats,” wrote Enriquez. “At the same time, it illustrates how automated response actions can generate enterprise-wide operational effects that are not immediately transparent to human operators.”

Could be weaponized

To test the ability of a threat actor to take advantage of a weakness in Defender XDR’s automatic attack disruption capability, Enriquez created a hybrid enterprise environment with 18 “users” and executed adversarial activity simulating hands-on-keyboard behavior across multiple identities to trigger high-confidence detection thresholds in Defender, through an attack tactic he calls Autonomous Defense Induced Disruption (ADID). In essence, it tricks the automatic disruption capability of Defender into giving a high-confidence score that the network is under attack.

“The results showed that when detection confidence thresholds were met, automated actions disabled all [18] Active Directory identities, including the local domain administrator, rendering the domain inaccessible,” Enriquez wrote.

“The research highlights the need for governance controls, privilege-aware safeguards, and system-level constraints to prevent autonomous containment from causing operational disruption,” he concluded.

Microsoft guidance: Keep auto attack disruption enabled

A Microsoft spokesperson said that the company has no comment on the research paper.

However, they said that Microsoft’s guidance is to keep automatic attack disruption enabled by default. “Opting out materially increases risk, particularly for multi-domain, multi-stage attacks such as HumOR [human intelligence operations, like social engineering], BEC [business email compromise] and AiTM [adversary in the middle], where even minutes of additional dwell time can translate into significant business impact.”

“At the same time,” Microsoft noted, “we recognize that security teams require control over autonomous actions. That’s why the capability is designed with granular controls. Security administrators can tune automation levels by device group and selectively exclude users, devices, or IP ranges based on operational needs. The recommended approach is targeted, intentional configuration, not a blanket opt-out. Customers retain full visibility into actions taken and have the ability to reverse automated responses at any time.”

Microsoft is previewing a new automatic device isolation capability in Defender for Endpoint’s auto attack disruption tool to help security pros contain cyber attacks in progress on their IT networks.

The company announced the capability earlier this month in a column about new features in Defender. There’s no word on when automatic device isolation will be in full production.

However, a new SANS Institute research paper warns that, in certain conditions, an attacker could leverage the new function to disable all user accounts.

The lesson, said Johannes Ullrich, the institute’s dean of research, is that autonomous AI action tools have to be tuned and tested like any other automation capability.

“Automatic isolation and attack disruption are not new concepts,” Ullrich said in an email, “but ideas like these have been used in the past in open source and commercial tools. This feature is most important in organizations with under-resourced IT security teams, as it automates attack response. However, these features must be carefully tuned. If they are left unconfigured, attackers can use them to delay response by disrupting accounts used by administrators.”

Nonetheless, in today’s environment, tools like these are important. Robert Enderle, IT consultant and head of the Enderle group, noted that modern automated malware and ransomware attacks move at machine speed, which means human response times are effectively obsolete.

By the time an analyst even sees a red flag, he said, the attacker has already established persistence or started encrypting files. Microsoft’s automatic device isolation acts as “a rapid, logical air gap. It instantly severs the device’s network connections, cutting off the attacker’s command and control (C2) and halting data exfiltration dead in its tracks. You have to bring an automated defense to an automated fight.”

He said a secondary benefit, often the more critical one for enterprise survival, is containing the blast radius. Attackers invariably use a compromised PC as a beachhead to move laterally across the corporate network, hunting for higher-value targets like domain controllers, he pointed out.

“By instantly quarantining that initial endpoint, you trap the threat where it stands. You ensure a single compromised laptop doesn’t metastasize into an enterprise-wide catastrophe,” he said.

There’s also is a massive forensic advantage, Enderle added. “In the old days, the instinct was often to literally pull the power plug, which destroys critical volatile memory, or physically yank the network cable, which completely blinds your remote security team. Logically isolating the device while maintaining a secure lifeline to security services preserves the crime scene. It prevents the attacker from deploying wiper malware or destroying logs, and it gives the Security Operations Center (SOC) the breathing room they need to safely investigate and remediate the machine without the panic of an actively spreading infection.”

How automatic attack disruption works

Automatic attack disruption is offered to organizations that subscribe to Microsoft Defender XDR, a unified cloud-based security suite that detects and investigates cyberattacks against PC, server, and IoT endpoints. It also manages hybrid identities and protects email and collaboration tools. As such, it correlates data to identify and respond to attacks.

The soon-to-be-delivered auto-isolation capability blocks most network traffic while keeping the device connected to security services. The action is time-limited and scoped to the incident, Microsoft said; security operators can release isolation at any time.

The broad automatic attack disruption capability uses AI to limit attackers’ lateral movement. “Attack disruption uses the full breadth of our extended detection and response (XDR) signals, taking the entire attack into account to act at the incident level,” Microsoft said in a detailed column describing the tool. “This capability is unlike known protection methods such as prevention and blocking based on a single indicator of compromise.”

To use automatic attack disruption, IT has to, at the least, enable Microsoft Defender for Endpoint Plan 2. It becomes more effective if Defender for Identity, Defender for Office 365 and Defender for Cloud apps are also deployed. Admins also have to configure appropriate permissions and monitoring.

Possible operational disruption

The SANS Institute’s academic paper by student Marcio Enriquez noted that AI systems that perform autonomous decisions like containment do improve response times and scalability. But they also rely on threshold-based logic derived from telemetry. “Even when operating on enterprise-wide data, they do not consistently account for system-level impact in their enforcement decisions,” the paper said, and thus can cause unintended disruptions when activated at scale. “This creates a gap between the need for rapid defensive actions and the organization’s ability to maintain operational continuity.”

It examined that gap by evaluating how threshold-driven autonomous containment actions can result in what it refers to as “large-scale operational disruption.”

Enriquez saw an example of this during a real security incident in the spring of 2025. A user in an organization was fooled by a phishing message and entered their credentials on a malicious website. Defender detected this, and within minutes initiated automated containment measures, including disabling the affected account, forcing a password reset and restricting logins across multiple managed devices.

However, because security analysts didn’t realize this was automated enforcement, they initially thought there had been lateral movement or widespread compromise. That triggered an emergency escalation involving security leadership, until further investigation realized that the propagation of containment controls was due to Defender.

“The event demonstrates the effectiveness of autonomous containment in rapidly interrupting active threats,” wrote Enriquez. “At the same time, it illustrates how automated response actions can generate enterprise-wide operational effects that are not immediately transparent to human operators.”

Could be weaponized

To test the ability of a threat actor to take advantage of a weakness in Defender XDR’s automatic attack disruption capability, Enriquez created a hybrid enterprise environment with 18 “users” and executed adversarial activity simulating hands-on-keyboard behavior across multiple identities to trigger high-confidence detection thresholds in Defender, through an attack tactic he calls Autonomous Defense Induced Disruption (ADID). In essence, it tricks the automatic disruption capability of Defender into giving a high-confidence score that the network is under attack.

“The results showed that when detection confidence thresholds were met, automated actions disabled all [18] Active Directory identities, including the local domain administrator, rendering the domain inaccessible,” Enriquez wrote.

“The research highlights the need for governance controls, privilege-aware safeguards, and system-level constraints to prevent autonomous containment from causing operational disruption,” he concluded.

Microsoft guidance: Keep auto attack disruption enabled

A Microsoft spokesperson said that the company has no comment on the research paper.

However, they said that Microsoft’s guidance is to keep automatic attack disruption enabled by default. “Opting out materially increases risk, particularly for multi-domain, multi-stage attacks such as HumOR [human intelligence operations, like social engineering], BEC [business email compromise] and AiTM [adversary in the middle], where even minutes of additional dwell time can translate into significant business impact.”

“At the same time,” Microsoft noted, “we recognize that security teams require control over autonomous actions. That’s why the capability is designed with granular controls. Security administrators can tune automation levels by device group and selectively exclude users, devices, or IP ranges based on operational needs. The recommended approach is targeted, intentional configuration, not a blanket opt-out. Customers retain full visibility into actions taken and have the ability to reverse automated responses at any time.”

This article originally appeared on CSOonline.

Microsoft is preparing to make a significant change to the Secure Boot system in Windows that will impact operations for both clients and servers.

In a nutshell: The Secure Boot certificates that Microsoft issued 15 years ago are being replaced by newer ones, with the older certificates set to expire beginning in June. To continue to receive the most up-to-date security protections for the Windows boot-up process, individual users and IT administrators alike need to make sure their Windows devices have the new Secure Boot certificates installed.

Have questions? Of course you do. Here are answers to eight key questions about the Secure Boot certificate updates.

What is Secure Boot?

Secure Boot is a security feature that verifies that all firmware-based software is signed by a trusted certificate when Windows starts up. If something doesn’t match, it gets blocked. This all happens immediately on boot, before Windows or anything else loads.

Secure Boot is a part of the UEFI firmware standard, which replaced the older BIOS model for modern PCs. It was added to UEFI in 2011 so that only trusted, signed code could run during startup.

Microsoft issued its original Secure Boot certificates in 2011 and introduced Secure Boot as an optional feature in Windows 8. It remained optional in Windows 10, since UEFI had not had much time to penetrate the market when Windows 10 was released in 2015. But Secure Boot became mandatory in Windows 11. Windows 11 came out in 2021, giving UEFI-powered systems plenty of time to saturate the marketplace.

What’s happening with Windows Secure Boot certificates?

To keep up with emerging threats, Microsoft in 2023 issued new Secure Boot certificates to replace the 2011 versions. Those began rolling out on Windows devices in 2024, and according to Microsoft, nearly all devices shipped in 2025 and later already include the 2023 certificates.

However, most older devices with Secure Boot enabled (those manufactured from 2012 to 2024) have been relying on the 2011 certificates — and those certificates begin expiring in June.

There are three Windows Secure Boot certificates expiring this year:

• Microsoft Corp. KEK CA 2011: authorizes changes to the Secure Boot database
• Microsoft UEFI CA 2011: signs third-party drivers to allow hardware components to load its firmware during boot
• Microsoft Windows Production PCA 2011: signs the Windows bootloader itself, the core piece of software that loads Windows from your hard drive into memory

The first two certificates will expire on June 27; the third will expire on October 19.

For devices that didn’t ship with the 2023 certificates pre-installed, Microsoft is now rolling out those new certificates via Windows Update.

What happens to devices that don’t have the updated certificates after the old ones expire?

Lacking the new certificates, your PC keeps working and you’ll still receive regular Windows updates, but the computer loses the ability to receive security updates for the boot process. New protections for Windows Boot Manager won’t install. Updates to the Secure Boot database won’t apply. Revocation lists that block known malicious software won’t update. Your system is essentially defenseless against emerging boot-level threats.

Over time, not having the current certificates may also lead to compatibility issues with newer operating systems, firmware, hardware, or Secure Boot–dependent software.

How are Secure Boot certificates updated?

For most devices that have Windows updates managed by Microsoft (this includes consumer devices and some business and education devices), the new certificates will be installed automatically via Windows Update as part of the regular monthly update process, with no additional action required. Microsoft has been gradually rolling out the new certificates since June 2025, so your device may have them already.

Some devices may require a separate firmware update from the device manufacturer before the system can apply the new Secure Boot certificates. That’s because the new certificates need to be written into your motherboard’s UEFI databases that Secure Boot uses during the boot process. HP, Dell, Lenovo, and other major PC manufacturers have been releasing BIOS updates specifically to ensure their systems can properly accept the new certificates.

Microsoft recommends that customers check their Original Equipment Manufacturer (OEM) support pages for any applicable firmware updates and install them where needed. Microsoft maintains a list of OEM support pages for Secure Boot update readiness.

Devices managed by organizations may follow different update processes and typically require IT administrator action. Microsoft has a comprehensive “Secure Boot Certificate updates: Guidance for IT professionals and organizations” mini-site that covers verifying Secure Boot status, preparation, firmware considerations, deployment options (including automated deployment), monitoring and remediation, troubleshooting, and more.

Which devices will get the updated certificates automatically?

Only devices running Windows versions currently supported by Microsoft will get the updated Secure Boot certificates:

• Windows 11 24H2, 25H2, and 26H1 (all editions); Windows 11 23H2 enterprise/education editions; and Windows 11 Long-Term Servicing Channel (LTSC) 2024 editions
• Windows 10 22H2 devices enrolled in the Extended Security Updates (ESU) program; and Windows 10 LTSB/LTSC 2016, 2019, and 2021 editions until their LTSC end-of-support dates
• Windows Server 2019, 2022, and 2025: covered with separate guidance in the Secure Boot Playbook for Windows Server

Out-of-support Windows versions will not receive the new certificates.

As noted above, Microsoft-managed Windows client devices will have the new Secure Boot certificates delivered automatically through Windows Update. The new certificates will not be delivered automatically in IT-managed environments.

How do I know if the new Secure Boot certificates have been installed?

Individuals and business/education users with Microsoft-managed updates can check Windows Security > Device security > Secure Boot. Here you’ll find badges and status messages indicating whether your device is fully updated and if you need to take action. See Microsoft’s “Secure Boot certificate update status in the Windows Security app” support page for details.

What else should I know about the Secure Boot certificate updates?

Because Secure Boot is rooted in platform firmware, some environments may require additional steps. This can include specialized hardware configurations, certain virtualized environments where the platform provider manages firmware behavior, or devices that depend on OEM support. Microsoft is working closely with hardware and platform partners to ensure broad compatibility and a smooth transition.

With the April 2026 Windows security update and upcoming monthly updates, some devices may experience one additional reboot during installation. This is the one-time restart that applies the new Boot Manager after the certificates have been written to firmware — it is expected and documented.

What resources are available for help deploying and troubleshooting the new Secure Boot certificates?

• aka.ms/getsecureboot: the canonical hub that Microsoft is keeping current with all information and guidance around Secure Boot certificate updates
• Windows devices for home users, businesses, and schools with Microsoft-managed updates: includes a troubleshooting section for problems with BitLocker recovery or a device that won’t start up after installing the new certificates
• Secure Boot Playbook for Windows client and Secure Boot Playbook for Windows Server: these guides walk IT admins through the entire planning and deployment process in self-managed environments
• Secure Boot troubleshooting guide: for IT admins
• Secure Boot status report in Windows Autopatch: service provided to Autopatch customers for fleet-scale monitoring at no additional cost

Google has introduced Agent Executor, an open source runtime aimed at helping enterprises run AI agents more reliably at scale, as attention shifts from building agent prototypes to managing the operational challenges of putting them into production.

To address those production-related challenges, the runtime, according to the company, comes with capabilities that are geared towards supporting long-running and distributed agent workflows.

Typically, long-running agent workflows are AI-driven tasks that execute over extended periods, from minutes to days, often involving multiple steps, system interactions, pauses for human input, or recovery from interruptions before reaching completion.

For such workloads, the runtime includes support for durable execution, allowing workflows to resume after outages or human approvals, along with secure sandboxing for isolating agent components, session consistency controls for distributed workflows, and connection recovery features intended to preserve execution state during network interruptions, Google wrote in a blog post.

The runtime also supports “trajectory branching,” which allows developers to test alternate execution paths from saved checkpoints without losing prior context, it added.

Furthermore, Agent Executor bridges multiple deployment models, including on prem and pre-built or custom managed agents, the company said, allowing users to mix and match between any or all of Google Antigravity, frontier agents built by Google, agents built by the user and managed by Google, and custom agents and agents using Agent2Agent (A2A) protocol, as desired.

Targeting production reliability gaps

Analysts and experts see value for both developers and enterprises in Agent Executor’s capabilities.

“Durability, orchestration, and resumability are the real blockers for any enterprise production agents,” said Advait Patel, senior reliability engineer (SRE) at Broadcom.

“What kills enterprise adoption is agents that lose their state when a pod restarts, sessions that corrupt under concurrent writes, or long running workflows that cannot recover from a network blip. Once your agent is taking actions on real systems, you cannot afford it to forget what it did halfway through,” he pointed out.

“The event log, snapshotting, single writer model, and connection recovery in Agent Executor are exactly the things SRE teams have been duct taping for the last year,” Patel noted, adding that existing frameworks such as LangChain and AutoGen are great for prototyping, but more often than not fall apart in production once agents run for hours or days.

For CIOs, said Gaurav Dewan, research director at Avasant, the runtime’s operational safeguards such as secure sandboxing, and checkpointing could prove just as significant for incident analysis and auditability.

At the same time, he cautioned that the runtime’s capabilities alone do not solve the broader governance and oversight challenges that CIOs continue to face with enterprise AI deployments.

 “Issues such as accountability, explainability of agent decisions, policy enforcement, and secure access across interconnected systems are still evolving,” he said. “As a result, while distributed runtimes can strengthen the operational backbone of agent deployments, CIO-level considerations around trust, compliance, and enterprise control are likely to require additional governance and oversight layers beyond runtime infrastructure alone.”

Using infrastructure layer to gain strategic advantage

Google, however, is not alone in trying to shape the emerging infrastructure layer for enterprise AI agents. Other hyperscalers, such as Microsoft, with AutoGen and AWS, with Bedrock AgentCore, are promoting open or interoperable frameworks to gain strategic advantage.

“There are growing indications that hyperscalers are converging toward a model that combines open or interoperable tooling at the top of the stack with monetization concentrated in underlying infrastructure layers,” Dewan said.

“Google, Microsoft, and AWS are increasingly offering SDKs, agent frameworks, and orchestration tools to drive developer adoption and ecosystem growth, while continuing to generate value through compute infrastructure, managed AI platforms, data services, and observability capabilities,” he added.

And, according to Patel, Google’s strategy around Agent Executor is reminiscent of the path that the hyperscaler followed with Kubernetes ten years ago: “Give away the runtime, [and] drive consumption on Google Cloud via services, such as the Gemini Enterprise Agent Platform and Managed Agents API.”

He added, “[hyperscalers] have figured out that proprietary agent frameworks will not get adopted at enterprise scale. The money is in cloud consumption, managed services, and model inference. The tools on top need to be open or nobody will trust them.”

Google has introduced Agent Executor, an open source runtime aimed at helping enterprises run AI agents more reliably at scale, as attention shifts from building agent prototypes to managing the operational challenges of putting them into production.

To address those production-related challenges, the runtime, according to the company, comes with capabilities that are geared towards supporting long-running and distributed agent workflows.

Typically, long-running agent workflows are AI-driven tasks that execute over extended periods, from minutes to days, often involving multiple steps, system interactions, pauses for human input, or recovery from interruptions before reaching completion.

For such workloads, the runtime includes support for durable execution, allowing workflows to resume after outages or human approvals, along with secure sandboxing for isolating agent components, session consistency controls for distributed workflows, and connection recovery features intended to preserve execution state during network interruptions, Google wrote in a blog post.

The runtime also supports “trajectory branching,” which allows developers to test alternate execution paths from saved checkpoints without losing prior context, it added.

Furthermore, Agent Executor bridges multiple deployment models, including on prem and pre-built or custom managed agents, the company said, allowing users to mix and match between any or all of Google Antigravity, frontier agents built by Google, agents built by the user and managed by Google, and custom agents and agents using Agent2Agent (A2A) protocol, as desired.

Targeting production reliability gaps

Analysts and experts see value for both developers and enterprises in Agent Executor’s capabilities.

“Durability, orchestration, and resumability are the real blockers for any enterprise production agents,” said Advait Patel, senior reliability engineer (SRE) at Broadcom.

“What kills enterprise adoption is agents that lose their state when a pod restarts, sessions that corrupt under concurrent writes, or long running workflows that cannot recover from a network blip. Once your agent is taking actions on real systems, you cannot afford it to forget what it did halfway through,” he pointed out.

“The event log, snapshotting, single writer model, and connection recovery in Agent Executor are exactly the things SRE teams have been duct taping for the last year,” Patel noted, adding that existing frameworks such as LangChain and AutoGen are great for prototyping, but more often than not fall apart in production once agents run for hours or days.

For CIOs, said Gaurav Dewan, research director at Avasant, the runtime’s operational safeguards such as secure sandboxing, and checkpointing could prove just as significant for incident analysis and auditability.

At the same time, he cautioned that the runtime’s capabilities alone do not solve the broader governance and oversight challenges that CIOs continue to face with enterprise AI deployments.

 “Issues such as accountability, explainability of agent decisions, policy enforcement, and secure access across interconnected systems are still evolving,” he said. “As a result, while distributed runtimes can strengthen the operational backbone of agent deployments, CIO-level considerations around trust, compliance, and enterprise control are likely to require additional governance and oversight layers beyond runtime infrastructure alone.”

Using infrastructure layer to gain strategic advantage

Google, however, is not alone in trying to shape the emerging infrastructure layer for enterprise AI agents. Other hyperscalers, such as Microsoft, with AutoGen and AWS, with Bedrock AgentCore, are promoting open or interoperable frameworks to gain strategic advantage.

“There are growing indications that hyperscalers are converging toward a model that combines open or interoperable tooling at the top of the stack with monetization concentrated in underlying infrastructure layers,” Dewan said.

“Google, Microsoft, and AWS are increasingly offering SDKs, agent frameworks, and orchestration tools to drive developer adoption and ecosystem growth, while continuing to generate value through compute infrastructure, managed AI platforms, data services, and observability capabilities,” he added.

And, according to Patel, Google’s strategy around Agent Executor is reminiscent of the path that the hyperscaler followed with Kubernetes ten years ago: “Give away the runtime, [and] drive consumption on Google Cloud via services, such as the Gemini Enterprise Agent Platform and Managed Agents API.”

He added, “[hyperscalers] have figured out that proprietary agent frameworks will not get adopted at enterprise scale. The money is in cloud consumption, managed services, and model inference. The tools on top need to be open or nobody will trust them.”

This article originally appeared on InfoWorld.

Google has introduced Agent Executor, an open source runtime aimed at helping enterprises run AI agents more reliably at scale, as attention shifts from building agent prototypes to managing the operational challenges of putting them into production.

To address those production-related challenges, the runtime, according to the company, comes with capabilities that are geared towards supporting long-running and distributed agent workflows.

Typically, long-running agent workflows are AI-driven tasks that execute over extended periods, from minutes to days, often involving multiple steps, system interactions, pauses for human input, or recovery from interruptions before reaching completion.

For such workloads, the runtime includes support for durable execution, allowing workflows to resume after outages or human approvals, along with secure sandboxing for isolating agent components, session consistency controls for distributed workflows, and connection recovery features intended to preserve execution state during network interruptions, Google wrote in a blog post.

The runtime also supports “trajectory branching,” which allows developers to test alternate execution paths from saved checkpoints without losing prior context, it added.

Furthermore, Agent Executor bridges multiple deployment models, including on prem and pre-built or custom managed agents, the company said, allowing users to mix and match between any or all of Google Antigravity, frontier agents built by Google, agents built by the user and managed by Google, and custom agents and agents using Agent2Agent (A2A) protocol, as desired.

Targeting production reliability gaps

Analysts and experts see value for both developers and enterprises in Agent Executor’s capabilities.

“Durability, orchestration, and resumability are the real blockers for any enterprise production agents,” said Advait Patel, senior reliability engineer (SRE) at Broadcom.

“What kills enterprise adoption is agents that lose their state when a pod restarts, sessions that corrupt under concurrent writes, or long running workflows that cannot recover from a network blip. Once your agent is taking actions on real systems, you cannot afford it to forget what it did halfway through,” he pointed out.

“The event log, snapshotting, single writer model, and connection recovery in Agent Executor are exactly the things SRE teams have been duct taping for the last year,” Patel noted, adding that existing frameworks such as LangChain and AutoGen are great for prototyping, but more often than not fall apart in production once agents run for hours or days.

For CIOs, said Gaurav Dewan, research director at Avasant, the runtime’s operational safeguards such as secure sandboxing, and checkpointing could prove just as significant for incident analysis and auditability.

At the same time, he cautioned that the runtime’s capabilities alone do not solve the broader governance and oversight challenges that CIOs continue to face with enterprise AI deployments.

 “Issues such as accountability, explainability of agent decisions, policy enforcement, and secure access across interconnected systems are still evolving,” he said. “As a result, while distributed runtimes can strengthen the operational backbone of agent deployments, CIO-level considerations around trust, compliance, and enterprise control are likely to require additional governance and oversight layers beyond runtime infrastructure alone.”

Using infrastructure layer to gain strategic advantage

Google, however, is not alone in trying to shape the emerging infrastructure layer for enterprise AI agents. Other hyperscalers, such as Microsoft, with AutoGen and AWS, with Bedrock AgentCore, are promoting open or interoperable frameworks to gain strategic advantage.

“There are growing indications that hyperscalers are converging toward a model that combines open or interoperable tooling at the top of the stack with monetization concentrated in underlying infrastructure layers,” Dewan said.

“Google, Microsoft, and AWS are increasingly offering SDKs, agent frameworks, and orchestration tools to drive developer adoption and ecosystem growth, while continuing to generate value through compute infrastructure, managed AI platforms, data services, and observability capabilities,” he added.

And, according to Patel, Google’s strategy around Agent Executor is reminiscent of the path that the hyperscaler followed with Kubernetes ten years ago: “Give away the runtime, [and] drive consumption on Google Cloud via services, such as the Gemini Enterprise Agent Platform and Managed Agents API.”

He added, “[hyperscalers] have figured out that proprietary agent frameworks will not get adopted at enterprise scale. The money is in cloud consumption, managed services, and model inference. The tools on top need to be open or nobody will trust them.”

This article originally appeared on InfoWorld.

Many CIOs are prioritising digital sovereignty, with concerns around extraterritorial data requests, regulatory compliance, and data security among the key drivers of this shift, according to IDC research.

But does this require moving completely away from the big hyperscalers? For many experts, this approach could lead to suboptimal outcomes.

Red Hat’s Senior Principal Chief Architect for EMEA, Chris Jenkins, warned in a CIO webcast that abandoning major public cloud providers entirely during a digital sovereignty shift could lead to a long, complex migration process while sacrificing their agility and speed.

Hyperscaler efficiency versus on-premises security is a false binary, he says, when a hybrid cloud strategy is best for most organisations. This way, they can move certain workloads to a particular jurisdiction for regulatory compliance reasons, while also benefiting from using major cloud providers for others.

“You can also use the hyperscalers, the public cloud, the private cloud and the sovereign cloud together. So, it creates this harmonious environment,” he says.

A hybrid cloud approach can be made sovereign by design, rather than completely starting over with new infrastructure, according to Jenkins. “Build in the sovereign principles and requirements for your organisation into your trusted software supply chain,” he advises.

For those IT leaders forming a digital sovereignty strategy, what first steps can they take? Jenkins says the best place to start is “understanding from operations, technical assurance, executive leadership, from an open source point of view, where you currently are.”

They can use a tool like Red Hat’s digital sovereignty assessment tool to assess this, and then plan how to close the gap, whether the goal is complete sovereignty or something more pragmatic.

Watch the full webcast to learn more about how a hybrid cloud approach can achieve digital sovereignty.

To watch the full Webcast Series ‘The rise of digital sovereignty’, click below

• Episode 1: Why digital sovereignty is a fast-rising priority in an uncertain world.
• Episode 3: The practical steps IT leaders must take to pivot toward a sovereign future

Another RSAC in San Francisco wrapped recently, and unsurprisingly, one topic dominated: AI agents.

In hallway conversations, panels and private meetings, AI agents, and the risks they introduce, were front and center. That shouldn’t surprise anyone. Over the past year, agents have become embedded across enterprise workflows, making decisions and acting autonomously across departments, from engineering to sales. The real question now is: how securely are they being deployed?

At RSA, a co-panelist compared poorly governed agents to teenagers testing boundaries. It’s an apt analogy. Unless guardrails are applied and tightly enforced, agents will find ways around them.

I’ve written previously about the risks of emerging AI agents, instances of agents behaving unpredictably, exposing sensitive data or operating outside intended constraints. At RSAC, those theoretical concerns became tangible stories of incidents both big and small.

RSAC recap

The real-world examples were shared in large numbers: agents making unauthorized purchases, generating unexpected cloud costs in AWS and Azure, and operating without user awareness.

But one story stood out. Yaki Faitelson, CEO of Varonis, a leading data governance company, described an incident of an agent attempting to access restricted files for which it did not have credentials. Unable to gain entry, it requested credentials from other agents. Eventually, another agent complied, effectively bypassing access controls.

That should concern every CISO, particularly in highly regulated industries like financial services. Without iron-clad enforced guardrails, agents interacting with one another can erode the security policies organizations depend on.

Key priorities for CISOs

Every executive team today is balancing the same challenge: how to integrate AI into core operations while maintaining control over data and security.

Coming out of RSAC, the priority is clear: get control of your agents. That starts with three areas:

1. Lock down the data. Agents should not have unrestricted access to core data systems. Organizations need to double down on data protection, leakage prevention and governance frameworks designed for an AI-driven environment.
2. Monitor agent behavior. You need full observability, what agents are doing, what they’re requesting and how they’re interacting with each other. Without this, you’re operating blind.
3. Enforce guardrails. Strong, enforceable controls are essential. This is still early-stage technology, and no single vendor has a complete solution. But lack of perfection isn’t an excuse for lack of control.

And just as the industry was digesting these challenges, another development raised the stakes.

Claude Mythos preview

Shortly after RSAC, Anthropic’s Claude Mythos Preview surfaced, alongside its broader Project Glasswing initiative.

According to Anthropic, Claude Mythos Preview can identify and exploit zero-day vulnerabilities across major operating systems and browsers. That’s a step change. We’re talking about AI that can uncover, and potentially weaponize, previously unknown flaws at scale.  It has demonstrated a greater than 83% first-attempt exploit rate, far outpacing prior vulnerability scanning tools.  And the model has found issues that no human has previously detected – including a 27-year-old vulnerability in OpenBSD, the secure operating system used in firewalls, routers and other core infrastructure products. 

To mitigate risk, Anthropic has limited access to a small group of partners, including major technology and financial institutions such as AWS, Apple, Google, JP Morgan and Microsoft. For everyone else, the reality is clear: you’ll need to rely on existing security tools and practices to identify and address vulnerabilities.

That creates immediate pressure for CISOs. If you can’t eliminate vulnerabilities quickly, you need to strengthen your defensive posture across firewalls, endpoints, identity systems and cloud infrastructure.

Looking ahead

Anthropic is moving fast, but they’re not alone. It’s reasonable to assume that other major players are pursuing similar capabilities, with industry estimates that these efforts are only 6-12 months behind Mythos.

That raises an uncomfortable question: what happens when these tools extend beyond controlled environments?

An increase in exploit volume and severity is inevitable. This isn’t a reason for panic, but it is a reason for urgency. The next 2–3 years will test security teams in ways we haven’t seen before.

To Anthropic’s credit, limiting access to Mythos, at least initially, gives the industry time to prepare. It allows security vendors, startups and enterprises to strengthen defenses before these capabilities become more widely available.

That’s a net positive.

At the same time, it will accelerate innovation. We’re likely to see a new wave of startups and solutions emerge in response, focused AI-native remediation and defense, in additional to agent governance, observability and control.

AI agents are here. The question isn’t whether to adopt them, it’s whether you can manage them.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

For most of my career, the enterprise software conversation followed a predictable script. A CRM, an ITSM platform, an ERP system, these were not things you built. They were things you bought, implemented and lived with. The reasoning was sound: Building them required enormous capital, long engineering tenures and specialized domain depth that only a handful of vendors could concentrate. So, enterprises paid the toll. And if you have ever read a SaaS earnings report, you know what that toll looks like on the margin line.

That calculus is breaking down. Not collapsing overnight but breaking down in a way that every CIO I speak with is starting to quietly acknowledge.

The reason is simple. AI has fundamentally changed the economics of writing software, and with it, the central premise of the enterprise SaaS model.

The moat was never the code

Here is the uncomfortable truth the last 24 months have surfaced: Most enterprise platforms are not technological marvels. An ERP, stripped to its essence, is a workflow engine with a data layer a system that captures events, routes them through rules and centralizes information so leadership can see what the business is actually doing. A CRM is a contact database with stages and notifications. An ITSM platform is a ticket system with SLAs and escalation trees.

None of this is autonomous driving. None of it is protein folding. It is, for the most part, business logic wrapped in a user interface and stitched together with integrations, exactly the category of software AI assisted development has become remarkably good at producing.

The moat was never the code. The moat was the cost of writing the code. That moat is draining faster than most vendor roadmaps are willing to admit.

The shift is no longer hypothetical. Retool’s 2026 Build vs. Buy Shift Report, drawn from a survey of 817 enterprise builders, found that 35% of teams have already replaced at least one SaaS tool with a custom internal build, and 78% plan to build more custom tooling in the year ahead. The categories leading this displacement, workflow automations and internal administrative tools, are exactly the workflow engine layer most enterprise platforms occupy.

Integration, historically the second pillar of SaaS defensibility is going the same way. Building and maintaining API connections, parsing third-party schemas, handling auth flows and data mapping: These were once multi-quarter projects requiring senior engineering effort. They are now, increasingly, prompts and pull requests.

The real reason enterprises haven’t moved yet

If the economics have shifted so dramatically, why hasn’t every Fortune 500 CIO kicked off a build-in-house initiative? The answer has almost nothing to do with technology.

Replacing a CRM or an ERP is not a software problem. It is a change management problem at a scale most outside observers drastically underestimate. You are not swapping out a tool; you are disrupting the daily workflows of tens of thousands of employees, retraining entire functions, reworking reporting structures and absorbing a period of real operational risk. The software itself is perhaps 30 percent of the effort. The other seventy percent is people, process, data migration and the organizational gravity every incumbent system accumulates over a decade of use.

This is why current vendor pricing has, so far, held. Not because the product is irreplaceable, but because the switching cost is measured in quarters of lost productivity, not in license fees.

The pricing conversation vendors are avoiding

Here is the dynamic. Enterprises will not replace incumbent systems out of enthusiasm for their own engineering. They will replace them when the spread between vendor cost and internal build cost becomes large enough to justify the organizational pain.

The pricing pressure on the customer side is already showing up in the data. Zylo’s 2026 SaaS Management Index shows enterprise SaaS spend now averaging $55.7 million annually, up 8% year-over-year, while application portfolios have remained essentially flat at around 305 applications. The increase is coming from pricing inflation, AI tiers, consumption charges and contract expansion, not from adding new tools. Customers are paying more for the same number of platforms, and they have noticed.

That threshold is not fixed. It moves with every improvement in AI-assisted development tooling, with every successful internal proof of concept, with every reference case from a peer who has done it and survived. If SaaS pricing does not meaningfully adjust, enterprises will eventually take the path of building their own, not because it is glamorous, but because at some point the math stops being close.

Vendors who respond early, by genuinely lowering total cost of ownership, by building platforms that are cheaper to customize than to rebuild, by shifting from seat-based rent extraction to something that reflects AI-era economics, will survive this transition in strong shape. Vendors who defend legacy margin structures will, in the medium term, find themselves defending empty castles.

Repricing is the easy part. Rewiring the company is the hard one.

I want to be precise here, because most vendor responses to this moment will get it wrong. The instinct is to run the discount lever, enterprise-wide deals, bundled SKUs, harder renewal negotiations. That is the obvious move. It is also insufficient.

The deeper shift is about the operating model of the SaaS company itself. For two decades, vendors were built around specific assumptions: Customers were captive, renewal was largely automatic, roadmaps could be dictated from the vendor side and the sales motion was about expansion rather than earned trust. Those assumptions produced the margins, and the cultural habits that defined the category.

Industry analysts are starting to document the early stages of this shift. L.E.K. Consulting’s analysis of how AI is changing SaaS pricing tracks the structural move away from seat-based and flat-fee models toward usage-based and hybrid structures, with specific examples like Atlassian’s recent cloud price changes and Microsoft phasing out volume-based enterprise discounts. The pricing models themselves are in flux, but pricing change alone is not the answer.

Rewiring means rebuilding the company around the assumption that the customer now has a credible alternative. It means product teams that treat customer workflow fluency as an engineering skill. It means pricing structures that share value rather than extract it. It means professional services organizations measured on reducing customer dependency rather than deepening it. And it means sales cultures that stop treating the CIO office as a target and start treating it as a partner whose internal build capability is now a legitimate competitive force.

A discount is a transaction. A win-win relationship is a rewiring. The vendors who survive this will be the ones who understand the difference.

A note to my fellow CEOs: If you have not yet thought of your CIO as a strategic voice in your leadership team, now is the time to reconsider. A good CIO today is not a technology manager. They are a business strategist with a technical fluency the rest of the C-suite, in most cases, does not have.

The exception: cybersecurity

I want to be careful not to overstate the thesis. One category of enterprise software does not follow this logic, and I believe the incumbent model will not only survive but strengthen: cybersecurity.

Palo Alto Networks, Zscaler, CrowdStrike and their peers sit in a fundamentally different position. The product is not really the software. The product is the threat intelligence, the accumulated, continuously updated understanding of adversaries, attack patterns and zero-day exposures, drawn from telemetry across thousands of customer environments that no single enterprise can replicate.

The investment patterns reflect this. Recorded Future’s research on enterprise threat intelligence indicates that 91% of organizations plan to increase threat intelligence spending in 2026, even as broader software budgets come under pressure. No enterprise wants to stand up its own cyber research function. No CIO wants the accountability of keeping pace with nation-state actors. The expertise is genuinely scarce, the stakes are existential and the failure mode, a breach, is career-ending in a way that a clunky CRM never is. That’s a real moat, and AI does not dissolve it. If anything, AI on the adversarial side only deepens the case for specialist providers.

But the exemption is not a license to stand still. If the rest of the enterprise stack moves toward internally built, AI-generated platforms, cybersecurity vendors must fundamentally rethink how and where they show up. The old model assumed a well-defined perimeter of vendor systems to protect. That perimeter is dissolving. What replaces it is a sprawl of internally built applications, AI agents and custom workflows, each one a new attack surface that wasn’t on any vendor’s roadmap six months before it went live.

The winning cybersecurity companies of the next cycle will not sell a product alongside the enterprise stack. They will embed inside it as security primitives in AI development tooling, as guardrails in agent frameworks, as policy layers in the internal platforms enterprises are building. Security must become a capability present at the moment of construction, not a control applied after deployment.

What this means for the next five years

I don’t believe the SaaS model is dying. I believe it is being repriced, and the repricing will be uneven, painful in some categories, barely felt in others. The vendors who recognize this early and move first will be the winners of the next cycle.

For CIOs, the honest advice is not to rush into replacing your ERP next quarter. The change management reality is still real. But it is worth building internal AI-assisted development capability now, starting with the edges, small workflow apps, agents, integrations, internal tooling where the risk is contained and the learning is transferable. Over time, that capability becomes optionality. And optionality, in a negotiation with a SaaS vendor, is worth more than any discount they will offer you unprompted.

The industry has spent a long time operating on the assumption that enterprise software is something you must rent. That assumption is now, for the first time in a generation, genuinely up for renegotiation. The companies that recognize this on both sides of the table are the ones that will define what comes next.

The rest will be renegotiated around.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Doing a great job in your current role is table stakes for modern CIOs. The most successful digital leaders embrace new challenges in situ and in fresh working environments, and with research reporting the average tenure for any digital leadership role to be about five years, the ability to move seamlessly into new opportunities has never been more crucial.

Evidence also suggests that CIOs who think outside the box and move between positions, employers, and industries better develop their leadership skills and produce benefits for their teams, businesses, and end customers. From generating novel solutions to embracing different cultures, here are examples from six specific industries on how broad experiences help diversify CIO leadership skills.

1. Formula One: focusing on teamwork produces novel solutions

Dan Keyworth, executive director, performance technology and systems at McLaren Racing, says leading technology in the fast-paced world of Formula One has fostered new skills.

“Being in a high-octane environment, you learn how the tools you provide to people make a material difference,” he says. “In some organizations where operations are a little slower, people don’t understand the tangible impact technology has.”

Keyworth says success in F1 is about using data to find a competitive edge. Having spent nine years with technology specialist Fujitsu, he joined McLaren in 2017. And during his time in motor racing, McLaren has continued to improve on the track, culminating in last season’s successes, where the team won the Constructors’ Championship and Lando Norris won his first driver’s title.

“That’s been an incredible journey for me, because as we’ve gone up the pecking order, I’ve realized how critical our technology is, and where there are opportunities to evolve and develop,” he says.

Keyworth says the other skill he’s developed in F1 is collaboration. “I think many organizations can be quite hierarchical, and you don’t find that in a Formula One team,” he says. “We’re in a room trying to solve problems, so ranks are removed and we go after challenges together. That approach has taught me a lot about human connection and leadership. Success is about creating a flat structure, getting around the problem, and getting stuck into something, no matter what the rank.”

2. Recruitment: welcoming change develops new leadership skills

Ankur Anand, group CIO at technology and talent solutions provider Nash Squared, joined in June 2023, after nearly six years at Manpower Group, where he rose to regional CIO and head of transformation for Europe. Before this role, he spent 15 years in senior technology positions at financial services giant Citi.

“The depth of experience I got from those experiences was enormous,” he says. “I felt I could take that knowledge into a mid-size organization with a huge appetite to grow. I wanted to create an impact based on all the learnings from my career.”

In his three years with Nash Squared, Anand has focused on creating a single view of customer data, establishing change management processes, and embracing emerging technology. Moving between organizations prepared him for the transformation he oversees.

“People can underestimate their ability to transition into change and required behavior in terms of how you react, manage people, and work with stakeholders,” he says. “It’s an enormous but positive change because you start adapting to different operating models and developing different leadership styles. What works in one environment with one business doesn’t necessarily work in another.”

3. Content services: being adaptable marks you out for success

Joel Hron, CTO at global content and technology specialist Thomson Reuters, was previously CTO at tech startup ThoughtTrace, which Thomson Reuters acquired in 2022. Hron joined the firm as part of the acquisition process.

“This role was a chance to lead a global team of 5,000 and shift the mindset into a more agile, entrepreneurial one,” he says. “To move an organization of that scale and size culturally was also something I saw as a challenge and a great opportunity.”

Taking on a fresh challenge is nothing new to Hron. After initially aiming to work in education, he attended graduate school, but was drawn to real-world research and development, particularly programming, modelling, and forecasting in the petroleum industry. After his stint in the startup sector, he says switching to Thomson Reuters honed his adaptability.

“I think that mindset has been forced into me over time because of the variety of roles I’ve had,” he adds. “All the small things I’ve learned come together to build the intuition I have today. When people ask me what should I do next, I tell them just be opportunistic, say yes more than you say no. If you trust yourself and feel it’s not the right thing, you can do something else. But say yes and give yourself the chance to learn something new and like something you didn’t expect.”

4. Property: pulling different levers hones capabilities

Richard Corbridge, CIO at property specialist Segro, says the current emphasis on AI and data means the digital leadership role is having a renaissance. “People seem to have landed back on the fact that the CIO is the executive chef in the kitchen,” he says. “I think that gives us a good opportunity to shine.”

One crucial factor in this renaissance, he adds, is the consumerization of technology fostered through mobility, the cloud, and now gen AI, which means LOB colleagues are as eager to learn about technology as their IT peers. From now on, digital leaders will be expected to source great ideas from across the organization.

“CIO is a more social role than 10 years ago,” he says. “You need to be in your business, not aside or on top of it. That positioning means a CIO who’s going from industry to industry is going to pick up knowledge of different demands.”

Rather than being experts within their own domain, successful CIOs are members of the senior leadership team that drives business transformation. Corbridge says his own broad experiences, including leading IT for the NHS, high-street retailer Boots, and the UK government’s Department for Work and Pensions, have helped him develop as a CIO.

“It’s been enjoyable taking big healthcare project experience to the private sector to see what levers I can pull differently,” he says.

5. Technology: embracing new cultures creates energy

Nick Pearson joined Ricoh Europe as CIO in 2023, after being head of IT platform at Vodafone. He’s also held senior tech roles at RS Group and PepsiCo, eventually becoming UK IT director. He says moving sectors helps leaders diversify skills, particularly when embracing new cultures.

“This is the first Japanese company I’ve worked for,” he says. “While it’s a loosely federated business, there’s a culture of Kaizen and continuous improvement. That’s a different approach to Vodafone, where people were focused on achieving 10 times the impact, productivity, or growth of projects.”

Pearson says one of the things he’s learned at Ricoh is that risk appetites can vary across cultures. “There’s a lot more rigor in project tracking and statuses in a Japanese firm than you’d expect in a Western company,” he says. “The approach is data-rich: the more information the better. In a US-style company, the board often just wants to know if a project is on track, and the rest of the deliverables are your concern. It’s super-energizing, and I’ve gained knowledge by experiencing different cultures.”

Pearson says being a CIO in the technology sector has also helped him appreciate the importance of product portfolio management skills. “In an IT services company, where the technology is changing so often, success means thinking about how you continually evolve your portfolio without cannibalizing your star product,” he says.

6. Travel: moving between domains keeps you sharp

Huy Dao, director of data and machine learning platform at travel specialist Booking.com, has spent the recent part of his career helping tech-focused companies like Zwift, Zillow, and now Booking exploit their data assets. Earlier in his career, he worked for one of the world’s biggest technology companies.

“I spent 18 years at Microsoft where we were primarily providing tech solutions, such as Office,” he says. “What’s interesting for me now is I get to learn about a new business domain, and that keeps me on my toes.”

As part of a central group that provides data and ML capabilities to Booking, Dao ensures his team has the right tools to complete their work. He also helps employees build and operate highly governed, high-quality data-enabled products.

“My role centers on how technology is applied to travel. I aim to understand how the business works, how our customers feel, and how our partner relationships are going,” he says. “The industry is very interesting, and that keeps me motivated to learn and contribute every day.”

Autonomous agent orchestration tool OpenClaw hit the scene last November and immediately went viral, but its dramatic flaws were exposed just as quickly.

Still, it marked a pivotal step in the agentic AI era, and enterprises have been exploring ways to deploy fleets of autonomous agents safely and securely ever since.

Automation Anywhere Tuesday rolled out its answer to this challenge, EnterpriseClaw, created in collaboration with Cisco, Nvidia, Okta, and OpenAI.

The company says the platform will enable companies to deploy autonomous AI agents across their desktops, cloud platforms, secured ‘behind-the-firewall’ networks, and on-premises systems, all while maintaining centralized control, access, and observability.

Automates business-critical work

EnterpriseClaw is built on Automation Anywhere’s Process Reasoning Engine (PRE) and Contextual Intelligence Graph, which automate business-critical work. It also integrates with Cisco AI Defense and DefenseClaw to provide security purpose-built for AI agents, Nvidia’s open-source runtime OpenShell, NIM microservices and Nemotron models for on-premises customers, and Okta’s cross-agent identity management and authentication controls. Furthermore, OpenClaw’s OpenAI collaboration will give customers access to leading models like GPT-5.5.

“The level of distrust and insecurity associated with OpenClaw is covered in significant detail in the EnterpriseClaw launch,” said Manish Jain, a principal research director at Info-Tech Research Group. “The collaboration between Nvidia, OpenAI, Okta, and Cisco adds to the credibility of the proposition of trusted infrastructure, identity, and security layers.”

Automation Anywhere says the platform will give enterprises the ability to deploy agents in parallel in managed containers behind firewalls, providing local access to files, apps, browsers, and terminals. Agents can hand off tasks and combine outputs so that value “compounds” rather than being isolated and confined to single-agent tasks, the company said.

Users can set policies, access controls, guardrails, and agent credentials, which are all enforced locally on-device, and receive information on telemetry, audit logs, and large language model (LLM) usage.

The company pointed to use cases like claims investigation: AI agents can gather information across desktop apps, internal documents, on-premises systems, and cloud platforms, all while keeping financial, operational, and other sensitive data secured inside enterprise systems. Other usage scenarios include code generation and debugging, local file post-incident log analysis, research, user interface (UI) automation, and secure data processing in regulated environments.

EnterpriseClaw is now available in preview, with general availability expected later this year.

No clear differentiator

Still, there’s no clear-cut differentiator here, noted Jason Andersen, a VP and principal analyst with Moor Insights & Strategy. Nvidia has already announced its NemoClaw open-source stack to provide guardrails for always-on agents, and EnterpriseClaw has essentially the same capabilities and generally-available stack.

“Which begs the question: If you are already using Nvidia’s, why choose this?” he asked. Indeed, the Cisco and Okta capabilities will “likely be interesting” to their existing bases. “But again, those products already work with other tools,” Andersen pointed out.

OpenClaw-like agents changing everything

Ultimately, noted technology analyst Carmi Levy, OpenClaw’s arrival has changed enterprise leaders’ view of AI, because it turned what was previously just a concept of AI agents into an everyday-accessible tool for a mass audience.

“As ChatGPT took chatbots out of the lab and drove them into mainstream use, OpenClaw did the same for AI agents,” he said. It shifted the notion of AI from something we chat with to something that actually gets work done. This represents “a key step in replacing human capital with technological capital.”

Info-Tech’s Jain explained that OpenClaw provided AI with three key features: Local execution via a desktop or laptop, persistent autonomy (operation without human input), and direct control over various systems such as WhatsApp or Slack.

“In effect, OpenClaw gave its agents claws (hands), allowing them to run in the background continuously,” he said. They can then execute real-world actions across file systems, web browsers, and applications based on a “single thread” of chat messaging.

But when claw agents quickly began leaking information about user data, there was a “polarization of emotions,” with users both excited and shocked about what they could do and access, he pointed out.

“OpenClaw did not meet enterprise-grade product standards,” said Jain. “The data leaks and inappropriate behaviors associated with claw agents exhibit how an uncontrolled tool, when introduced with no guardrails, will lead to massive issues.”

While Automation Anywhere is deploying EnterpriseClaw in partnership with a group of credible companies, that is just one side of the story; enterprises must govern all AI agents as “persistent digital actors without conscience,” he noted.

Moor’s Andersen also pointed out that OpenClaw can be run on many different models, essentially as a client and a server. But this means there are no real governance capabilities available, “so it’s kind of a wild west, which is why we are seeing companies create these enterprise offerings,” he said.

Claw agents ‘amazing,’ but enterprises beware

What resonates most about OpenClaw is that it can be run alongside open-source AI models like Gemma on a local machine, and users don’t have to pay for or worry about data, Andersen pointed out. This is a direct response to other wildly popular but more expensive tools like Claude Cowork; the latter is “amazing,” but “somewhat addictive,” so users can easily burn through the lowest-cost $20 a month usage credit option.

Tools like OpenClaw are “pretty great” when you have many tasks running in parallel, Andersen noted. For instance, in a marketing campaign, agents can check sales volumes and generate new content at the same time.

Levy added that agents could potentially replace “the human worker-bee” altogether, handling the minutiae of day-to-day work.

Helpdesk workflows are “particularly aligned” with the capabilities of OpenClaw-like agents, he pointed out, as the agents can autonomously manage and close tickets. Or, in administrative work, they can take on repetitive, low-risk and high-return tasks like scheduling meetings, drafting email messages, and managing follow-ups. In software development, vibe-coding agents can efficiently generate large volumes of code for diverse projects.

“Is the code any good? The verdict is still out on that, but it’s clear that OpenClaw-like agents are already rapidly tilting the coding landscape in favour of automation,” said Levy.

Still, agents need a lot of permissions to live up to expectations, which can introduce “unnecessary or unacceptable” levels of risk, he noted. Builders will need to grant sufficient access to maintain productivity, but not so much that they set the stage for an “AI-powered debacle” down the road.

Enterprises also run the risk of AI-fed data leakage, likely from opportunistic agents accessing sensitive data from multiple sources and sharing it beyond originally intended purposes, Levy said. Agents are subject to “AI-ified cybersecurity risks,” such as prompt injection and instruction attacks that use hidden text in documents to autonomously execute remote commands.

Another issue is explainability; particularly in regulated industries, enterprises must be able to show traceability and justify why a certain action was taken and who signed off on it. Additionally, “longer-term reliance at this level will inevitably erode institutional knowledge as the human workers who originally crafted it are replaced by automation,” Levy cautioned.

This article originally appeared on CIO.com.

Autonomous agent orchestration tool OpenClaw hit the scene last November and immediately went viral, but its dramatic flaws were exposed just as quickly.

Still, it marked a pivotal step in the agentic AI era, and enterprises have been exploring ways to deploy fleets of autonomous agents safely and securely ever since.

Automation Anywhere Tuesday rolled out its answer to this challenge, EnterpriseClaw, created in collaboration with Cisco, Nvidia, Okta, and OpenAI.

The company says the platform will enable companies to deploy autonomous AI agents across their desktops, cloud platforms, secured ‘behind-the-firewall’ networks, and on-premises systems, all while maintaining centralized control, access, and observability.

Automates business-critical work

EnterpriseClaw is built on Automation Anywhere’s Process Reasoning Engine (PRE) and Contextual Intelligence Graph, which automate business-critical work. It also integrates with Cisco AI Defense and DefenseClaw to provide security purpose-built for AI agents, Nvidia’s open-source runtime OpenShell, NIM microservices and Nemotron models for on-premises customers, and Okta’s cross-agent identity management and authentication controls. Furthermore, OpenClaw’s OpenAI collaboration will give customers access to leading models like GPT-5.5.

“The level of distrust and insecurity associated with OpenClaw is covered in significant detail in the EnterpriseClaw launch,” said Manish Jain, a principal research director at Info-Tech Research Group. “The collaboration between Nvidia, OpenAI, Okta, and Cisco adds to the credibility of the proposition of trusted infrastructure, identity, and security layers.”

Automation Anywhere says the platform will give enterprises the ability to deploy agents in parallel in managed containers behind firewalls, providing local access to files, apps, browsers, and terminals. Agents can hand off tasks and combine outputs so that value “compounds” rather than being isolated and confined to single-agent tasks, the company said.

Users can set policies, access controls, guardrails, and agent credentials, which are all enforced locally on-device, and receive information on telemetry, audit logs, and large language model (LLM) usage.

The company pointed to use cases like claims investigation: AI agents can gather information across desktop apps, internal documents, on-premises systems, and cloud platforms, all while keeping financial, operational, and other sensitive data secured inside enterprise systems. Other usage scenarios include code generation and debugging, local file post-incident log analysis, research, user interface (UI) automation, and secure data processing in regulated environments.

EnterpriseClaw is now available in preview, with general availability expected later this year.

No clear differentiator

Still, there’s no clear-cut differentiator here, noted Jason Andersen, a VP and principal analyst with Moor Insights & Strategy. Nvidia has already announced its NemoClaw open-source stack to provide guardrails for always-on agents, and EnterpriseClaw has essentially the same capabilities and generally-available stack.

“Which begs the question: If you are already using Nvidia’s, why choose this?” he asked. Indeed, the Cisco and Okta capabilities will “likely be interesting” to their existing bases. “But again, those products already work with other tools,” Andersen pointed out.

OpenClaw-like agents changing everything

Ultimately, noted technology analyst Carmi Levy, OpenClaw’s arrival has changed enterprise leaders’ view of AI, because it turned what was previously just a concept of AI agents into an everyday-accessible tool for a mass audience.

“As ChatGPT took chatbots out of the lab and drove them into mainstream use, OpenClaw did the same for AI agents,” he said. It shifted the notion of AI from something we chat with to something that actually gets work done. This represents “a key step in replacing human capital with technological capital.”

Info-Tech’s Jain explained that OpenClaw provided AI with three key features: Local execution via a desktop or laptop, persistent autonomy (operation without human input), and direct control over various systems such as WhatsApp or Slack.

“In effect, OpenClaw gave its agents claws (hands), allowing them to run in the background continuously,” he said. They can then execute real-world actions across file systems, web browsers, and applications based on a “single thread” of chat messaging.

But when claw agents quickly began leaking information about user data, there was a “polarization of emotions,” with users both excited and shocked about what they could do and access, he pointed out.

“OpenClaw did not meet enterprise-grade product standards,” said Jain. “The data leaks and inappropriate behaviors associated with claw agents exhibit how an uncontrolled tool, when introduced with no guardrails, will lead to massive issues.”

While Automation Anywhere is deploying EnterpriseClaw in partnership with a group of credible companies, that is just one side of the story; enterprises must govern all AI agents as “persistent digital actors without conscience,” he noted.

Moor’s Andersen also pointed out that OpenClaw can be run on many different models, essentially as a client and a server. But this means there are no real governance capabilities available, “so it’s kind of a wild west, which is why we are seeing companies create these enterprise offerings,” he said.

Claw agents ‘amazing,’ but enterprises beware

What resonates most about OpenClaw is that it can be run alongside open-source AI models like Gemma on a local machine, and users don’t have to pay for or worry about data, Andersen pointed out. This is a direct response to other wildly popular but more expensive tools like Claude Cowork; the latter is “amazing,” but “somewhat addictive,” so users can easily burn through the lowest-cost $20 a month usage credit option.

Tools like OpenClaw are “pretty great” when you have many tasks running in parallel, Andersen noted. For instance, in a marketing campaign, agents can check sales volumes and generate new content at the same time.

Levy added that agents could potentially replace “the human worker-bee” altogether, handling the minutiae of day-to-day work.

Helpdesk workflows are “particularly aligned” with the capabilities of OpenClaw-like agents, he pointed out, as the agents can autonomously manage and close tickets. Or, in administrative work, they can take on repetitive, low-risk and high-return tasks like scheduling meetings, drafting email messages, and managing follow-ups. In software development, vibe-coding agents can efficiently generate large volumes of code for diverse projects.

“Is the code any good? The verdict is still out on that, but it’s clear that OpenClaw-like agents are already rapidly tilting the coding landscape in favour of automation,” said Levy.

Still, agents need a lot of permissions to live up to expectations, which can introduce “unnecessary or unacceptable” levels of risk, he noted. Builders will need to grant sufficient access to maintain productivity, but not so much that they set the stage for an “AI-powered debacle” down the road.

Enterprises also run the risk of AI-fed data leakage, likely from opportunistic agents accessing sensitive data from multiple sources and sharing it beyond originally intended purposes, Levy said. Agents are subject to “AI-ified cybersecurity risks,” such as prompt injection and instruction attacks that use hidden text in documents to autonomously execute remote commands.

Another issue is explainability; particularly in regulated industries, enterprises must be able to show traceability and justify why a certain action was taken and who signed off on it. Additionally, “longer-term reliance at this level will inevitably erode institutional knowledge as the human workers who originally crafted it are replaced by automation,” Levy cautioned.

Apple is realizing real business benefits as it builds a circular manufacturing process across the company. Manufactured using recycled materials and renewable energy, the popular new MacBook Neo is a great illustration of this.

Apple says the Neo is manufactured using 45% renewable electricity and holds 60% recycled materials by weight. That recycling includes 90% recycled aluminium and 100% recycled cobalt in the battery. 

e-Waste becomes input

The high-quality enclosure is made through a process in which durable recycled aluminum is pressed into near-final shape using just half the raw material of traditional machining. 

Apple even leaned into corporate social responsibility when it came to the A18 chip it puts inside these systems, as it originally used ‘binned’ processors originally intended for the iPhone 16 Pro to drive the five core A18. 

These were rejected processors Apple had in hand anyway, and while it has had to order additional chips to cope with demand for the MacBook Air, the original plan meant it got to sell a product based on chips it wouldn’t otherwise have been able to use. Apple has done this before, such as when it put A15 Bionic chips inside the iPhone SE.

Strategic environmentalism

Effectively, use of binned chips and recycled materials means Apple has been able to find a way to build a $599 laptop that is highly affordable, and it doesn’t compromise design or product quality. This is the power of circular manufacturing, which isn’t just ethically smart, but seems to deliver real business advantages.

The heavy use of recycled components and materials helps reduce Apple’s overall costs, enabling it to repurpose e-waste it is already recycling and proofing it against increasing raw materials costs. 

Resilient by design

Recycled materials also make Apple’s supply chain more resilient. 

Aluminum, for example, is currently at a four-year price high due to severe shipping and supply disruptions courtesy of the forever war in the Middle East. In that context, making heavy use of recycled materials means Apple is less exposed to those costs as it might otherwise be. It can also continue to make a high-quality laptop at prices other players probably can’t match — unless they also have strong return and recycling schemes.

Cobalt isn’t as directly exposed to the Middle East conflict, but the industry is critical to defense munitions production, which means the cost of cobalt is rising. Much of global cobalt supply comes from the Democratic Republic of the Congo amid forced labor claims. Because so much of it comes from one place, transportation costs for cobalt are increasing as a result of war, while demand grows, pushing prices higher. Apple’s move to use recycled cobalt protects it against these price fluctuations. While recycled cobalt has a cost, it is more predictable, and recycled cobalt is something Apple presumably already has on hand.

Sustainability is good for business

The opportunity Apple unlocked by pushing toward a circular supply chain by 2030 is the ability to introduce a compelling new Mac laptop at a highly attractive price. (It has introduced a system so good Microsoft compared it with PCs it in a white paper.)

Apple’s focus on sustainability in product provision also strengthens the company’s reputation. By visibly doing the right thing, Apple has also been able to build its relationship with consumers.

When demand exceeds circular supply

Apple’s circular manufacturing strategy can be seen as being both environmentally responsible and commercially effective. It means the MacBook Neo isn’t just a $599 Apple notebook, it’s also a living illustration of how circular production unlocks huge competitive advantage, supporting profitability, affordability, and brand value.

Is it all good? Probably not, after all – Apple has been forced to order millions of new A-series chips to put inside these devices due to high demand. The benefit of recycled materials doesn’t always automatically outweigh the impact of mass production. If a product sells strongly, you must still get those components somewhere. But it is also true that the application of strategic common sense has helped Apple achieve real business results while also doing the right thing.

Can your business claim the same?

Please follow me on Twitter, or join me in the AppleHolic’s bar & grill and Apple Discussions groups on MeWe.

AI is useless without access to abundant and accurate data. Unfortunately, many enterprises are saddled with data that’s stored in a way that’s unusable for AI applications.

AI data incompatibility is widespread, even among organizations actively investing in AI, says Daren Campbell, tax technology and transformation leader at business advisory firm EY Americas.

“Adoption of generative and agentic AI is accelerating, but only a small minority of organizations have the data maturity required to scale AI effectively,” he states. “This helps to explain why many companies report AI activity without sustained business impact, since ambition is moving faster than underlying data foundations.”

Is your enterprise’s productivity being held hostage by inaccurate, defective, or obsolete data? Here’s a quick rundown of seven key signs that indicate your organization needs a data makeover.

Your data strategy is designed for compliance not decision-making

AI-incompatible data is typically the result of many years of siloed systems, inconsistent standards, and weak data governance.

“Much of today’s enterprise data was designed for compliance and static reporting, not for learning, automation, or real-time decision-making,” Campbell says. “The problem is compounded by unmanaged unstructured data, missing metadata, unclear ownership, and limited traceability, all of which makes it difficult for AI systems to interpret data reliably.”

Campbell adds that both generative and agentic AI are rapidly accelerating, yet only a small minority of organizations have the data maturity required to scale AI effectively. “This helps explain why many enterprises report AI activity without any sustained business impact, as ambition is moving faster than underlying data foundations.”

You’re weak on data management

A key data management issue is teams struggling to use of existing data within its current environment, says David Harmony, senior executive distinguished engineer at financial services firm Capital One.

“Making data well-managed is a critical, early step that’s a precursor to being able to leverage your data for AI,” he states. Harmony believes that business leaders must always know where their data is and what the data contains. “Without a well-managed data strategy, it’s difficult to make the most use of your data as AI accelerates,” he says.

Harmony says that Capital One is addressing this issue by modernizing its data ecosystem in the cloud and building enterprise platforms that support data publishing, consumption, governance, and infrastructure management. The goal is creating a well-managed foundation for AI initiatives. “AI is most effective when it’s built on a strong foundation of well-managed data,” he states.

Your data governance isn’t governing

If IT and business leaders can’t clearly explain where their data lives, who owns it, and whether it can be trusted, the enterprise isn’t AI-ready, says Vasileios Maroulas, associate vice chancellor and AI director at the University of Tennessee, Knoxville. “If every analysis requires manual reconciliation, AI will only amplify inconsistency,” he warns.

Organic system growth, siloed departments, inconsistent definitions, and lack of governance all contribute to data unpredictabilty, Maroulas says. He notes that most enterprises build their infrastructure to run operations, not to enable prediction or automation. “AI exposes those structural gaps,” he notes.

To increase data predictability, Maroulas advises focusing on governance and interoperability. “Define ownership, standardize terminology, and modernize pipelines deliberately,” he says.

Your business intelligence strategy has lost its users

Weak business intelligence adoption is a key indicator that an organization’s data simply isn’t ready for AI, says Olga Kupriyanova, AI and data engineering technology director with research advisory firm ISG. What does business intelligence have to do with artificial intelligence? “Everything,” she states. “BI is the proving ground for enterprise data.”

When BI underperforms, business users don’t wait — they work around it, Kupriyanova says. “They’ll export data, build shadow models, create local definitions, and hard-code their own business logic into spreadsheets or custom analytics.” Over time, such unofficial semantic layers multiply. “None of them flow back into the enterprise warehouse, and that’s where the real danger lies, creating a false sense of health,” she says.

From the outside, it may seem like the organization has no major data issues, because reports are being produced and decisions are being made, Kupriyanova explains. “Yet, in reality, users have quietly stopped relying on the core data platform and stopped asking IT for help.”

Your data doesn’t align with business outcomes AI can influence

When AI systems suddenly begin spewing answers that are inconsistent, outdated, or out of sync with the experience expected, it’s a clear sign of incompatible data, warns Guy Bourgault, head of agentic solutions at technology advisory firm Concentrix. “These kinds of misfires usually point to underlying knowledge sources that haven’t been maintained or governed with intention,” he says.

Leaders tend to see warning signs of incompatible data when it becomes difficult to draw a straight line between their available data and the business outcomes AI is expected to influence, Bourgault states. “When that clarity is missing, it’s a sign that the data foundation isn’t prepared to support AI at scale.”

AI-incompatible data often stems from information that was originally written for humans to interpret, not for machines to process, Bourgault says.

“Many knowledge bases fall into this category, since they rely on human intuition to fill-in missing context or navigate decision trees that AI can’t reliably follow,” he notes. “As permissions age or become overly broad, AI may access content it was never intended to see, leading to responses that are inaccurate or potentially risky.” Over time, the mix of outdated content, unclear structure, and loose governance creates a fragile data environment that AI struggles to interpret correctly, Bourgault says.

You’re overloaded with data debt

Data quality is something most people prefer to complain about rather than fix, observes Arthur O’Connor, academic director of data science at the City University of New York’s School of Professional Studies.

“It requires addressing the accumulated sins of the past, including inconsistent data formats, missing values, conflicting business rules, and disparate interfaces and protocols,” he says. “It’s about correcting a legacy of taking shortcuts.” Few organizations, he observes, have the time, energy and will to do that.

This data debt issue isn’t just a technical challenge; it’s also an organizational one, O’Connor says. “The prime reason internal datasets aren’t discoverable or managed well across the enterprise is because neither the IT staff nor the business teams who use data have the resources or incentives to realize the data’s full value,” he states. “While data users want completely accurate, clean, and well-managed data, the individual data owners typically don’t have the budget, financial incentive, or organizational authority to ensure a high level of quality and transparency.”

The basic problem, O’Connor says, is that while AI is sexy, exciting, and interesting, data governance tends to be tedious, boring, and painful.

Basic insights are already a problem

A reliable warning sign is how easily your organization’s team can obtain basic insights, Jen Clark, director of AI advisory services at business and tax consulting firm Eisner Advisory Group.

“If standard reporting and analytics are a struggle, if pulling together a clear picture requires effort across teams and resources, then AI will amplify the challenge, not solve it,” she warns. “Similarly, if data is disconnected or siloed without a clear path to integration, that’s usually a sign foundational work is needed before AI can deliver real value.”

Data represents the real world, and the real world is messy, Clark observes. It’s rarely, if ever, perfectly ready for an ideal AI scenario, and there are always trade-offs, she notes. “The question isn’t whether incompatibility exists, it’s how you scope around it to still drive meaningful outcomes.”

AWS has increased Amazon CloudWatch Logs Insights query result limits from 10,000 to 100,000 rows and added pagination support for its GetQueryResults API to help developers and site reliability engineers (SREs) troubleshoot and debug large-scale distributed applications more efficiently.

The update to the monitoring and observability service, according to an AWS blog post, will reduce the need to repeatedly split queries into smaller time windows during incident investigations, debugging, and operational audits across enterprise environments.

Analysts see sound operational reasoning behind the move.

“The old 10,000-row CloudWatch limit was a real problem for large distributed systems. During outages, SRE teams often had to rerun the same query across multiple small time windows and manually combine results. Automated monitoring and compliance pipelines also needed extra custom logic, making systems more complex and fragile,” said Pareekh Jain, principal analyst at Pareekh Consulting.

“The new 100,000-result limit makes investigations much easier. Teams can now analyze larger incidents in a single query, reducing manual effort and speeding up troubleshooting. Dashboards, exports, and pattern analysis also work on more complete data,” Jain noted.

“In microservices environments where one request touches many services, teams now have a much better chance of seeing the full impact of a failure in one search,” Jain pointed out.

Pagination support could boost observability automation

The added pagination support for the GetQueryResults API, in fact, according to Avasant research director Gaurav Dewan, is the “bigger” architectural improvement.

“Previously, query APIs could return truncated datasets, requiring teams to re-run queries with additional filters or implement custom logic to retrieve complete results. This added complexity, especially for automated workflows such as runbooks, bots, or SIEM ingestion pipelines,” Dewan said.

“With pagination, query results can now be accessed incrementally in a structured way. This makes it easier to programmatically retrieve large datasets and is likely to improve the reliability of automation workflows built on top of CloudWatch,” Dewan added.

Despite the immediate benefits, neither analyst was convinced that the new update would eliminate the need for third-party observability or SIEM platforms in enterprise environments.

“It reduces friction at the margins, but doesn’t close the structural gaps that drive third-party observability or SIEM tools adoption,” Jain said.

While teams troubleshooting Lambda, ECS, or EKS workloads inside AWS may now rely more on CloudWatch for incident investigations instead of exporting logs to third-party tools simply because of earlier query limits, for SIEM, security analytics, compliance, or multi-cloud environments, platforms like Datadog, Splunk, or Elastic still offer broader cross-platform visibility, advanced correlation, and long-term governance features that CloudWatch does not fully address, Jain pointed out.

No direct cloud cost savings

Jain also downplayed the likelihood of major direct cloud cost savings from the update, noting that CloudWatch Logs Insights pricing is primarily based on the volume of data scanned rather than the number of results returned.

Instead, he said, the larger benefit is likely to come from operational efficiency and faster incident resolution.

“If SRE teams spend less time fighting query limits, rerunning searches, and stitching logs together, they can identify issues much faster. For large enterprise applications, even reducing outage investigation time from 15 minutes to 2 minutes can translate into significant operational and business value,” Jain said.

Enterprise users, according to AWS, can control the number of records returned in a query using the “LIMIT” command after setting the higher query ceilings either via the Amazon CloudWatch console or the AWS CLI. The feature has been made generally available across all AWS regions.

The complexity of modern networks and data centers has made it impossible to rely solely on manual oversight.

Hybrid cloud architectures, SD-WAN overlays, and multi-vendor environments have created configuration sprawl that teams cannot track by hand. At the same time, GPU clusters have pushed data center power loads well beyond what traditional facility planning handles. Average rack density was just 7 kW in 2021, according to AFCOM. AI training racks now routinely exceed 30 kW, and Nvidia’s GB200 NVL72 systems can spike past 150 kW per rack, according to the Uptime Institute.

Digital twin technology addresses these problems: Build an accurate model of the real environment, then use it to test changes before they reach production.

For network teams, digital twin technology provides a continuously updated behavioral model built from device configuration and state data. For data center engineers, it provides a virtual replica of the physical facility where rack layouts, cooling configurations and power loads can be simulated before hardware is touched.

What a digital twin actually does

A digital twin is a virtual representation of an environment and it synchronizes with the live environment continuously, which distinguishes it from static simulations built during a project’s design phase.

For networks, that means collecting configuration and state data continuously across every device, including routers, switches, firewalls, load balancers and cloud environments. All that information is updated in the model as the infrastructure changes. Network teams query the model to evaluate the impact of a planned change, test different approaches and validate that an update accomplishes its goals before pushing it to production.

For data centers, the twin uses computational fluid dynamics and electrical simulation to model the facility. Engineers can test rack layout changes, cooling strategy shifts and equipment additions to identify hot spots, power overloads and containment failures before any physical work begins.

Where each type of twin proves out

Network twins and data center twins address the same categories of operational risk, applied to different infrastructure layers:

Foundry