In Vernor Vinge’s science fiction novel A Deepness in the Sky, one of the characters works as a software archaeologist, mining thousands of years of code and libraries to find the solutions to development problems. In that fictional far future, every problem has been solved at least once, often in many ways with different interfaces for different languages and processor families.

Today’s software development world isn’t quite that complex, as we only have a few decades of programming to build on. Working with a platform as old as Windows, with all its layers and history and all the possible ways to build code on it, we’re still left to look for the right SDK and API to use in our toolchains. Microsoft’s layers of abstractions try to help, but they can cause confusion and make it hard to migrate code from older frameworks to the state-of-the-art ones for today.

All those layers are one reason why it’s unfashionable to write native Windows applications, as it can be hard to find the right prerequisites to developing with your choice of tools.

Separating software development from the OS

It’s also been hard to get the right SDKs and APIs to reach all your users. Microsoft used to only ship new developer bits with new OS releases, slowing progress and making it hard to get the latest features to users. Things began to change with the shift to rolling Windows releases with Windows 10, in the guise of “Windows as a service.” The intent was not so much that Microsoft controlled your PCs, but that developers would be able to address the widest possible audience with the latest features, allowing Windows developers to give their users the same experience as on iOS or Android.

Microsoft could finally separate the developer platform from the OS, shipping new developer tools and SDKs on their own schedule and in their own separate packages. That process has led to today’s Windows App SDK, a set of cross-language tools that provide native access to key Windows functions and APIs, including devices’ built-in neural processing units. Even with this and the ability for tools like Visual Studio to automatically install dependencies, it can still be hard to put all the necessary pieces together, let alone for other development tools and environments.

With Microsoft long having had the ambition to put its tools where developers are, there’s a need to put the necessary scaffolding and toolchain in place for alternative development environments and languages, especially where it comes to supporting cross-platform development in languages like Dart or Swift.

What’s needed is a way to automate the process of bringing the necessary libraries and environments to your choice of development tools. Windows development is as much about systems programming as it is building graphical user interfaces. Low-level code in Rust or C++ needs the same level of support as a .NET C# application, even if you’re using Vim or Eclipse.

Microsoft rediscovers the command line

A key element of Microsoft’s current developer strategy is its rediscovery of the command line. Spurred on by both the complete reworking of the Windows terminal and by the release of WSL, Microsoft has delivered a whole suite of command-line tools, covering everything from Azure to .NET, as well as the GitHub Copilot agent orchestration tools. By using the same terminal tool inside its programming editor, you’re able to code, manage, and run without losing context and flow.

One of the latest CLI tools works with the Windows App SDK, simplifying the process of creating, building, and publishing Windows applications without using Visual Studio and encompassing most toolchains used for Windows development. It’s an open source project, hosted on GitHub.

Getting the tool on a development PC requires installing it via WinGet. Open a Windows Terminal and run an install command, restarting your terminal to ensure that you’re working with updated environment variables. In addition to the CLI tool, there is an experimental GUI that can quickly add debug identities to existing code.

Bootstrap Windows development with winapp

With winapp installed, you’re ready to put together a Windows development environment with a single command. Running winapp init on a development PC puts you into an interactive environment where a few simple questions take you from an application name to a ready-to-go environment, complete with Windows’ developer mode enabled (if you’re starting on a brand-new PC). If you’ve already set up developer mode and downloaded the SDKs, the tool will use what you have ready—after checking that you have the latest versions.

A handful of minutes later and the SDK will have created all the necessary files for your application, downloaded and installed the required SDKs and libraries, and set up the required manifests and configuration files—even configuring the certificates needed for code signing and application packaging. One downside is that it doesn’t create a new directory for your code. You need to do this first and then run the CLI tool from a terminal running in your new directory.

Winapp CLI commands replace key steps in the software development life cycle, with the intent of simply leaving you to write code. The first step, init, sets up the necessary scaffolding for building a Windows application. If you’re using Node.js, the next step, node create-addon, puts the templates in place to link your JavaScript code to native Windows functions.

Once you’ve written your code, it’s time to go back to winapp to set up the tools for testing and packaging. This includes the ability to generate signing certificates and build the required identity for debugging without packaging your code as MSIX bundles. Finally, it simplifies the process of packaging your code for distribution, either using your own platform or via the Microsoft Store. There’s no need to worry about whether you’re building x64 or Arm code; winapp will work for both.

As the documentation notes, this process takes out between 10 and 12 steps (depending on your choice of platform), turning them into four simple CLI commands. Your code also gains the benefits of integration with the Windows platform, using the Windows App SDK APIs.

Working with winapp and Rust

Usefully Microsoft provides documentation for working with alternate toolchains beyond the familiar .NET and C++. One key development environment being addressed by winapp is Rust development, helping you build memory-safe Windows applications and reducing the risk of security breaches in your code.

Working with Rust requires a basic Rust toolchain, which can be installed with the familiar rustup command. Once Rust is installed on your development PC, create a new Rust application and open a terminal in its directory. With winapp installed, run its init command to add the scaffolding of a Windows application around the default Rust code. However, when prompted to install the Windows App SDKs, choose the option to not install an SDK. You will need to install the Windows crate to provide access to Windows APIs.

As winapp creates the temporary identity to test your code, as well as the manifest and certificates used to package Rust code as MSIX, you can now use your choice of editor to build an application before building a release with the Rust compiler and using winapp to install the developer certificate created when you initialized the application before packaging the resulting binary.

Using winapp in Node.js and Electron

Running the CLI tool in JavaScript environments like Electron or Node.js is slightly different from directly using it in Windows’ own terminal, as you’re working inside another CLI environment. Here you need to install it using npm and run it with npx. However, once you’re inside the winapp CLI environment, you can use the same commands to manage your JavaScript Windows application’s life cycle.

You’re not limited to using the CLI on a Windows PC: You can use it as part of a GitHub runner or inside Azure DevOps, allowing it to become part of your CI/CD pipeline. Microsoft provides actions for both tools to quickly install it in runners and agents, simplifying automated builds and tests.

Tools such as the Windows App SDK’s CLI are increasingly important. We’re now spending most of our time inside our development environments, and having key utilities a few keystrokes away inside a terminal gives us the necessary shortcuts to be more productive. Having it in your development toolchain should save time and let you concentrate on code instead of worrying about all the steps to package and sign your applications.

The Microsoft Azure outage that dragged out for 10 hours in early February serves as another stark reminder that the cloud, for all its promise, is not immune to failure. At precisely 19:46 UTC on February 2, the Azure cloud platform began experiencing cascading issues stemming from an initial misconfiguration of a policy affecting Microsoft-managed storage accounts. This seemingly minor error ballooned outwards, knocking out two of the most critical layers underpinning enterprise cloud success: virtual machine operations and managed identities.

By the time the dust began to settle, more than 10 hours later at 06:05 UTC the next morning, customers across multiple regions were unable to deploy or scale virtual machines. Mission-critical development pipelines ground to a halt, and hundreds of organizations struggled to execute even the simplest tasks on Azure. The ripple effect spread across production systems and workflows central to developer productivity, including CI/CD pipelines that run through Azure DevOps and GitHub Actions. Compounding the issue, managed identity services faltered, especially in the eastern and western United States, disrupting authentication and access to cloud resources across a swath of essential Azure offerings, from Kubernetes clusters to analytics platforms and AI operations.

The after-action report is all too familiar: an initial fix triggers a surge in service traffic, further overwhelming already-struggling platforms. Mitigation efforts, such as scaling up infrastructure or temporarily taking services offline, eventually restore order, but not before damage is done. Disrupted operations lead to lost productivity, delayed deployments, and, perhaps most insidiously, a reinforcement of the growing sense that major cloud outages are simply part of the territory of modern enterprise IT.

As the headlines become more frequent and the incidents themselves start to blur together, we have to ask: Why are these outages becoming a monthly, sometimes even weekly, story? What’s changed in the world of cloud computing to usher in this new era of instability? In my view, several trends are converging to make these outages not only more common but also more disruptive and more challenging to prevent.

Human error creeps in

It’s no secret that the economic realities of cloud computing have shifted. The days of unchecked growth are over. Headcounts no longer expand to keep pace with surging demand. Hyperscalers such as Microsoft, AWS, Google, and others have announced substantial layoffs in recent years, many of which have disproportionately affected operational, support, and engineering teams—the very people responsible for ensuring that platforms run smoothly and errors are caught before they reach production.

The predictable outcome is that when experienced engineers and architects leave, they are often replaced by less-skilled staff who lack deep institutional knowledge. They lack adequate experience in platform operations, troubleshooting, and crisis response. While capable, these “B Team” employees may not have the skills or knowledge to anticipate how minor changes affect massive, interconnected systems like Azure.

The recent Azure outage resulted from precisely this type of human error, in which a misapplied policy blocked access to storage resources required for VM extension packages. This change was likely rushed or misunderstood by someone unfamiliar with prior issues. The resulting widespread service failures were inevitable. Human errors like this are common and likely to recur given current staffing trends.

Damage is greater than before

Another trend amplifying the impact of these outages is the relative complacency about resilience. For years, organizations have been content to “lift and shift” workloads to the cloud, reaping the benefits of agility and scalability without necessarily investing in the levels of redundancy and disaster recovery that such migrations require.

There is growing cultural acceptance among enterprises that cloud outages are unavoidable and that mitigating their effects should be left to providers. This is both an unrealistic expectation and a dangerous abdication of responsibility. Resilience cannot be entirely outsourced; it must be deliberately built into every aspect of a company’s application architecture and deployment strategy.

However, what I’m seeing in my consulting work, and what many CIOs and CTOs will privately admit, is that resilience is too often an afterthought. The impact of even brief outages on Azure, AWS, or Google Cloud now ricochets far beyond the IT department. Entire revenue streams grind to a halt, and support queues overflow. Customer trust erodes, and recovery costs skyrocket, both financial and reputational. Yet investment in multicloud strategies, hybrid redundancies, and failover contingencies lags behind the pace of risk. We’re paying the price for that oversight, and as cloud adoption deepens, the costs will only increase.

Systems at the breaking point

Hyperscale cloud operations are inherently complex. As these platforms become more successful, they grow larger and more complicated, supporting a wide range of services such as AI, analytics, security, and Internet of Things. Their layered control planes are interconnected; a single misconfiguration, such as with Microsoft Azure, can quickly lead to a major disaster.

The size of these environments makes them hard to operate without error. Automated tools help, but each new code change, feature, and integration increases the likelihood of mistakes. As companies move more data and logic to the cloud, even minor disruptions can have significant effects. Providers face pressure to innovate, cut costs, and scale, often sacrificing simplicity to achieve these goals.

Enterprises and vendors must act

As we analyze the recent Azure outage, it’s obvious that change is necessary. Cloud providers must recognize that cost-cutting measures, such as layoffs or reduced investment in platform reliability, will ultimately have consequences. They should focus more on improving training, automating processes, and increasing operational transparency.

Enterprises, for their part, cannot afford to treat outages as inevitable or unavoidable. Investment in architectural resilience, ongoing testing of failover strategies, and diversification across multiple clouds are not just best practices; they’re survival strategies.

The cloud continues to be the engine of innovation, but unless both sides of this partnership raise their game, we’re destined to see these outages repeat like clockwork. Each time, the fallout will spread a little further and cut a little deeper.

When it comes to cloud infrastructure portability, the reigning solutions just don’t live up to their promise. Infrastructure as code (IaC) solutions like Terraform shoehorn nuanced infrastructure into too-broad terms. Cloud provider offerings like Azure Migrate, AWS Migration Services, and Google Cloud Migrate generally don’t translate native workloads into competitors’ clouds. And governance tools are often excellent at alerting users to finops and drift issues, but rarely help users actually fix the issues they flag.

