Red Hat OpenShift 4.20, the latest version of Red Hat’s Kubernetes-based hybrid cloud application platform, is now available. The Red Hat OpenShift 4.20 release features capabilities for accelerating AI workloads and strengthening security, according to Red Hat.

Introduced November 11, OpenShift 4.20 can be accessed from the Red Hat OpenShift product page. For AI, new capabilities are designed to streamline deployment and management of complex AI workloads, Red Hat said. The LeaderWorkerSet (LWS) API for AI workloads, for example, simplifies management of large, distributed AI workloads with automated orchestration and scaling, according to Red Hat. Deployment time is reduced using image volume source for AI workloads, allowing new models to be integrated in minutes without rebuilding application containers. These features together provide functionality for Red Hat OpenShift AI or other AI platforms to help users move more easily from experimentation to production. Cluster management is enabled via Model Context Protocol (MCP) using tools such as Visual Studio Code.

The 4.20 version of Red Hat OpenShift also helps secure the main traffic between control-plane components with initial support for post-quantum cryptography, delivering long-term cryptographic protection for critical communications, Red Hat said. The release also brings greater operational flexibility to the core platform and strengthens security capabilities for Red Hat OpenShift Platform Plus customers. This includes the availability of Red Hat Advanced Cluster Security 4.9 and enhancements to Red Hat Trusted Artifact Signer and Red Hat Trusted Profile Analyzer to help manage and analyze security data.

This release also adds CPU load-aware rebalancing and Arm support to boost performance and resource utilization for virtualized workloads, said the company. Expanded hybrid cloud extends Red Hat OpenShift Virtualization to bare-metal deployments on Oracle Cloud, providing more control over infrastructure and the placement of data. And with enhanced storage offloading functionality, the migration toolkit for virtualization accelerates VM migration from legacy solutions to OpenShift Virtualization through existing storage resources.

Visual Studio 2026, the latest version of Microsoft’s signature IDE, is now generally available. Touted as an “AI-native intelligent development environment,” the IDE also features faster startup and improved user experience.

Announced November 11, the update can be downloaded from the Visual Studio homepage. Visual Studio 2026 uses AI intelligence for such things as complex debugging, performance profiling, and application modernization, Microsoft said. AI removes friction and surfaces insights, enabling developers to move faster without disrupting flow, the company said. In addition to AI-driven development, the release announcement noted that Visual Studio 2026 features performance improvements and a redesigned user experience.

Visual Studio 2026 is compatible with projects and extensions from Visual Studio 2022. The IDE is decoupled from build tools, so developers can update to Visual Studio 2026 without affecting .NET or C++ compilers, said the company. Following the initial update, automatic monthly updates will be provided.

Visual Studio 2026 was released in preview in September 2025. The 2026 update includes the following changes and additions:

• A refreshed interface aligned with the Fluent UI design system to improve usability, accessibility, and visual clarity.
• Full support available for .NET 10 and C# 14.
• Test code coverage, available in Visual Studio Community and Professional editions.
• New C# and C++ agents, which can be used to improve precision and speed.
• The new “Did You Mean” feature, which intelligently detects intent and suggests better matches to improve search performance and results.
• A new “Editor Appearance” setting that focuses on the editor’s look and feel. This setting can be used to match the overall IDE theme but also works independently, allowing users to customize their coding environment without having to align with the broader IDE.

User feedback helped fix more than 5,000 bugs and add more than 300 feature requests leading up to the Visual Studio 2026 release, according to Microsoft.

A malicious npm package named “@acitons/artifact” was found impersonating the legitimate “@actions/artifact” module, directly targeting the CI/CD pipelines within GitHub Actions workflows.

According to Veracode findings, the package was uploaded on November 7 and was designed to trigger during the build process of GitHub-owned repositories. Once executed inside a CI/CD runner, the payload captures any tokens available to that build environment and then uses those credentials to publish malicious artifacts–effectively impersonating GitHub itself.

“This incident isn’t just about a malicious npm package, it is about the blind trust many organizations place in the modern supply chain,” said Randolph Barr, CISO at Cequence Security. “Most organizations focus their controls on runtime environments, yet the CI/CD pipeline often runs with higher privilege than any developer. A single typosquatted dependency can silently execute code during a build, access repository tokens, and impersonate an organization, just as this attack attempted to do with GitHub’s own repositories.“

The malicious package picked up over 260k downloads before detection, and a total of six versions were uploaded–none detectable by “any popular anti-virus” products, Veracode researchers noted in a blog post.

GitHub says that the packages were uploaded internally as part of its red teaming efforts. “The packages referenced in Veracode’s blog were part of a tightly controlled exercise conducted by GitHub’s Red Team,” a GitHub spokesperson told CSO. “GitHub takes security seriously and regularly tests its security posture through rigorous, realistic Red Team exercises to ensure resilience against current threat actor techniques. At no point were GitHub systems or data at risk.”

Hijacking the GitHub Actions build process

On the surface, @acitons/artifact package looked normal with its metadata describing it as “actions artifact lib,” and its homepage and repository URLs closely mirroring those of the legitimate GitHub project. But embedded inside was a post-install hook that downloaded and executed an obfuscated shell script named “harness.”