I have outlined these issues in a companion article—I invite you to start there. In this article, I provide an overview of an infrastructure replication methodology, Cloud Cloning, which my colleagues and I at FluidCloud have created to address the challenges above. Below, I’ll explain how Cloud Cloning achieves all this by walking you through how our solution works. 

Capturing the full scope of public cloud setups

As a first step of enabling cloud portability, Cloud Cloning starts with a complete snapshot of the source cloud infrastructure. Cloud Cloning calls the cloud provider’s APIs and scans and captures the complete cloud infrastructure footprint, including the many resources, dependencies, and nuances like VPCs, subnets, firewall rules, and IAM (identity and access management) permissions that the reigning multicloud tools tend to overlook.

To give some context as to what this snapshot achieves, it helps to understand where multicloud tools evolved from. From the beginning, the multicloud field emerged to support migrations from on-prem private clouds up to the public ones. As such, these tools were focused on recreating the two most fundamental primitives of private clouds: VMs and storage. To a large extent, that focus continues today, with leading offerings like AWS Migrate, Azure Migrate, Google Cloud Migrate, Nutanix Move, Veeam, and Zerto focused largely on just these two areas.

The problem is that, when it comes to migrating across public clouds, VMs and storage are only a small part of the picture. Public cloud environments rely on complex architectures with hundreds of services spanning databases, storage buckets, IAM users and permissions, subnets, routing, firewalls, Kubernetes clusters and associated control planes, and a lot more.

By starting with a snapshot of the full infrastructure ecosystem, Cloud Cloning captures a vast amount of the critical cloud elements that conventional tools don’t. In our experience, those other tools tend to capture between 10% and 30% of the source cloud setup, whereas Cloud Cloning captures 60% or more.

Translating from Cloud A to Cloud B

Once Cloud Cloning has captured the full picture of the source cloud infrastructure, the next step is mapping that infrastructure onto the target cloud’s services and configuration model. Because each cloud’s API specifications are so radically different, this translation work is no small feat. Consider just a few examples from three key areas:

• Compute and resource management: Each cloud provider exposes similar compute and networking building blocks, but different semantics. AWS Auto Scaling Groups, Azure VM Scale Sets, and GCP Instance Groups, for instance, behave differently in how they handle availability, placement, and scaling. The same applies to security: AWS security groups are allow-only; Azure uses ordered allow/deny rules with priorities; and GCP defines separate ingress and egress firewall rules. These and other differences make it difficult to reproduce deployments exactly without re-interpreting the underlying intent into the target cloud.
• Storage and data: Storage and data services are not interchangeable across clouds. Block volumes and file systems differ in performance, snapshot behavior, and consistency guarantees. Meanwhile, managed databases such as AWS RDS, Azure SQL / PostgreSQL, and GCP Cloud SQL share engines but diverge in extensions, limits, backup semantics, and failover models. As a result, storage and data layers often need to be re-architected rather than directly replicated.
• Identity and access: IAM is one of the least portable layers across clouds. AWS uses policy-driven roles and users; Azure ties permissions to subscriptions and role assignments; and GCP enforces hierarchical IAM with service accounts at multiple levels. As a result, access models and automation workflows rarely translate directly and must be re-thought for each cloud.

Because the leading cloud migration tools aren’t focused on infrastructure, they’re simply not set up to make these complex translations. As I discuss here, while infrastructure-as-code solutions seem like the perfect cloud-agnostic tool to work around this lack of interoperability, IaC doesn’t really solve this portability problem either. Notably, hyperscaler-native IaC like CloudFormation (AWS) and Bicep (Azure) were developed with particular clouds in mind, and even cloud-agnostic options like Terraform must be custom-tailored to each particular provider. As a result, theoretically cloud-neutral IaC ends up being highly cloud-specific in practice.

As IT professionals well know, the standard path to this translation work is grueling. It involves painstakingly reverse-engineering infrastructure from the source into the target cloud—and often requires separate experts in each cloud to map out the infrastructures together.

Cloud Cloning solves this translation problem—converting configuration fully from one cloud provider into another through its patented cloud mapping technology. Thus, for one representative example, it can start with an active cloud-native AWS infrastructure—using services such as EC2 instances, VPCs, subnets, security groups, Kubernetes, IAM, or databases—and convert that environment into an equivalent one in Azure or GCP. In each case, the result is workloads that retain their core functionality while adapting to the target cloud’s specific APIs, semantics, and guardrails. The result is applications that are truly multicloud, without the need to increase engineering overhead.

Importantly, Cloud Cloning reverse‑engineers IaC from the live environment to the target cloud in a way that’s fully automated, eliminating the need for remediation or other manual rework. Given that each VM destination requires its own complex, often opaque network setups and configurations, this automation can be particularly welcome. Cloud Cloning delivers these results as Terraform configurations by default.

Addressing governance needs: Finops and drift

One area where the reigning multicloud tools fall short is governance, especially in terms of finops and drift management. Let’s go through how Cloud Cloning tackles these issues, starting with finops.

How Cloud Cloning handles finops

Today, cloud finops operates on two very separate tracks: optimizations within an individual cloud and migrations from one cloud to another. Neither track serves multicloud financial operations effectively.

Within individual clouds, finops is dominated by cloud-specific tools such as AWS Cost Explorer and Compute Optimizer, Azure Cost Management and Advisor, and Google Cloud Billing and Recommender. These tools are often excellent at optimizing costs within their specific cloud, but they’re not designed to recommend what’s often the biggest cost optimization of them all: migrating elsewhere. That silence is costly, to say the least. In our experience, IT teams can save dramatically—sometimes as much as 50%—by recreating configurations in alternative clouds or even regions.

Once IT teams do decide to migrate, the target clouds’ native tools and support teams do the lion’s share of finops work. Based on prospective customers’ recent billing records, the cloud provider delivers a high-level estimate of what a comparable setup would cost in the prospective target. In theory, that’s information that customers can use to decide on and migrate to an alternative environment. But given the vast complexity outlined above, it’s not enough to know how much a new setup could cost. Teams need to see how to translate their specific architectures into the exact equivalents for the target environment. That’s information that cloud providers don’t share, and that the high-level billing information used as source data simply can’t support.

To fully optimize cloud costs, IT teams need a cloud-agnostic, detailed, and actionable view of the exact clouds and configurations where current functionality would be priced best. The good news is that Cloud Cloning provides this comprehensive view. Using the same translation techniques described earlier, Cloud Cloning allows for precise comparisons of functionality and price across clouds and environments. Plus, Cloud Cloning provides the Terraform code teams can use to automatically implement the new cloud setups they decide to go with.

In other words, Cloud Cloning takes the siloed and often murky world of cross-cloud finops, and brings it far closer to the “shop and click” comparison it ought to be.

How Cloud Cloning tackles drift

Cloud deployments and migrations involve a massive number of variables. With a dizzying array of dependencies, tools, and architectures in the mix, even the most straightforward deployment can reach complexities that are far beyond what humans can manage on their own, and each nuance can go sideways in subtle but critical ways. Given that there are really no tools to track all multi-tenancy changes within a single cloud—let alone across multiple cloud providers—keeping track of changes stands to be a losing proposition. Even with the most scrupulous devops hygiene and related best practices in play, multicloud initiatives are often rife with configuration drift that goes wholly unnoticed until something breaks. 

IaC solutions such as Terraform don’t solve the drift problem, either. After all, Terraform only works as designed if teams adopt a Terraform‑first workflow—using Terraform as the source of truth from the start, consistently updating and tracking the configuration files, and ensuring the state file accurately reflects the real environment. If teams make changes outside of Terraform or let files and state fall out of sync, Terraform can’t reliably control or predict your infrastructure. Again, given all the complexity, this is still a recipe for drift.

Cloud Cloning tackles the drift challenge based on the rich infrastructure snapshots described above. Cloud Cloning takes regular snapshots of the entire infrastructure on a customizable schedule (24 hours by default). Then, it compares these state captures against current configurations in a detailed infrastructure changelog, flagging and delivering alerts on changes that could be problematic. This includes not only standard drift issues that are focused on inventory, but also around veering from cost parameters and security controls.

From infrastructure as code to cloud-native migration tools to governance offerings, cloud portability has long suffered from major gaps and too much manual work, all of which has led to a global lock-in crisis. With so many firms looking to diversify their cloud portfolio fast, we need a better solution for cloud infrastructure migration and rearchitecting. With Cloud Cloning, we believe we have provided that solution.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

Multicloud is having a crisis. Gartner predicts that over 50% of multicloud or cross-cloud efforts won’t deliver on expected benefits by 2029, with poor interoperability and fragmentation serving as key culprits.

While these numbers don’t speak to cloud migration directly, from my own experience as an IT leader, plus from my field research in developing FluidCloud, I can tell you that multicloud disappointment and cloud migrations go hand in hand.

What causes all that frustration? To a large extent, you can blame the tools. Infrastructure migration systems propose to deliver end-to-end automation, from initial replication through ongoing governance. In reality, these applications leave huge gaps in the migration process. Instead of multicloud freedom, IT teams face a cascade of unanticipated work, expense, and friction.

The good news: To address the migration challenges, my colleagues and I have developed a new approach to cloud infrastructure portability, Cloud Cloning. In two articles here, I will outline the shortcomings of previous approaches and explain how Cloud Cloning solves the above problems. The goal is to help firms capture the multicloud promise at last.

To start, below I dive into what’s missing from the three main categories of legacy cloud infrastructure migration offerings: cloud-native tools, infrastructure as code, and governance products. In the companion article, I describe how Cloud Cloning answers these legacy issues with a wholly new approach.

Cloud-native migration tools: Built for the source, not the target

If you’re migrating to a hyperscaler, the cloud providers’ own migration offerings—such as Azure Migrate, AWS Migration Services, and Google Cloud Migrate—feel like obvious choices. Built specifically for the cloud you’re moving to, these solutions can provide excellent automation for provisioning and migration with templates, snapshots, managed services and more.

The problem is design for a specific service can also mean design for one service. These solutions are provided to facilitate migration to the clouds that provide them – ideally (from the cloud provider’s viewpoint) for a long time. They’re not designed to encourage free portability across clouds.

This design-for-stickiness includes guiding customers toward native services (such as AWS CloudFormation, Azure Cosmos DB, or GCP Firebase Authentication) that won’t run correctly elsewhere without significant rewrites to the applications built on them. The solutions also often encourage lock-in pricing—for instance, by recommending a particular infrastructure along with a three-year plan commitment to maximize savings.

To be clear, it’s arguably unfair to ask cloud providers to operate differently. After all, we can’t expect providers to offer capabilities and pricing designed to help customers move off to their competitors. But it’s also true that the customer’s goal is to work with whatever cloud is right for them, at any given time. This puts the customer and cloud provider at cross-purposes when it comes to cloud-agnostic computing—which is why, when it comes to migrations, it’s best for customers to seek out unaligned options.

Infrastructure as code tools: Automate only part of the way

With automated, version-controlled foundations to build from, infrastructure as code (IaC) solutions like Terraform and OpenTofu have earned their spot as crucial cloud migration assets. Their huge popularity is no surprise (Terraform’s AWS provider alone has topped 5.5 billion downloads).

The problem is that these solutions tend to translate infrastructure into broad terms, leaving critical small details to teams to work out on their own. This oversight can be especially problematic in areas like security policy, network load balancing, and firewall models and configurations, where small differences between one cloud and the next can be both make-or-break for migration success and extremely difficult to find. Even after using IaC, teams still must spend exorbitant amounts of time poring through plans, state files, and live resources to catch and correct these subtleties that fall through the cracks.

None of this is meant to undermine the value that infrastructure as code solutions provide. In fact, in the companion article I describe how Terraform is central to FluidCloud’s Cloud Cloning process. IaC is a powerful instrument in the migration arsenal; it’s just not reliable by itself to ensure that migrations succeed and resources behave as they should.

Governance tools: Built to find problems, not fix them

It’s unquestionable that observability and finops platforms like Datadog, New Relic, and Kubecost can be crucial in surfacing underutilized resources, performance bottlenecks, and budget overruns. The problem is that while they’re often excellent at spotting problems, most don’t guide teams to take the critical next step toward solving problems and optimizing cloud setups.

• As their name implies, observability tools are designed to observe and report on issues, not to automate solutions. For instance, they might detect high CPU usage or spot failing requests, but they won’t then launch new servers, add containers, or adjust configurations to fix the problem. It’s on customer teams to do that work.
• Finops applications, meanwhile, might alert users that a region they’re using is particularly expensive. It won’t follow up with automation to help port infrastructure over to a cheaper area, or show cost comparisons to help teams find alternative clouds to rebuild current infrastructure at a lower cost.

Governance offerings are often excellent at flagging critical issues, which is unquestionably helpful. But without automation to follow up, they’re only raising problems without offering solutions. That isn’t helpful enough.

Across these examples and classes of applications, the underlying issue is the same. The market is full of products that, in theory, turn the complex cloud migration process into something predictable and efficient. The reality is that IT teams are left with extensive “last mile work” of translating and implementing source infrastructure in the target cloud’s architecture and dependencies.

IT teams deserve a better solution. Cloud Cloning solves the problems I’ve laid out above. I explain how in this article.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

AI agents able to submit huge numbers of pull requests (PRs) to open-source project maintainers risk creating the conditions for future supply chain attacks targeting important software projects, developer security company Socket has argued.

The warning comes after one of its developers, Nolan Lawson, last week received an email regarding the PouchDB JavaScript database he maintains from an AI agent calling itself “Kai Gritun”.

“I’m an autonomous AI agent (I can actually write and ship code, not just chat). I have 6+ merged PRs on OpenClaw and am looking to contribute to high-impact projects,” said the email. “Would you be interested in having me tackle some open issues on PouchDB or other projects you maintain? Happy to start small to prove quality.”

A background check revealed that the Kai Gritun profile was created on GitHub on February 1, and within days had 103 pull requests (PRs) opened across 95 repositories, resulting in 23 commits across 22 of those projects.

Of the 103 projects receiving PRs, many are important to the JavaScript and cloud ecosystem, and count as industry “critical infrastructure.” Successful commits, or commits being considered, included those for the development tool Nx, the Unicorn static code analysis plugin for ESLint, JavaScript command line interface Clack, and the Cloudflare/workers-sdk software development kit.

Importantly, Kai Gritun’s GitHub profile doesn’t identify it as an AI agent, something that only became apparent to Lawson because he received the email.

Reputation farming

A deeper dive reveals that Kai Gritun advertises paid services that help users set up, manage, and maintain the OpenClaw personal AI agent platform (formerly known as Moltbot and Clawdbot), which in recent weeks has made headlines, not all of them good.

According to Socket, this suggests it is deliberately generating activity in a bid to be viewed as trustworthy, a tactic known as ‘reputation farming.’  It looks busy, while building provenance and associations with well-known projects. The fact that Kai Gritun’s activity was non-malicious and passed human review shouldn’t obscure the wider significance of these tactics, Socket said.

“From a purely technical standpoint, open source got improvements,” Socket noted. “But what are we trading for that efficiency? Whether this specific agent has malicious instructions is almost beside the point. The incentives are clear: trust can be accumulated quickly and converted into influence or revenue.”

Normally, building trust is a slow process. This gives some insulation against bad actors, with the 2024 XZ-utils supply chain attack, suspected to be the work of nation state, offering a counterintuitive example. Although the rogue developer in that incident, Jia Tan, was eventually able to introduce a backdoor into the utility, it took years to build enough reputation for this to happen.

In Socket’s view, the success of Kai Gritun suggests that it is now possible to build the same reputation in far less time, in a way that could help to accelerate supply chain attacks using the same AI agent technology. This isn’t helped by the fact that maintainers have no easy way to distinguish human reputation from an artificially-generated provenance built using agentic AI. They might also find the potentially large numbers of of PRs created by AI agents difficult to process.

“The XZ-Utils backdoor was discovered by accident. The next supply chain attack might not leave such obvious traces,” said Socket.

“The important shift is that software contribution itself is becoming programmable,” commented Eugene Neelou, head of AI security for API security company Wallarm, who also leads the industry Agentic AI Runtime Security and Self‑Defense (A2AS) project.  

“Once contribution and reputation building can be automated, the attack surface moves from the code to the governance process around it. Projects that rely on informal trust and maintainer intuition will struggle, while those with strong, enforceable AI governance and controls will remain resilient,” he pointed out.

A better approach is to adapt to this new reality. “The long-term solution is not banning AI contributors, but introducing machine-verifiable governance around software change, including provenance, policy enforcement, and auditable contributions,” he said. “AI trust needs to be anchored in verifiable controls, not assumptions about contributor intent.”

OpenAI has hired Peter Steinberger, creator of the viral OpenClaw AI assistant, to spearhead development of what CEO Sam Altman describes as “the next generation of personal agents.”

The move comes weeks after OpenClaw, previously known as Clawdbot and then Moltbot, achieved explosive popularity despite security researchers warning of serious vulnerabilities in the open-source tool.

Steinberger will join OpenAI full-time to drive the company’s personal agent strategy. OpenClaw will operate as an open source project under an independent foundation that OpenAI will support, Altman said on X.

“The future is going to be extremely multi-agent and it’s important to us to support open source as part of that,” Altman wrote.

The appointment is significant because OpenClaw demonstrated strong market demand for agents that can execute tasks autonomously, said Sanchit Vir Gogia, chief analyst at Greyhound Research. The project accumulated over 145,000 GitHub stars in weeks despite security concerns.

“The hiring matters because OpenClaw sits at the edge where conversational AI becomes actionable AI,” Gogia said. “It moves from drafting to doing.”

In a blog post, Steinberger said the opportunity to build agents at scale convinced him to join a large organization after years of entrepreneurship. “The vision of truly useful personal agents — ones that can help with real work, not just answer questions — requires resources and infrastructure that only a handful of companies can provide,” he wrote.

He said OpenClaw will continue evolving as an open-source project. “This isn’t an acqui-hire where a project gets shut down. I’ll still be involved in guiding its direction, just with significantly more resources behind it.”

OpenClaw gives AI models the ability to interact with desktop environments, executing actions like clicking buttons, filling forms, and navigating between applications. Unlike traditional robotic process automation tools relying on pre-programmed scripts, OpenClaw-powered agents can adapt to interface changes and make contextual decisions.

Steinberger, who founded and sold PDF toolkit company PSPDFKit to Nutrient in 2024, began OpenClaw as a weekend project in November 2025.

Orchestration over intelligence

Altman’s emphasis on multi-agent systems reflects a broader competitive shift in AI, according to analysts. The race is moving from model intelligence to runtime orchestration.

That orchestration layer, encompassing model coordination, tool invocation, persistent context management, connector standards, identity enforcement, policy controls, and human override mechanisms, is becoming the competitive battleground, Gogia said.

“What differentiates vendors now is not the existence of agents, but how they structure control,” Gogia added.

Anthropic has advanced computer use patterns in Claude, Microsoft has invested heavily in multi-agent orchestration through AutoGen and Copilot, and Google’s Project Astra points toward ambient multimodal assistance.

Deployment lags hype

Despite the competitive rush, enterprise deployment remains limited. According to Gartner research, only 8% of organizations have AI agents in production. Success rates drop sharply as agent workflows scale, with compound reliability falling below 50% after just thirteen sequential steps, even assuming 95% per-step reliability.

“It will still take a few years for AI agents to handle complex, multistep workflows,” said Anushree Verma, senior director analyst at Gartner. “Organizations would essentially need ‘an agentic brain’, something that can create, run, and manage workflows.”

Security poses another challenge. Prompt injection becomes more dangerous when agents can take actions, and agents require governance similar to privileged user accounts—including role-based permissions, audit logging, and human checkpoints for critical actions.

Currently, agents are seeing success in bounded use cases like IT ticket triage and data extraction, but struggle with cross-system workflows involving financial commitments or regulated decisions.

Open-source commitment

OpenAI’s decision to maintain OpenClaw as an open source project could help address some enterprise security concerns by allowing organizations to audit code and customize implementations. However, open-source transparency alone doesn’t eliminate enterprise requirements around security controls, support models, and accountability, according to Gogia.

Neither Altman nor Steinberger provided specifics about when agent capabilities might appear in OpenAI’s commercial products, though Altman indicated the technology would “quickly become core to our product offerings.”

Questions remain about how OpenClaw’s framework will integrate with OpenAI’s existing products and whether OpenAI will address security concerns that affected the open-source version.

We spent the better part of two decades arguing about text files. You can be forgiven for blotting that from your mind, but if you were anywhere near enterprise IT between 2000 and 2020, it’s pretty much all we talked about. GNU General Public License, Apache License, MIT License, etc., etc. That was on the vendor side. On the enterprise side, emergency meetings were held because someone found the wrong copyright header buried in a dependency three levels deep. Entire toolchains and compliance teams sprang up to answer a simple question: What are we allowed to ship?

It felt critically important at the time. In a way, it was—sort of. We were defining the rules of engagement for how software could be shared, reused, and monetized. We were trying to turn a chaotic bazaar of code into something enterprises could trust and weave into their software supply chain.

Surprise! We’re doing it again, except the “code” is no longer a library you link against. Now it is an autonomous system that can take actions on your behalf. This is why the hottest arguments in AI right now are starting to feel like déjà vu. Open weights versus proprietary. Training data provenance. Who can sue whom. Etc.

These are good questions. They just happen to be the wrong questions.

In the agentic AI era, the “license” is not a legal document. It is a technical configuration that defines what the software is allowed to do. Getting those permissions wrong has expensive, potentially destructive consequences. Getting them right…? Well, that turns out to be a very big deal.

The physics of risk

In the open source era, the worst-case scenario for getting licensing wrong was legal. If you shipped GPL code inside a proprietary product, you got a nasty letter, you settled, and you moved on. Lawyers handled it.

Agents change the physics of risk. As I’ve noted, an agent doesn’t just recommend code. It can run the migration, open the ticket, change the permission, send the email, or approve the refund. As such, risk shifts from legal liability to existential reality. If a large language model hallucinates, you get a bad paragraph. If an agent hallucinates, you get a bad SQL query running against production, or an overenthusiastic cloud provisioning event that costs tens of thousands of dollars. This isn’t theoretical. It’s already happening, and it’s exactly why the industry is suddenly obsessed with guardrails, boundaries, and human-in-the-loop controls.

I’ve been arguing for a while that the AI story developers should care about is not replacement but management. If AI is the intern, you are the manager. That is true for code generation, and it is even more true for autonomous systems that can take actions across your stack. The corollary is uncomfortable but unavoidable: If we are “hiring” synthetic employees, we need the equivalent of HR, identity access management (IAM), and internal controls to keep them in check.

All hail the control plane

This shift explains this week’s biggest news. When OpenAI launched Frontier, the most interesting part wasn’t better agents. It was the framing. Frontier is explicitly about moving beyond one-off pilots to something enterprises can deploy, manage, and govern, with permissions and boundaries baked in.

The model is becoming a component, in other words. The differentiator is the enterprise control plane wrapped around it.