Veracode’s analysis showed that this script, compiled with a shell-script compiler tool, contained a time-based kill switch set to deactivate after November 6, 2025–likely to evade detection after a brief active window. Once invoked, the harness would fetch a JavaScript file (“verify.js” meant to check whether the build environment belonged to GitHub and, if so, exfiltrate GitHub Action tokens. These tokens could then be misused to impersonate GitHub and publish malicious releases.

“Typosquatting is a well-known and growing threat vector in software supply chains whereby attackers publish packages with similar names as legitimate ones and then wait for a mistake to happen, bringing the victim to their repository to install malicious code by mistake,” explained Boris Cipot, Senior Security Engineer at Black Duck. “This attack strategy is designed to exploit typos and to leverage the automated nature of CI/CD pipelines.”

Cipot added that the use of a post-install hook and a short-lived obfuscated payload shows a deliberate attempt to blend in with normal build activity.

Lessons in defense

Barr pointed out that higher privileges in CI/CD pipelines make them an ideal target. Attackers who compromise a build runner can inject code at the source, sign releases with legitimate credentials, or push authentic-looking artifacts.

Mitigations, Cipot recommended, would include short-lived, scoped tokens with regular secret rotations. Automated scanning for suspicious packages using tools like Socket.dev or Phylum might also help stay ahead of the threat. Other ways to verify package authenticity include checksum validation and emerging standards like Sigstore, he added.

Jason Soroko, senior fellow at Sectigo, advises an immediate response for teams potentially affected. “Search source code, lockfiles, caches, and registries for @acitons and 8jfiesaf83 then quarantine any runners that fetched them,” he said. “Rotate all tokens and review artifacts and package publish history for the period from October 29 to November 6, 2025.”

Meta researchers have unveiled a new reinforcement learning framework called SPICE (Self-Play in Corpus Environments) that enables large language models (LLMs) to improve their reasoning skills without human supervision.

Developed with the National University of Singapore, SPICE trains a single model to act both as a Challenger, which generates complex, document-based problems, and a Reasoner, which solves them.

By grounding the learning process in real-world text corpora rather than synthetic data, the system avoids the hallucination loops that have plagued earlier self-play methods. It achieves an average improvement of nearly 10% in mathematical and general reasoning benchmarks.

The researchers described the approach as a “paradigm shift” toward AI systems that can self-improve through interaction with the vast, verifiable knowledge embedded in web documents rather than static human-curated datasets.

Why self-improving AI is difficult

The idea of self-improving AI has begun to take shape with the rise of LLMs capable of reasoning. However, most existing methods face fundamental barriers after some initial progress.

“Without external grounding, models inevitably plateau or collapse due to two critical issues,” the researchers said in the paper. “(1) hallucination amplification, where factual errors in both generated questions and answers compound as models train on their own unverifiable synthetic data, and (2) information symmetry, where both the problem generator and solver share the same knowledge base, preventing genuine challenge and leading to simpler, more repetitive patterns.”

Even new techniques that try to keep training data diverse, such as variational synthesis, still run into limits. They can only work with what was already captured during pretraining, essentially remixing the same information in new ways.

What makes SPICE effective

SPICE is built on the concept that a single LLM assumes two alternating roles, one that creates challenges and another that tries to solve them.

In one phase, the model acts as the Challenger, drawing information from a large document corpus to generate complex, document-grounded questions. In the next phase, it switches roles to become the Reasoner, attempting to answer those questions without seeing the source material.

The Challenger earns higher rewards when it creates problems that sit right at the edge of what the Reasoner can handle, making the tasks difficult but still solvable. The Reasoner is rewarded for producing correct answers.

This back-and-forth process, supported by real-world data, allows the system to keep discovering new challenges and improving its ability to solve them without human supervision.

This approach removes the verification bottleneck that has limited earlier research to specialized areas such as mathematics and coding. Because the answers are based on real documents, the system can verify them against factual sources rather than relying on synthetic or assumed data.

What the tests show

When tested across different LLMs, the researchers found that SPICE showed clear and consistent improvements in reasoning performance.

On the Qwen3 4B model, performance rose from 35.8 to 44.9 percent, while the larger Qwen3 8B model climbed from 43.0 to 48.7 percent. A stronger impact was seen in OctoThinker models, with improvements from 14.7 to 25.2 percent on the 3B version and from 20.5 to 32.4 percent on the 8B version.

“The adversarial dynamics between Challenger and Reasoner create an automatic curriculum: the fixed Reasoner’s pass rate decreases from 55% to 35% as it learns to generate progressively harder problems, while the fixed Challenger’s pass rate increases from 55% to 85%, indicating successful co-evolution of both roles,” the study said. 

The researchers also found that grounding the training process in real documents was essential for lasting improvement.

Models trained without this external reference quickly hit a ceiling and stopped getting better. But when SPICE drew on real-world text, it kept progressing steadily, using fresh document material to generate new and more complex challenges throughout training.

Implications of the study

By using large document collections as external sources of knowledge, SPICE helps models improve instead of stagnating on their own data. Industry analysts say such frameworks could eventually influence how enterprises train domain-specific AI models, but adoption will come with new responsibilities.

“SPICE opens new possibilities for adaptive AI, but enterprises can’t afford to set it and forget it,” said Tulika Sheel, senior VP at Kadence International. “Self-improving systems need self-checking mechanisms. Human oversight, audit trails, and compliance guardrails must stay front and center.”

Sheel noted that while the Challenger–Reasoner setup could, in theory, be replicated with corporate data such as financial or legal documents, it would demand “deep infrastructure, clean datasets, and a strong focus on transparency.”

She also warned that autonomous learning loops introduce risks like bias amplification and compliance drift. “SPICE nudges AI closer to self-sufficiency, but autonomy without accountability is dangerous,” she said.

Anish Nath, practice director at Everest Group, suggested that enterprises would benefit more from frameworks like SPICE by treating them as a training capability, not autonomy in production.

“Run self-play in sandboxes with gated releases; start on low-risk/internal workflows, then graduate to critical processes as evidence accumulates,” Nath said. “Enforce guardrails: schema-constrained outputs, policy engine, least-privilege tool whitelists, drift/anomaly detection, signed actions + audit trails, rollback/kill-switches, and human approvals for high-impact actions.”

Nath added that self-generated training data does point toward autonomous development loops, but warned of risks such as model collapse, data poisoning, and untracked drift. “These can be mitigated with independent evaluation models, provenance tracking, versioned datasets, and human gates for capability upgrades,” he said. “Improvement has to remain controlled, auditable, and compliant.”

The economics of the software development business have always been kind of weird. Some things with software scale spectacularly, and some things scale very poorly. Pricing is always a challenge; it’s hard to know when it is right. Even what, exactly, is being sold has always puzzled the best thinkers in the software business. And of course, open-source software throws a monkey wrench into the whole works.

For the first few decades, all software was bespoke. IBM and others sold mainframes and mini-computers, and software was normally sold with the computer and customized for each customer. Eventually, larger firms had in-house developers who wrote software for their company’s particular needs. There wasn’t a broad market for software, so software was expensive and limited to larger companies that could afford the esoteric hardware needed to run it. Economies of scale were extremely limited. 

The notion of “software as a product” came about as a result of a US Justice Department case that forced IBM to unbundle the software from its hardware. Eventually, the advent of the personal computer allowed for a broader software market.

I remember well going into a Computerland store and browsing for computers and boxes of software stored on floppy disks. Shoot, you could buy a computer and software at Sears. 

Peddling disks

The economics of the software package era were interesting. Each version of a given software package was to be written, tested, documented, burned onto disks (floppies, CD-ROMs, DVDs), and delivered to a store before even a dollar of revenue was realized. 

Customers expected extensive documentation, making for a heavy, hard-to-transport product. (The famous Borland C++ 3.0 box was around a foot and a half long and weighed upwards of 25 pounds.) And in the early days, the documentation wasn’t enough—customers expected and got free telephone support. You read that right: free, live telephone support. It didn’t last long. It eventually moved to pay-by-the-minute support, before all support went online.

The PC revolution also brought on the advent of shareware—a “try before you buy” model that has gone by the wayside, but was widely used by small developers at the time. Executable installers were downloaded from CompuServe, AOL, and bulletin board systems (and of course later from the Internet), and passed around via floppy disks at user group meetings.

The software would either be limited in functionality, display “nagware,” or run for only a limited period of time. Users could mail a check to the author, who would then send a license key that would unlock all of the features of the software. (I was a humble shareware vendor back in the 1990s, but I am vexed that the Internet seems to have no memory at all of any of my programs.)

Despite how the software was sold or delivered, just like today it all had bugs, and the vendors needed to deliver updates and patches, usually via a physical medium. Because the installs were static, those fixes were few and far between, and had to be batched up and delivered physically like the original package. Users learned to live with bugs.

New features were delivered the same way, with a “major point release” that users had to pay for. Convincing users that the latest version was worth the upgrade became a challenge, particularly if the new version was perceived as buggy and the previous version was considered stable and perfectly functional.

It was during this time that the notion of enterprise licensing came to the fore, with large software companies selling software “by the seat” with annual support and maintenance contracts.

Software piracy and licensing

Licensing became a big flash point. Software piracy soon became an ongoing battle between vendors and hackers. Smaller businesses needing more seats often “massaged” the number of installations at their offices to keep licensing costs down. This led to the use of dongles—a hardware stick that had to be plugged into the computer for the software to work—as well as license servers and software that had to “phone home” over the internet to start up. These methods, of course, were not very customer-friendly. 

Some software companies quietly tolerated piracy, figuring that the more their software spread—even illegally—the more legitimate sales would follow in the long run. The argument was that if students and hobbyists pirated the software, it would lead to business sales when those people entered the workforce. The catchphrase here was “piracy is cheaper than marketing.” This was never an official position, but piracy was often quietly tolerated.

In the end, the version release system led to peaks and valleys in revenue, as well as a bit of, ahem, sleight of hand with the definition of “sold.” Was the software sold the second it left the warehouse, headed to a retailer? Or when the customer paid for it at the register? It became common to “pump the channel” with boxes late in a financial quarter, then return the software after the first of the month, next quarter’s numbers notwithstanding. The dreaded Sarbanes-Oxley Act was motivated in small part by this practice.

The true value of software

Of course, the real value wasn’t in the physical products shipped, but in the actual bits and bytes that ended up in the memory of the computer. I remember a Usenet discussion (OK, argument) with a guy who complained that he had spent $299 and all he got were three lousy floppy discs. He remained unconvinced.

Over the years, the boxes got thinner and the documentation went onto the Internet. For a time, though, “online help” meant a *.hlp file on your hard drive. People fought hard to keep that type of online help well into the Internet age. “What if I’m on an airplane? What if I get stranded in northern British Columbia?”

Eventually, the physical delivery of software went away as Internet bandwidth allowed for bigger and bigger downloads. And it’s probably a good thing. I remember installing WordPerfect for Windows from 25 3½-inch floppies. I suspect some software packages today would have to be delivered on multiple DVDs!

But of course, things have changed, and today we rarely think of “installing software.” While I feel a certain nostalgia for the famous blue installation screens, it’s nice not to have to worry if I have enough disk space left to install that cool new tool I downloaded off of AOL. 

It took a while to get here, but today, software is almost universally delivered via the browser or some form of a package manager. We either run our applications in Chrome, or we install them with tools like HomeBrew, Chocolatey, or apt. 

And much of the software that is delivered this way is open source. Open-source software had a challenging route to the mainstream. Suffice it to say that entrenched commercial software companies didn’t take kindly to having to compete with free. But the case for open source was compelling, and businesses figured out ways to make money with it, mainly by selling premium features and support for the basic free product. 

The rise of SaaS

Much of that open-source software became the foundation for the Internet. It naturally followed that software as a service (SaaS) became the dominant model for delivering software, and we normally pay for that on a subscription basis. 

SaaS has many advantages over the physical delivery model. The obvious one is no more boxes shipped in trucks—software just appears on your computer with a few command-line incantations. Subscription-based sales smooth out the revenue for software companies, making finances more predictable. Bug fixes and new features are delivered immediately after being tested and approved.  Because the hard work is now done server-side, client computers no longer need gobs of processing power, memory, and storage space, and can be much smaller and lighter. These days, I do most of my work on a Chromebook.

But SaaS too has interesting economic implications for software companies. The marketplace generally expects a free tier for a SaaS product, and delivering free services can become costly if not done carefully. The compute costs money, after all. An additional problem is making sure that your free tier is good enough to be useful, but not so good that no one wants to move up to the paid tiers. 

Artificial intelligence makes this equation even more complex. AI takes a huge amount of processing power, and the processors themselves are scarce and can’t be manufactured fast enough. The electricity requirements are so great that companies are exploring building dedicated energy sources such as small modular reactors or on-site microgrids to power all those GPUs. Providing all of that with a free tier might be a stretch.

And even the paid tiers have limits today. For AI companies in particular, instead of a month of service, customers now pay for a limited amount of “tokens,” which have become a rough approximation for processing time. 

You can see how the economics of all that would be, once again, challenging.

From floppies to cloud credits

Making money in the software business is challenging. Some companies have done it really well and today are valued in the trillions of dollars. Even some individual developers, like my shareware hero, Nico Mak of WinZip fame, are probably comfortably retired as a result of their shareware success. Over the years, the notion of “owning software” has migrated to the idea that one pays for access to vast computing power that can be delivered to any browser. 

The economics of software have always been a bit peculiar because the product is maddeningly costly to design and produce, yet incredibly easy to replicate and distribute. The years go by, but the problem remains the same: how to turn ideas and code into a profitable business? We have changed the packaging—from floppies to cloud credits—but that difficult challenge remains the same.

Maybe that is the secret truth here. Software keeps changing, but the economics never really do.

When the Mojo language first appeared, it was promoted as being the best of two worlds, bringing the ease of use and clear syntax of Python, along with the speed and memory safety of Rust.

For some time, the only way to evaluate those claims was using an online notebook environment that ran Mojo code on remote servers. More recently, the Mojo compiler has been released as a standalone download for Mac and Linux. (Microsoft Windows is not yet supported directly, but it’s possible to run Mojo by way of WSL2.)

In this article, we’ll look at what it’s like to use Mojo locally. We’ll also discuss how Mojo resembles Python, how it’s different, and what it has to offer to programmers familiar with Python and other languages.

Mojo language basics

When Mojo was first announced, it was easy to think of it as a “superset” of Python, where existing Python programs would also be valid Mojo programs. It has since become clear that Mojo’s goal is not to provide inherent compatibility with Python—that is, it isn’t meant to be a runtime for existing Python programs. Instead, Mojo aims to provide a syntax that’s familiar and comfortable to Python users, but a feature set that’s more suited to lower-level programming than Python—for instance, to allow manual memory management in the style of Rust or C++.

Where full compatibility with Python programs and the Python ecosystem is required, Mojo can call out to the Python runtime and use it to handle those cases. The disadvantage there is performance, since calls to the Python runtime and anything in its sphere incur a cost. As a workaround, you could use Python in cases where you needed its ecosystem, and Mojo where your priority was performance.

Mojo’s most touted advantage over Python is that it is compiled ahead of time to machine-native code, using the LLVM toolchain. This gives Mojo programs an inherent speed advantage, although that advantage holds up best when working with features specific to Mojo.

Python features are likely to come at the cost of emulating Python’s dynamic behaviors, which are inherently slow—or again, by just using the Python runtime. That said, Mojo has native behaviors that can replace some of those things. For instance, in lieu of Python’s non-native integers of any size, Mojo can support integers of up to 256 bits that are actually aliases for fast SIMD operations.

Comparing syntax: Mojo vs. Python

Many of Mojo’s native language features do one of two things: They’re either entirely new features not found in Python or a more performant expansion of a Python feature. In the latter case, enhanced performance comes at the cost of losing Python’s dynamism.

In Python, for instance, there is no way to formally declare variable references; variables are just created as needed. In Mojo, you can use the keyword var to make an explicit variable declaration in the current scope. How the two languages handle variable scoping is also different. In Mojo, a variable can only be scoped within a given nested code block, such as an if block  (although you can pre-declare variables in the larger scope). In Python, a variable declared in an if block persists after the block ends.

Mojo also has its own struct keyword that stands in contrast to Python’s class. Classes are just Python classes, with all the dynamic (and slow) behaviors you’d expect. The struct types, though, are more like their C/C++ and Rust counterparts, with fixed layouts determined at compile time but optimized for machine-native speed.

Another Mojo keyword designed to distinguish Mojo’s behaviors from Python’s is fn. You can use def or fn to define a function, but fn will only allow you to raise errors when they are explicitly defined. Typically, a fn function handles all its own error conditions internally. This avoids generating potentially unneeded runtime error-handling code, which could impact performance.

The following code snippet, a struct for a point-like entity, shows all these principles in action:

struct Point:
    var x: Int
    var y: Int

    fn __init__(out self, x: Int, y: Int)
        self.x = x
        self.y = y

As a Python developer, you’ll notice immediately how closely Mojo code resembles Python’s—the use of whitespace for syntax, for instance. But the differences add up.

The Mojo compiler and toolchain

If you want to use Mojo on your own system, Modular provides downloadable binaries. If you’re already a Python user, the easiest way to get started with Mojo is to set up a Python virtual environment and install Mojo as if it were a Python package. This also makes cross-integration with Python easier, as any third-party Python libraries needed for a Mojo project can be installed and used in that venv. (More on this later.)

Once you have it set up, running Mojo programs is as simple as writing a file with a .mojo extension and using mojo filename.mojo to run it. The startup time for a Mojo program is noticeably longer than for a comparable Python program; that’s because the Mojo program is compiled to native code. If you use mojo build filename.mojo, that compiles the program in question to a standalone binary, and lets you reuse it without having to recompile. Compiled Mojo binaries can be quite compact; a simple “Hello, World!” program compiles to a 19K binary on Linux.

The Mojo toolchain can also be used with Modular’s package manager and project management tool, pixi. You can use pixi to manage Mojo-only projects as well as projects that blend Mojo and Python, as it supports all the metadata used in Python projects (e.g., pyproject.toml). The tool also provides lockfile and environment-management mechanisms. Some of the demo projects in the Mojo repository use pixi, but it’s entirely possible to keep using pip or uv if you’ve already invested in those tools.

Working with Python in Mojo

When you write Mojo code, the default assumption is that everything you type is Mojo. If you want to use Python features, you have to import them specifically. For instance, if you wanted to use NumPy from Python to do something specific to it (like integrating it with an existing workflow), you’d do something like this:

from python import Python

def main():
    np = Python.import_module("numpy")
    rand_array = np.random.rand(32)

The Mojo module python provides interop with the Python ecosystem as a whole, and the Python.import_module method works like Python’s own import mechanism. Every standard library item in Python, along with every third-party module installed into the virtual environment you’re using, can be imported this way. Imports do have some restrictions—you can’t import into the top level of a Mojo module, and you can’t emulate from x import y behaviors yet.

What’s key about Python/Mojo interop is that all native Python operations use an instance of the Python runtime. They aren’t emulated in Mojo itself. The advantage here is all Python behaviors are exactly what you’d expect them to be. But the downside is that every call across the Mojo/Python boundary incurs a performance cost. This isn’t peculiar to Mojo; any interop between Python and another language through Python’s foreign function interface sustains a per-call overhead. The common way to handle this is just to reduce the number of calls in either direction, by batching operations.

Mojo can also be called from Python in cases where you run Python programs in the same environment as Mojo. The mechanism for doing this is more complex, though, and requires some boilerplate. But the end result allows Python to see and use Mojo modules as Python extension modules, as if they were written in C or Rust, or by way of Python’s Cython project.

Could Mojo replace Python?

Mojo was originally touted as a language for data science and machine learning, but that pitch has since been refined. The About Mojo section of the language’s manual describes Mojo as “a systems programming language specifically designed for high-performance AI infrastructure and heterogeneous hardware.” Python, by contrast, is not intended to be a systems language, but has made a place for itself in the AI/ML world as a “glue language,” providing a convenient interface to things that by themselves aren’t convenient.

Replacing Python isn’t simply a matter of creating a faster language, because speed of execution was never Python’s draw to begin with. Speed of development and a robust ecosystem have always come first. For Mojo to replace Python, it would need to not only compete but excel in both of those categories. It would need to not just make use of existing Python libraries—since that comes at a potential performance cost—but create its own native equivalents for them. The same goes for having Mojo eclipse Python generally, such as in web development. Everything required to do that would take years to set in motion.

In the long run, Mojo is likely to be best used in the same way other languages are, as a complement to Python, enabling certain things that are still difficult to do in Python. In the meantime, Mojo can continue to grow on its own, and will eventually find a niche of its own.

Node.js is a popular and versatile cross-platform JavaScript runtime environment. Node was the first runtime to allow developers to run JavaScript outside the browser, opening a new world of possibilities in server-side JavaScript. Its ease of use, massive ecosystem and performance characteristics have continued to secure its place as one of the most important technologies of the modern web.

Anytime you need to run JavaScript on the server—be it for a systems utility, a REST API, data processing, or anything else—Node is an excellent choice. There are newer runtimes, namely Deno and Bun, but Node remains the standard for server-side JavaScript.

Also see: 10 JavaScript concepts you need to succeed with Node.

Getting started with Node

If you haven’t already experienced Node, this article will introduce you. We’ll step through installing Node and the NPM package manager, spinning up a simple web server, and using the Node cluster module to take advantage of multiple CPU cores.

We’ll also look at using the NPM package manager to install additional Node modules and other JavaScript packages. And we’ll dip a toe into using a Node framework, in this case the ubiquitous Express server, to create more feature-rich and flexible Node.js servers. Let’s get started!

Installing Node and NPM

There are a few ways to install Node, including the installer that Node itself provides, but the recommended way is with a version manager. The most common version manager is NVM. This makes it easy to install Node and change versions when you need to. (There is also a Microsoft Windows-specific version called nvm-windows.)

NVM can be installed with an installer or using a CLI. In the following example, we use curl:

$ curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash

Once you have NVM installed, installing the most recent version of Node is simple:

$ nvm install latest

The install latest command makes the latest version available. Mine is Node 24.9.0, so I activate it with:

$ nvm use 24.9.0

Anytime you need to install another version of Node, you can use nvm install and nvm use to switch between them.

You should now see Node available at your command prompt:

$ node -v

v24.9.0

When you install Node this way, the Node package manager (NPM) is also installed:

$ npm -v

11.6.0

Note that using NVM also avoids potential permissions issues with NPM packages when using the installer.

A simple web server in Node

To start simply, we can use an example from the Node homepage. Copy the Synopsis example code as directed there and paste it into your code editor, then save it as example.js:

const http = require('node:http');

const hostname = '127.0.0.1';
const port = 3000;

const server = http.createServer((req, res) => {
  res.statusCode = 200;
  res.setHeader('Content-Type', 'text/plain');
  res.end('Hello, InfoWorld!\n');
});

server.listen(port, hostname, () => {
  console.log(`Server running at http://${hostname}:${port}/`);
});

Open a shell in the directory where you saved the file, and run the file from your command line:

$ node example.js

Server running at http://127.0.0.1:3000/

You can now go to the browser and check it out at 127.0.0:3000, and you should see the greeting shown here:

Matthew Tyson

Back at the terminal, press Control-C to stop the running server.

Before we go further, let’s pull apart the code.

Creating a simple HTTP server with Node

We start with the command:

const http = require(‘http’);

This is how you include a module in your code, in this case, the standard http module. (The http module ships with Node, so you don’t have to add it as a dependency.) This module provides the createServer and listen functions we’ll use later on.

You might have noted that this example used a CommonJS import. While older, this style of import is still very common in Node programs as well as some documentation. However, it’s gradually being phased out in favor of ES Modules (ESM), the standardized module system introduced in ECMAScript 2015. An ESM import would look like this:

import http from 'http';

After we import the http module, we define a couple of values we need (hostname and port):

const hostname = '127.0.0.1';

const port = 3000;

Next, we create the server:

const server = http.createServer((req, res) => {
  res.statusCode = 200;
  res.setHeader(‘Content-Type’, ‘text/plain’);
  res.end(‘Hello World\n’);
});

The creatServer command accepts a callback function, which we define using the fat arrow notation. The callback function passes two arguments, the request (req) and response (res) objects needed to handle HTTP requests. The req argument contains the incoming HTTP request, which in this case is ignored. The res.end method sets the response data to ‘Hello InfoWorld\n’ and tells the server that it is done creating the response.

Next, we have:

server.listen(port, hostname, () => {
  console.log(`Server running at http://${hostname}:${port}/`);
});

The server.listen function accepts three arguments. The first two are the port and hostname, and the third is a callback that is executed when the server is ready (in this case, it prints a message to the console).

Having all the event handlers defined as callbacks is one of the most subtle and powerful parts of Node. It’s key to Node’s asynchronous non-blocking architecture.

Node.js runs on an event loop, which always reverts to handling events when not otherwise engaged. It’s like a busy order-taker continually picking up orders and then updating the order-maker with their order. We receive updates via the callbacks.

A multi-process web server with Node

Node’s asynchronous, non-blocking nature makes it good at handling many parallel requests, but it’s not truly concurrent by default. There are a few ways to make a Node application use multiple threads for true concurrency. One of the simplest is to use the PM2 project, which lets you run the same Node application in many processes.

By launching each application instance in its own process, the operating system can make use of multiple cores on the machine. This is not usually a concern at first, but it’s a key performance consideration to bear in mind.

You can install PM2 globally like so:

$ npm install -g pm2

For our example, we want to make it obvious that the different processes are handling requests. We can achieve that goal with a small change to the server:

res.end(`Hello, InfoWorld! Handled by ${process.pid}`);

The process.pid field is a built-in environment variable, providing a unique ID for the currently running process in Node. Once PM2 is installed and the app is updated, we can run it like so:

$ pm2 start example.js -i max

That should launch several instances of the same program, as shown here:

Matthew Tyson

Then, if you open multiple windows, you can see the unique ID of each instance:

Matthew Tyson

An Express web server with Node

For our final example, we’ll look at setting up an Express web server in Node. This time we’ll use NPM to download Express and its dependencies. NPM is one of the greatest storehouses of software on the planet, with literally millions of libraries available. Knowing how to use it is essential for working with Node.

NPM works just like other package managers you may have used, letting you define and install dependencies in a structured way. To install Express, go to your project directory and type:

$ npm install express

Node should respond with something like: added 68 packages in 5s.

You will notice several directories have been added to a /node_modules directory. Those are all the dependencies needed for Express. You usually don’t have to interact with node_modules yourself, but it’s good to know that’s where things are saved.

Now look at the package.json file, which will have something like this in it:

{
  "dependencies": {
	"express": "^5.1.0"
  }
}

This is how dependencies are defined in NPM. It says the application needs the express dependency at version 5.1.0 (or greater).

Setting up the Express server in Node

Express is one of the most-deployed pieces of software on the Internet. It can be a minimalist server framework for Node that handles all the essentials of HTTP, and it’s also expandable using “middleware” plugins.

Since we’ve already installed Express, we can jump right into defining a server. Open the example.js file we used previously and replace the contents with this simple Express server:

import express from 'express';

const app = express();
const port = 3000;

app.get('/', (req, res) => {
  res.send('Hello, InfoWorld!');
});

app.listen(port, () => {
  console.log(`Express server at http://localhost:${port}`);
});

This program does the same thing as our earlier http module version. The most important change is that we’ve added routing. Express makes it easy for us to associate a URL path, like the root path (‘/’), with the handler function.

If we wanted to add another path, it could look like this:

app.get('/about', (req, res) => {
  res.send('This is the About page.');
});

Once we have the basic web server set up with one or more paths, we’ll probably need to create a few API endpoints that respond with JSON. Here’s an example of a route that returns a JSON object:

app.get('/api/user', (req, res) => {
  res.json({
	id: 1,
	name: 'John Doe',
	role: 'Admin'
  });
});

That’s a simple example, but it gives you a taste of working with Express in Node.

Conclusion

In this article you’ve seen how to install Node and NPM and how to set up both simple and more advanced web servers in Node. Although we’ve only touched on the basics, these examples demonstrate many elements that are required for all Node applications, including the ability to import modules.

Whenever you need a package to do something in Node, you will more than likely find it available on NPM. Visit the official site and use the search feature to find what you need. For more information about a package, you can use the npms.io tool. Keep in mind that a project’s health depends on its weekly download metric (visible on NPM for the package itself). You can also check a project’s GitHub page to see how many stars it has and how many times it’s been forked; both are good measures of success and stability. Another important metric is how recently and frequently the project is updated and maintained. That information is also visible on a project’s GitHub Insights page.

Snowflake has entered into a definitive agreement to acquire San Francisco-headquartered startup Datometry, for an undisclosed sum, to bolster SnowConvert AI, one of its existing set of migration tools.

SnowConvert AI, which is powered by Snowflake’s Cortex AI Agents, is a free product that was introduced earlier this year to help enterprises reduce the complexity and time required to migrate their data warehouse workloads to Snowflake by not only automating code conversion, but also code verification and validation. The company also offers the Snowpark Migration Accelerator, which focuses solely on moving Spark workloads.

Both products address common issues encountered during workload migrations; enterprises often see challenges such as schema mismatches, code incompatibilities, data corruption, and workflow disruptions, and they typically have to manually test whether the logic, transformations, and operations were correctly translated to the new platform’s syntax and semantics.

Datometry’s acquisition, according to Snowflake, will enable it to integrate the startup’s migration-related technology into SnowConvert AI to further accelerate the product’s ability to reduce the time required for a given migration.

Analysts believe that Snowflake is specifically focused on Datometry’s Hyper-Q, a data warehouse virtualization platform that allows applications written for legacy data warehouses to run on modern cloud platforms without requiring the original SQL code to be rewritten.

Forrester vice president and principal analyst Charlie Dai said that Hyper-Q, which emulates SQL statements and translates data in real time between applications and the cloud data warehouse, will complement SnowConvert AI.

“SnowConvert AI excels at static code conversion, but it still requires code extraction and re‑insertion. Hyper‑Q complements this with on‑the‑fly translation to tackle dynamic constructs and application‑embedded SQL that converters often miss,” Dai said.

Seconding Dai, Pareekh Jain, senior analyst at Jain Consulting, pointed out that this acquisition could help Snowflake differentiate itself from rivals such as AWS Redshift, Google BigQuery, and Azure Synapse, who rely more on traditional ETL and batch migration strategies. 

“Migration is a huge decision for customer enterprises,” Jain said. “CFOs and CTOs are reluctant to move large legacy warehouses [such as] Teradata and Oracle into the cloud because of cost, time, and risk. By offering a more compelling proposition which is faster and lower cost, actually free, Snowflake gains a competitive muscle versus other cloud data warehouses.”

Snowflake’s fiercest rival, Databricks, offers a tool similar to SnowConvert AI, which provides AI-powered insights into conversion scope, configurable code transpilation, LLM-driven transformation, and streamlined validation of migrated systems, thanks to its acquisition of BladeBridge earlier this year. However Databricks does not also offer a product with virtualization capabilities such as those in Hyper-Q.

Microsoft has released .NET 10, a major update of its software development platform. .NET 10 features a range of improvements including enhancements for AI, new cryptography APIs, runtime improvements, and the C# 14 language with field-backed properties.

.NET 10 is being touted by Microsoft as the most performant release of .NET yet, with improvements across the runtime, workloads, and languages. The software can be downloaded at dotnet.microsoft.net.

Among the new features for AI, .NET 10 includes the Microsoft Agent Framework, which is intended to make development of intelligent AI agents as straightforward as building a web API. The Agent Framework features a set of .NET libraries designed to reduce the complexity of AI agent development, Microsoft said. Multiple workflow patterns are supported including sequential, concurrent, handoff, and group chat orchestration. Agents can be powered with tools through function definitions or integrations like Model Context Protocol (MCP) servers. Agents can be deployed using familiar .NET hosting patterns with built-in dependency injection, middleware support, and production-ready observability. .NET 10 provides first-class support for MCP, making it easy to extend agents with external tools and services, Microsoft said.

For cryptography, .NET 10 introduces extensive new APIs across cryptography, globalization, numerics, serialization, collections, and diagnostics. Also, with quantum computing on the horizon, .NET 10 expands post-quantum cryptography support with Windows Cryptography API: Next Generation (CNG) support, enhanced ML-DSA with simplified APIs, and HashML-DSA support, plus Composite ML-DSA for hybrid approaches. Additional cryptography enhancements include AES KeyWrap with Padding support for secure key wrapping scenarios. The .NET 10 runtime boasts “significant improvements” in JIT inlining, method devirtualization, and stack allocations, Microsoft said. This includes Advanced Vector Extensions 10.2 support for cutting-edge Intel silicon, NativeAOT enhancements for smaller and faster ahead-of-time compiled apps, improved code generation for struct arguments, and enhanced loop inversion for better optimization. 

Microsoft’s C# and F# languages get attention in the .NET 10 release. C# 14 introduces field-backed properties to provide a smoother path from auto-implemented properties to custom accessors. Also, nameof for unbound generic types lets developers use nameof(List) without requiring a type argument. Parameter modifiers in lambdas allow ref, in, or out without specifying parameter types explicitly. Partial instance constructors and events complement partial methods and properties from C# 13. Extension blocks add support for static extension methods and both static and instance extension properties, while null-conditional assignment using the ?.= operator offer cleaner null-safe code.

F# 10 brings language, library, and tooling enhancements designed to make programs safer, more resilient, and performant. Nullable reference types bring type safety to interactions with C# libraries, while optimized integral ranges speed up for loops and other comprehensions. Optimized equality checks avoid boxing and increase the performance of many common operations. Discriminated unions get autogenerated .Is* properties for quick case testing. The standard library now includes random functions for collections that are useful for data science and game development, Microsoft said. Developer productivity gets a boost from improved diagnostics, parse recovery, and various tool improvements.

Leading up to the production release of .NET 10, Microsoft provided two release candidates and seven preview releases.

Other new features and improvements in .NET 10:

• NET MAUI 10 features a new project template that integrates with Aspire service defaults. This template provides extension methods that connect telemetry and service discovery to an app, enables configuration of OpenTelemetry metrics and tracing, and configures HttpClient to work with service discovery.
• .NET MAUI 10 also brings improvements to core controls, such as web request interception for both BlazorWebView and HybridWebView, for modifying headers, redirecting requests, or supplying local responses.
• .NET 10 has clipboard-related updates for Windows Forms, including improved clipboard access and better handling of clipboard data formats.
• ASP .NET Core 10 introduces several new features and enhancements, including Blazor improvements, OpenAPI enhancements, and minimal API updates that make building web applications more productive.

For decades, the database has been the silent partner of commerce—a trusted, passive ledger. It was the system of record, the immutable vault that ensured every action had an equal, auditable reaction. This model underwrote the entire global economy. But that era of predictable, human-initiated transactions is over.

We are entering the agentic era. A new class of autonomous agents—systems that perceive, reason, act, and learn—are becoming the primary drivers of business operations. They don’t just execute prescribed workflows; they generate emergent, intelligent behavior. This creates a profound new challenge for leadership. In a business increasingly run by autonomous systems, how do you ensure trust, control, and auditability? Where is the handshake in a system that thinks for itself?

The answer is not to constrain the agents, but to evolve the environment in which they operate. The database can no longer be a passive record-keeper. It must be radically transformed into a system of reason—an active, intelligent platform that serves as the agent’s conscience. The database must not only record what an agent did, but provide an immutable, explainable “chain of thought” for why it did it. This is the dawn of the AI-native database.

The new mandate for leadership

• Your database must evolve from a passive ledger to an active reasoning engine. Your data platform is no longer just a repository. It must become an active participant in informing, guiding, and enabling autonomous action.
• The enterprise knowledge graph is your durable AI advantage. Sustainable differentiation will not come from the AI model alone, but from the comprehensiveness of your proprietary data, structured as a graph of interconnected entities that powers sophisticated reasoning.
• Success hinges on an “agentops” framework for high-velocity deployment. The primary bottleneck in delivering AI value is the human workflow. The platform that wins is the one that provides the most productive and reliable path from concept to production-grade autonomous system.

Phase 1: Perception – Giving agents high-fidelity senses

An agent that cannot perceive its environment with clarity and in real-time is a liability. This is why The Home Depot, a leading home improvement retailer, built their “Magic Apron” agent—it moves beyond simple search to provide expert 24/7 guidance, pulling from real-time inventory and project data to give customers tailored recommendations. This level of intelligent action requires a unified perception layer that provides a complete, real-time view of the business. The foundational step is to engineer an AI-native architecture that converges previously siloed data workloads.

Unifying real-time senses with HTAP+V

The fatal flaw of legacy architectures is the chasm between operational databases (what’s happening now) and analytical warehouses (what happened in the past). An agent operating on this divided architecture is perpetually looking in the rearview mirror. The solution is a converged architecture: hybrid transactional/analytical processing (HTAP). Google has engineered this capability by deeply integrating its systems, allowing BigQuery to directly query live transactional data from Spanner and AlloyDB without impacting production performance.

For the agentic era, however, a new sense is required: intuition. This means adding a third critical workload—vector processing—to create a new paradigm, HTAP+V. The “V” enables semantic understanding, allowing an agent to grasp intent and meaning. It’s the technology that understands a customer asking “where is my stuff?” has the same intent as one asking about a “delivery problem.” Recognizing this, Google has integrated high-performance vector capabilities across its entire database portfolio, enabling powerful hybrid queries that fuse semantic search with traditional business data.

Teaching agents to see the whole picture

An enterprise’s most valuable insights are often trapped in unstructured data—contracts, product photos, support call transcripts. An agent must be fluent in all these languages. This requires a platform that treats multimodal data not as a storage problem, but as a core computational element. This is precisely the future BigQuery was built for, with innovations that allow unstructured data to be queried natively alongside structured tables. DeepMind’s AlphaFold 3, which models the complex interactions of molecules from a massive multimodal knowledge base, is a profound demonstration of this power. If this architecture can unlock the secrets of biology, it can unlock new value in your business.

A control plane for perception

An agent with perfect senses but no ethics is dangerous. In an era of machine-speed decisions, traditional, manual governance is obsolete. The solution is to build agents that operate within a universe governed by rules. This requires transforming the data catalog from a passive map into a real-time, AI-aware control plane. This is the role of Dataplex, which defines security policies, lineage, and classifications once and enforces them universally—ensuring an agent’s perception is not only sharp, but foundationally compliant by design.

Phase 2: Cognition – Architecting memory and reasoning

Once an agent can perceive the world, it must be able to understand it. This requires a sophisticated cognitive architecture for memory and reasoning. Imagine a financial services agent that uncovers complex fraud rings in minutes by reasoning across millions of transactions, accounts, and user behaviors. This demands a data platform that is an active component of the agent’s thought process.

Engineering a multi-tiered memory

An agent needs two types of memory.

1. Short-term memory: A low-latency “scratchpad” for the immediate task, requiring absolute consistency. Spanner, with its global consistency, is precisely engineered for this role and is used by platforms like Character.ai to manage agent workflow data.
2. Long-term memory: The agent’s accumulated knowledge and experience. BigQuery, with its massive scale and serverless vector search, is engineered to be this definitive cognitive store, allowing agents to retrieve the precise “needle” of information from a petabyte-scale haystack.

Connective reasoning with knowledge graphs

A powerful memory is not enough; an agent must be able to reason. Standard retrieval-augmented generation (RAG) is like giving an agent a library card—it can find facts, but it can’t connect the ideas. The critical evolution is GraphRAG. GraphRAG gives the agent the ability to be a scholar, traversing a knowledge graph to understand the deep relationships between entities.

As vector search becomes commoditized, the enterprise knowledge graph becomes the true, durable moat—i.e., the durable, competitive advantage of the enterprise. This is the future Google is engineering with native graph capabilities in its databases, a vision validated by DeepMind research on implicit-to-explicit (I2E) reasoning, which shows that agents become exponentially better at complex problem-solving when they can first build and query a knowledge graph.

Phase 3: Action – Building an operational framework for trust

The ultimate advantage in the agentic era is velocity—the speed at which you can transform an idea into a production-grade, value-creating autonomous process. A powerful agent that cannot be trusted or deployed at scale is just a science project. This final phase is about building the high-velocity “assembly line” to govern an agent’s actions reliably and safely.

Embedded intelligence and explainability

For an agent’s actions to be trusted, its reasoning must be transparent. The foundation for this is bringing AI directly to the data. Today, platforms like BigQuery ML and AlloyDB AI make this a reality, embedding inference capabilities directly within the database via a simple SQL call. This transforms the database into the agent’s conscience.

But inference alone is not enough. The next frontier of trust is being pioneered by DeepMind through advanced capabilities that are becoming part of the platform. This includes a new generation of Explainable AI (XAI) features, informed by DeepMind’s work on data citation, which allows users to trace a generated output back to its source. Furthermore, before an agent acts in the physical world, it needs a safe place to practice. DeepMind’s research with models like the SIMA agent and generative physical models for robotics demonstrates the mission-critical importance of training and validating agents in diverse simulations—a capability being integrated to de-risk autonomous operations.

From MLops and devops to agentops: The new rules of engagement

With trust established, the focus shifts to speed. The bottleneck is the human workflow. A new operational discipline, agentops, is required to manage the life cycle of autonomous systems. This is why major retailers like Gap Inc. are building their future technology roadmap around this principle, using Vertex AI platform to accelerate their e-commerce strategy and bring AI to life across their business. The platform’s Vertex AI Agent Builder provides a comprehensive ecosystem from a code-first Python toolkit (ADK) to a fully managed, serverless runtime (Agent Engine). This integrated tool chain is what solves the “last mile” problem, collapsing the development and deployment life cycle.

Three steps to the AI-native era

The transition to the agentic era is an architectural and strategic reset. The path forward is clear:

1. Unify the foundation (Perception): Commit to a true AI-native architecture built on converged HTAP+V workloads, integrating platforms like AlloyDB, Spanner, and BigQuery under a single governance plane.
2. Architect for cognition (Reasoning): Design your data platform for autonomous agents, not just chatbots. Prioritize a tiered memory architecture and invest in a proprietary enterprise knowledge graph as your central competitive moat.
3. Master the last mile (Action): Direct investment toward a world-class agentops practice centered on an integrated platform like Vertex AI, which is what separates failed experiments from transformative business value.

This integrated stack provides a durable and uniquely powerful platform for building the next generation of intelligent, autonomous systems that will define the future of your enterprise.

—

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.

Efforts by the European Union to wrest control of its digital infrastructure from American cloud companies have become a flashpoint in the debate over sovereignty and innovation. The proposed European Cybersecurity Certification Scheme for Cloud Services (EUCS), with its controversial “sovereignty requirement,” is a bold initiative aimed at reducing Europe’s reliance on US-based hyperscalers such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud.

While this initiative highlights the EU’s desire for digital independence, it also underscores the broader challenge of balancing sovereignty with the advantages of technological advancements provided by global cloud leaders. From an American perspective, the conflict sends a message to US cloud providers and businesses that depend on them to adapt their strategies to succeed in a world where such policies might soon become common. For the EU, the battle over cloud sovereignty will only become more complex as it attempts to balance competing priorities.

An EU proposal for cloud sovereignty

Europe’s unease with the prominence of US cloud providers extends beyond worries about market share. The EUCS proposal, supported by France, Germany, Spain, and Italy, highlights concerns about US extraterritorial laws such as the CLOUD (Clarifying Lawful Overseas Use of Data) Act. The act empowers US law enforcement to compel US-based service providers (Microsoft, Google, etc.) to provide data regardless of where that data is stored—whether it’s in the US, Europe, or anywhere else in the world. 

Such concerns underscore real risks related to sensitive government and private data, especially for critical infrastructure and strategic industries. Proponents of the sovereignty requirement argue that requiring certified providers to store, process, and manage data entirely within European jurisdiction—and to be European-owned—would eliminate vulnerabilities and strengthen the European cloud ecosystem.

However, the initiative has received as much criticism as support. Smaller EU countries, along with tech-dependent nations like Ireland and the Netherlands, have pushed back against the sovereignty clause, arguing that it smacks of protectionism and unfairly excludes American providers from competing on equal footing. These countries value US providers’ innovation, security, and technical excellence—areas where European cloud firms lag.

Ultimately, the deadlock highlights a bigger question: Can Europe afford to give up access to top-tier technological solutions to achieve its long-term goal of sovereignty? Is there a middle path that respects European independence while ensuring fair competition? The EU’s struggle highlights the complexity of large-scale cloud adoption and the challenges of reducing dependence on a few dominant hyperscalers.

Lessons for a fragmented world

From the US side, the rise of geopolitical and regulatory challenges, such as the EUCS, serves as a warning to hyperscalers that their dominance is not permanent, whether in Europe or elsewhere. Market fragmentation caused by protectionist policies highlights the need for cloud providers to be more flexible and adaptable.

Even American businesses using AWS, Microsoft, or Google are concerned about centralization. Some question whether heavy reliance on a single hyperscaler or geographic region is sustainable in the long term, as it introduces exposure to geopolitical conflicts, vendor lock-in, and restrictions on accessing innovative solutions outside the Big Three.

Nevertheless, viewing Europe’s situation solely as an opportunity or a source of competition for US firms would be a mistake. The EU’s scenario highlights a bigger, global challenge: decreasing reliance on a few major providers while promoting more diverse ecosystems.

Total sovereignty will take years

The EU faces a prolonged battle as governments realize that American hyperscalers dominate in services, scalability, and innovation, with billions invested in platforms that surpass European options in infrastructure, AI, and ecosystems. Many member states prefer US providers’ practical benefits over sovereignty concerns. Denmark, the Netherlands, and the Baltic states are opposed to strict sovereignty clauses.

Pushing for stricter sovereignty won’t fix Europe’s dependence. American providers offer “sovereign clouds” that comply with European laws but rely on US parent companies, showing market closure is futile without strong internal options. The EUCS faces years of regulatory battles and tech compromises as member states balance economic, legal, and strategic needs.

What each side must consider

The current debate provides valuable lessons beyond Europe. First, regulatory alignment needs to strike a balance between protecting sovereignty and preserving innovation. EU policymakers need to understand that strict restrictions alone will not create competitive local ecosystems. Regulatory frameworks should incentivize development, R&D investments, and collaboration between governments and European tech firms. For US providers, adaptability is key. Finding ways to create value within regulatory constraints helps companies compete fairly in Europe.

Second, the need for diversified cloud strategies extends beyond Europe; it is a global requirement. For businesses and governments on both sides of the Atlantic, reliance on a single provider is becoming increasingly unsustainable. Multicloud and hybrid cloud strategies will be critical for reducing risk, even though these strategies introduce additional complexity. US companies should lead by example, proving their willingness to integrate seamlessly with heterogeneous ecosystems rather than locking customers into walled gardens.

Third, both sides must work together to establish common security and operational standards. Rather than focusing solely on walls and barriers, the transatlantic debate could be an opportunity to set common standards for security, transparency, and data sovereignty. Building frameworks like these will help global organizations navigate regulatory fragmentation while minimizing inefficiencies.

The road to autonomy and pragmatism

The EU’s vision of cloud sovereignty makes a strong case for data protection and less reliance, but this goal is still years away from being achievable. Splintered priorities, the dominance of US hyperscalers, and the lack of viable European alternatives make progress uncertain. Yet this struggle is not unique to Europe. The challenge of avoiding reliance on a few central players and the accompanying geopolitical implications affects countries around the globe.

The best route is to temper protectionist regulations through pragmatic collaboration, mutual adaptation, and shared goals. As cloud computing becomes more critical to global infrastructure, both sides have much to gain from building a digital future that combines sovereignty with innovation, stability, and fair competition. Rather than steadfastly opposing Europe’s ambitions, the US and its cloud giants can become essential partners in making this vision a reality that benefits everyone.

If you like coding agents, such as Gemini CLI and its competitors, but you get tired of supervising them closely and you would like to see a coding agent that does more on its own, safely, then consider Google Jules. The goal here is to have a tool that is an amplifier for your software development efforts. People used to hope for 10x amplification of programming productivity. Now they are speculating about 100x.

“Jules is an experimental coding agent that helps you fix bugs, add documentation, and build new features. It integrates with GitHub, understands your code base, and works asynchronously—so you can move on while it handles the task,” according to Google’s description. Jules has a web interface and runs in the Google cloud.

By “integrates with GitHub,” Google means that Jules connects with and uses your GitHub repository, which pretty much guarantees that you can review its code and reject anything you don’t like. That makes Jules inherently safe. Jules runs in a virtual machine, where it clones your code, installs dependencies, and modifies files.

You interact with Jules using Jules Tools, a command-line interface (CLI) that allows you to delegate coding tasks to Jules and monitor its progress. A CLI is the most natural way to interact with a coding agent for many programmers and for most use cases.

Google Jules competes with OpenAI Codex Cloud and Codex CLI, Claude Code, Windsurf, Augment Code, Amp, Cline, Zencoder, and Google’s own Gemini CLI. There are differences among all of these, of course.

Getting started with Jules

To start using Jules, visit jules.google.com, sign in with your Google account, and accept the one‑time privacy notice. Then connect Jules to your GitHub repositories by clicking “Connect to GitHub account,” completing the login flow, and choosing “all” or specific repos that you want to connect to Jules. I chose “all.” Then go back to Jules.

You’ll see something like the second screen shot below, where you can pick a repo and a branch to work on, and enter a prompt. You might like to get your bearings (in 90 seconds) from this video.

Foundry

Foundry

Getting started with Jules Tools

To get started, install the tool globally using npm:

[sudo] npm install -g @google/jules

To authenticate, log in:

jules login

The commands you can use in Jules Tools are here.

Jules VM

Jules runs code in a secure, cloud-based virtual machine (VM) with internet access running Ubuntu Linux. The preinstalled developer tools include Node.js, Bun, Python, Go, Java, Rust, and more. You can add a setup script on a per-repo basis using the “Configuration” option. I thought I might need to do that for a TypeScript project, but it was handled by npm without my intervention.

Running tasks with Jules

You can start Jules working on your tasks in several ways. In the web interface, as we discussed earlier, pick a repo and a branch to work on, and then enter a prompt. If you have files or images to add to the prompt for context, use the paper clip icon at the lower left. Drop down the plan selector and choose “Interactive plan,” “Review plan,” or “Plan and go,” depending on your preference. Then click on the right arrow to kick off the task.

Be specific. Jules calls the Gemini model, which (sadly) can’t read your mind. “Fix this” or “Fix everything” are too vague to work. On the other hand, “Pick an open bug report and try to fix it” should work fine on a repository that has open bug reports. If and when the session is successful, you’ll have the opportunity to either modify the original branch or create a new branch with the fix, and the option to create and submit a pull request (PR) if you wish.

You can also run tasks from Jules Tools. The basic non-interactive command is:

jules remote new --repo  --session ""

For example:

jules remote new --repo torvalds/linux --session "write unit tests"

Finally, you can start tasks from a GitHub issue by applying the label “jules” (case insensitive).

Reviewing plans and code

Jules’ plans start with a description of its intentions, a step-by-step breakdown, and assumptions or set-up steps. You can open each step to see its details if you wish. You can give feedback in the chat. When you’re ready, click “Approve plan.” If you don’t respond, Jules will eventually auto-approve its plan.

You can chat with Jules at any time, even if it’s working. For example, you can ask it to revise a step, point out something it missed, clarify your original request, answer its questions, or provide additional information Jules may need. Jules will update its plan if it needs to.

Jules displays an activity feed as it works. When it makes code changes, it displays a mini-diff. You can expand a mini-diff into a full diff editor. As with plans, you can comment on code to give feedback, ask for revisions, or ask for additional tests or cleanup.

Managing Jules tasks and your repos

To start a new task, click on the Jules icon to get to the home screen, click the + button in a task view, or click “New session” in a repo view. You can pause or delete active tasks from the task view. You can give Jules access to more repositories in GitHub by clicking the “Add repository” item at the bottom of the repo selector drop-down.

Using Jules Tools

Jules Tools does a decent job of documenting itself:

martinheller@Mac Code % jules help
A CLI for Jules, the asynchronous coding agent from Google.

Usage:
  jules [flags]
  jules [command]

Examples:
jules # Launch the TUI
jules remote list --session # List all the sessions on Jules
jules remote list --repo # List all the repos connected to Jules
jules remote pull --session 123456 # Pull the result of the session (ID: 123456)

# Create a remote session
jules remote new --repo torvalds/linux --session "write unit tests"

# Create multiple remote sessions for each task in TODO.md
cat TODO.md | while IFS= read -r line; do\
  jules remote new --repo . --session "$line";\
done

# Create a remote session based on the first issue that's assigned to @me on this GitHub repo
gh issue list --assignee @me --limit 1 --json title | jq -r '.[0].title' | jules remote new --repo .

# Use Gemini CLI to analyze GitHub issues and send the hardest one to Jules
gemini -p "find the most tedious issue, print it verbatim\n$(gh issue list --assignee @me)" | jules remote new --repo .

Available Commands:
  completion  Generate the autocompletion script for the specified shell
  help        Help about any command
  login       Login your Google account to use Jules
  logout      Logout your Google account
  remote      Interact with remote sessions, e.g. new/list/pull
  version     Show the version

Flags:
  -h, --help           help for jules
      --theme string   Which theme to use, dark/light (default "dark")

Use "jules [command] --help" for more information about a command.

Note that Jules Tools can also update itself. On a Mac where the CLI has been installed globally, that requires root (sudo) privilege.

Some tests with Jules

I tested Jules in two forked repos, websocket (Go) and qwen-code (TypeScript). In both cases I asked it to pick an open bug report and try to fix it. I could have used some of the script suggestions in the Jules Tools help; I didn’t want to complicate things.

Foundry

Foundry

Foundry

Foundry

Foundry

Foundry

Foundry

Foundry

Foundry

Foundry

Foundry

Foundry

Well done, Jules

I was pleasantly surprised by how well Jules performed. Putting gemini-2.5-pro inside a feedback loop where it can see compiler, linter, and run-time errors greatly improves the final results. That made Jules behave better than Gemini CLI, and more like Claude Code and OpenAI Codex.

I did my review within the constraints of the free Jules plan, which allows 15 daily tasks and three concurrent tasks. If I were using it heavily for real work, I could see paying for the Google AI Pro plan, which allows 100 daily tasks and 15 concurrent tasks, for $19.99 per month. That doesn’t necessarily mean that I would give up my ChatGPT or GitHub Copilot subscriptions, however.

As always, you are responsible for reviewing, testing, and debugging the code produced by any AI, even though agents like Jules do a certain amount of that themselves. And as has been the case for the last couple of years, new AI models and agents are dropping frequently, to the extent that not even someone tracking the field full-time can keep up with all the new developments.

Cost

Free basic plan with 15 daily tasks, three concurrent. Google AI Pro plan: 100 daily tasks, 15 concurrent, $19.99/month. Google AI Ultra plan: 300 daily tasks, 60 concurrent, $249.99/month.

Platform

Node.js for Jules CLI; Windows, macOS, Linux.

Bottom line

Google’s Jules performs better than its Gemini CLI despite using the same model, and more like Anthropic’s Claude Code and OpenAI’s Codex. Just be sure to cast a cold eye on its output, as you would any AI model or agent, since they are prone to making things up.

Pros

1. Works fairly well to generate and fix code in GitHub repositories.
2. Can operate asynchronously for moderately complex changes.
3. You can interrupt it at any time.
4. Limits are per task, not per token.

Cons

1. Currently limited to GitHub repos.
2. May not be as good as OpenAI’s Codex or Anthropic’s Claude Code for some use cases.
3. You need to double-check its work.

Pervasive, evasive malware thought to have been eliminated has wormed its way back into development environments.

Just a little over two weeks after GlassWorm was declared “fully contained and closed” by the open source OpenVSX project, the self-propagating worm is once again targeting Visual Studio Code extensions, add-ons that enhance open source VS Code, providing new features, debuggers, and other tools to improve developer workflows. Researchers from Koi have discovered a new wave of infections and three more compromised extensions.

First discovered in October, GlassWorm employs undisplayable Unicode characters to make malicious code invisible to code editors in VS Code environments. The worm has also now wriggled its way into GitHub repositories, hiding payloads in AI-generated commits that appear to be legitimate code changes.

Released by a Russia-based attack group, the malware is infecting victims around the world. This included dozens of individual developers and enterprises in the US, Europe, Asia, South America, and “a major government entity” in the Middle East.

“Same attacker infrastructure, still fully operational,” the Koi researchers note. They add, “this isn’t just about compromised extensions anymore. This is about real victims, critical infrastructure at risk, and a worm that’s doing exactly what we warned it would do: Spreading through the developer ecosystem.”

Also compromising GitHub repos

The Koi researchers identified three new OpenVSX code extensions containing GlassWorm that were downloaded at least 10,000 times in total:

• adhamu.history-in-sublime-merge (downloaded 4,000 times)
• ai-driven-dev.ai-driven-dev (downloaded 3,300 times)
• yasuyuky.transient-emacs (downloaded 2,400 times)

All three GlassWorm extensions are “still literally invisible” in code editors, the researchers note. They are encoded in unprintable Unicode characters that look like blank space to the human eye, but execute as JavaScript.

The attackers have posted new transactions to the Solana blockchain that outline updated remote command-and-control (C2) endpoints for distributing malicious payloads. But while these transactions are fresh, the servers remain unchanged, the researchers note.

“This demonstrates the resilience of blockchain-based C2 infrastructure — even if payload servers are taken down, the attacker can post a new transaction for a fraction of a cent, and all infected machines automatically fetch the new location,” they write.

Developers are also reporting that their GitHub repositories have been compromised with commits that appear as “project-specific” AI-generated code changes as part of normal development activity. These commits feature the same invisible Unicode malware as those in VS Code. Further, attackers are stealing GitHub credentials and using worm techniques to push commits to additional repositories.

“It is deeply concerning but not surprising to see GlassWorm re‑emerge so quickly,” noted Ensar Seker, CISO at threat intel company SOCRadar.

What makes this especially dangerous is the way attackers resurfaced the supply chain worm after it was removed, he noted. “The removal of a few extensions isn’t enough when the attacker controls propagation mechanisms and leverages points across multiple marketplaces.”

Highlights a ‘fundamental weakness’

Interestingly, attackers seemed to have gotten sloppy with their own infrastructure, leaving an exposed endpoint that Koi researchers exploited to surface data and a partial list of victims. They also discovered from the threat actor’s keylogger data that they use the open source C2 framework browser extension RedExt, and were able to access attackers’ user IDs for multiple messaging platforms and cryptocurrency exchanges.

The victim list has since been turned over to law enforcement, victims are being notified, and an active investigation is underway, the Koi researchers note.

David Shipley of Beauceron Security called these exploits both technological, and process and market-driven. OpenVSX doesn’t seem to have the resources as a community to manually review submitted code, he noted, instead relying on automated tools and publisher agreements.

This problem highlights a “fundamental weakness” in the open source market model: Free or low-cost approaches means resources aren’t available and incentives aren’t aligned to apply the required level of security for today’s threat environment, said Shipley.

“Put simply, when you’re not paid enough to do manual code reviews, you don’t,” he noted. “When you don’t have humans who can think checking for clever hacks, the clever hacks get in.”

Question the value of OpenVSX

Security teams should question the value proposition of OpenVSX, Shipley advised. If they’re willing to manually review and send alerts about code from the open source registry, they can mitigate risk. Otherwise, they should consider getting code from a curated source with more review controls.

“Supply chain and open source are now ‘it’ in the global game of cybersecurity tag, and they’re going to stay ‘it’ for a long time,” said Shipley. This could potentially be the case until economics are rebalanced to allow for more security, or the model “collapses under the weight of insecurity.”

“There’s no automated AI magic pixie dust that can stop 100% of these threats reliably,” he said. “Good enough automated scans were good enough until attackers realized this was a tremendously viable attack delivery method.”

SOCRadar’s Seker agreed that the core issue isn’t the malware, but the “systemic shift” in supply chain threats.

“The software supply chain is no longer just about dependencies,” he said, but  rather, its toolchains, marketplaces, and the entire development ecosystem. “You’ve got to treat developer infrastructure like production infrastructure.”

Developers and security teams should key into critical signals: malicious extensions containing invisible Unicode characters being uploaded; hidden C2 channels using blockchain memos and legitimate services like Google Calendar to evade takedowns; and infected developer machines being used as proxy nodes to launch further infections.

Companies should reduce attack surfaces by only allowing components from trusted publishers, disabling auto‑updates where possible, and maintaining an inventory of installed extensions, Seker advised, as well as monitoring for abnormal outbound connections from workstations, credential harvesting activity for developer‑level tokens (npm, GitHub, VS Code), and proxy or VNC server creation. Further, security teams should apply the “same rigor” they use for third-party libraries to their own developer toolchains.

“When malicious actors treat your IDE [integrated developer environment] as the launch pad, your supply chain exposure expands drastically,” said Seker.

Ultimately, he warned: “These are not typical supply chain attacks where you patch a single library and move on. They’re architected to persist.”

C#, Microsoft’s object-oriented, cross-platform, open source language for the .NET platform, has become the fastest-growing language on Tiobe’s monthly index of programming language popularity. C# may eventually surpass Java in popularity, Tiobe surmised.

In the latest Tiobe Programming Community index, published November 10, C# was rated at 7.65%, an increase of 2.67 percentage points from a year ago. With its high growth rate, C# could become Tiobe’s language of the year for 2025, a designation given to the language with the highest ratings increase during the. C# won this award for the year 2023.

“How did C# achieve this? Java and C# are battling for a long time in the same areas,” said Tiobe CEO Paul Jansen, in a bulletin accompanying this month’s index. “Right now it seems like C# has removed every reason why not to use C# instead of Java: it is cross-platform nowadays, it is open source, and it contains all new language features a developer wants. While the financial world is still dominated by Java, all other terrains show equal shares between Java and C#,” Jansen wrote. Furthermore, Microsoft is going strong and C# is still Microsoft’s most-backed programming language, Jansen noted.

C# has never rated higher than Java in the Tiobe index. But currently, the difference between the two is less than one percentage point, with Java ranked fourth with an 8.54% rating. Until recently, no language could beat the growth figures of Python, but Python seems to have plateaued, Jansen said. Python leads the Tiobe index with a 23.37% rating this month.

Software quality services company Tiobe bases its ratings on the number of skilled engineers world-wide, courses, and third-party vendors for each language. Tiobe uses popular websites including Google, Amazon, Wikipedia, Bing, and more than 20 others to calculate the ratings.

The Tiobe index top 10 for November 2025:

1. Python, 23.37%
2. C, 9.68%
3. C++, 8.95%
4. Java, 8.54%
5. C#, 7.65%
6. JavaScript, 3.42%
7. Visual Basic, 3.31%
8. Delphi/Object Pascal, 2.06%
9. Perl, 1.84%
10. SQL, 1.8%

The Go language, which ranked eighth last month, slipped to 11th place in Tiobe’s November index, with a rating of 1.72%. Go had a rating of 1.92% last month.

The alternative Pypl Popularity of Programming Language Index assesses language popularity based on how often language tutorials are searched on in Google.

The Pypl index top 10 for November 2025:

1. Python, 27.3%
2. Java, 12.47%
3. C/C++, 11.5%
4. Objective-C, 9.65%
5. R, 5.7%
6. JavaScript, 5.6%
7. C#, 3.62%
8. Swift, 3.41`%
9. PHP, 3.04%
10. Rust, 2.62%

Three newly disclosed high-severity bugs in the “runc” container runtime let attackers break out of containers despite standard hardening and isolation controls.

According to Aleksa Sarai, a senior software engineer at SUSE and an OCI board member, the bugs stem from logic flaws in how runc handles writes to certain procfs files, letting attackers inside containers hijack host privileges by abusing masked paths, console bind-mounts, and write gadgets.

“All these vulnerabilities ultimately allow (through different methods) for full container breakouts by bypassing runc’s restrictions for writing to arbitrary /proc files,” Sarai said in an advisory posted to the oss-sec list.

Sarai emphasized that while these attacks require custom mount configurations or untrusted images, the threat is very real for containerized systems, especially in orchestrators like Docker or Kubernetes.

The advisory urges users to update immediately to patched versions or apply the provided patches.

Masked-path issue: CVE-2025-31133

The first of the trio addresses a masked-path issue in runc where the container runtime replaces a file with a bind-mount to “/dev/null”, a data sink file on Unix-like systems. If an attacker can instead make /dev/null a symlink to a critical procfs file (e.g., /proc/sys/kernel/core_pattern or /proc/sysrq-trigger), runc inadvertently mounts that target read-write, granting the attacker host access.

On one variant, runc simply ignores a missing /dev/null and proceeds, which leads to information disclosure via masked files like “/proc/kcore” or “/proc/timer_list”, both sensitive kernel-visible interfaces.

Sarai warned that while the attack cannot mount arbitrary host files directly, the methods are sufficient to trigger full container breakout or host crash.

The flaw, tracked as CVE-2025-31133, affects all known runc versions and has received a severity rating of 7.3 out of 10. It has been fixed in versions 1.2.8, 1.3.3, and 1.4.0-rc.3.

Console and Write-Gadget Lurkers: CVE-2025-52565 & CVE-2025-52881

The second vulnerability, tracked as CVE-2025-52565, targets “/dev/console” bind-mount handling. An attacker can replace the target path with a symlink, which will cause runc to bind-mount the wrong target, allowing the attacker to gain write access to procfs paths.

“As with CVE-2025-31133, this happens after pivot_root(2) and so cannot be used to bind-mount host files directly, but an attacker can trick runc into creating a read-write bind-mount of /proc/sys/kernel/core_pattern or /proc/sysrq-trigger, leading to a complete container breakout,” Sarai said, adding that versions 1.0.0-rc3 and later remain vulnerable.

The third flaw (CVE-2025-52881) allows an attacker to bypass Linux Security Modules (LSM) such as SELinux or AppArmor by redirecting writes to procfs files. Once the LSM labels are effectively neutered, writes to host-level procfs become possible, enabling full host compromise.

“Based on our analysis, neither AppArmor nor SELinux can protect against the full version of the redirected write attack,” Sarai said. “ The container runtime is generally privileged enough to write to arbitrary procfs files, which is more than sufficient to cause a container breakout.”

Using rootless containers can help, as doing so will block most of the inadvertent writes, Sarai added. Additional analysis from Sysdig confirmed that all three flaws require the ability to start containers with custom mount configurations, which can be easily achieved through untrusted container images and Dockerfiles. Exploitation of these flaws can be done by monitoring suspicious symlink behaviors, Sysdig said. For this, it has added detection rules for its Secure and Falco users. 

We’re years into the generative AI boom, but much of what we see on X or LinkedIn is still mostly consumer-grade demoware. Sure, you can quickly spin up cool stuff with a ChatGPT prompt, but that’s not where the real magic (or money) will happen. It’s time to get serious about AI. For enterprises trying to put their data to work, the true revolution isn’t model creation at all. It’s inference: the application of those models to real, governed enterprise data to solve actual business problems. Inference will determine who wins in enterprise AI.

Put bluntly: You don’t have a model problem; you have a data-and-deployment problem. Not that you’re alone in this. Follow the money and it’s clear this is a systemic issue.

In the past few months, OpenAI and others have inked massive contracts with cloud vendors, not to build new models, but rather to ensure capacity to run existing ones. OpenAI’s reported $300 billion commitment to Oracle (disclosure: I work for Oracle), along with massive deals across other providers, isn’t about funding science projects. It’s about locking in predictable, industrial-scale capacity to run models. “Scaling frontier AI requires massive, reliable compute,” says OpenAI founder Sam Altman. The frontier labs can chase ever-larger models; the rest of us have to make them pay off.

So, the real question is how to use enterprise data to make that inference useful and run it at scale without breaking the budget.

Inference overtakes training

IDC forecasts that global investment in AI inference infrastructure will surpass spending on training infrastructure by the end of 2025. That’s a dramatic tipping point. It means enterprises and cloud providers are now spending more on the plumbing to deploy models than on creating the models themselves. The reason is simple: You train a model once in a while, but you run it every hour, all day. This isn’t to say model training is irrelevant. On the contrary, foundational research and the creation of smaller, domain-specific models remain critical. But for the vast majority of enterprises, the race to build a better ChatGPT is a distraction. The real, immediate value comes from figuring out how to make AI work for your data in production.

Lots and lots of production.

IDC also found that 65% of organizations are expected to be running more than 50 generative AI use cases in production by 2025, and more than 25% will exceed 100 use cases. Each of those use cases represents potentially thousands or millions of inference calls. This explosion of real-world usage is driving a corresponding explosion in infrastructure needs. When Amazon CEO Andy Jassy says Bedrock “could ultimately be as big a business as EC2,” he’s really saying the quiet part out loud: Managed inference is the new rent check.

AWS is hardly alone; every major cloud is racing to turn inference into a first-class utility. Nvidia’s latest GPUs are optimized not just for training huge models, but for churning out AI-driven answers efficiently. Startups are building chips and AI accelerators purely for fast, low-cost inference at the edge and in data centers. The reason is simple: If every application in the enterprise is going to embed some AI-driven smarts, the number of inferences running per day will explode, and so will demand for efficient infrastructure to serve them.

Feeding models the right context

Why this shift toward inference? Enterprises are starting to realize that the biggest, fanciest model means nothing without business-specific context and data. As Oracle cofounder Larry Ellison argues, the next frontier of AI isn’t model creation at all—it’s data contextualization: “The companies building massive language models may make headlines, but the real value lies in connecting those models to the right data: private, high-value, business-critical enterprise information.” Nor is he alone in this argument. Chaoyu Yang, founder and CEO of the open source platform BentoML, suggests that “inference quality is product quality” because inference “determines how fast your product feels, how accurate its responses are, and how much it costs to run every single day.”

Much of that data lives in an enterprise’s databases, which are becoming the “memory layer” for AI, a place to store the knowledge that models draw on, as I’ve argued. Today’s generative AI systems are “the ultimate amnesiacs,” processing each query in isolation. They don’t know your company’s data, nor do they retain interactions from last week, unless we connect them to a data source. Hence the rise of retrieval-augmented generation (RAG) and the explosion of vector databases. By storing facts and context in a database that an LLM can query on the fly, we give the model an external brain and a semblance of long-term memory. This dramatically improves relevance and reduces hallucinations because the model no longer needs to guess. Your data can tell it the answer.

A bigger model without better context just hallucinates at scale. No one needs that.

Accelerating into the inference era

We’ve known for a while that enterprises won’t fully embrace AI until the “boring” issues are solved, things like integration, security, compliance, and cost management. As Spring framework creator Rod Johnson puts it, “Startups can risk building houses of straw. Banks can’t.” Those issues come to the forefront when AI goes into production. The good news is that mainstream adoption brings discipline: unit tests for AI agents, monitoring for model outputs, explicit rules about what data an AI can or can’t use, etc. We’re now seeing that discipline being applied, which suggests AI is growing up and getting ready for real-world usage.

For enterprises that are anxious to move faster on putting their data (and inference) to work, hopeful that high-stakes AI projects will succeed at least as often as other projects, start by inventorying your highest-value data (customer interactions, supply chain logs, knowledge bases, etc.,) and think about how AI could unlock it. The goal is to bring the model to the data. This might mean using a cloud service that lets you fine-tune a foundation model on your data, or using retrieval techniques so the model can reference your data on the fly. Either way, your proprietary data is your AI edge. Focus on that more than on tweaking model architectures. It doesn’t matter how sophisticated your model is if you’re feeding it lame data. If you don’t know where this data sits, you’re not really ready for AI. Sorry.

Also, if you’re a developer, you need to think about where you can be most valuable. For starters, developers should be:

• Thinking beyond model training
• Mastering RAG pipelines
• Understanding vector database query optimization
• Writing secure, low-latency APIs to serve the model
• Creating prompts that are tightly coupled to data schemas
• Figuring out cost management and monitoring per API call

Second, you don’t need 50 AI use cases from the start. Instead, begin with a smaller list of high-impact use cases. This is about moving beyond slideware and into real production. Where can inference on your data move the needle? Maybe it’s generating custom product recommendations from customer histories, or automating answers to employee HR questions from policy documents. Use early wins to build momentum. Over time, you’ll expand the portfolio of AI-infused applications, but ensuring you have a solid foundation first pays dividends.

Third, optimize for cost-efficient inference, which is both a matter of choosing the right infrastructure and the right model size for the job. (Don’t use a 175-billion-parameter behemoth if a 3-billion-parameter model fine-tuned on your data performs almost as well.) The four big cloud providers are investing heavily to make this a reality.

Fourth, as exciting as it may be to really get humming with AI, don’t forget governance and guardrails. If anything, inference makes these concerns more urgent because AI is now touching live data and customer-facing processes. Put in place the “boring” stuff: data access controls (Which parts of your database can the model see?), prompt filtering and output monitoring (to catch mistakes or inappropriate responses), and policies on human oversight.

A healthy dose of AI pragmatism

The signals are clear: When budget plans, cloud road maps, and C-suite conversations all point toward inference, it’s time to align your business strategy. In practice, that means treating AI not as magic pixie dust or a moonshot R&D experiment, but as a powerful tool in the enterprise toolbox, one that needs to be deployed, optimized, governed, and scaled like any other mission-critical capability.

The first cloud era was won by whoever made compute cheap and easy. The AI era will be won by whoever makes intelligence on top of governed data cheap, easy, and safe. In practice, that means making inference ubiquitous, efficient, and enterprise-friendly. Chasing the biggest model is optional. Making inference work on your own data is not.

Artificial intelligence hides more complexity than any technology wave before it. Writing code, wiring APIs, and scaling infrastructure now feel effortless, but that ease conceals an expanding layer of invisible decisions beneath the surface. The hard problems have moved upward, into judgment, coordination, and systems thinking.

Shawn “Swyx” Wang’s 2023 post is widely credited with defining the new concept of the “AI engineer” as someone who effectively applies foundation models via APIs or open-source tools to build, evaluate, and productize AI systems rather than train them.

As that vision of the AI engineer has proven out, each new layer of abstraction keeps pushing engineers farther from the primitives of programming and framework internals. As a result, new kinds of hidden skills are emerging, suited to a world where large language models (LLMs), not humans, generate the first draft of our software.

Evaluation is the new CI

Continuous integration (CI) once defined good engineering hygiene. Today, the same discipline of measurement, testing, and automation has become essential for AI systems.

Jeff Boudier, product and growth lead at Hugging Face, the open-source platform that underpins much of today’s model sharing and evaluation ecosystem, describes this shift as the next great standard in software practice. “Evaluation is the new CI,” he told InfoWorld. “The real engineering leverage is not choosing the right model, it is building systems that can continually measure, test, and swap them.”

Hugging Face has built its platform around that principle. Its Evaluate library standardizes the process of assessing models across hundreds of tasks, while AI Sheets provides a no-code interface for comparing models on custom data sets. Developers can run evaluation workflows on on-demand GPUs through Hugging Face Jobs, and track progress on open leaderboards that benchmark thousands of models in real time. Together, these tools turn evaluation into a continuous engineering discipline. “The most important muscle companies need to build,” said Boudier, “is the ability to create their own evaluation data sets with relevant questions and good answers that reflect how their customers actually talk.”

Experts across academia and industry agree that this focus on evaluation will reshape software development. On Lenny’s Podcast, Hamel Husain, consultant at Parlance Labs, called evals “a systematic way of looking at your LLM data, creating metrics, and iterating to improve.” In the same podcast, Shreya Shankar, a PhD researcher at UC Berkeley, noted that evals provide “a big spectrum of ways to measure application quality,” from checking core functionality to evaluating how systems respond to ambiguous or unexpected user behavior. Engineer Shaw Talebi described the impact in a post on X: “Building LLM systems felt more like praying to the AI gods than engineering. But that all changed when I learned about eval-driven development.”

What testing was to software, evaluation is becoming to AI. It is the process that turns model unpredictability into something engineers can understand and control.

Adaptability as the core design principle

If evaluation defines quality, adaptability defines longevity. But adaptability in the AI era means something very different from learning new frameworks or languages. It now means designing systems that can survive change on a weekly or even daily basis.

“We are still in a phase where research is moving faster than engineers,” said Boudier. “Every week on Hugging Face there is a new top-five model. It is not about which one you pick, it is about building technology that lets you swap painlessly when a better one appears.”

Earlier generations of engineers adapted to hardware shifts or long product cycles. AI engineers adapt to a moving frontier. Model APIs, context windows, inference prices, and performance benchmarks can all change within a month. The challenge is not learning a tool, but building processes that absorb continuous disruption.

Barun Singh, chief product officer at Andela, a global talent marketplace that connects companies with remote software engineers and other technologists from emerging markets, believes this is the defining skill of the decade. “In many ways all knowledge work is undergoing this massive change, but software engineering is undergoing the biggest change first,” he told InfoWorld. “AI tools can either accelerate your understanding or create a false sense of productivity with a huge amount of debt.”

Singh sees adaptability as both technical and cognitive. “The more you can think at a high level and at ground level simultaneously, the more advanced you are,” he said. “The person who has both a deep understanding of classical architecture and real experience with LLMs in production, that is the hardest hire right now.” Singh also highlights the need for boundaries as a mark of professional maturity. “Creating boundaries for your work in the form of testing, so you catch mistakes before they reach production, becomes even more important in the age of AI.” In this sense, adaptability is not about chasing novelty. It is about designing systems and workflows that can safely accommodate it.

De-risking as an engineering discipline

The third skill shaping AI engineering is de-risking. Engineers now need to think like compliance officers, ensuring that data sources, models, and pipelines can withstand scrutiny.

Michele Lee, general counsel in residence at Wilson Sonsini, told InfoWorld that engineers must take ownership of these questions. “They are much closer to the data considerations and the architecture considerations,” she said. Lee noted that regulators around the world are already asking who is accountable when AI systems cause harm and that transparency about training data and model behavior is becoming an engineering requirement.

At the AI Conference 2025 held in San Francisco in October, Jessica Li Gebert, a data monetization consultant at Neudata, described this as both a risk and an opportunity. She called enterprise data “a treasure trove” but warned that many companies have no idea how to move from recognizing that value to realizing it. “There is a huge knowledge gap,” she said, “between believing your data has value and actually understanding how to unlock it safely.” Engineers who can build governance and lineage controls will be critical to bridging that gap.

Michael Hejtmanek, Gebert’s colleague and vice president of corporate solutions at Neudata, added that most enterprises still view sharing data with AI developers as “an insurmountable danger or risk.” Engineers fluent in both data systems and risk management will become essential to AI adoption.

Engineering what the models can’t

Over the last two decades, enterprises have competed for developer talent by perfecting the ergonomics of software creation: Continuous integration pipelines, cloud platforms, and collaborative workflows that made code more testable, reproducible, and observable. The next phase of that competition will hinge on the systems that bring the same rigor to AI.

The engineers who build evaluation loops, model registries, and governance frameworks are not just keeping pace with innovation. They are defining how intelligence is integrated into enterprise applications and workflows. In the same way CI brought more reliability, predictability, and security to software development, these new systems will make model behavior measurable, improvable, and accountable.

Do you think it’s time to turn an AI agent loose to do your procurement for you? As that could be a potentially expensive experiment to conduct in the real world, Microsoft is attempting to determine whether agent-to-agent ecommerce will really work, without the risk of using it in a live environment.

Earlier this week, a team of its researchers launched the Magentic Marketplace, an initiative they described as an “an open source simulation environment for exploring the numerous possibilities of agentic markets and their societal implications at scale.” It manages capabilities such as maintaining catalogs of available goods and services, implementing discovery algorithms, facilitating agent-to-agent communication, and handling simulated payments through a centralized transaction layer.

The 23-person research team wrote in a blog detailing the project that it provides “a foundation for studying these markets and guiding them toward outcomes that benefit everyone, which matters because most AI agent research focuses on isolated scenarios — a single agent completing a task or two agents negotiating a simple transaction.”

But real markets, they said, involve a large number of agents simultaneously searching, communicating, and transacting, creating complex dynamics that can’t be understood by studying agents in isolation, and capturing this complexity is essential “because real-world deployments raise critical questions about consumer welfare, market efficiency, fairness, manipulation resistance, and bias — questions that can’t be safely answered in production environments.”

They noted that even state-of-the-art models can show “notable vulnerabilities and biases in marketplace environments,” and that, in the simulations, agents “struggled with too many options, were susceptible to manipulation tactics, and showed systemic biases that created unfair advantages.”

Furthermore, they concluded that a simulation environment is crucial in helping organizations understand the interplay between market components and agents before deploying them at scale.

In their full technical paper, the researchers also detailed significant behavioral variations across agent models, which, they said, included “differential abilities to process noisy search results and varying susceptibility to manipulation tactics, with performance gaps widening as market complexity increases,” adding, “these findings underscore the importance of systematic evaluation in multi-agent economic settings. Proprietary versus open source models work differently.”

Bias and misinformation an issue

Describing Magentic Marketplace as “very interesting research,” Lian Jye Su, chief analyst at Omdia, said that despite recent advancements, foundation models still have many weaknesses, including bias and misinformation.

Thus, he said, “any e-commerce operators that wish to rely on AI agents for tasks such as procurement and recommendations need to ensure the outputs are free of these weaknesses. At the moment, there are a few approaches to achieve this goal. Guardrails and filters will enable AI agents to generate outputs that are targeted and balanced, in line with rules and requirements.”

Many enterprises, said Su, “also apply context engineering to ground AI agents by creating a dynamic system that supplies the right context, such as relevant data, tools, and memory. With these tools in place, an AI agent can be trained to behave more similarly to a human employee and align the organizational interests.”

Similarly, he said, “we can therefore apply the same philosophy to the adoption of AI agents in the enterprise sector in general. AI agents should never be allowed to behave fully autonomously without sufficient check and balance, and in critical cases, human-in-the-loop.”

Thomas Randall, research lead at Info-Tech Research Group, noted, “The key finding was that when agents have clear, structured information (like accurate product data or transparent listings), they make much better decisions.” But the findings, he said, also revealed that these agents can be easily manipulated (for example, by misleading product descriptions or hidden prompts) and that giving agents too many choices can actually make their performance worse.

That means, he said, “the quality of information and the design of the marketplace strongly affect how well these automated systems behave. Ultimately, it’s unclear what massive value-add organizations may get if they let autonomous agents take over buying and selling.”

Agentic buying ‘a broad process’

Jason Anderson, vice president and principal analyst at Moor Insights & Strategy, said the areas the researchers looked into “are well scoped, as there are many different ways to buy and sell things. But, instead of attempting to execute commerce scenarios, the team kept it pretty straightforward to more deeply understand and test agent behavior versus what humans tend to assume naturally.”

For example, he said, “[humans] tend to narrow our selection criteria quickly to two or three options, since it’s tough for people to compare a broad matrix of requirements across many potential solutions, and it turns out that model performance also goes down when there are more choices as well. So, in that way there is some similarity between humans and agents.”

Also, Anderson said, “by testing bias and manipulation, we can see other patterns such as how some models have a bias toward picking the first option that met the user’s needs rather than examining all the options and choosing the best one. These types of observations will invariably end up helping models and agents improve over time.”

He also applauded the fact that Microsoft is open sourcing the data and simulation environment. “There are so many differences in how products and solutions are selected, negotiated, and bought from B2B versus B2C, Premium versus Commodities, cultural differences and the like,” he said. “An open sourcing of this tool will be valuable in terms of how behavior can be tested and shared, all of which will lead to a future where we can trust AI to transact.”

One thing this blog made clear, he noted, “is that agentic buying should be seen as a broad process and not just about executing the transaction; there is discovery, selection, comparison, negotiation, and so forth, and we are already seeing AI and agents being used in the process.” 

However, he observed, “I think we have seen more effort from agents on the sell side of the process. For instance, Amazon can help someone discover products with its AI. Salesforce discussed how its Agentforce Sales now enables agents to help customers learn more about an offering. If [they] click on a promotion and begin to ask questions, the agent can them help them through a decision-making process.” 

Caution urged

On the buy side, he said, “we are not at the agent stage quite yet, but I am very sure that AI and chatbots are playing a role in commerce already. For instance, I am sure that procurement teams out there are already using chat tools to help winnow down vendors before issuing RFIs or RFPs. And probably using that same tool to write the RFP. On the consumer side, it is very much the same, as comparison shopping is a use case highlighted by agentic browsers like Comet.”

Anderson said that he would also “urge some degree of caution for large procurement organizations to retool just yet. The learnings so far suggest that we still have a lot to learn before we see a reduction of humans in the loop, and if agents were to be used, they would need to be very tightly scoped and a good set of rules between buyer and seller be negotiated, since checking ‘my agent went rogue’ is not on the pick list for returning your order (yet).”

Randall added that for e-commerce operators leaning into this, it is “imperative to present data in consistent, machine-readable formats and be transparent about prices, shipping, and returns. It also means protecting systems from malicious inputs, like text that could trick an AI buyer into making bad decisions —the liabilities in this area are not well-defined, leading to legal headaches and complexities if organizations question what their agent bought.”

Businesses, he said, should expect a future where some customers are bots, and plan policies and protections, accordingly, including authentication for legitimate agents and rules to limit abuse.

In addition, said Randall, “many companies do not have the governance in place to move forward with agentic AI. Allowing AI to act autonomously raises new governance challenges: how to ensure accountability, compliance, and safety when decisions are made by machines rather than people — especially if those decisions cannot be effectively tracked.”

Sharing the sandbox

For those who’d like to explore further, Microsoft has made Magentic Marketplace available as an open source environment for exploring agentic market dynamics, with code, datasets, and experiment templates available on GitHub  and Azure AI Foundry Labs.

This article originally appeared on Computerworld.

Kong has released Insomnia 12, an update to the company’s open-source API development platform. The update is intended to accelerate API and Model Context Protocol (MCP) server development with AI-powered collaboration and testing.

Unveiled November 4 and generally available now, Insomnia 12 enables users to build, test, and deploy faster with native MCP clients, AI mock servers, and AI-powered commit suggestions, Kong said. The latest version of Insomnia addresses challenges in building MCP servers pertaining to how to validate and test what is being built quickly and reliably without complex steps. With Insomnia 12, the platform’s test-iterate-debug workflow is extended to AI-native development, while AI-driven features are introduced that reduce manual overhead and accelerate development, according to Kong.

Key capabilities cited for Insomnia 12 include:

• Native MCP clients enable testing and debugging of MCP servers with the same test-iterate-debug workflow Kong provides for APIs. Users can connect directly to servers, manually invoke any tool, prompt, or resource with custom parameters, and inspect protocol-level and authentication messages and responses.
• AI mock generation allows users to create mock servers by describing their requirements in natural language, providing a URL, JSON sample, or OpenAPI spec.
• AI-powered commits automatically generate descriptive commit messages and logical file groupings by analyzing diffs and history.
• Users can choose between cloud-based large language model (LLM) providers or local LLMs, giving teams control over where code and data reside while balancing performance and privacy needs.
• Insomnia 12 makes it easier for teams to collaborate on API and MCP development. Git Sync provides seamless version control and cross-machine collaboration, while enterprise users can instantly trial advanced security,  governance, and compliance features such as SCIM (System for Cross-domain Identity Management), SSO (Single Sign On), and RBAC (Role-based Access Control). 

AWS is finally making planning for cloud deployments less of a guessing game for enterprise teams.

The cloud service provider has launched a new planning tool named Capabilities by Region, which provides visibility into the availability of services, tools, and features, including AWS CloudFormation resources, across its global regions.

This visibility is critical to enterprises for planning and successfully deploying workloads in the cloud, and without it could lead to fallouts ranging from spiralling operational expenses and service outages to compliance breaches, analysts say.

“Enterprises struggle with regional service parity. They often discover gaps late in deployment, which causes delays and costly rework. This capability with authoritative, forward-looking visibility into service availability will help address such issues,” Charlie Dai, vice president and principal analyst at Forrester, said.

Dai was referring to the tool’s capability that shows whether a particular service or feature is planned for a region or not.

AWS’s ability to showcase planned service and feature expansions is a key differentiator from rival offerings, said Pareekh Jain, principal analyst with Pareekh Consulting.

While Microsoft Azure’s Product Availability by Region portal lists services by geography, it lacks forward-looking timelines and the unified API comparability that AWS’s Capabilities by Region delivers, Jain noted.

Region Picker, which is a similar offering from Google, too, falls short on granular, future-facing service or API roadmaps and focuses on passing information that would help enterprises optimize for price, carbon footprint, and latency.

According to Jain, Capabilities by Region can help enterprises avoid overspending in the cloud, which is a widespread and growing concern.

Industry estimates show that nearly 30% of most cloud budgets are wasted due to underutilized resources or poor visibility into resources, Jain added.

Unlike AWS CloudFormation and the AWS Cost Explorer, which are other tools related to planning and management of cloud deployments and are accessible via the AWS Management Console, AWS’s Capabilities by Region tool can be accessed via its Builder Center — an AWS products and services-related community portal targeted at cloud architects and developers.

Analysts say the new tool has been deliberately placed outside the AWS Management Console to avoid disruptions to live deployments.

“It is safer for non-admins/partners, and avoids touching live environments. Keeping it outside the Console lowers barriers to entry as no AWS account is needed,” Jain said. AWS is also making all the data inside Capabilities by Region accessible through the AWS Knowledge MCP Server, which will provide developers an avenue to automate cloud planning or get recommendations for cloud deployments via generative AI assistants.