The press and analyst commentary immediately reached for the same metaphor: It looks like HR for AI coworkers. Even The Verge picked up OpenAI’s language about being inspired by how enterprises scale people. Outlets covering Frontier emphasized that it is assigning identities and permissions to agents rather than letting them roam free. Then, almost on cue, OpenAI followed with Lockdown Mode, a security posture designed to reduce prompt-injection-driven data exfiltration by constraining how ChatGPT interacts with external systems.

Put those two announcements together and the industry’s direction becomes obvious. We are not racing toward “smarter assistants.” We are racing toward governable, permissioned agents that can be safely wired into systems of record. This is why I keep coming back to the same framing: We are no longer in a model race. We are in a control-plane race.

We are currently in the “Wild West” phase of agent deployment. It’s exciting, but boy, is it stressful if you’re an enterprise that wants to deploy agents safely at scale. Developers are chaining agents together with frameworks, wiring them into enterprise apps, and giving them broad scopes because it is the fastest way to get a demo working. The result isn’t just spaghetti code. It is spaghetti logic. You end up with a swarm of semi-autonomous systems passing state back and forth, with no clean audit trail of who authorized what.

This is where trust collapses, and where costs mushroom.

I have called this the AI trust tax. Every time an AI system makes a mistake that a human has to clean up, the real cost of that system goes up. The only way to lower that tax is to stop treating governance as a policy problem and start treating it as architecture. That means least privilege for agents, not just humans. It means separating “draft” from “send.” It means making “read-only” a first-class capability, not an afterthought. It means auditable action logs and reversible workflows. It means designing your agent system as if it will be attacked because it will be.

This is also why I’ve been hammering on the idea that memory is a database problem. If agent memory is effectively a state store, then it needs the same protections every state store needs: firewalls, audits, and access privileges. Agentic permissions are the natural extension of that argument. Once the agent can act, it needs privilege boundaries as rigorous as those for any database admin.

Permissions are the new copyleft

In the early 2000s, open source licenses did something brilliant. They made reuse frictionless by being standardized and widely understood. The Apache and MIT licenses reduced legal uncertainty. The GPL used legal constraints to enforce a social norm of sharing.

Now we need the equivalent for agents.

Right now, permissions are a mess of vendor-specific toggles. One platform has its own way of scoping actions. Another bolts on an approval workflow. A third punts the problem to your identity and access management team (good luck!). That fragmentation will slow adoption, not accelerate it. Enterprises can’t scale agents until they can express simple rules. We need to be able to say that an agent can read production data but not write to it. We need to say an agent can draft emails but not send them. We need to say an agent can provision infrastructure only inside a sandbox, with quotas, or that it must request human approval before any destructive action.

We need something like a “Creative Commons” for agent behavior: A standard vocabulary for agentic scopes that can travel with the agent across platforms.

Open source eventually got two things that made enterprises comfortable: licenses and the tools to inventory what they were actually using. A software bill of materials (SBOM) is the modern form of that inventory, and standards like System Package Data Exchange (SPDX) exist largely to make licensing and supply-chain tracking interoperable. The agent world needs the same move. We need a machine-readable manifest for what this agent is and what this agent can do. Call it permissions.yaml if you want. The name doesn’t matter. The portability does.

So, yes, we need a new open source, but not that kind of open source. Not the kind that has the same ol’ open source folks haggling over whether you can have open source AI, without the training data, or whatever. That’s a nice question for yesterday’s open source program office to fixate on, but it’s not relevant to where software is going today.

No, where it’s going is all about agents and the permissions that govern them. Back in 2014, I suggested we were already living in a “post–open source world.” I definitely wasn’t thinking of agents when I wrote that “software matters more than ever, but its licensing matters less and less.” I still think that’s true, though perhaps there’s still room for “licensing” discussions as we figure out how to make agents safely interoperate at scale.

Anthropic’s Model Context Protocol (MCP), coined the “USB-C for AI,” has inspired the software industry to think bigger with their AI assistants. Now, armed with access to external data and APIs, as well as to internal platforms and databases, agents are getting arms and legs to conduct impressive automation.

MCP is no longer reserved for trendy AI startups or niche software-as-a-service providers, as the major clouds have begun experimenting with adding MCP servers to their offerings to help customers automate core cloud computing operations. These MCP servers sit alongside and complement existing CLIs and APIs as a protocol for AI consumption.

Using an MCP server connected to the cloud of their choosing, engineers could improve the quality of responses of AI coding agents by providing them with cloud documentation and other highly contextual information relevant to the host cloud. But it goes further than knowledge gathering. MCP in cloud computing could be used to spin up new servers and adjust configurations, or retrieve production metadata in an instant.

The best part is that any MCP-compliant AI client should be able to interact with these servers using nothing more than natural language commands. Popular AI-powered development environments, such as Cursor, Windsurf, and Visual Studio Code, and LLM-driven AI agents, such as Claude, Codex, and GitHub Copilot, all support MCP out of the box.

Below, we’ll examine MCP servers from the major cloud providers. These officially supported remote MCP servers use your existing cloud credentials to enable authenticated API calls from AI clients. They’re free to use in the sense that no additional licensing is required, beyond the standard cloud service and data transfer costs they generate.

AWS MCP servers

Amazon Web Services (AWS) provides a suite of over 60 official MCP servers that span the wide AWS product catalog. AWS MCP servers run the gamut—from servers that provide access to documentation, to those dedicated to infrastructure and deployment, containers, Lambda functions, AI/ML frameworks, data and analytics, messaging, cost analysis, and more.

The general-purpose AWS MCP Server is the best place to start. It’s a remote server hosted by AWS that connects agents with the latest documentation, API references, and standard operating procedures (SOPs) to execute multi-step workflows. These SOPs can configure and provision infrastructure, as well as monitor and analyze cloud costs.

To consider a real-world MCP use case, take troubleshooting an error that has affected multiple AWS services. You might prompt the AWS MCP Server with a command like, “Investigate increased 5xx errors in prod over the last 30 minutes.” Paired with the right context and permissions, the AWS MCP Server will access relevant metrics, logs, and configuration data across services to surface a likely root cause.

A major benefit of AWS’s approach to MCP is that the servers are officially maintained. The catalog is both comprehensive and continuing to evolve, including a gradual migration toward Streamable HTTP, an improved transport protocol. Overall, AWS has clearly invested heavily in MCP as a foundation for agent-forward cloud operations.

Azure MCP Server

Microsoft Azure’s Azure MCP Server allows AI agents to interact with Azure services via natural language commands. Instead of providing separate MCP servers, Azure breaks its MCP server into more than 40 individual MCP tools that span Azure best practices, AI/ML services, analytics, compute, containers, databases, devops, IoT, storage, and other categories.

Using the Azure MCP Server, you can interact conversationally with Azure using prompts such as “Show me all my resource groups” or “List blobs in my storage container named ‘documents,’” according to the documentation. Other queries can list databases, enumerate Azure storage accounts, analyze large datasets in Azure databases, and perform plenty of other actions.

Azure provides an easy-to-follow getting-started guide, with a bit more hand-holding compared to AWS. The documentation clearly walks through installation, tool parameters, and settings to enable or disable agent control over sensitive functions. Each tool has solid documentation with examples of possible natural language prompts.

Google Cloud MCP servers

Google Cloud Platform (GCP) announced its official Google Cloud MCP servers in December 2025. As such, Google Cloud remote MCP servers are still in preview at the time of writing, meaning they are available “as is” with limited support. Nonetheless, Google Cloud currently provides four official remote MCP servers that are operational, spanning dataset operations, virtual machine management, Kubernetes management, and more.

For example, a natural language expression like “Get metadata details and table IDs my dataset ‘newUsers’” issued to the BigQuery MCP server would likely invoke tools like list_table_ids to list table IDs, along with get_dataset_info and get_table_info to retrieve metadata.

Alternatively, you could issue a command like “Kill my running VM in project 0009 in the east zone” to the Compute Engine MCP, which could invoke the stop_instance tool to stop the VM. Other tools support actions like deletion or resetting instances, as well as more benign commands like getting compute metadata and operational traces.

Google Cloud provides MCP servers for Google Kubernetes Engine (GKE) and Google Security Operations. Google also offers the Maps Grounding Lite MCP server, which helps developers build LLM apps on the Google Maps Platform, along with a number of other open-source servers intended for local hosting.

Similar to other cloud offerings, Google Cloud MCP servers provide controls to enable read-only or read-write functions. One unique benefit is Google’s approach to logging for all MCP interactions and access, which could help auditing for cloud administrators. Although GCP currently offers a much sparser array of MCP servers than the other hyperscalers, its MCP tools are promising for automating core cloud computing operations.

Oracle MCP servers

Oracle has a long history of providing private and public cloud options for enterprises. More recently, it has dipped a toe into MCP with a small set of MCP servers that wrap popular Oracle platforms. These servers can manage Oracle Cloud Infrastructure (OCI) and operate on Oracle databases and MySQL resources.

For example, Oracle SQLcl is the command-line interface (CLI) for Oracle Database, and its MCP server enables agents to execute queries and process results. On the Oracle blog, engineers suggest the prompt, “Connect to my fun side project and tell me about what kind of data I have there,” which invokes a list-connections tool that returns all saved Oracle connections in storage.

Other use cases for Oracle’s MCP servers include describing database schemas in plain language and generating them, analyzing MySQL usage patterns in real time, or pointing a project to existing database tables to populate data within an application.

Some of Oracle’s MCP work remains in a proof-of-concept phase, but it signals an interesting direction for combining well-established database platforms with emerging AI-driven prototyping and development workflows.

IBM Cloud MCP servers

The IBM Cloud MCP servers are experimental at the time of writing, yet they are designed to be a comprehensive knowledge-gathering layer between AI assistants and the IBM Cloud platform. They can be used to retrieve information about services within a user’s IBM Cloud computing environments.

Unlike most MCP servers on this list, which run in the cloud, IBM’s Core MCP Server is intended to be installed locally and then pointed at the IBM Cloud CLI. It’s essentially a layer over the IBM Cloud CLI. The Core MCP Server can also be containerized for fit-for-purpose needs. However, there are a few potential hindrances: the server is stateful, it is not designed for multi-account use, and it does not support OAuth.

Still, the Core MCP Server could be a user-friendly way to query IBM Cloud to discover cloud resources, retrieve extensive metadata, filter results based on strings, list service names, and more. The documentation suggests simple prompts such as “Are there any VPCs in this account?”, “What zones are available in us-east?”, and “What resource groups are in my account?”

Beyond the Core MCP Server, IBM Cloud also provides MCP servers for Cloud Internet Services (DNS, GLB, WAF, DDoS, and CDN), logs, streams, Kubernetes and OpenShift, code monitoring, object storage, serverless services, VPC, and other IBM Cloud services.

Documentation is thorough, with solid examples, and using MCP should feel natural to those already familiar with IBM’s dense CLI and API commands. However, most actions available through IBM Cloud MCP servers are read-only. For the time being, IBM’s MCP servers serve mainly as an experimental, information-gathering interface.

The cloud is your oyster

MCP has gained increasing enterprise traction in recent months, aligning with the emergence of hyperscaler support for the protocol. Used in a cloud operational context, MCP could eliminate tedious tasks like configuring fields in human-facing GUIs or manually searching through API references and product documentation.

Using the MCP servers outlined above presents an exciting prospect: a new, streamlined, AI-driven control layer for operating the hyperscale clouds. At least, that’s the goal. The reality is that it’s still early days, and many of these servers remain in an experimental or preview phase. The security models also vary significantly from server to server, and not all support mutating operations, with many defaulting to read-only modes.

Taking advantage of AI agents, MCP, and natural language to automate cloud operations will require plenty of experimentation and hands-on testing, not to mention creativity. From database lookups and resource management to provisioning, scaling, root-cause analysis, and cost optimization, it’s ultimately up to operators to decide how MCP fits into their workflows. In essence, with MCP, the cloud is your oyster. What will you do with it?

Google’s Conductor AI extension for context-driven development has been fitted with a new automated review feature intended to make AI-assisted engineering safer and more predictable.

Announced February 12, the new Automated Review feature allows the Conductor extension to go beyond planning and execution into validation, generating post-implementation reports on code quality and compliance based on defined guidelines, said Google. Conductor serves as a Gemini CLI extension designed to bring context-driven development to the developer’s terminal.

It shifts project awareness out of ephemeral chat logs and into persistent, version-controlled markdown files. Automated Review, with the new validation capability, introduces a rigorous “verify” step to the development lifecycle; once the coding agent completes its tasks, Conductor can generate a comprehensive post-implementation report.

With safety integrated into the core of every review, the Conductor extension scans for critical vulnerabilities before code is merged. High-risk issues are flagged such as hardcoded API keys, potential PII (Personally Identifiable Information) leaks, or unsafe input handling that could expose the application to injection attacks. Additional Automated Review capabilities cited include:

• Code review, where the Conductor extension acts as a peer reviewer, performing deep static and logic analysis on newly generated files.
• Plan compliance, where the system checks new code against the developer’s plan.md and spec.md files.
• Guideline enforcement, to maintain long-term code health.
• Test suite validation, integrating the entire test suite directly into the review workflow.

The enterprise world is awash in hope and hype for artificial intelligence. Promises of new lines of business and breakthroughs in productivity and efficiency have made AI the latest must-have technology across every business sector. Despite exuberant headlines and executive promises, most enterprises are struggling to identify reliable AI use cases that deliver a measurable ROI, and the hype cycle is two to three years ahead of actual operational and business realities.

According to IBM’s The Enterprise in 2030 report, a head-turning 79% of C-suite executives expect AI to boost revenue within four years, but only about 25% can pinpoint where that revenue will come from. This disconnect fosters unrealistic expectations and creates pressure to deliver quickly on initiatives that are still experimental or immature.

The way AI dominates the discussions at conferences is in contrast to its slower progress in the real world. New capabilities in generative AI and machine learning show promise, but moving from pilot to impactful implementation remains challenging. Many experts, including those cited in this CIO.com article, describe this as an “AI hype hangover,” in which implementation challenges, cost overruns, and underwhelming pilot results quickly dim the glow of AI’s potential. Similar cycles occurred with cloud and digital transformation, but this time the pace and pressure are even more intense.

Use cases vary widely

AI’s greatest strengths, such as flexibility and broad applicability, also create challenges. In earlier waves of technology, such as ERP and CRM, return on investment was a universal truth. AI-driven ROI varies widely—and often wildly. Some enterprises can gain value from automating tasks such as processing insurance claims, improving logistics, or accelerating software development. However, even after well-funded pilots, some organizations still see no compelling, repeatable use cases.

This variability is a serious roadblock to widespread ROI. Too many leaders expect AI to be a generalized solution, but AI implementations are highly context-dependent. The problems you can solve with AI (and whether those solutions justify the investment) vary dramatically from enterprise to enterprise. This leads to a proliferation of small, underwhelming pilot projects, few of which are scaled broadly enough to demonstrate tangible business value. In short, for every triumphant AI story, numerous enterprises are still waiting for any tangible payoff. For some companies, it won’t happen anytime soon—or at all.

The cost of readiness

If there is one challenge that unites nearly every organization, it is the cost and complexity of data and infrastructure preparation. The AI revolution is data hungry. It thrives only on clean, abundant, and well-governed information. In the real world, most enterprises still wrestle with legacy systems, siloed databases, and inconsistent formats. The work required to wrangle, clean, and integrate this data often dwarfs the cost of the AI project itself.

Beyond data, there is the challenge of computational infrastructure: servers, security, compliance, and hiring or training new talent. These are not luxuries but prerequisites for any scalable, reliable AI implementation. In times of economic uncertainty, most enterprises are unable or unwilling to allocate the funds for a complete transformation. As reported by CIO.com, many leaders said that the most significant barrier to entry is not AI software but the extensive, costly groundwork required before meaningful progress can begin.

Three steps to AI success

Given these headwinds, the question isn’t whether enterprises should abandon AI, but rather, how can they move forward in a more innovative, more disciplined, and more pragmatic way that aligns with actual business needs?

The first step is to connect AI projects with high-value business problems. AI can no longer be justified because “everyone else is doing it.” Organizations need to identify pain points such as costly manual processes, slow cycles, or inefficient interactions where traditional automation falls short. Only then is AI worth the investment.

Second, enterprises must invest in data quality and infrastructure, both of which are vital to effective AI deployment. Leaders should support ongoing investments in data cleanup and architecture, viewing them as crucial for future digital innovation, even if it means prioritizing improvements over flashy AI pilots to achieve reliable, scalable results.

Third, organizations should establish robust governance and ROI measurement processes for all AI experiments. Leadership must insist on clear metrics such as revenue, efficiency gains, or customer satisfaction and then track them for every AI project. By holding pilots and broader deployments accountable for tangible outcomes, enterprises will not only identify what works but will also build stakeholder confidence and credibility. Projects that fail to deliver should be redirected or terminated to ensure resources support the most promising, business-aligned efforts.

The road ahead for enterprise AI is not hopeless, but will be more demanding and require more patience than the current hype would suggest. Success will not come from flashy announcements or mass piloting, but from targeted programs that solve real problems, supported by strong data, sound infrastructure, and careful accountability. For those who make these realities their focus, AI can fulfill its promise and become a profitable enterprise asset.

Microsoft has released a beta of TypeScript 6.0, an update to the company’s strongly typed JavaScript variant that promises to be the last release based on the current JavaScript codebase. TypeScript 7.0 will debut a compiler and language service written in Go for better performance and scalability.

The TypeScript 6.0 beta was announced February 11. Developers can access it through npm by running the command npm install -D typescript@beta. A production release of TypeScript 6.0 is planned for March 17. A release candidate for TypeScript 6.0 is due February 24.

Among the key features of TypeScript 6.0 is a new flag, --stableTypeOrdering, to assist with migrations to the planned Go-based TypeScript 7.0. “As announced last year (with recent updates here), we are working on a new codebase for the TypeScript compiler and language service written in Go that takes advantage of the speed of native code and shared-memory multi-threading,” said Microsoft’s Daniel Rosenwasser, principal product manager for TypeScript, in the blog post unveiling the beta. TypeScript 6.0 will in many ways act as a bridge between TypeScript 5.9 and TypeScript 7.0, he said. “As such, most changes in TypeScript 6.0 are meant to help align and prepare for adopting TypeScript 7.0.” But there are some new features and improvements that are not just about alignment.

Also featured in TypeScript 6.0 is support for the es2025 option for both target and lib, less context sensitivity on this-less functions, and new types for Temporal, which provide standard objects and functions for working with dates and times. With the --stableTypeOrdering flag, the type ordering behavior of TypeScript 6.0 matches that of TypeScript 7.0, reducing the number of differences between the two codebases. Microsoft does not necessarily encourage using this flag all the time as it can add a substantial slowdown to type checking (up to 25% depending on the codebase).

With TypeScript 6.0’s es2025, option, the new target adds new types for built-in APIs (e.g. RegExp.escape) and moves a few declarations from esnext into es2025. With this-less functions, if this is never actually used in a function, then it is not considered contextually sensitive. That means these functions will be seen as higher priority when it comes to type inference. For Temporal, the long-awaited ECMAScript Temporal proposal has reached stage 3 and is expected to be added to JavaScript in the near future, Rosenwasser said. TypeScript 6.0 now includes built-in types for the Temporal API, so developers can start using it in TypeScript code via --target esnext or "lib": ["esnext"] or the more granular temporal.esnext.

Other new features and improvements in TypeScript 6.0:

• New types have been added for “upsert” methods. ECMAScript’s “upsert” proposal, which recently reached stage 4, introduces two new methods on Map and WeakMap. These include getOrInsert or getOrInsertComputed. These methods have been added to the esnext library so they can be used immediately in TypeScript 6.0.
• RegExp.escape, for escaping regular expression characters such as *, ?, and +, is available in the es2025 library and can be used in TypeScript 6.0 now.
• The contents of lib.dom.iterable.d.ts and lib.dom.asynciterable.d.ts are fully included in lib.dom.d.ts. TypeScript’s lib option allows developers to specify which global declarations a target runtime has.

Microsoft has made GitHub Copilot testing for .NET, a new capability in GitHub Copilot Chat that automates the testing of C# code, generally available in the just-released Visual Studio 2026 v18.3 IDE.

Microsoft announced the capability on February 11.

GitHub Copilot testing for .NET automates the creation, running, and testing of C# code for projects, files, classes, or members. It has built-in awareness of the developer’s solution structure, test frameworks, and build system and operates as an end-to-end testing workflow rather than a single-response prompt, Microsoft said. GitHub Copilot testing for .NET can generate tests for the xUnit, NUnit, and MSTest test frameworks.

When prompted with a testing request, GitHub Copilot testing generates unit tests scoped to the selected code, builds and runs the tests automatically, detects failures and attempts to fix them, and reruns the tests until a stable starting point is reached, according to Microsoft.

When test generation is completed, GitHub Copilot provides a structured summary to help developers understand what has been changed, Microsoft said. This summary includes test files and projects completed or modified, before-and-after coverage information, pass/fail signals and unstable cases, insights into testability gaps, and direct links to the generated tests for immediate review and iteration.

Additionally, GitHub Copilot testing for .NET now supports free-form prompting, making it easier for the developer to describe what to test. GitHub Copilot testing for .NET requires a paid GitHub Copilot license.

A new fine-tuning technique aims to solve “catastrophic forgetting,” a limitation that often complicates repeated model updates in enterprise deployments.

Researchers at MIT, the Improbable AI Lab, and ETH Zurich have introduced a fine-tuning method designed to let models learn new tasks while preserving previously acquired capabilities.

To prevent degrading existing capabilities, many organizations isolate new tasks into separate fine-tuned models or adapters. That fragmentation increases costs and adds governance complexity, requiring teams to continually retest models to avoid regression.

The new technique, called self-distillation fine-tuning (SDFT), is designed to address that tradeoff.

The researchers said that SDFT “leverages in-context learning by using a demonstration-conditioned model as its own teacher, generating on-policy training signals that preserve prior capabilities while acquiring new skills.”

They added that it consistently outperforms Supervised Fine Tuning (SFT) “across skill learning and knowledge acquisition tasks,” achieving higher new-task accuracy “while substantially reducing catastrophic forgetting.”

In experiments, the researchers found the method enables models to accumulate new skills sequentially while preserving performance on prior tasks, a capability that could simplify how enterprises update and specialize production models over time.

The need and the solution

Despite rapid advances in foundation models, most enterprise AI systems remain static once deployed. Prompting and retrieval can adjust behavior at inference time, but the model’s parameters do not change to internalize new skills or knowledge.

As a result, each new fine-tuning cycle risks catastrophic forgetting, where gains on a new task degrade performance on earlier ones.

“To enable the next generation of foundation models, we must solve the problem of continual learning: enabling AI systems to keep learning and improving over time, similar to how humans accumulate knowledge and refine skills throughout their lives,” the researchers noted.

Reinforcement learning offers a way to train on data generated by the model’s own policy, which reduces forgetting. However, it typically requires explicit reward functions, which are not easy in every situation.

SDFT suggests an alternative. Instead of inferring a reward function, it uses the model’s in-context learning ability to generate on-policy learning signals from demonstrations.

During training, the same model plays two roles. A teacher version is conditioned on both the query and expert examples. A student version sees only the query, reflecting real-world deployment. The student updates its parameters to align with the teacher’s predictions on its own generated outputs.

“In sequential learning experiments, SDFT enables a single model to accumulate multiple skills over time without performance regression, establishing on-policy distillation as a practical path to continual learning from demonstrations,” the researchers said.

Challenges to overcome

SDFT appears quite realistic as the technique removes the need for maintaining “model zoos” of separate adapters or fine-tuned variants, according to Lian Jye Su, chief analyst at Omdia.

However, whether this translates to commercial deployment remains to be seen as certain challenges persist.

For instance, SDFT requires significantly more training time and roughly 2.5 times the computing power of standard SFT. It also depends on sufficiently capable base models with strong in-context learning ability.

Sanchit Vir Gogia, chief analyst at Greyhound Research, also warned that SDFT does not eliminate the need for regression infrastructure. Because the model learns from its own generated rollouts, enterprises must ensure reproducibility through strict version control and artifact logging.

“Consolidation shifts operational complexity from model count to governance depth,” Gogia said.

The costs can be offset, according to Su, by avoiding catastrophic forgetting of key context and complex reward functions in reinforcement learning. But it may be a while before this reaches enterprises. “SDFT will most likely be experimented with first for internal developer tools and general assistants where the risk of a ‘self-taught error’ will be lower than in regulated domains like financial or medical decision-making,” said Faisal Kawoosa, founder and lead analyst at Techarc.

Go 1.26 has been released. The latest version of the Google-built programming language enables the higher performing Green Tea garbage collector (GC) by default. It also introduces a change to generic types that simplifies the implementation of complex data structures.

Introduced February 10, Go 1.26 can be downloaded from go.dev.

The Green Tea GC, included as an experimental feature in last year’s Go 1.25, brings a 10% to 40% reduction in garbage collection overhead in real-world programs that make heavy use of garbage collection, the Go team said. This is because it improves the performance of marking and scanning small objects through better locality and CPU scalability, according to the team. Further improvements are expected in GC overhead on the order of 10% when running on newer AMD64-based CPU platforms. For the cautious, the Green Tea GC can by disabled by setting GOEXPERIMENT=nogreenteagc at build time. This opt-out setting is expected to be removed in Go 1.27.

Generic types in Go 1.26 now may refer to themselves in their own type parameter list. This change simplifies implementation of complex data structures and interfaces, the Go team said. The newfunction, which creates a new variable, now allows its operand to be an expression, specifying the initial value of the variable. And the go fix command now is the home of Go’s modernizers, providing a push-button way to update Go codebases to the latest idioms and core library APIs. And the baseline runtime overhead of cgo calls has been reduced by about 30%.

Also in Go 1.26:

• The compiler can allocate the backing store for slices on the stack in more situations, thus improving performance.
• For WebAssembly applications, the runtime now manages chunks of heap memory in smaller increments, leading to significantly reduced memory usage for applications with heaps less than around 16 MiB in size.
• On 64-bit platforms, the runtime now randomizes the heap base address at startup. This a security enhancement that makes it harder for attackers to predict memory addresses and exploit vulnerabilities when using cgo, the Go team said.
• An experimental profile type named goroutineleak reports leaked goroutines. Look for it in the runtime/pprof package.
• An experimental simd/archsimd package provides access to architecture-specific SIMD operations.
• Go 1.26 is the last release to run on macOS 12 Monterey. Go 1.27 will require macOS 13 Ventura or later.

Signals is a simple idea with massive power. In one fell swoop, Signals provides reactivity while keeping state simple, even in large applications. That’s why the Signals pattern has been adopted for inclusion in Solid, Svelte, and Angular.

This article introduces Signals and demonstrates its fresh approach to state management, bringing new life to the JavaScript front end.

Introducing the Signals pattern

The Signals pattern was first introduced in JavaScript’s Knockout framework. The basic idea is that a value alerts the rest of the application when it changes. Instead of a component checking its data every time it renders (as in React‘s pull model), a signal “pushes” the update to exactly where it is needed.

This is a pure expression of reactivity, sometimes called “fine-grained” reactivity. It is almost magical how individual signals can update the output of a value without requiring any intervention from the developer.

The “magic” is really just an application of functional programming, but it has big benefits for an application architecture. The Signals pattern eliminates the need for complex rendering checks in the framework engine. Even more importantly, it can simplify state management by providing a universal mechanism that can be used anywhere, even across components, eliminating the need for centralized stores.

Before Signals: The virtual DOM

To understand why signals are such a breath of fresh air, we can start by looking at the dominant model of the last decade: The Virtual DOM (VDOM), popularized by React.

The VDOM is an abstract DOM that holds a version in memory. When application state changes, the framework re-renders the component tree in memory, compares it to the previous version (a process called diffing), then updates the actual DOM with the differences.

While this makes UI development declarative and predictable, it introduces a cost. The framework does significant work just to determine what hasn’t changed. This is compounded by data-heavy components like lists and trees. And, as applications grow larger, this diffing overhead adds up. Developers then resort to complex optimization techniques (like memoization) in an effort to keep the engine from overworking.

Fine-grained reactivity

State management via VDOM implies repeatedly walking a tree data structure in memory. Signals side-steps this entirely. By using a dependency graph, Signals changes the unit of reactivity. In a VDOM world, the unit is the component, whereas with Signals, the unit is the value itself.

Signals is essentially an observer pattern where the observers are automatically enrolled. When a view template reads an individual signal, it automatically subscribes to it. This creates a simple, direct link between the data and the specific text node or attribute that displays it. When the signal changes, it notifies only those exact subscribers.

This is a point-to-point update. The framework doesn’t need to walk a component tree or determine what changed. This shifts the performance characteristic from O(n) (where n is tree size) to O(1) (immediate, direct update).

Hands-on with Signals

The best way to understand the benefits of Signals is to see the pattern in action. When developing application components, the difference between using Signals and a more traditional VDOM approach is, at first, almost invisible. Here’s React handling a simple state instance:

function Counter() {
  const [count, setCount] = useState(0);
  const double = count * 2;

  return (
     setCount(count + 1)}>
      {count} doubled is {double}
    
  );
}

Now consider the same idea in Svelte using individual signals with the Runes syntax:

 count += 1}>
  {count} doubled is {double}

In both cases, you have a reactive value (count) and a value that is dependent on it (double). They both do the same thing. To see the difference, you can add a console log to them. Here’s the log with React:

export default function Counter() {
  const [count, setCount] = useState(0);
  const double = count * 2;

  console.log("Re-evaluating the world...");

  return (
     setCount(count + 1)}>
      Count is {count}, double is {double}
    
  );
}

Every time the component mounts, or updates, the console will output this line of logging. But now look at the same log from Svelte:

 count += 1}>
  Count is {count}, double is {double}

In this case, the console logging happens only once, when the component mounts.

At first, this seems impossible. But the trick is, the signal just directly connects the value to its output, with no need to invoke the surrounding JavaScript that created it. The component does not need to be re-evaluated. The signal is a portable unit of reactivity.

How Signals eliminates dependent values

Another important result of using signals is how we manage side-effects. In React, we have to declare the dependent values. These are the parameters we pass to useEffect. This is a common area of complaint in terms of developer experience (DX) because it is an additional relationship to manage. Over time, this can lead to mistakes (like forgetting to add a value) and may otherwise impact performance. As an example, consider what happens when there are many values:

useEffect(() => {
  console.log(`The count is now ${count}`);
}, [count]);

Passing the same job with signals eliminates the dependent values:

effect(() => {
  console.log(`The count is now ${count()}`);
});

In this case, we’ve used Angular syntax, but it’s similar across other frameworks that use signals. Here’s the same example with Solid:

createEffect(() => {
  console.log(count());
});

The end of ‘prop drilling’

Using the Signals pattern for state management also impacts application design. We can see it most readily in the way we have to pass properties down the component tree, from parent to child, when we need to share state:

// In React, sharing state can mean passing it down...
function Parent() {
  const [count, setCount] = useState(0);
  return ;
}

function Child({ count }) {
  // ...and down again...
  return ;
}

function GrandChild({ count }) {
  // ...until it finally reaches the destination.
  return 
{count}
;
}

The impact will also show up in centralized stores like Redux, which strive to reduce complexity sprawl but often seem to add to the problem. Signals eliminates both issues by making a centralized state simply another JavaScript file you create and import in the components. For example, here’s how a shared state module might look in Svelte:

// store.svelte.js
// This state exists independently of the UI tree.
export const counter = $state({
  value: 0
});

// We can even put shared functions in here
export function increment() {
  counter.value += 1;
}

Using this is just normal JavaScript:

  Click Me

Toward a Signals standard?

Historically, successful patterns that start out in libraries or individual frameworks often migrate into the language. Just think of how jQuery’s selectors influenced document.querySelector, or how Promises became part of the JavaScript standard.

Now, we are seeing it happen again with Signals. There is currently a proposal (TC39) to add signals directly to JavaScript. The goal isn’t to replace how frameworks work, but to provide a standard format for reactivity, which frameworks can then adopt.

Imagine defining a signal in a vanilla JavaScript file and having it drive a React component, a Svelte template, and an Angular service simultaneously. If adopted, this would move state management from a framework concern to a language concern—a big win for simplicity. Of course, it’s only a win if it goes well and doesn’t just spawn another way to do things.

Conclusion

For a long time, JavaScript developers have accepted a tradeoff in front-end development, exchanging the raw performance of direct DOM manipulation for the declarative ease of the Virtual DOM. We accepted the overhead because it made applications easier to manage.

Signals offers a way to grow beyond that compromise. While the roots of the pattern go back to the early days of the web, credit is due to Ryan Carniato and Solid.js for proving that fine-grained reactivity could outperform the VDOM in the modern era. Their success sparked a movement that has now spread to Angular, Svelte, and possibly the JavaScript language itself.

Signals gives JavaScript developers a declarative experience by defining state and letting the UI react to it, but with the surgical performance of direct updates. Returning to a push model, versus the pull model we’ve come to accept, lets us do more with less code. And with that, it may be the quest for simplicity in JavaScript is finally gaining traction.

Neoclouds are specialized clouds devoted to the wildly dynamic world of artificial intelligence, currently experiencing explosive 35.9% annual growth. Built from the ground up to meet AI’s significant computational demands, neoclouds first emerged several years ago. Dozens of providers have arrived since then, with CoreWeave, Crusoe, Llambda, Nebius, and Vultr among the neocloud leaders.

The ”neo” in neoclouds serves to distinguish them from the more established cloud providers such as AWS, Google Cloud, and Microsoft Azure, whose multitude of options for infrastructure, managed services, and applications imply that cloud providers must offer an endless aisle of choices. The hyperscalers were first to support AI workloads, too, but it was a retrofitted option on an existing platform rather than a clean slate implementation built for purpose.

Neoclouds have one job: provide an optimal home for AI. Most obviously, that means neoclouds feature GPU-first computing, typically available at a price-per-hour less than half that of the hyperscalers. Neoclouds also offer high-bandwidth networking, low-latency storage, advanced power management, and managed services for deploying, monitoring, maintaining, and securing AI workloads. These capabilities are offered through a more streamlined and easy to use surface, unencumbered by traditional non-AI features.

In contrast to the cookie-cutter options offered by the hyperscalers, neoclouds take a boutique approach, responding to the special requirements and evolving needs of customers—including customers that push the envelope of AI development. That flexibility is a key reason why an increasing number of AI startups, enterprises, researchers, and independent developers are choosing neoclouds as their AI platform of choice.

Choosing the best configuration

The best neoclouds offer a wide range of hardware choices plus skilled guidance for customers about which GPU, memory, networking and storage options best suit which AI tasks. That advice is based on deep AI engineering experience, but a few general principles apply. If you were planning on training your own large language model (LLM), for example, you’d need the highest-end configuration available—at this writing, probably NVIDIA GB200 Grace Blackwell GPUs with 186GBs VRAM each.

But today, vanishingly few players beyond such monster AI providers as Anthropic, OpenAI, Google, or Meta train their own LLMs. Fine-tuning LLMs that have already been trained, which typically includes augmenting them with additional data, is far more prevalent and requires far less horsepower. The same goes for LLM post-training and reinforcement learning. And the processing required for inference alone—that is, running LLMs that have already been trained and tuned—is again far less demanding.

It’s worth noting that massive consumer adoption of LLM chatbots has obscured the fact that AI covers a very wide range—including video generation, computer vision, image classification, speech recognition, and much more. Plus, small language models for such applications as code completion, customer service automation, and financial document analysis are becoming increasingly popular. To choose configurations that match AI tasks, neocloud customers must either come in the door with bona fide AI engineering skills or rely on the options and guidance offered by neocloud  providers.

Managed AI services

Most added-value neocloud services center on maximizing inference performance, with ultra-low latency and seamless scaling. A key performance metric is TTFT (time to first token), which measures how long it takes for an LLM to generate and return the first word of its response after receiving a prompt.

No surprise, then, that one of the most competitive areas is optimization of a neocloud’s inference engine to reduce TTFT times, as well as to sustain overall throughput. AI agents cannot afford to return 429 errors, rate-limiting responses that frustrate users by indicating the maximum number of server requests has been exceeded.

A number of infrastructure-level techniques can keep AI results flowing. Sophisticated caching schemes can queue up local and remote nodes to provide nearly instantaneous results. Continuous batching reduces request wait times and maximizes CPU utilization. And a technique known as quantization deliberately reduces the precision of model weights post-training to increase memory utilization with no discernible effect on the accuracy of results. As workload sizes increase, the best neoclouds scale up to meet demand automatically, offering flexible token-based pricing to keep costs manageable.

Although still less expensive than the AI infrastructure offerings of the hyperscalers, the high end for neoclouds tends to be on-demand pricing per hour of GPU time. But some neoclouds now also offer so-called serverless pricing, where customers pay per token generated. The latter can decrease costs dramatically, as can spot pricing offered by neoclouds that temporarily have unused GPU capacity (ideal for fault-tolerant workloads that may experience fluctuating performance).

Increasingly, neocloud providers also offer predeployed open source LLMs such as Kimi-K2, Llama, Gemma, GPT-OSS, Qwen, and DeepSeek. This accelerates model discovery and experimentation, allowing users to generate API keys in minutes. More advanced neocloud providers tune their inference engines to each model for maximum optimization. A single pane of glass for inference performance metrics as well as model provisioning and management is highly desirable.

Ultimately, the idea is to provide infrastructure as a service specifically for AI, without all the application-layer stuff the hyperscalers have larded onto their platforms. The extensive automation, self-service configuration, and array of options are all tailor made for AI.

Solving the cost equation

Today, enterprises still tend to be in the experimental phase when it comes to running their own AI models. That’s why the majority of neocloud customers are AI natives—a mix of specialized AI providers offering everything from code generation tools to video generation to vertical solutions for health care, legal research, finance, and marketing.

Cost is critical for such providers, which is why neoclouds’ ability to offer AI infrastructure for far less than the hyperscalers is so attractive. Pricing models tailored to customer needs provide additional advantages.

But AI natives that need consistent performance at very low cost typically negotiate long-term contracts with neoclouds stretching months or years. These providers’ entire businesses are dependent on AI and rely on having high-quality inference without interruption. Agreements often include managed inference services as well as reliable, low-latency storage for massive data sets and high-throughput model training.

Reliability and security

As with any cloud, neoclouds must offer enterprise-grade reliability and security. One reason to opt for one of the neocloud leaders is that they’re more likely to have geographically distributed data centers that can provide redundancy when one location goes offline. Power redundancy is also critical, including uninterruptible power supplies and backup generators.

Neocloud security models are less complex than those of the hyperscalers. Because the bulk of what neoclouds offer is AI-specific infrastructure, business customers may be better served to think in terms of bringing neocloud deployments into their own security models. That being said, neoclouds must offer data encryption at rest as well as in transit, with the former supporting ephemeral elliptic curve Diffie-Hellman cryptographic key exchange signed with RSA and ECDSA. Also look for the usual certifications: SOC 2 Type I, SOC 2 Type II, and ISO 27001.

Neoclouds provide an environment that enables you to deploy distributed workloads, monitor them, and benefit from a highly reliable infrastructure where hardware failures are remediated transparently, without affecting performance. The result is better reliability, better observability, and better error recovery, all of which are essential to delivering a consistent AI customer experience.

The neocloud choice

We live in a multicloud world. When customers choose a hyperscale cloud, they’re typically attracted by certain features or implementations unavailable in the same form elsewhere. The same logic applies to opting for a neocloud: It’s a decision to use the highest-performing, most flexible, most cost-effective platform for running AI workloads.

The neocloud buildout can barely keep up with today’s AI boom, with new agentic workflows revolutionizing business processes and so called “AI employees” on the verge of coming online. The potential of AI is immense, offering unprecedented opportunities for innovation.

A recent McKinsey report estimated that by 2030, roughly 70% of data center demand will be for data centers equipped to host advanced AI workloads. No doubt a big chunk of that business will continue to go to the hyperscalers. But for customers who need to run high-performance AI workloads cost-effectively at scale, or who have needs that can’t be met by the hyperscalers’ prefab options, neoclouds provide a truly purpose-built solution.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

Microsoft has released .NET 11 Preview 1, a planned update to the cross-platform software development platform that features JIT performance improvements, faster compression, CoreCLR support onWebAssembly, and a host of other capabilities.

Unveiled February 10,  the preview can be downloaded from dotnet.microsoft.com. Improvements cover areas ranging from the runtime and libraries to the SDK, the C# and F# languages, ASP.NET Core and Blazor, and .NET MAUI (Multi-platform App UI). Changes to the JIT compiler focus on improving startup throughput, enabling more optimizations, and reducing overhead in key code patterns. The enhancements include raising the multicore JIT MAX_METHODS limit to better support large workloads and improve startup throughput in method-heavy apps. Also, non-shared generic virtual methods are de-virtualized to reduce virtual-call overhead and enable further inlining/optimization opportunities. The JIT also generalizes pattern-based induction-variable (IV) analysis to enable more loop analysis cases, opening the door to more loop optimizations, according to Microsoft.

Additionally in .NET 11, initial work has been done to bring CoreCLR support to WebAssembly, although this feature is not yet ready for general release in Preview 1. As part of this work, .NET 11 Preview 1 begins bringing up a Wasm-targeting RyuJit that will be used for AOT compilation. .NET WebAssembly is being migrated from the Mono runtime to CoreCLR.

Zstandard compression support in .NET libraries in .NEt 11 means significantly faster compression and decompression compared to existing algorithms while maintaining competitive compression ratios. New APIs include a full set of streaming, one-shot, and dictionary-based compression and decompression capabilities. Also featured is a per-year cache for time zone transitions, improving performance for time conversions. The cache stores all transitions for a given year in UTC format, eliminating repeated rule lookups during conversions.

C# 15 in .NET 11 Preview 1 introduces collection expressions arguments, a feature that supports scenarios where a collection expression does not produce the desired collection type. Collection expression arguments enable developers to specify capacity, comparers, or other constructor parameters directly within the collection expression syntax. C# 15 also brings extended layout support, by which the C# compiler emits the TypeAttributes.ExtendedLayout for types that have the System.Runtime.InteropServices.ExtendedLayoutAttribute applied. This feature is primarily intended for the .NET runtime team to use for types in interop scenarios.

With F# 11 in .NET 11 Preview 1, the F# compiler has parallel compilation enabled by default and features faster compilation of computation expression-heavy code. ML compatibility has been removed, though. The keywords asr, land, lor, lsl, lsr, and lxor — previously reserved for ML compatibility — are now available as identifiers. Microsoft said that F# began its life as an OCaml dialect running on .NET, and for more than two decades, the compiler carried compatibility constructs from that heritage including .ml and .mli source file extensions, the #light "off" directive for switching to whitespace-insensitive syntax, and flags like --mlcompatibility. These served the language well during its early years, providing a bridge for developers coming from the ML family, the company said, but that chapter comes to a close. About 7,000 lines of legacy code have been removed across the compiler, parser, and test suite.

.NET 11 follows the November 2025 release of .NET 10, which brought AI, language, and runtime improvements. Other features touted for .NET 11 include the following:

• Runtime async introduces new runtime-level infrastructure for async methods. The goal is to improve tools and performance for async-heavy codepaths.
• CoreCLR is now the default runtime for Android Release builds. This should improve compatibility with the rest of .NET as well as reduce startup times, Microsoft said.
• CLI command improvements in the SDK include dotnet run being enhanced to support interactive selection workflows, laying the foundation for improved .NET MAUI and mobile development scenarios.
• The Blazor web framework adds an EnvironmentBoundary component for conditional rendering based on the hosting environment. This component is similar to the MVC environment tag helper and provides a consistent way to render content based on the current environment across both server and WebAssembly hosting models, Microsoft said.
• XAML source generation is now the default in .NET 11 for all .NET MAUI applications, improving build times, debug performance, and release runtime performance. Debug build app behavior is consistent with release build app behavior, according to Microsoft.

As enterprises shift from experimenting with AI agents to deploying them in production environments, Google is rolling out a structured skills program aimed at helping developers build, test, and operationalize AI agents using Google Cloud tools, specifically its Agent Development Kit (ADK).

Named the Gemini Enterprise Agent Ready (GEAR) program, the initiative packages hands-on labs, 35 free monthly recurring Google Skills credits, and badge-earning pathways into a track within the Google Developer Program.

Currently, the pathways available include “Introduction to Agents” and “Develop Agents with Agent Development Kit (ADK),” which are targeted at helping developers understand the anatomy of an agent, how they integrate with Gemini Enterprise workflows, and how to build an agent using ADK.

These pathways will enable developers learn a new set of practical engineering skills to succeed in real business environments, Google executives wrote in a blog post.

They contend that by embedding GEAR within the Google Developer Program and Google Skills, developers can experiment without cost barriers and systematically learn how to build, test, and deploy agents at scale.

This, in turn, helps enterprises accelerate the transition from isolated AI pilots to operational solutions that generate measurable value across production workflows, they wrote.

The difficulty of moving AI from pilot to production is well documented: Deloitte’s 2026 State of AI in the Enterprise report found that only about 25 % out of 3,200 respondents said that their enterprises have moved only 40 % of their AI pilots into production.

Rival hyperscalers, too, offer similar programs.

While Microsoft runs structured AI learning paths and certifications via Microsoft Learn tied to Azure AI, AWS provides hands-on labs and training through AWS Skill Builder with AI/ML and generative AI tracks.

Beyond skills development, however, these initiatives seem to be closely tied to broader platform strategies and Google’s rollout of GEAR can also be read as part of a broader strategy to cement Gemini Enterprise’s role as a competitive agent development platform at a time when hyperscalers are all vying to own the enterprise agent narrative.

Microsoft’s stack — including Azure OpenAI Service, Azure AI Studio, and Copilot Studio — has been actively positioning itself as an agent orchestration and workflow automation hub.

Similarly, AWS is pushing Bedrock Agents as part of its foundation model ecosystem.

Others, such as Salesforce and OpenAI, are also in on the act. While Salesforce markets its Agentforce suite embedded in CRM workflows, OpenAI’s Assistants API is being positioned as a flexible agent layer.

For more than two decades, IT operations has been dominated by a reactive culture. Engineers monitor dashboards, wait for alerts to fire and respond once systems have already begun to degrade. Even modern observability platforms equipped with distributed tracing, real-time metrics and sophisticated logging pipelines still operate within the same fundamental paradigm: something breaks, then we find out.

But the digital systems of today no longer behave in ways that fit this model. Cloud-native architectures built on ephemeral micro services, distributed message queues, serverless functions and multi-cloud networks generate emergent behavior far too complex for retrospective monitoring to handle. A single mis-tuned JVM flag, a slightly elevated queue depth or a latency wobble in a dependency can trigger cascading failure conditions that spread across dozens of micro services in minutes.

The mathematical and structural complexity of these systems has now exceeded human cognitive capacity. No engineer, no matter how experienced, can mentally model the combined state, relationships and downstream effects of thousands of constantly shifting components. The scale of telemetry alone, billions of metrics per minute, makes real-time human interpretation impossible.

This is why reactive IT is dying and this is why predictive engineering is emerging, not as an enhancement, but as a replacement for the old operational model.

Predictive engineering introduces foresight into the infrastructure. It creates systems that do not just observe what is happening; they infer what will happen. They forecast failure paths, simulate impact, understand causal relationships between services and take autonomous corrective action before users even notice degradation. It is the beginning of a new era of autonomous digital resilience.

Why reactive monitoring is inherently insufficient

Reactive monitoring fails not because tools are inadequate, but because the underlying assumption that failures are detectable after they occur no longer holds true.

Modern distributed systems have reached a level of interdependence that produces non-linear failure propagation. A minor slowdown in a storage subsystem can exponentially increase tail latencies across an API gateway. A retry storm triggered by a single upstream timeout can saturate an entire cluster. A microservice that restarts slightly too frequently can destabilize a Kubernetes control plane. These are not hypothetical scenarios, they are the root cause of the majority of real-world cloud outages.

Even with high-quality telemetry, reactive systems suffer from temporal lag. Metrics show elevated latency only after it manifests. Traces reveal slow spans only after downstream systems have been affected. Logs expose error patterns only once errors are already accumulating. By the time an alert triggers, the system has already entered a degraded state.

The architecture of cloud systems makes this unavoidable. Auto scaling, pod evictions, garbage collection cycles, I/O contention and dynamic routing rules all shift system state faster than humans can respond. Modern infrastructure operates at machine speed; humans intervene at human speed. The gap between those speeds is growing wider every year.

The technical foundations of predictive engineering

Predictive engineering is not marketing jargon. It is a sophisticated engineering discipline that combines statistical forecasting, machine learning, causal inference, simulation modeling and autonomous control systems. Below is a deep dive into its technical backbone.

Predictive time-series modeling

Time-series models learn the mathematical trajectory of system behavior. LSTM networks, GRU architectures, Temporal Fusion Transformers (TFT), Prophet and state-space models can project future values of CPU utilization, memory pressure, queue depth, IOPS saturation, network jitter or garbage collection behavior often with astonishing precision.

For example, a TFT model can detect the early curvature of a latency increase long before any threshold is breached. By capturing long-term patterns (weekly usage cycles), short-term patterns (hourly bursts) and abrupt deviations (traffic anomalies), these models become early-warning systems that outperform any static alert.

Causal graph modeling

Unlike correlation-based observability, causal models understand how failures propagate. Using structural causal models (SCM), Bayesian networks and do-calculus, predictive engineering maps the directionality of impact:

• A slowdown in Service A increases the retry rate in Service B.
• Increased retries elevate CPU consumption in Service C.
• Elevated CPU in Service C causes throttling in Service D.

This is no longer guesswork, it is mathematically derived causation. It allows the system to forecast not just what will degrade, but why it will degrade and what chain reaction will follow.

Digital twin simulation systems

A digital twin is a real-time, mathematically faithful simulation of your production environment. It tests hypothetical conditions:

• “What if a surge of 40,000 requests hits this API in 2 minutes?”
• “What if SAP HANA experiences memory fragmentation during period-end?”
• “What if Kubernetes evicts pods on two nodes simultaneously?”

By running tens of thousands of simulations per hour, predictive engines generate probabilistic failure maps and optimal remediation strategies.

Autonomous remediation layer

Predictions are pointless unless the system can act on them. Autonomous remediation uses policy engines, reinforcement learning and rule-based control loops to:

• Pre-scale node groups based on predicted saturation
• Rebalance pods to avoid future hotspots
• Rarm caches before expected demand
• Adjust routing paths ahead of congestion
• Modify JVM parameters before memory pressure spikes
• Ppreemptively restart micro services showing anomalous garbage-collection patterns

This transforms the system from a monitored environment into a self-optimizing ecosystem.

Predictive engineering architecture

To fully understand predictive engineering, it helps to visualize its components and how they interact. Below are a series of architecture diagrams that illustrate the workflow of a predictive system:

DATA FABRIC LAYER

┌──────────────────────────────────────────────────────────┐

 │ Logs | Metrics | Traces | Events | Topology | Context    │

└───────────────────────┬──────────────────────────────────┘

                                                              ▼

FEATURE STORE / NORMALIZED DATA MODEL

┌──────────────────────────────────────────────────────────┐

 │ Structured, aligned telemetry for advanced ML modeling   │

└──────────────────────────────────────────────────────────┘

                                                               ▼

PREDICTION ENGINE

 ┌────────────┬──────────────┬──────────────┬──────────────┐

 │ Forecasting │ Anomaly      │ Causal       │ Digital Twin │

 │ Models      │ Detection    │ Reasoning    │ Simulation   │

 └────────────┴──────────────┴──────────────┴──────────────┘

                                                     ▼

 REAL-TIME INFERENCE LAYER

 (Kafka, Flink, Spark Streaming, Ray Serve)

                                                      ▼

AUTOMATED REMEDIATION ENGINE

•  Autoscaling
• Pod rebalancing
• API rate adjustment
• Cache priming
• Routing optimization

                                                       ▼

CLOSED-LOOP FEEDBACK SYSTEM

This pipeline captures how data is ingested, modeled, predicted and acted upon in a real-time system.

Reactive vs predictive lifecycle

Reactive IT:

Event Occurs → Alert → Humans Respond → Fix → Postmortem

Predictive IT:

Predict → Prevent → Execute → Validate → Learn

Predictive Kubernetes workflow

   Metrics + Traces + Events

              │

              ▼

Forecasting Engine

(Math-driven future projection)

              │

              ▼

 Causal Reasoning Layer

(Dependency-aware impact analysis)

              │

              ▼

 Prediction Engine Output

“Node Pool X will saturate in 25 minutes”

              │

              ▼

Autonomous Remediation Actions

•  Pre-scaling nodes
• Pod rebalancing
• Cache priming
• Traffic shaping

              │

             ▼

       Validation

The future: Autonomous infrastructure and zero-war-room operations

Predictive engineering will usher in a new operational era where outages become statistical anomalies rather than weekly realities. Systems will no longer wait for degradation, they will preempt it. War rooms will disappear, replaced by continuous optimization loops. Cloud platforms will behave like self-regulating ecosystems, balancing resources, traffic and workloads with anticipatory intelligence.

In SAP environments, predictive models will anticipate period-end compute demands and autonomously adjust storage and memory provisioning. In Kubernetes, predictive scheduling will prevent node imbalance before it forms. In distributed networks, routing will adapt in real time to avoid predicted congestion. Databases will adjust indexing strategies before query slowdowns accumulate.

The long-term trajectory is unmistakable: autonomous cloud operations.

Predictive engineering is not merely the next chapter in observability, it is the foundation of fully self-healing, self-optimizing digital infrastructure.

Organizations that adopt this model early will enjoy a competitive advantage measured not in small increments but in orders of magnitude. The future of IT belongs to systems that anticipate, not systems that react.

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

Dedicated desktop applications for agentic AI make it easier for relatively non-technical users to work with large language models. Instead of writing Python programs and wrangling models manually, users open an IDE-like interface and have logged, inspectable interactions with one or more LLMs.

Amazon and Google have released such products with a focus on AI-assisted code development—Kiro and Antigravity, respectively. Both products offer the option to run models locally or in cloud-hosted versions.

LM Studio by Element Labs provides a local-first experience for running, serving, and working with LLMs. It’s designed for more general conversational use rather than code-development tasks, and while its feature set is still minimal, it’s functional enough to try out.

Set up your models

When you first run LM Studio, the first thing you’ll want to do is set up one or more models. A sidebar button opens a curated search panel, where you can search for models by name or author, and even filter based on whether the model fits within the available memory on your current device. Each model has a description of its parameter size, general task type, and whether it’s trained for tool use. For this review, I downloaded three different models:

• GLM 4.7 Flash by Z.ai
• Nemotron 3 Nano by NVIDIA
• GPT-OSS, the 20B version of OpenAI’s open source model

Downloads and model management are all tracked inside the application, so you don’t have to manual wrangle model files like you would with ComfyUI.

Foundry

Conversing with an LLM

To have a conversation with an LLM, you choose which one to load into memory from the selector at the top of the window. You can also finetune the controls for using the model—e.g., if you want to attempt to load the entire model into memory, how many CPU threads to devote to serving predictions, how many layers of the model to offload to the GPU, and so on. The defaults are generally fine, though.

Conversations with a model are all tracked in separate tabs, including any details about the model’s thinking or tool integrations (more on these below). You also get a running count of how many tokens are used or available for the current conversation, so you can get a sense of how much the conversation is costing as it unfolds. If you want to work with local files (“Analyze this document for clarity”), you can just drag and drop them into the conversation. You can also grant the model access to the local file system by way of an integration, although for now I’d only do that with great care and on a system that did not include mission-critical information.

Foundry

Integrations

LM Studio lets you add MCP server applications to extend agent functionality. Only one integration is included by default—a JavaScript code sandbox that allows the model to run JavaScript or TypeScript code using Deno. It would have been useful to have at least one more integration to allow web search, though I was able to add a Brave search integration feature with minimal work.

The big downside with integrations in LM Studio is that they are wholly manual. There is currently no automated mechanism for adding integrations, and there’s no directory of integrations to browse. You need to manually edit a mcp.json file to describe the integrations you want and then supply the code yourself. It works, but it’s clunky, and it makes that part of LM Studio feel primitive. If there’s anything that needs immediate fixing, it’s this.

Despite these limits, the way MCP servers are integrated is well-thought-out. You can disable, enable, add, or modify such integrations without having to close and restart the whole program. You can also whitelist the way integrations work with individual conversations or the entire program, so that you don’t have to constantly grant an agent access. (I’m paranoid, so I didn’t enable this.)

Using APIs to facilitate agentic behavior

LM Studio can also work as a model-serving system, either through the desktop app or through a headless service. Either way, you get a REST API that lets you work with models and chat with them, and get results back either all at once or in a progressive stream. A recently added Anthropic-compatible endpoint lets you use Claude Code with LM Studio. This means it’s possible to use self-hosted models as part of a workflow with a code-centric product like Kiro or Antigravity.

Another powerful feature is tool use through an API endpoint. A user can write a script that interacts with the LM Studio API and also supplies its own tool. This allows for complex interactions between the model and the tool—a way to build agentic behaviors from scratch.

Foundry

Conclusion

LM Studio’s clean design and convenience features are a good start, but many key features are missing. Future releases could focus on adding salient features.

Tool integration still requires cobbling things together manually, and there is no mechanism for browsing and downloading from a curated tools directory. The included roster of tools is also extremely thin—as an example, there isn’t an included tool for web browsing and fetching.

Another significant issue is that LM Studio isn’t open source even though some of its components are—such as its command-line tooling. The licensing for LM Studio allows for free use, but there’s no guarantee that will always be the case. Nonetheless, even in this early incarnation, LM Studio is useful for those who have the hardware and the knowledge to run models locally.