A critical remote code execution (RCE) vulnerability in GitHub could potentially allow attackers to execute arbitrary code on GitHub.com and GitHub Enterprise Server.

Uncovered by Wiz researchers, the now-patched bug exploited how GitHub handles server-side “git push” operations. By crafting malicious input within a standard Git push, an authenticated user could execute arbitrary commands via GitHub’s backend Git processing pipeline.

GitHub acknowledged the severity of the finding, with CISO Alexis Wales noting, “A finding of this caliber and severity is rare, earning one of the highest rewards available in our Bug Bounty program.”

GitHub fixed the issue on GitHub.com and released patches for all supported versions of GitHub Enterprise Server within hours of the report. However, Wiz said that 88% of Enterprise Server instances remained vulnerable on the internet at the time of public disclosure.

GitHub’s faulty processing of git push

The flaw, tracked as CVE-2026-3854, stemmed from how GitHub processes git push requests within its backend Git infrastructure. According to Wiz, the issue involves an internal component referred to as X-STAT, which sits in the path of GitHub’s server-side handling of Git operations.

Wiz researchers found that a specially crafted git push could pass maliciously structured input into X-STAT, where it was not safely handled before being incorporated into backend command execution. Because this processing happens server-side as part of GitHub’s normal handling of repository events, the input could influence how commands were constructed or executed within that pipeline.

The flaw received a near-critical CVSS rating of 8.8 out of 10, and was fixed in GitHub Enterprise Server versions 3.14.25 through 3.20.0. The flaw was categorized by GitHub as a “command injection” issue, resulting from “improper neutralization of special elements used in a command.”

AI was reportedly used in finding this flaw, using the IDA MCP (AI-augmented) reverse engineering tooling. “This is one of the first critical vulnerabilities discovered in closed-source binaries using AI, highlighting a shift in how these flaws are identified,” Wiz researcher Sagi Tzadik said in a blog post. “Despite the complexity of the underlying system, the vulnerability is remarkably easy to exploit.”

Full compromise across tenants

In its analysis, Wiz detailed how the issue could be escalated from initial command execution to full remote code execution on affected systems.

“On GitHub.com, this vulnerability allowed remote code execution on shared storage nodes. We confirmed that millions of public and private repositories belonging to other users and organizations were accessible on the affected nodes,” Tzadik said, adding that the impact was even more severe for self-hosted environments. On GitHub Enterprise Server, the vulnerability granted full server compromise, including access to all hosted repositories and internal secrets.

The article originally appeared in CSO.

Oracle NetSuite is adding AI capabilities to SuiteCloud to help developers customize its ERP platform faster using natural language prompts.

In a statement, the company said its NetSuite SuiteCloud Agent Skills “will make it easier for developers to create customized vertical and industry-specific applications by giving AI coding assistants a better understanding of the conventions, patterns, and best practices in SuiteCloud – NetSuite’s standards-based AI extensibility and customization platform.”

The new skills give AI coding assistants NetSuite-specific development guidance, including UI framework references, permission codes, SuiteScript fields, documentation practices, OWASP security guidance, and tools to help migrate older SuiteScript 1.0 code to SuiteScript 2.1.

This comes as developers increasingly use AI coding assistants in their daily work. Stack Overflow’s 2025 Developer Survey found that 84% of respondents were either using or planning to use AI tools in their development process, up from 76% a year earlier.

The tougher challenge for enterprise software vendors is making those tools understand how business applications actually work. For platforms like NetSuite, useful AI assistance requires knowledge of the platform’s own APIs, permission models, UI conventions, and business workflows. In ERP systems, even a small customization error can ripple into core business operations.

Impact and adoption challenges

NetSuite said it is “introducing SuiteCloud development guidance across more than 25 AI coding platforms.” Analysts said this could reduce friction for developers by making NetSuite-specific knowledge available across widely used AI coding tools, rather than limiting it to a single vendor-controlled environment.

“If you can package platform-specific knowledge in a format that drops into any of the major AI coding tools through an open framework, removing a lot of friction, that is great for enterprise developers,” said Neil Shah, VP for research at Counterpoint Research.

However, broader adoption across enterprise software platforms may depend on how ready vendors and customers are to switch from their long-established development practices.

“Enterprises have already invested in systems and personnel to build their applications using their own proprietary approaches,” Shah said. “We will have to see how soon vendors adopt this new approach and whether they are ready to let go of sunk costs and perhaps some personnel.”

In this sense, the technology may be more immediately useful for new applications or for modernization work around legacy systems, rather than for wholesale redevelopment of existing enterprise applications. Cost and governance are other important considerations.

“What the token economics will be as enterprises get up the learning curve remains to be seen, as the initial token burn rate is likely to be significantly higher,” Shah said. “Also, security and risk are big challenges here, as ERP apps are tightly coupled, and one small change in approach that does not work well with the proprietary stack could break downstream workflows and become a disaster.”

That means companies are likely to test such tools cautiously, especially for customizations that touch sensitive data. Shah said that enterprises will have to use this in a sandboxed environment to check for code hallucinations and to see what breaks in terms of business logic, security, or privacy.

Microsoft Word was once the most commonly used software in the world. A .doc file was the lingua franca of the computing world, and “send me a Word doc” became part of the business lexicon. Word won the battle against WordPerfect, which was never quite able to make the transition to the world of Windows. 

That battle with WordPerfect might have been a pyrrhic victory, however, as Word ended up something quite different than what the original product manager might have hoped. By out-featuring WordPerfect, MS Word became a bloated and unwieldy application that had way too much stuff jam-packed into it. It fell victim to the “just because you can do it doesn’t mean you should” syndrome. Each new release included more obscure and less-used new features that looked good on a marketing sheet, but that only made the product more confusing to end users.

And all that happened in a world where new features had to be coded by hand and took weeks or months. What is going to happen to software now that adding features can be done with AI in an afternoon?

Highway to featuritis

Software product managers have a challenging job. One of the biggest difficulties is central to their role: What features get added next? Adding features usually takes time, and thus a backlog of features accumulates. This gives the product manager time to vet features, examine them, determine their fit for the product, and ultimately decide if the feature is worth the effort. Items in the backlog are constantly evaluated and reevaluated to determine if they will make the product more appealing to customers.

In other words, the existence of the backlog gives the product manager time for proper due diligence. But with the advent of agentic AI, the days of features languishing in the backlog are coming to an end. Agentic coding will allow features to be conceived in the morning and shipped in the afternoon. Our build and test pipelines already allow bugs to be fixed and deployed in hours. We are about to experience the same acceleration for product features.

And this presents a new challenge to product managers. Instead of having to decide what well-vetted features to build next, they are going to have to make rapid decisions about whether a given feature is worth doing. 

The temptation, of course, is to add as many features as possible, because the competition is certainly already adding them as fast as possible. And this puts us back into the situation where “featuritis” or feature creep threatens to bloat and overcomplicate a product — something that good product managers are careful to avoid.

Coding unleashed

The problem is made worse by the fact that developers can add features so quickly that they can — and probably will — bypass normal processes and just add the feature without anyone stopping to ask if the feature is valuable, desirable, or even useful. Those processes — which take into account security issues, legal factors, and market forces — exist for a reason. Bypassing them can have serious ramifications. The challenge shifts from not having enough time to build what you want to not having the time to decide what not to build.

This will require a cultural shift in organizations. Product managers will have to shift from trying to convince their organization to squeeze one more feature into a product cycle to trying to keep superfluous features out. Instead of being pressured by upper management to add more features, forces will start to muster to limit the ability of teams to add features just to keep things under control. 

It used to be the hard part was jamming in that extra feature. Now? The hard part will be keeping them out.

If Python developers have one consistent gripe about their beloved language, it tends to be this: Why is it so hard to take a Python program and deploy it as a standalone artifact, the way C, C++, Rust, Go, and even Java can be deployed? Are we stuck with requiring everyone to install the Python runtime first before they can use a Python program? And why are all the workarounds for this problem so clunky?

One of the features that makes Python so appealing — its dynamism — is also the reason Python apps are so difficult to bundle and deploy. Not impossible, but challenging. Bundled Python apps end up being big packages, never less than a dozen megabytes or more. Plus, the tools for creating those bundles aren’t the friendliest or most convenient.

So what is it about Python’s dynamism that’s reponsible for this?

The pleasures and perils of Python’s dynamism

When we talk about Python as a “dynamic” language, that means more than the fact that Python apps are executed with an interpreter. It also means that many decisions about the behaviors of Python apps are made at run time, and not ahead of time.

Many of Python’s conveniences come from this design choice. Variables don’t have to be declared in advance, and they are automatically garbage-collected when no longer in use. Imports can be declared ahead of time, but they can also be generated at run time — and theoretically they can import code from anywhere. Python code can even be generated and interpreted at run time.

These flexible behaviors all come at a cost: it’s hard to predict what a Python program may do at run time. One of the factors that make it so difficult is that the code in a Python program can theoretically be changed by other code. A library can be imported, have methods overridden, even have its bytecode altered. It’s hard to optimize Python for high performance because so many optimizations rely on knowing what the code will do ahead of time (although the new JIT and other changes are helping with that).

Two big consequences arise from all this:

1. The most reliable way to run a Python program is through an instance of the Python runtime, so that all of Python’s dynamic behaviors can be recreated. Any solution that turns a Python app into some kind of redistributable package must include the runtime in some form. And any solution that would include “just enough” of the Python runtime to run that program would break promises about Python’s dynamism.
2. It’s difficult to package a Python app for standalone use because it’s difficult to predict which Python capabilities the app will need at runtime. Not impossible, but difficult enough that it’s far from trivial. It also means that any third-party libraries the app requires must be bundled with the app in their entirety.

Third-party libraries: All or nothing

Python apps require very clear declarations of which libraries they need to run, via pyproject.toml or requirements.txt. What’s more, Python’s dynamism means you can’t make any assumptions about which parts of those libraries are actually used.

In the world of C++ or Rust, you can compile statically-linked binaries that omit any code that isn’t called from within your program. Python libraries can’t work this way; any part of the library could be called by any code at any time. Therefore the entire library — including all of its own dependencies, like binaries — must be included.

Thus any attempt to package a Python app as a standalone executable must include all of its dependencies. The result can be quite a large package — large enough to be off-putting to those who don’t want to deliver, say, a 300MB artifact to their users. But Python’s dynamism requires including everything.

In theory you could trace the call path of a Python program and “tree-shake” it — remove everything that never gets called. But that would work only for that particular run of the program. Guaranteeing this would work for any run of the program, including those where Python’s dynamism gets exploited, is all but impossible.

The only workable solution: A total package

All of these issues mean we have only a few ways to deploy a Python program reliably:

• Install it into an existing Python interpreter. This is the most common scenario, but it requires setting up a copy of the interpreter. At best, this means an entirely separate step, one fraught with complexity if Python versions already exist on the system. This is also the scenario people want to avoid in the first place, because they want to make their app as easy to redistibute as possible.
• Bundle the interpreter with the program and its dependencies. This is the approach taken by projects like PyInstaller and Nuitka. The downsides are that the deliverables tend to be quite large, and creating them requires learning the quirks of these projects. But they do work.
• Use a system like Docker to bundle the program. Docker containers introduce their own world of trade-offs. On the one hand, you get absolutely everything you need to run the program, including any system-level dependencies. On the other hand, the resulting container can be positively hefty. And, of course, using Docker means adopting an additional software ecosystem.

Some of the newer solutions to the problem try to solve one particular pain point or another, as a way to make the whole issue less unpalatable. For instance, PyApp uses Rust to build a self-extracting binary that installs the needed Python distribution, your app, and all its dependencies. It has two big drawbacks: you need the Rust compiler to build it for your project, and your project must be an installable package that uses the pyproject.toml standard. The first of these requirements is likely to be the larger hurdle; most Python projects need a pyproject.toml of some kind at this point.

Another solution is one I wrote myself: pydeploy. It also requires the project in question be installable via pip install. Otherwise, pydeploy needs nothing more than Python’s standard library to generate a self-contained deliverable with the Python runtime included. Its big drawback right now is that it only works for Microsoft Windows, but in theory it could work on any operating system.

Maybe someday

All the recent major changes being proposed for Python, such as the new native JIT and full concurrency or multithreading, are meant to enhance Python’s behavior as a dynamic language. Any proposals designed to change that dynamism essentially would mean creating a new language with different expectations about its behavior.

While there have been attempts to launch variants of Python that address one limitation or another (e.g., Mojo), the original Python language, for all its limits, remains a massive center of gravity. As the language continues to develop, there’s always the chance we’ll someday see a “blessed”, Python-native solution to the problem of distributing standalone Python apps. In the meantime, the solutions we have may be less than elegant, but at least we have solutions.

The threat actor seeding the Open VSX code marketplace with fraudulent extensions that download the GlassWorm malware has uploaded 73 more impersonated links, as its attempt to infect software supply chains continues.

Philipp Burckhardt, head of threat intelligence at Socket, which revealed the latest activity, called it a “significant escalation” in the gang’s activity, after it added 72 malicious extensions last month.

The extensions impersonate trusted developer tools. More recently, the listed extensions contain benign code so they will evade malware scanners. Later, after connecting automatically to newly-created GitHub or other public accounts, they download GlassWorm to developers’ computers as an update. This latest wave includes some extensions that rely on bundled native binaries.

“The extension itself acts as a thin loader,” Socket explained in its report. “By shifting critical logic outside of what tools typically scan, and spreading it across multiple delivery mechanisms, the threat actor increases the likelihood of evading detection.”

Of the 73 new extensions seen by Socket, last week, six were activated to connect to sources of malware. This week, eight more were activated, Burckhardt said in an interview.

Socket has notified the Eclipse Foundation, which oversees the Open VSX marketplace, of the latest fraudulent additions, and Burckhardt expects that by now all 73 have been deleted.

But the continuing attacks are another example of how threat actors are trying to use open code marketplaces used by developers, such as Open VSX and npm, to compromise applications as they are being created, to enable the later distribution of data stealing malware.

[Related content: GlassWorm malware spreads via dependency abuse]

Extensions are add-on modules that help developers speed application creation. Since Microsoft’s Visual Studio Code is one of the most common code editors around the world, VS Code extensions are a tempting target for threat actors. Popular extensions include utilities that do everything from analyzing JavaScript, TypeScript, and other supported languages for potential errors, to AI tools that suggest code completions. The Eclipse Foundation says the Open VSX registry hosts over 12,000 extensions from more than 8,000 publishers.

A systemic gap in dev environment security

GlassWorm, despite its name, isn’t a worm, but a loader. According to StepSecurity, GlassWorm’s stage 3 payload includes a dedicated credential theft module that harvests GitHub and npm tokens from multiple sources. The attacker then uses these credentials to force-push malware into all of the victim’s repositories.

The loader includes host gating that detects and negates the dropping of malware on Russian language computers, leaving Burckhardt to suspect that the threat actors behind this campaign are Russian.

Tanya Janca, who teaches secure coding through her firm, SheHacksPurple, observed, “what makes the GlassWorm campaign particularly dangerous and interesting is that it exposes a systemic gap in how we secure developer environments.”

“With software packages, we have lockfiles, pinned hashes, and reproducible builds. With IDE [integrated development environment] extensions, we have almost nothing. There is no integrity verification, no equivalent of package-lock.json, and most organizations have no policy whatsoever governing what developers are allowed to install into their IDEs.”

 Malicious actors have noticed the gap. For them, targeting VS Code extensions is a lower-friction attack surface than targeting packages, she said, specifically because the controls that organizations have spent years building around their dependency pipelines simply do not exist for extensions.

The reason only some of the 73 extensions had been activated before the warning spread is certainly deliberate, Janca added. “This looks like an intentionally staged deployment: publish them all broadly to establish credibility and accumulate downloads, then activate harmful subsets over time to avoid triggering mass detection and to preserve a reserve of ready assets if some are removed or noticed.

Advice for developers

Janca said developers who want to reduce their exposure to the GlassWorm campaign should start with the basics: install fewer extensions and treat each one as a dependency with real risk attached. Disable auto-update so you control when updates are applied, and carefully evaluate each one. Use a next-generation SCA tool that covers IDE extensions and other areas of the supply chain, not just third party packages and components.

“One thing most people overlook,” she added: “Audit what you already have installed. Extensions accumulate over the years and the developer who built that extension in 2022 may not be the same person maintaining it today.”

Teams that want stronger guarantees should use a behavioral monitoring tool that watches runtime activity, Janca said, not just install-time content. Establish a formal approval process for new extensions, with security sign-off. Maintain an allowlist of approved extensions, and do not install from alternative marketplaces like Open VSX without treating it as a higher-risk source.

“The same discipline we apply to open source packages needs to be applied to the tools living inside our IDEs and the rest of our software supply chain,” she said.

Train developers to recognize signs

Burckhardt said CSOs need to ensure developers are trained to recognize phony extensions, carefully examining the names of files they are looking for to avoid being fooled by typosquatting, and verifying a publisher is legitimate. Some GlassWorm-related extensions have more downloads than a legitimate extension, he noted, a suspicious sign.

Developers should also be restricted in what they can download, he added, particularly extensions newly added to a repository. It may also be necessary to disable the ability to automatically download extension updates, he said, and developers should be warned to only download extensions they need, not ones to experiment with.

CSOs should also look for security tools that give visibility into what developers download, Burckhardt added.

And to help detect Open VSX issues, earlier this month the Eclipse Foundation announced the Open VSX Security Researcher Recognition Program to encourage responsible vulnerability disclosure.

This article originally appeared on CSOonline.

GitHub is moving its Copilot coding assistant to a usage-based billing model, replacing fixed subscription pricing with consumption-based charges as demand for AI-driven development workloads increases.

The change, announced in a company blog, will take effect on June 1 and will apply to Copilot Pro, Pro+, Business, and Enterprise plans. Under the new model, usage will be measured through “AI credits,” reflecting the compute resources consumed during interactions with the service.

“Today, we are announcing that all GitHub Copilot plans will transition to usage-based billing on June 1, 2026,” Mario Rodriguez, GitHub’s Chief Product Officer, wrote in the blog post. “Instead of counting premium requests, every Copilot plan will include a monthly allotment of GitHub AI Credits, with the option for paid plans to purchase additional usage.”

There will be no change to base subscription prices, and every plan will include a monthly allotment of credits matched to its price, and once that allotment is exhausted, customers can either buy more or stop, the blog post added. Token consumption will be charged at the published API rate of the underlying model.

The change marks the second pricing recalibration for Copilot in less than a year. GitHub introduced premium request limits in June 2025, capping Pro users at 300 monthly premium requests and Enterprise users at 1,000, with overages billed at $0.04 each.

It also follows a week of tactical changes. The company tightened limits on Copilot Free, Pro, Pro+, and Student plans last week and paused self-serve purchases of Copilot Business, framing both as short-term reliability measures while it stood up the new metering infrastructure. Rodriguez said those limits would be loosened once usage-based billing is in effect.

Why GitHub is changing the model

Rodriguez framed the move as a response to how Copilot is being used today, rather than a price increase.

“Copilot is not the same product it was a year ago,” he wrote in the blog. “It has evolved from an in-editor assistant into an agentic platform capable of running long, multi-step coding sessions, using the latest models, and iterating across entire repositories. Agentic usage is becoming the default, and it brings significantly higher compute and inference demands.”

Under the existing premium request unit (PRU) model, a quick chat question and a multi-hour autonomous coding run can cost the user the same amount, the post said.

“GitHub has absorbed much of the escalating inference cost behind that usage, but the current premium request model is no longer sustainable,” Rodriguez wrote. “Usage-based billing fixes that. It better aligns pricing with actual usage, helps us maintain long-term service reliability, and reduces the need to gate heavy users.”

Sanchit Vir Gogia, chief analyst at Greyhound Research, said the sustainability framing was accurate but incomplete. GitHub was managing its own inference cost exposure, he said, and the per-seat model was breaking under agentic workloads at the same time. “The first is the proximate cause. The second is the structural cause of the proximate cause,” Gogia said.

A single developer seat, he added, now contained two very different economic profiles. “A quiet user nudging completions across a normal working day. A power user orchestrating hour-long edits on a frontier model with heavy context. The first costs almost nothing to serve. The second can cost an order of magnitude more, sometimes considerably more than that.”

A market moving to consumption pricing

GitHub is not the first AI coding vendor to pivot to consumption-based pricing. Cursor moved from fixed fast-request allotments to credit pools in June 2025, prompting a public apology and refunds after some users incurred large overages. Anthropic took a similar path with Claude Code, charging on a token basis through its API with capped subscription tiers layered on top. OpenAI followed, moving Codex pricing onto token-based credits.

The shift comes as enterprise AI cost overruns are emerging as a recurring CIO concern. IDC has forecast that the Global 1,000 companies will underestimate their AI infrastructure costs by 30% through 2027, a gap that token-metered tooling will widen rather than narrow.

Gogia said the pricing convergence across vendors was a workload event being expressed through pricing, not a pricing fashion. He warned that better telemetry from vendors would not, on its own, contain the spend. “The dashboards do not lower the bill. The architecture lowers the bill. The dashboards merely describe the bill while it arrives,” he said.

GitHub is keeping its plan prices unchanged across Copilot Pro at $10 a month, Pro+ at $39, Business at $19 per user per month, and Enterprise at $39, with each plan now carrying a monthly pool of AI Credits worth the same amount as the subscription, the post added. GitHub will preview the new bills on customer billing pages from early May, ahead of the June 1 transition.

Xiaomi has released and open-sourced MiMo-V2.5 and MiMo-V2.5-Pro under the MIT License, giving developers another potentially lower-cost option for building AI agents that can run longer tasks such as coding and workflow automation.

Both models support a 1-million-token context window, the company said. MiMo-V2.5-Pro is designed for complex agent and coding tasks, while MiMo-V2.5 is a native omnimodal model that can work with text, images, video, and audio.

The release comes as agentic AI workloads are putting new pressure on enterprise AI budgets. These systems can burn through large numbers of tokens as they plan, call tools, write code, and recover from errors, making cost and deployment control increasingly important for developers.

By using the MIT License, Xiaomi said it is allowing commercial deployment, continued training, and fine-tuning without additional authorization. Tulika Sheel, senior vice president at Kadence International, said the MIT License can make it attractive. “It allows enterprises to freely modify, deploy, and commercialize the model without restrictions, which is rare in today’s AI landscape,” Sheel said.

“On ClawEval, V2.5-Pro lands at 64% Pass^3 using only ~70K tokens per trajectory — roughly 40–60% fewer tokens than Claude Opus 4.6, Gemini 3.1 Pro, and GPT-5.4 at comparable capability levels,” Xiaomi said in a blog post.

The models use a sparse mixture-of-experts (MoE) design to manage compute costs. The 310-billion-parameter MiMo-V2.5 activates only 15 billion parameters per request, while the 1.02-trillion-parameter Pro version activates 42 billion. Xiaomi said the Pro model’s hybrid attention design can reduce KV-cache storage by nearly seven times during long-context tasks.

Xiaomi cited several long-horizon tests, including a SysY compiler in Rust that MiMo-V2.5-Pro completed in 4.3 hours across 672 tool calls, passing 233 of 233 hidden tests. It also said the model produced an 8,192-line desktop video editor over 1,868 tool calls across 11.5 hours of autonomous work.

Will enterprises adopt MiMo?

Whether Xiaomi’s MiMo-V2.5 models can gain adoption among enterprise developers over closed frontier models for agentic coding and automation workloads will depend on how enterprises evaluate performance, cost, and risk.

“When assessing Xiaomi’s MiMo-V2.5 and its variants, enterprise developers should look at the total cost of ownership,” said Lian Jye Su, chief analyst at Omdia. “The TCO consists of token efficiency, cost per successful task, and the absence of licensing costs associated with proprietary models. Closed frontier models may still win on generic tasks, and the hardest edge cases, but open-weight models excel in agentic work that is high-volume in nature.”

Pareekh Jain, CEO of Pareekh Consulting, said enterprises should assess MiMo-V2.5 less as a replacement for Claude or GPT and more as a cost-efficient agent model for high-token workloads.

“The key benchmark signal is not just accuracy, but tokens per successful task,” Jain said. “Frontier models often reach higher success rates on complex coding benchmarks, but do so with massive reasoning overhead. MiMo-V2.5 is designed for Token Efficiency, meaning it achieves comparable results with significantly fewer input and output tokens.”

Jain said that could make MiMo-like models useful as “economic workhorses” for repetitive coding, QA, migration, documentation, testing, and automation workloads, while closed frontier models remain the quality ceiling for the hardest tasks.

Ashish Banerjee, senior principal analyst at Gartner, said models like MiMo could materially shift enterprise AI economics for long-horizon agents.

“When tasks stretch into millions of tokens, metered proprietary APIs stop looking like a convenience and start looking like a tax on iteration,” Banerjee said. “By contrast, MiMo’s MIT license, open weights, 1M-token context window, and relatively low pricing make private-cloud or self-hosted deployment strategically credible.”

However, Banerjee said this does not mean enterprises will abandon proprietary APIs.

“Enterprises will continue to use proprietary APIs for frontier accuracy and low-operations consumption, while shifting scaled, repeatable agent workflows toward open models where cost predictability, data control, and customization matter more,” Banerjee said. “In short, long-horizon, high-volume agentic AI will evolve into a hybrid market, with open models like MiMo breaking pure API dependence.”

Su added that adoption may face challenges because Chinese-origin models can trigger concerns in regulated Western organizations.

OpenAI has released Symphony, an open-source specification for turning issue trackers such as Linear into control planes for Codex coding agents.

Instead of asking an AI tool for help with one coding problem at a time, Symphony is designed to let agents pick up work from an issue tracker, run in separate workspaces, monitor CI, and prepare changes for human review.

In a blog post, OpenAI said the system grew out of a bottleneck it encountered as engineers began running multiple Codex sessions. Engineers could manage only three to five sessions before context switching became painful, the company said, limiting the productivity gains from faster coding agents.

OpenAI said the impact was visible quickly, with some internal teams seeing landed pull requests rising 500% in the first three weeks.

The orchestration layer can monitor issue states, restart agents that crash or stall, manage per-issue workspaces, watch CI, rebase changes, resolve conflicts, and shepherd pull requests toward review, the company said.

“The deeper shift is how teams think about work,” OpenAI said. “When our engineers no longer spend time supervising Codex sessions, the economics of code changes completely. The perceived cost of each change drops because we’re no longer investing human effort in driving the implementation itself.”

The approach, however, does introduce new problems, according to OpenAI. Agents can miss the mark when given ticket-level work, and not every task is suitable for orchestration. The company said ambiguous problems or work requiring strong judgment may still require engineers to work directly with interactive Codex sessions.

Sanchit Vir Gogia, chief analyst and CEO at Greyhound Research, said Symphony should be viewed less as another AI coding assistant and more as an emerging operational layer for software delivery.

“It schedules, tracks, retries, reconciles, persists state, and governs flow. In other words, it begins to resemble a lightweight operating system for software delivery, and that resemblance is the story,” Gogia said.

Implications for enterprises

Symphony is transforming AI from being a developer productivity aid to an execution model for software work, said Biswajeet Mahapatra, principal analyst at Forrester.

“Forrester’s research on agent control planes and adaptive process orchestration shows that value increases when agents are embedded into workflows and governed at scale rather than invoked interactively by individuals,” Mahapatra said.

Always-on orchestration, Mahapatra added, shifts AI from a personal coding aid to shared engineering infrastructure, helping teams organize work around issues and tasks while reducing developer cognitive load.

However, enterprises will need to look beyond output metrics such as lines of code or pull request counts and focus instead on quality, delivery speed, developer experience, and business impact.

“Relevant measures include lead time to usable functionality, defect escape rates, rework and code churn, production stability, and perceived developer flow and cognitive load as part of DevEx,” Mahapatra said. “Forrester’s application development research consistently highlights that productivity improvement must show higher quality, faster feedback loops, and clearer business impact, not simply more generated code.”

Gogia also warned against treating higher pull request volumes as proof of productivity gains, saying the 500% figure cited by OpenAI should prompt caution rather than comfort.

“Generation scales effortlessly, validation does not,” Gogia said. “As output volume rises, the burden of review, testing, and governance rises with it.”

Enterprises should also track peer-review friction, downstream rework, escaped defects, post-deployment incidents, recovery time, and the impact on junior engineers, he said.

Challenges to overcome

According to Neil Shah, vice president of research at Counterpoint Research, one of the biggest challenges for enterprises will be keeping orchestration platforms secure while deciding how much autonomy to give coding agents.

Orchestrators will need to handle diverse task types, support handoffs between agents, and provide “total transparency through comprehensive audit trails,” Shah noted.

That will become more important as agents begin creating and managing tasks within automated orchestration systems, reducing the amount of direct human oversight.

“Enterprises struggle with enforcing consistent security policies, auditability, and risk controls across distributed agents, especially when orchestration is decoupled from existing SDLC and identity systems,” Mahapatra said.

Mahapatra added that enterprises will also need to resolve questions around legacy toolchain integration, ownership of agent decisions, traceability of changes, and separation of duties before adopting open agent-orchestration specifications at scale.

One of the more dangerous assumptions in the current AI market is that broad adoption means meaningful adoption. It does not. Much of what enterprises call AI transformation is, in fact, AI experimentation focused at the edge of the business, in systems and workflows that support employees but are not central to how the enterprise actually operates. These include calendaring, scheduling, meeting summaries, employee communications, customer messaging, document generation, internal assistants, and similar productivity-oriented use cases.

Those applications may be useful, but they are not core applications that directly run the business and determine whether the company performs well or poorly. Inventory management, sales order entry, logistics execution, supply chain planning, procurement, warehouse management, manufacturing operations, and financial transaction processing belong in this category. If these systems fail, the business feels it immediately through delayed orders, lost revenue, rising costs, poor customer outcomes, and weakened operational control.

McKinsey reports that AI is most often used in IT, marketing and sales, and knowledge management, with common use cases including content support, conversational interfaces, and customer service automation. It also says most organizations are still in experimentation or pilot mode, and only 39% report any enterprise-level earnings impact. This supports the idea that adoption is broad, but deep, core-business transformation is still limited.

That distinction is critical because it exposes that most enterprise AI efforts are not going into the systems that define operational performance. They are going into the systems that are easiest to automate, easiest to pilot, and easiest to talk about in a board presentation. The market is flooded with productivity enhancements that create movement around the business while leaving the business itself mostly untouched.

The problem here is that it’s often much harder to prove the value of AI in meaningful business terms. When AI is directed toward applications that are less strategic and not central to the business, the benefits tend to be indirect, diffuse, and difficult to connect to outcomes that matter. Saving time in drafting emails, summarizing meetings, or streamlining internal collaboration may sound positive, but those gains often remain anecdotal. They rarely translate cleanly into measurable improvements in margin, cycle time, service levels, or revenue generation. In other words, the farther you move from the operational core, the fuzzier the business case tends to become.

Why enterprises avoid the core

If core applications are where the larger value sits, why are enterprises not making them the center of AI strategy? The answer is simple enough: More is at stake, the costs rise quickly, and confidence remains low.

Applying AI to edge applications usually carries limited downside. If a meeting summary is incomplete or an internally generated document needs revision, the business survives. A person steps in, makes corrections, and moves on. The failures are manageable. That is one reason shadow AI has spread so quickly. Employees can experiment with relatively little organizational risk because the blast radius is usually small.

Core systems are entirely different. If AI makes flawed decisions in inventory allocation, order processing, logistics routing, or supply chain forecasting, the impact is immediate and expensive. It can mean stockouts, excess inventory, missed shipments, poor customer service, broken supplier coordination, and measurable financial damage. These systems do not tolerate loosely governed experimentation. A bad result here is not a minor inconvenience.

Enterprises know this. Many are not confident enough in their own ability to design, govern, and support AI systems that can operate safely within business-critical processes. Frankly, that caution is justified. Too many AI projects are still based on generic strategies, templated approaches, and weak data integration. They are rushed in order to demonstrate something flashy rather than something operationally useful. The result is a parade of pilots, proofs of concept, and isolated wins that never make it into the systems that matter most.

The current AI platform market adds to the challenge. Enterprises are being handed powerful pieces of technology, but often without a coherent path to operational value. In many cases, they still need to assemble the models, workflows, governance, data layers, and integration points themselves. That engineering burden is already heavy at the edge. In the core, where systems are older, more customized, and more intertwined with business processes, it becomes even more difficult. It is no surprise that enterprises often choose the safer route and automate around the business before they attempt to automate within it.

Edge use cases are also attractive because they are visible and politically easy to support. Executives can tout progress because employees are using AI tools. Vendors can point to adoption numbers and usage metrics. Consultants can highlight quick wins. But visibility is not the same as impact. In fact, the emphasis on visible but low-risk use cases may be delaying the harder work required to produce real enterprise value.

Finding real AI value

Enterprises are unlikely to find real transformation until AI improves the systems that determine how the enterprise performs. Better demand forecasting. Smarter inventory positioning. Faster and more accurate sales order processing. Improved logistics coordination. More adaptive supply chain decisions. Better procurement timing. Stronger resilience in fulfillment operations. These are not cosmetic improvements. They affect the outcomes that executives, boards, and investors actually care about.

This is also where value becomes easier to measure. In edge applications, benefits are often framed in soft language around convenience, efficiency, or time savings. In core applications, the metrics are tangible. Did order accuracy improve? Did cycle time drop? Did stockouts decline? Did transportation costs fall? Did customer service levels rise? Because core applications sit closer to the economics of the business, AI deployed there has a much clearer chance of proving itself.

None of this means enterprises should ignore edge applications altogether. There is still practical value in reducing low-level manual work and giving employees better tools. But those efforts should be viewed as supporting use cases, not the center of strategy.

Enterprises need to stop confusing easy automation with strategic transformation. The priority should now be a smaller number of AI initiatives aimed directly at business-critical systems, supported by better data, stronger governance, internal expertise, and realistic operational design. Until that happens, much of enterprise AI will remain what it is today: interesting technology circling the edges of the business while the real opportunity sits untouched in the middle because success is harder and risk is greater.

While the software development industry has been gorging on large language models (LLMs), the front-end ecosystem has quietly fractured into three competing but interrelated architectural paradigms. Between the dominance of reactive frameworks, the hypermedia-driven simplicity of true REST, and the decentralized resilience of SQL everywhere, developers are no longer just choosing a library, they are choosing where the data lives: at the server, at the client, or both.

Three competing architectures, more or less

Web developers are long familiar with React and the galaxy of similar reactive frameworks like Angular, Vue, and Svelte. For nearly a decade, these have dominated the narrative with their competition and co-inspiration. HTMX and hypermedia-driven applications have championed a return to the true RESTful thin client, alongside alternatives like Hotwire and Unpoly.

We could in a sense see reactivity and hypermedia as two opposing camps. Somewhere in between is the local-first SQL movement, which proposes putting SQL directly in the browser. The waters are a bit muddy because local SQL can and does work right alongside React.

It’s still safe to say that a reactive framework paired with a JSON API back end that talks to a datastore (SQL or otherwise) is still the de facto standard. But that monolithic story is starting to fracture in some very interesting ways.

Where the weight of the data lies

Data of course is the central mass of web applications. Where it lives and how it moves produce the gravity around which everything else must revolve. Each of these architectures proposes to handle that gravity in its own way, with different benefits and tradeoffs.

Hypermedia (e.g., HTMX): Keep the data largely off the client. The client is just a visual representation of the server data. The back-end “API” is responsible for producing the data-driven markup. Any kind of datastore can be used by the API server.

React and friends: A sophisticated, stateful engine runs in the client, and the developer syncs that state with the back end via RESTful JSON API calls. The back-end server tends to be dumb, responsible largely for just invoking other services to provide business logic or data persistence.

Local-first SQL: The data is distributed to the clients, like with React and friends, but in a much different way. Although the data is automatically synced directly to a datastore (like Postgres), the back-end API server is used only for specialized service calls—not for data persistence.

To summarize:

• HTMX: Data gravity is at the server.
• React: Data gravity is split between the server and the client.
• Local-first: Data gravity is at the client.

Comparing the approaches

Besides the technical stats, the developer experience for each of these paradigms is quite different. However, while each paradigm feels different, they intersect in some interesting ways. Let’s take a closer look.

React and friends

Reactivity is the world we have been working in for 15 years. We’ve got a whole universe of frameworks: React, Angular, Vue, Svelte, Solid, and full-stack variants like Next.js, Nuxt, SvelteKit, Astro, etc. The beauty of these is in the core reactive idea. You have a state that consists of the variables and the UI is updated automatically. The UI is a pure function of state: $UI = f(state).

The downside is the gradual, almost imperceptible layering of intense complexity over the top of it all. This complexity seems at first just incidental, but it is in fact a direct outcome of the basic premise: building a state engine on the browser.

The result is you have two states: the browser and the database. The reactive engine becomes a negotiation layer. Add to that the various inherent complexities of managing the browser state, and the result is quite a lot for front-end developers to wrap their heads around.

In the effort to manage such complexity, wring more performance, and improve developer experience, we have wound up with quite a sprawling empire of tools and techniques. Even just for React we have React Server Components, complex state-management libraries like Redux or Zustand, and orchestration layers like TanStack Query for manual cache invalidation.

On the back end, we talk to JSON APIs (or GraphQL), which can become unwieldy as a kind of boilerplate layer, but has in its favor an almost universal understanding.

HTMX and similar (Hotwired, Unpoly)

HTMX is like using HTML that has superpowers. You can do a huge amount of what you use reactive frameworks for, including all the AJAX and a lot of the partial rendering and effects, with just a few extra attributes sprinkled judiciously.

You spend a lot of time on the server, using a template engine like Pug, Thymeleaf, or Kotlin DSL. These are where you bring together the data from the persistence service and combine it with markup. The markup you generate includes the HTMX attributes.

You tend to decompose the templates, i.e., break them up into dedicated chunks. The idea is you want to have a chunk that can be used within the larger UI to create the whole layout, along with the ability to use that chunk alone when (and if) it is called upon for an AJAX response.

Hypermedia with HTMX is a very powerful model. You are actually using REST, meaning you are transmitting a representational state.

Hotwire and Unpoly are similar libraries. In the case of Hotwire, you can achieve quite a bit of functionality and performance even without changing your HTML, just by using Turbo Frames to intercept link clicks and form submissions, automatically turning standard page navigation into partial DOM updates.

The beauty of the hypermedia approaches is that you gain a lot with a little. You are staying as much as possible in HTML, the very poster child of simplicity. On the other hand, you are giving up some of the sheer sophisticated power of reactive frameworks.

Local-first apps

Local-first development is the new kid on the block. Like React and friends, local-first keeps the data in two places, but it does so in a radically different way. In its most essential form, it means running a database in the browser that is kept aligned with the remote datastore via a syncing engine. This kind of thing has been done before with NoSQL databases like CouchDB or with the IndexedDB API, but the modern browser takes it to another level with a Wasm-based database engine, like SQLite.

The user gets a small view of the full data, called a partial replication or a bucket (also called a “shape”). The front-end app interacts directly with that data, and the infrastructure automatically does the work of keeping everything synced. A big benefit here is strong offline support (because the client device is carrying around an actual database).

This is a massive departure from the request-response cycle. In local-first, you don’t fetch data; you subscribe to it. The network becomes a background daemon that reconciles local and remote state using CRDTs (conflict-free replicated data types). CRDTs ensure that if two users edit a task while offline, the merge is seamless rather than messy.

There is also a degree of simplification in using SQL everywhere, though that is offset by a rather unfamiliar and involved architectural setup. A syncing engine like PowerSync or Electric SQL is required, and it has a set of rules that must be maintained. Plus the auth and interaction between the database and the syncing engine must be configured.

Local-first eliminates both the API server and the HTML template server. It pushes the entire data negotiation layer into the automated syncing engine that runs off developer-defined rules.

Interestingly, local-first SQL can be used as a data driver for React (and other reactive engines) or plain vanilla HTML + JS. As such, it is an interesting alternative take on the architecture of the web, which is agnostic about the front end.

Perhaps the strangest arrangement to contemplate is using HTMX and local-first SQL together. This is like a mad scientist architecture, which of course means developers are doing it. In this setup, the back-end HTMX template engine is actually a service worker running the SQL engine. In theory, you get the simplicity of HTMX and the ultra-speed + offline functionality of local SQL.

Reactivity, hypermedia, or local-first? How to choose

We remain in the era of the default choice being React plus a JSON API. From there you might experiment with innovative frameworks like Svelte or Solid. If you are looking for an ingenious way to leverage RESTful simplicity, HTMX or Hotwired are must-tries. Local-first SQL is an exotic animal, fit for the likes of Linear or Notion right now, but somewhat daring for most of us doing standard production work.

More broadly, the emergence of this trilemma signals the end of the “one true way” for web development. We are moving away from the library wars and into a world of architectural choice.

The choice between reactivity, hypermedia, and local-first isn’t just about code. It’s about where you want to place the data.

• If you want the data to be a server-side document, choose hypermedia.
• If you want the data to be a shared memory state, choose reactivity.
• If you want the data to be a distributed database, choose local-first.

And of course, it is possible to put the approaches together to strive for a blend of the right benefits for your project.

As the JSON-over-the-wire monolith continues to fragment, the best architects won’t be the ones who know the most hooks or the most attributes. They will be the ones who understand the weight of their data and choose the architecture that lets the data move most freely. The framework wars are over, but the battle for the network has just begun.

The most important thing Google announced at Google Cloud Next 2026 wasn’t another model, another Tensor Processing Unit (TPU), or another way to sprinkle Gemini across the enterprise (though it did all these things). Rather, it was an admission, or possibly a warning.

Agents need supervision.

We already knew this, of course, but “to know and not yet to do is not yet to know” as my high school philosophy teacher used to say. We like to think of agents as digital employees frenetically doing our bidding, but they’re also brittle software systems with credentials, budgets, memory, access to sensitive data, and a weird talent for failing in ways that are both expensive and hard to reconstruct.

That’s the real story of Google Cloud Next 2026. The consensus was that Google showed up to claim the agentic enterprise. I think the more interesting read is that Google showed up to contain it.

Yes, Google talked up the “agentic cloud.” It’s impossible to attend a conference these days that doesn’t. And, yes, it announced Gemini Enterprise Agent Platform, eighth-generation TPUs, new Workspace Intelligence AI capabilities, and a long list of integrations meant to make AI feel native to every corner of the enterprise. If you wanted a victory lap for the agentic era, there was plenty of keynote material to choose from.

But strip away the stage lighting, and the message was much more interesting: Enterprises have spent the past two years falling in love with AI agents. Now they need to keep them from embarrassing, bankrupting, or exposing the business.

That’s not a knock on Google. Quite the opposite. It may be the most useful thing Google announced.

Trust, but verify

The minute AI moves from saying things to doing things, all the boring enterprise questions demand answers. Who authorized this? What data did it use? What system did it touch? Why did it take that action? How much did it cost? How do we stop it?

Google’s announcements were, in large part, answers to those questions.

Consider what Google actually emphasized. Knowledge Catalog is designed to ground agents in trusted business context across the data estate. Gemini Enterprise now includes an inbox to manage and monitor agents, including long-running agents. Workspace is getting new controls to monitor, control, and audit agent access to data to reduce prompt injection, oversharing, and data loss risks. Google Cloud’s security announcements included new agentic defense capabilities and Wiz-powered coverage to help secure agents across cloud and AI development environments.

These are not the tools you build when everything is humming along nicely. These are what you build when customers are discovering the awkward middle ground between “the demo worked” and “we trust this thing with real work.”

The agent control plane

Analysts seem to have settled on “agent control plane” as the phrase for this emerging layer of enterprise AI. It’s a good phrase because it’s familiar. It suggests Kubernetes for cognition: a unified place to govern, observe, route, secure, and optimize fleets of AI agents.

If only. We’re still far from that world.

The reason agents need a control plane isn’t that they’re already replacing employees; rather, it’s that enterprises are giving probabilistic systems access to deterministic workflows and discovering (surprise!) that somebody needs to watch the handoff. Agent demos make autonomy look clean, but enterprise systems make autonomy weird. The customer record is in one system, the contract is in another, the exception handling lives in someone’s inbox, the policy is in a PDF last updated in 2021, and the person who understands why the workflow works that way left the company during the pandemic.

Now we’re adding agents to the mess.

This is why I’m sympathetic to Google’s control-plane push, even as I’m suspicious of any vendor story that sounds too tidy. Yes, it’s useful to have a unified agent platform, governance, agent monitoring, evaluation, observability, and simulation. All needed. The new Gemini Enterprise story matters precisely because Google is trying to centralize the messy operational pieces that enterprises otherwise stitch together badly.

But let’s not mistake the control plane for the work itself.

Pilots are easy; production is hard

The data on agentic AI keeps saying the same thing: Enthusiasm is running far ahead of operational maturity.

Camunda’s 2026 State of Agentic Orchestration and Automation report found that 71% of organizations say they use AI agents, but only 11% of agentic AI use cases reached production in the past year. Even more telling, 73% admitted a gap between their agentic AI vision and reality. Gartner has been similarly chilly, predicting that more than 40% of agentic AI projects will be canceled by the end of 2027. Why? Cost, unclear business value, and inadequate risk controls.

Let’s be clear. Those aren’t model problems. They’re all-too-familiar enterprise software problems.

The same pattern shows up in security and governance. Writer’s 2026 enterprise AI survey found that 67% of executives believe their company has suffered a data leak or security breach because of unapproved AI tools. Also, 36% lack a formal plan for supervising AI agents, and 35% admit they couldn’t immediately pull the plug on a rogue agent.

Of the three, it’s that last number that is perhaps scariest. These are software agents with access to business systems, customer data, and organizational credentials, yet more than one-third of organizations aren’t confident they can stop one quickly when it misbehaves.

What, me worry?

The agent is the least interesting part

The dirty secret of the agentic enterprise is that the agent is probably the least interesting part of the architecture. It gets all the hype, but the real work is identity, permissions, workflow boundaries, data quality, retrieval, memory, evaluation, audit trails, cost controls, and deciding which system is allowed to be the source of truth when the agent gets confused.

The presentations at Google Cloud Next didn’t prove that the agentic enterprise had arrived. Instead they proved that the agentic enterprise, if or when it arrives, will look a lot like enterprise software has always looked when it starts to matter. Less magic; more governance.

That’s progress, but it’s not sexy progress.

If you’re trying to pick winners in agentic AI, don’t look for those with the cleverest agents. Instead, look to the companies with the cleanest data contracts, the best evaluation discipline, the most coherent identity model, and the least tolerance for shadow AI chaos. The industry doesn’t want to tell that story because it’s much more fun to talk about autonomous digital workers than data lineage and access control.

But boring is where enterprise software becomes real.

Here’s another reason to be cautious about declaring the agentic era won: Agents are only as useful as the data they can safely understand and act upon. Google clearly knows this. The Agentic Data Cloud framing, including Knowledge Catalog and cross-cloud Lakehouse work, is an admission that agents need trusted business context. Without that context, they’re not enterprise workers. They’re articulate tourists wandering through your systems.

Hence, the most encouraging announcements at Google Cloud Next weren’t the ones that made agents sound more autonomous. They were the ones that made agents sound more manageable. Agentic AI promises to be big, but only when it demonstrates it can be boring.

JavaScript remains one of the most in-demand programming languages for web development—and that’s not likely to change anytime soon. While a JavaScript certification alone may not land anyone a development job, it definitely has its benefits.

“JavaScript isn’t just holding steady, it is still the most in-demand language in the market,” says Dan Roque, recruitment manager at HRUCKUS, a provider of professional and career services.

The Stack Overflow 2025 Developer Survey of more than 49,000 developers shows that JavaScript remains the most-used programming language, coming in ahead of HTML/CSS, SQL, and Python.

“It has held the top spot for over a decade, every single year since the survey began in 2011,” Roque says. JavaScript’s core advantage is its ubiquity, he says. “A developer who knows it well can contribute to front-end interfaces, back-end APIs [application programming interfaces], serverless functions, and automation pipelines without switching languages,” he says.

JavaScript remains foundational because the web still serves as the default app platform, and most JavaScript growth is really the ecosystem expanding, with frameworks, tooling, and TypeScript becoming the common enterprise path, says Josh George, founder of Josh George Consulting, an independent technology strategy consulting firm.

“JavaScript is the universal runtime for user experiences and caters to browsers, Node-based back ends, edge/serverless functions, and cross-platform apps,” George says. “The greatest benefit is a single language family across client and server, plus the added bonus of an enormous package ecosystem and mature tooling.”

The programming language has evolved from being just a browser scripting language into a full-stack development platform, says Lucas Botzen, CEO and human resources manager at careers site Rivermate. “From an HR and industry perspective, organizations increasingly prefer technologies that allow teams to build both front-end and back-end systems with the same language,” he says. “That consistency reduces hiring complexity and accelerates development cycles.”

JavaScript and AI

AI-powered coding tools such as Claude Code and GitHub Copilot can increase productivity related to JavaScript development, Rogue says, with studies showing they can help developers complete JavaScript tasks faster. As a result, many developers plan to use AI in their development process, he says.

“Employers aren’t just looking for developers who know JavaScript. They’re increasingly looking for [developers] who can evaluate and orchestrate AI-generated code within a JavaScript workflow,” Rogue says. AI is reshaping what mid-level and senior JaveScript roles actually look like, he says.

“However, more and more technical testing and final interviews, especially in government-related roles, prohibit the use of AI during the last legs of the process, to ensure the talent actually can code and understand code without AI, and to validate whether they can review and troubleshoot AI-generated code on their own,” Rogue says.

AI helps most with the “surface area” work, “meaning scaffolding components, generating tests, suggesting refactors, and explaining unfamiliar code paths,” George says. “The bigger shift though is that teams expect developers to spend less time typing boilerplate and more time making judgment calls like with API design, performance budgets, security, and maintainable architectures.”

JavaScript certs and the hiring process

Okay, so JavaScript is still a highly important piece of the development ecosystem. But is having a JavaScript certification necessary today? “It depends on context, but the answer I’d give is ‘yesn’t,’” Rogue says. “It is increasingly important, especially in structured hiring environments, because it provides a credibility anchor that résumés alone often can’t. But it doesn’t replace actual demonstrated skill.”

There isn’t really a widely accepted global authority or standard on issuing JaveScript certifications, Rogue says, “so it’s much lower on the totem pole of validity when it comes to skill-signaling. Still, for client-facing or compliance-driven roles, certifications provide third-party validation that reduces perceived risk when a client is approving a candidate.”

For back-end and full-stack roles, performance-based credentials that require solving real coding problems in a timed, proctored environment remain the gold standard, Rogue says. “Employers have simply grown skeptical of multiple-choice tests.”

In most hiring decisions, “a JavaScript certification is not the primary signal of competence,” says Jacob Strauss, CTO at ChaseLabs, a provider of AI-based sales development tools. “They tend to help more as evidence of structured study than as a decisive hiring credential.”

In practice, the strongest way to stand out is to pair any certification with a small, real project. “JavaScript changes continuously, and what matters in production is the ability to build, debug, and operate real systems,” Strauss says. “That said, certifications can be useful in specific scenarios: early-career candidates, career switchers who need a credible baseline, or organizations trying to standardize Node.js skills across a team. In those cases, a cert can reduce uncertainty, but it works best as supporting evidence alongside shipped work.”

A JavaScript certification can serve as a screening mechanism or tie-break factor. “In high-volume pipelines, a cert may help a résumé survive the first pass, especially when applicants have limited professional history,” Strauss says. “For roles that involve running Node services in production, a certification can signal familiarity with asynchronous patterns, HTTP fundamentals, debugging, and service reliability concerns.”

Even then, however, strong portfolios tend to outweigh credentials, Strauss says. A clean repository with typed code, sensible architecture, tests, and clear commit history is a far more predictive indicator than a generic certificate,” he says.

Certifications can be influential in high-volume hiring, where recruiters need fast signals, or in regulated and enterprise contexts that prefer standardized training, George says. “It can also help when teams need specific competency areas, such as modern framework fundamentals, testing practices, secure coding basics, etc., and want a consistent baseline,” he says.

In-demand JavaScript certifications

CIW JavaScript Specialist. This certification covers core JavaScript topics such as functions, variables, Document Object Model (DOM) manipulation, form validation, event handling, AJAX/JSON asynchronous communication, and object-oriented programming. Candidates learn how to tackle complex scripting scenarios and debug code, according to Certification Partners, which owns and manages CIW certifications. The CIW JavaScript Specialist certification equips candidates with practical skills to build dynamic, interactive, and user-friendly websites using JavaScript, says Certification Partners.

JavaScript Algorithms and Data Structures. Administered by FreeCodeCamp, this is considered an ideal certification for JavaScript beginners. Candidates will learn the JavaScript fundamentals such as variables, arrays, objects, loops, functions, DOM, and more. They’ll also learn about object-oriented programming, functional programming, and algorithmic thinking.

JavaScript Developer Certificate. This certification validates proficiency in JavaScript programming, HTML DOM manipulation, and web development fundamentals. Before applying for the exam, candidates need to have a fundamental knowledge of JavaScript and HTML DOM, according to W3Schools, which offers the certification. The certification tests ability to manipulate HTML DOM and validates proficiency in dynamic website development.

JSA—Certified Associate JavaScript Programmer. This certification from the JS Institute, which is managed by OpenEDG, demonstrates a candidate’s proficiency in object-oriented analysis, design, and programming and the more advanced use of functions in the JavaScript language, according to the institute. Becoming JSA-certified ensures that individuals are acquainted with how JavaScript enables them to design, develop, deploy, refactor, and maintain JavaScript programs and applications.

JSE—Certified Entry-Level JavaScript Programmer. Also available from the JS Institute, this certification demonstrates a candidate’s understanding of the JavaScript core syntax and semantics, as well as their proficiency in using the most essential elements of the language, tools, and resources to design, develop, and refactor simple JavaScript programs. Becoming JSE-certified ensures that individuals are acquainted with the most essential means provided by the core JavaScript language, so they can work toward the intermediate level, the institute says.

Mimo JavaScript Certification. This certification verifies a candidate’s ability to build interactive features, manage data, and understand the logic that powers modern front-end and full-stack development, according to Mimo. It shows mastery of variables, functions, loops, conditionals, arrays, objects, and ES6 features, and provides hands-on experience solving coding challenges. Participants work through practical projects such as dynamic web pages, forms, and interactive user interface components.

OpenJS Node.js Application Developer (JSNAD). Created by the OpenJS Foundation, but retired in September 2025, the JSNAD certification demonstrates the ability to manage Node.js core modules, implement technical asynchronous logic, handle technical streams and buffers, and configure technical security protocols. Candidates were tested on solving complex back-end development problems and implementing scalable server-side applications in real world scenarios, according to Udemy, which still offers classes and practice exams related to JSNAD certification. The program explores the technical aspects of buffers, streams, and file system operations within the Node.js runtime, Udemy says.

Senior JavaScript Developer. Offered by Certificates.dev, the Senior JavaScript Developer certification validates mastery in JavaScript, including prototypes, inheritance, and performance optimization techniques, according to Certificates.dev. It demonstrates proficiency in advanced asynchronous programming, testing, and security vulnerability mitigation. It’s designed for experienced developers aiming for technical leadership roles.

Meta is continuing its compute grab as the agentic AI race accelerates to a sprint.

Today, the company announced a partnership with Amazon Web Services (AWS) that will bring “tens of millions” of AWS Graviton5 cores (one chip contains 192 cores) into its compute portfolio, with the option to expand as its AI capabilities grow. This will make the Llama builder one of the largest Graviton customers in the world.

The move builds on Meta’s expansive partnerships with nearly every chip and compute provider in the business. It’s working with Nvidia, Arm, and AMD, as well as building its own internal training and inference accelerator chip.

“It feels very difficult to keep track of what Meta is doing, with all of these chip deals and announcements around in-house development,” said Matt Kimball, VP and principal analyst at Moor Insights & Strategy. This makes for “exciting times that tell us just how incredibly valuable silicon is right now.”

Controlling the system, not just scale

Graphics processing units (GPUs) are essential for large language model (LLM) training, but agentic AI requires a whole new workload capability. CPUs like Graviton5 are rising to this challenge, supporting intensive workloads like real-time reasoning, multi-step tasks, frontier model training, code generation, and deep research.

AWS says Graviton5 has the ability to handle “billions of interactions” and to coordinate complex, multi-stage agentic tasks. It is built on the AWS Nitro System to support high performance, availability, and security.

“This is really about control of the AI system, not just scale,” said Kimball. As AI evolves toward persistent, agentic workloads, the role of the CPU becomes “quite meaningful;” it serves as the control plane, handling orchestration, managing memory, scheduling, and other intensive tasks across accelerators.

“This is especially true in agentic environments, where the workloads will be less linear and more stateful,” he pointed out. So, ensuring a supply of these resources just makes sense.

Reflecting Meta’s diversified approach to hardware

The agreement builds on Meta’s long-standing partnership with AWS, but also reflects what the company calls its “diversified approach” to infrastructure. “No single chip architecture can efficiently serve every workload,” the company emphasized.

Proving the point, Meta recently announced four new generations of its MTIA training and inference accelerator chip and signed a massive deal with AMD to tap into 6GW worth of CPUs and AI accelerators. It also entered into a multi-year partnership with Nvidia to access millions of Blackwell and Rubin GPUs and to integrate Nvidia Spectrum-X Ethernet switches into its platform, and was also one of Arm’s first major CPU customers.

In the wake of all this, Nabeel Sherif, a principal advisory director at Info-Tech Research Group, posed the burning question: “What are they going to do with all this capacity?”

Primarily it will support Meta’s internal experimentation and innovation, he said, but it also lays the groundwork and provides the capacity for Meta to offer its own agentic AI services, for instance, its Llama AI model as an API, to the market.

“What those [services] will look like and what platforms and tools they’ll use, as well as what guardrails they’ll provide to users, is still unclear, but it’s going to be interesting to see it develop,” said Sherif.

The expanded capacity will enable a diversity of use cases and experimentation across various architectures and platforms, he said. Meta will have many options, and access to supply in an environment currently characterized not only by a wide variety of new CPU approaches, but by significant supply chain constraints. The AWS deal should be viewed as a complement to its partnerships and investments in other platforms like ARM, Nvidia, and AMD.

Kimball agreed that the move is “most definitely additive,” not a replacement or substitution. Meta isn’t moving off GPUs or accelerators, it’s building around them. “This is about assembling a heterogeneous system, not picking a single winner,” he said. “In fact, I think for most, heterogeneity is critical to long term success.”

Nvidia still dominates training and a lot of inference, while AMD is becoming “more and more relevant at scale,” Kimball noted. Arm, meanwhile, whether through CPU, custom silicon or other efforts, gives Meta architectural control, and Graviton5 fits into that mix as a “cost- and efficiency-optimized general-purpose compute layer.”

A question of strategy

The more interesting question is around strategy: Does this signal Meta is becoming a compute provider? Kimball doesn’t think so, noting that it’s likely the company isn’t looking to directly compete with hyperscalers as a general-purpose cloud. “This is more about vertical integration of their own AI stack,” he said.

The move gives them the ability to support internal workloads more efficiently, as well as providing the infrastructure foundation to expose more of that capability externally, whether through APIs, partnerships, or other means, he said.

And there’s a cost dynamic here, too, Kimball noted. As inference becomes persistent, especially with agentic systems, economics shift away from peak floating-point operations per second (FLOPS) (a measure of compute performance) and toward sustained efficiency and total cost of ownership (TCO).

CPUs like Graviton5 are well positioned for the parts of that workload that don’t require accelerators, but still need to run continuously. “At Meta’s scale, even small efficiency gains per workload compound quickly,” Kimball pointed out.

For developers and enterprise IT, the signal is pretty clear, he noted: The AI stack is getting more heterogeneous, not less so. Enterprises are going to see tighter coupling between CPUs, GPUs, and specialized accelerators, with workloads increasingly split across them based on behavior (prefill versus decode, stateless versus stateful, burst versus persistent).

“The implication is that infrastructure decisions have to become more workload-aware,” said Kimball. “It’s less about ‘which cloud?’ and more about ‘where does this specific part of the application run most efficiently?’”

This article originally appeared on NetworkWorld.

As Europe seeks to assert its technological independence from the US vendors Aleph Alpha, once seen as Germany’s sovereign AI hope, is the target of a transatlantic takeover.

Aleph Alpha is set to merge with Canada’s Cohere in a deal that will bring together Cohere’s global AI clout and Aleph Alpha’s background in research. The two companies hope they will be able to develop an AI powerhouse, with backing from their Canadian and German ecosystems

“Organizations globally are demanding uncompromising control over their AI stack. This transatlantic partnership unlocks the massive scale, robust infrastructure, and world-class R&D talent required to meet that demand,” said ” said Cohere CEO Aidan Gomez in a news release that artfully presents the deal as a merger of equals but that, according to a footnote, only requires the approval of the German company’s shareholders, a sure sign of a one-sided takeover.

The combined companies will be looking to offer customized AI in highly-regulated sectors including finance, defense and healthcare. By pooling their talents and offerings, theu hope to offer AI solutions to organizations according to local laws, cultural contexts, and institutional requirements.

The move comes at a time when businesses across the word are looking at non-US options as a reaction to the Trump administration’s policy on tariffs and the uncertainty caused by the war with Iran.

There have been several initiatives within Europe to counteract the US dominance. The EU’s Eurostack plan looked to make sure that major projects had a European option. Aleph Alpha was one of the companies highlighted within the scheme. The EU also launched Open  Euro LLM, an attempt to slow down the US and China’s lead in AI.

This article first appeared on CIO.

Tencent has updated its Hunyuan AI model, its first major release since it recruited Yao Shunyu, a leading AI scientist from OpenAI. Tencent’s Hy3 model, currently available in preview, offers improvements in areas from complex reasoning to coding.

The Chinese technology conglomerate is playing catch-up with other Chinese AI developers including ByteDance, Alibaba and DeepSeek. China is betting big on open-source AI to offer alternatives to major US players. Back in 2023, Tencent claimed its then-new Hunyuan LLM was a more powerful and intelligent option than the versions of ChatGPT and Llama available at the time.

Tencent has backed AI start-ups including Moonshot AI and StepFun, hoping that they will boost its cloud computing division. The company has also restructured its research team to improve the quality of training data. It aims to double its investment in AI to more than $5 billion this year.

Not to be outdone, DeepSeek announced its V4 Flash and V4 Pro Series, the newest versions of its LLM model. DeepSeek became an overnight hit in January 2025 with the launch of its R1 AI model and has gone on to develop other models since. It said the V4 model upgrades will offer users advances in reasoning and agentic tasks, while a new feature called Hybrid Attention Architecture improves the ability of the AI platform to remember queries across long conversations.

Cloud computing is a key foundation of modern business, yet many approach learning it in overly complicated ways. New learners often believe they need costly boot camps, certification bundles, or long technical courses before they can get a job in the field. This approach discourages potential entrants and creates false barriers around a discipline that’s already difficult to navigate. The truth is simpler: Free cloud courses are among the best starting points because they reduce risk, boost confidence, and introduce learners to the vocabulary, platforms, and models that define the cloud era.

The first stage of any cloud journey is orientation, not mastery. People need to understand what cloud computing means in practice, how infrastructure differs from platform services, why elasticity matters, where governance fits, and how major providers organize their offerings. A well-rounded exposure to the depth and breadth of a subject matter is a proven benefit of traditional higher education models. However, the traditional approach to course investigation and experimentation has become too costly for many prospective cloud students.

Free courses allow learners to explore without financial pressure. If someone discovers they prefer architecture over administration, or are more drawn to security than to development, the learning experience still creates value. Nothing is wasted.

Do cloud providers offer their free foundational learning as a charity? Of course not. This is ecosystem development. When AWS, Microsoft, Google Cloud, Oracle, IBM, and others publish free learning paths, they are hoping to cultivate future architects, engineers, analysts, and decision-makers.

Where to start

Start your cloud career by reviewing free introductory courses from vendors or leading educational platforms. These courses aim not only to teach features but also to foster the mental models providers want new users to develop. Free courses are also a good starting point because they let learners compare platforms before choosing one. This matters because beginners often hear strong opinions about the “best” cloud provider. The better question is which provider suits a learner’s goals. Someone focused on enterprise Windows may prefer Microsoft Azure. Those interested in startups or market demand may choose AWS. Those focused on data, analytics, or Kubernetes may opt for Google Cloud. Free courses enable this comparison without forcing early specialization.

The list below is a practical starting point. It includes reputable, free or free-to-start courses and learning paths from major providers and platforms. Some offer entirely free access to core material, while others allow enrollment at no cost but may charge separately for certificates or advanced lab features. That distinction is not a drawback for beginners. Early on, what matters most is understanding the landscape, learning the terminology, and gaining enough fluency to decide what should come next.

Courses from AWS

• Cloud Practitioner – Digital and Classroom Training
• Getting Started with AWS Cloud Essentials

Courses from Microsoft Learn

• Introduction to Cloud Infrastructure (AZ-900T00-A)
• Microsoft Azure Fundamentals: Describe Cloud Concepts

Courses from Google Cloud Skills Boost

• Cloud Computing Fundamentals
• Google Cloud Fundamentals: Core Infrastructure

Courses from IBM

• Introduction to Cloud Computing (via Coursera)
• Introduction to Cloud Computing (via edX)

Course from Oracle University/Learn Oracle

• Become an OCI Foundations Associate

Course from Alibaba Cloud Academy

• Free for All: New User Learning Path

Why free courses work so well

Effective courses aren’t just about price; they’re about structure. Good introductory cloud courses progress from concepts to examples to platform navigation, teaching learners to think about regions, zones, VMs, storage, identity, networking, and managed services before actual implementation skills are required. Many new learners fail by jumping into tools too soon. They try to deploy before they can explain. Free foundation courses avoid this by establishing context first, making hands-on learning more effective.

People entering the cloud market from nontraditional backgrounds should note that not all future cloud professionals need coding skills. Many successful cloud careers start in systems administration, security, project delivery, business analysis, operations, data management, or technical sales. Free courses help by focusing on concepts and platform literacy rather than deep engineering, making the field more accessible. This accessibility is a strength, helping cloud expand across industries.

Treat free courses as a starting point in a broader strategy, not the whole journey. They provide a good foundation. For example, you could start with an IBM overview, followed by AWS or Azure fundamentals to gain familiarity with a major provider, then Google Cloud to expand horizons. Next, engage in hands-on labs, architecture diagrams, small deployments, and role-based learning in areas like security, networking, AI, data engineering, or finops. Free courses are the launch point, not the end point.

The best first move

Commit. Begin your cloud journey this week. Start with one foundational course from a major provider and finish it. Then take a second course from a different provider to compare terminology, service models, and user experience. That simple approach gives you momentum, perspective, and a much clearer sense of where to invest your time next.

Procrastination is not your friend in an industry that evolves quickly and rewards curiosity. Don’t pay for depth before you earn breadth. Also realize that as the cloud industry matures and skills shortages ease, the availability of these free courses is likely to decline. Carpe diem.

To many people, AI manifests one of sci-fi’s central plot points: built intelligence or machines that think and act independently of a human supervisor. But from my perspective, we haven’t quite achieved the true fulfilment of that vision.

For this reason, many thought leaders describe world models as AI’s next big paradigm shift. These models learn from the full physical environment — synthetic or real — and can understand the spatial and physics complexities of worlds, unlike LLMs, which are restricted to language and images.

AMI’s Yann LeCun is such a strong believer that he quit his role as chief AI scientist at Meta to found his own organization to advance world models. “I’ve not been making friends in various corners of Silicon Valley, including at Meta, saying that within three to five years, [world models] will be the dominant model for AI architectures, and nobody in their right mind would use LLMs of the type that we have today,” LeCun said.

Apparently, LLMs have achieved groundbreaking results. They can only improve with more compute and more data, which are increasingly expensive, unwieldy and deliver only diminishing returns.

World models are the vital prerequisite for AGI

I believe that world models have the potential to actualize many of the capabilities that sci-fi dreams about.

To truly achieve artificial general intelligence (AGI), world models will need to go beyond pattern recognition to capture how the world actually works. A system capable of general reasoning must understand relationships – physical, social and causal — well enough to transfer knowledge between unfamiliar situations.

Without that holistic perspective, a model may perform impressively when conditions perfectly match those described in its training, yet it will fail when those conditions suddenly change. To be effective “generally,” AI needs the ability to revise its internal understanding when it encounters new situations.

A comprehensive world model allows an agent to simulate outcomes, reason about constraints and adapt to new environments, turning static predictions into flexible problem-solving.

With the right levels of adaptability, an agent can update its beliefs, reinterpret context and devise new strategies rather than relying on static rules. This capacity mirrors human intelligence, where prior knowledge is continuously reshaped to handle new situations, from learning unfamiliar technologies to navigating entirely new cultures.

After all, real-world decisions are rarely isolated. Actions interact with physics, timing, goals and human behavior, all at once. To plan effectively, an AGI must anticipate consequences, identify causation, and integrate knowledge across domains. Replicating humans’ integrated understanding and open-ended problem solving is what separates narrow intelligence from general intelligence.

A world model is worlds apart from an LLM

In short, world models provide AI with common sense to understand how things operate in a given environment — and what might happen if conditions or objects are altered.

For example, Meta’s JEPA was built towards this goal, focusing on predicting abstract representations rather than raw pixels, and it serves as a key building block for future world models.

Large language models, or LLMs, seem very powerful today, but they are dwarfed by world models. World models are multimodal AI models that are self-learning, capable of general reasoning and spatially aware. LLMs are just very good at predicting what comes next in a pattern.

Here’s my take on the main differences between a world model and an LLM:

• Learning methods. World models use continuous reinforcement learning to train themselves by observing their environment and inferring missing data, such as the PlaNet model-based reinforcement learning system. In contrast, LLMs are inefficient and require extensive training on massive datasets.
• Spatial awareness. World models like Genie 3 interact dynamically with multidimensional environments, enabling them to imagine and generate 3D, 4D and 5D visualizations of consistent, interactive worlds. LLMs, on the other hand, don’t have any awareness of space.
• Deep understanding. World models extrapolate from partial information to understand concepts like cause and effect and object permanence, whereas LLMs are limited by a shallow understanding of the world. They can predict the next word based on learned patterns, but they don’t understand what that word means.
• Long-term planning. By executing thousands of simulations, agents like those based on the DreamerV3 model can find the optimal sequence to achieve a goal, allowing them to plan for different contingencies and make informed decisions in new circumstances. LLM long-term planning, on the other hand, is fragile and unreliable.
• Multimodal inputs and outputs. World models are able to consume inputs in diverse forms, and also produce outputs in many different modes. For example, World Labs’ Marble is a multimodal world model that can reconstruct and simulate 3D environments from still images. LLMs are restricted to 2D inputs and outputs.

How does a world model work?

A world model is made up of three connected modules:

• The perception module. This section takes raw sensory inputs such as images, video and proprioception and encodes them into a compact latent representation of the environment.

• The prediction module. This is a dynamics model which handles probability distribution and captures causality and temporal structure. It probabilistically predicts the next latent state and the expected results of any actions.

• The planning (control) module. This module uses the output of the prediction model to simulate future trajectories and select actions that optimize achievements towards a goal.

“At its core, a world model is an internal representation that an AI system constructs to simulate the external environment. By continuously processing sensory data, a robot builds a dynamic blueprint of its surroundings,” explains Aurorain founder Luhui Hu. “This fusion of perception, prediction and planning mirrors cognitive processes in humans, setting the stage for more advanced robotic behavior.”

World models open up immense possibilities

There seem to be almost no limits to the potential waiting within world models, even if we set aside AGI aspirations for the moment. Here are just a few of the many ways world models could impact our lives.

Immersive visual experiences

With world models, it is finally becoming possible to build convincing worlds that you can interact with and experience. These are the very first capabilities that are coming on line, thanks to models like those developed by Decart, which can even be used as playable, game engine-free simulations.

“Because what’s running your game or your environment is an AI, you can interact with it in the ways we’re used to interacting with AI,” says Dean Leitersdorf, Decart’s CEO and cofounder.

“You’d be able to say, ‘Hey, can you turn this into Elsa themed?’ And then, boom, everything becomes Elsa-themed. ‘And can you add a flying elephant?’ And there’s a flying elephant in the game. And it’s not just there as a picture. You can actually interact with it. You can, I don’t know, punch the elephant, it’ll punch you back, or whatever you can do with an elephant.”

Fast iteration for innovations

Interactive, consistent world generation has consequences that go far beyond entertainment.

Models like Marble and Oasis that can generate persistent, downloadable 3D environments from text prompts, photos, videos, 3D layouts, or panoramic images currently focus on gaming and VR, but they also open the door to robotics training in simulated environments.

Multi-dimensional computational modeling enables use cases like exploring molecular chemistry, developing novel biomedical treatments, probing the makeup of the universe, designing earthquake-proof buildings, understanding complex climate patterns and researching new materials.

Video that obeys real-world laws

Among the use cases for world models that are most exciting to me, creating hyper-realistic AI-generated video certainly stands out as especially compelling.

As AI systems improve their understanding of physical dynamics, the distinction between video generation and world models is becoming less clear.

Runway’s GWM-1 general world model is a good example. It simulates reality through autoregressive, frame-by-frame video generation, a step Runway positions toward “general world models” that fully replicate the physics of simulated environments. Luma AI’s Modify Video has a similar goal.

Safer, more accurate decisions

Because world models can extrapolate from partial information, rapidly simulate many possible outcomes of multiple decisions and accurately forecast consequences, they can significantly improve decision-making across a wide range of use cases.

Possibilities include complicated multi-factor economic modeling, understanding climate patterns that are currently unpredictable and supporting complex long-term planning for regional and international policy decisions.

They also improve the safety of self-driving cars by enabling them to predict the outcomes of actions, such as changing lanes, to avoid collisions.

Realistic robots

Robots that serve as lab assistants, carers, 24/7 industrial workers and explorers in inaccessible and/or hostile environments are an old sci-fi dream. World models can help overcome a serious ongoing obstacle to making “physical AI” possible: the lack of relevant training data.

NVIDIA’s Cosmos platform 2.5 was built to predict and generate physics-aware videos of future environment states, producing synthetic training data generation for autonomous vehicles and robotics at massive scale.

“Unlike language models, training data is scarce for today’s robotic research. World models will play a defining role in this,” says Fei-Fei Li, CEO and founder of World Labs. “As they increase their perceptual fidelity and computational efficiency, outputs of world models can rapidly close the gap between simulation and reality. This will in turn, help train robots across simulations of countless states, interactions and environments.”

World models rest at AI’s next frontier

With so much power and so many possibilities, world models promise to take AI technology to a great leap forward beyond LLMs, making some of our long-held sci-fi wishes come true.

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

The AI agent introduction frenzy continued at a torrid pace this week, with OpenAI launching what it called workspace agents in ChatGPT and Microsoft adding hosted agents to its Foundry Agent Service.

Both launched on the same day that Google both updated its Gemini Enterprise app to provide new ways for office workers to build, manage, and interact with AI agents, and launched the Gemini Enterprise Agent Platform, which the company said is designed to build, scale, govern, and optimize agents.

This trio of offerings follows Anthropic’s early April introduction of Claude Managed Agents, a suite of composable APIs for building and hosting cloud-hosted agents, which is now in public beta.

In its announcement, OpenAI said, “workspace agents are an evolution of GPTs. Powered by Codex, they can take on many of the tasks people already do at work—from preparing reports, to writing code, to responding to messages. They run in the cloud, so they can keep working even when you’re not. They’re also designed to be shared within an organization, so teams can build an agent once, use it together in ChatGPT or Slack, and improve it over time.”

Microsoft, meanwhile, stated in a blog that its latest move “brings agent-optimized compute and services designed for production-grade enterprise agents.” After its preview of hosted agents last year at Microsoft Ignite, the company said, “this refresh is a fundamentally different experience: secure per-session sandboxes with filesystem persistence, integrated identity, and scale-to-zero economics.”

Announcements are connected

Jason Andersen, principal analyst at Moor Insights & Strategy, said, “these four announcements are connected, as the frenzy around agents continues. What OpenAI is announcing is the native ability to support the creation and sharing of agents.”

This is new functionality for OpenAI, which is a bit late to the game; Google, Microsoft, Anthropic and others have had this capability for some time, and are in fact moving farther ahead with these other announcements, he said.

 “What we are seeing with Anthropic and Microsoft is that, as agents become more powerful, they will go to great lengths to solve the problem they are posed with, and sometimes that includes the agent writing code and doing other tasks,” he pointed out. “This increases complexity and concerns about agents and models being well managed while running. The hosting options both of these vendors provide are a more advanced infrastructure for agents to run.”

Right now, he added, “many agents are being treated as simply a more advanced front end. These newer options provide the ability for an agent to do things like spin up a dedicated container, and they can support semi-autonomous and, in some cases, autonomous operations. These two announcements are more infrastructure-related, whereas OpenAI is more about agent building.”

He described the Google launch as being “something in between.”

He noted, “OpenAI’s announcement is very similar to last year’s announcement of Gemini Enterprise from Google. This year, Google took steps forward to enable a management control plane for agents called Gemini Enterprise Agent Platform, which enables a much richer sharing experience and a number of management and governance capabilities.”

On the whole, Andersen said, “the agent space is getting very hot, and some who have been later to the party are getting on board, and those who have been investing are evolving to provide end customers more scale, operations, and security capabilities.”

Brian Jackson, principal research director at Info-Tech Research Group, said that with the flurry of announcements “we’re seeing a race to gain critical mass as the agentic platform becomes the daily work interface for the enterprise. Anthropic and OpenAI are coming at it from their AI startup positioning, while Google, Microsoft, and Amazon are leveraging their entrenched hyperscaler and enterprise platform positions.”

Jackson pointed out that the differentiation in what these tech firms offer is most clear in who they are targeting and their delivery model.

He noted that OpenAI’s Workspace Agents are designed for non-technical business teams. They provide templates for agents that can automate tasks from lead scoring to vendor research reports. Users can “prompt” their way to work automation without worrying about the behind-the-scenes mechanics – what model is being used, what APIs are being called, how data is retrieved and written, or how permissions are granted.

Anthropic is taking a different approach, he said. Rather than going directly to business users, it is providing tools to enterprise development teams to build their own agents and provide a custom interface to their users. Anthropic’s Managed Agents are a group of composable APIs that developers can use. The approach is more flexible, but it requires more effort to produce value.

Microsoft and Google, on the other hand, are both vertically integrated platforms providing an agentic layer on top of an extensive stack. Microsoft’s Foundry is similar to Anthropic’s offering, but offers even more flexibility by remaining model-agnostic and allowing developers to choose their preferred agentic framework.

New problems as the market develops

As the agentic platform market develops, Jackson observed, “we are seeing new problems crop up regarding observability. Detecting and observing agents will be rooted in the identity system used to provision them. However, since each platform uses its own identity system, it will be difficult for any one platform to see all agents created in an enterprise, or worse, those created by a rogue user (‘Shadow AI’).”

Furthermore, he added, “agentic workflows imply significantly higher AI token consumption to complete work. We are already seeing AI capacity constraints and price increases due to high demand. Because agents require multiple ‘reasoning’ steps to complete a single task, it is very hard to predict what a workflow you automate today might cost to run one year from now.”

This means that IT leaders need to decide where they will build the agentic layer of their stack. “You don’t want to get it wrong, because becoming entrenched in one platform means significant vendor lock-in,” he said. “We already worry about lock-in with systems and data, but when you add an intelligence layer, you are essentially building a brain with neuronal pathways to your workflows. It is not going to be easy to do a ‘brain transplant’ to another platform later.”

Google is recasting its data and analytics portfolio as the Agentic Data Cloud, an architecture it says is aimed at moving enterprise AI from pilot to production by turning fragmented data into a unified semantic layer that agents can reason over and act on more reliably at scale.

The new architecture builds on Google’s existing data platform strategy, bringing together services such as BigQuery, Dataplex, and Vertex AI, and elevating their capabilities in metadata, governance, and cross-cloud interoperability into what the company describes as a shared intelligence layer.

That intelligence layer strategy is underpinned by the new Knowledge Catalog, an evolution of Dataplex Universal Catalog, that the company said uses new capabilities to extend its metadata foundation into a semantic layer mapping business meaning and relationships across data sources.

These capabilities include native support for third-party catalogs, applications such as Salesforce, Palantir, Workday, SAP, and ServiceNow, and the option to move third-party data to Google’s lakehouse, which automatically maps the data to Knowledge Catalog.

To capture business logic more directly for data stored inside Google Cloud, the company is adding tools including a LookML-based agent, currently in preview, that can derive semantics from documentation, and a new feature in BigQuery, also in preview, that allows enterprises to embed that business logic for faster data analysis.

Beyond aggregation, the catalog itself is designed to continuously enrich semantic context by analyzing how data is used across an enterprise, senior google executives wrote in a blog post.

This includes profiling structured datasets as well as tagging and annotating unstructured content stored in Google Cloud Storage, the executives pointed out, adding that the catalog’s underlying system can also infer missing structure in data by  using its Gemini models to generate schemas and identify relationships.

Turning data into business context the next battleground for AI

For analysts, Google’s focus on semantics targets one of the biggest barriers to production AI for enterprises.

“The hardest AI problem is inconsistent meaning,” said Dion Hinchcliffe, lead of the CIO practice at The Futurum Group, noting that a unified semantic layer could help CIOs establish consistent business context across systems while reducing the need for developers to manually stitch together metadata and lineage.

That focus on semantic context also reflects a broader shift in how hyperscalers are approaching enterprise AI. Microsoft with Fabric IQ and AWS with Nova Forge are pursuing similar strategies, building semantic context layers over enterprise data to make AI systems more consistent and easier to operationalize at scale.

While Microsoft’s approach is to wrap AI applications and agents with business context and semantic intelligence in its Fabric IQ and Work IQ offerings, AWS want enterprises to blend business context into a foundational LLM by feeding it their proprietary data.

Mike Leone, principal analyst at Moor Insights and Strategy, said Google’s approach, though closer to Microsoft’s, places the data gravity one layer above the lakehouse, within its data catalog and semantic graph capabilities.

“Google and Microsoft are solving the same problem from different angles, Fabric through a unified data foundation and Google through a unified semantic and context layer,” Leone said.

Even data analytics software vendors are converging on the idea of offering a catalog that can map semantic context from a variety of data sources, Leone added, pointing to Databricks’ Unity Catalog and Snowflake’s Horizon Catalog.

Semantic accuracy could pose challenges for CIOs

However, Google’s approach to building an intelligent semantic layer, especially its evolved Knowledge Catalog, comes with its own set of risks for CIOs.

The new catalog’s automated semantic context refinement capability, according to Jim Hare, VP analyst at Gartner, could amplify governance challenges, especially around metadata management: “In complex enterprise domains, errors in inferred relationships or definitions will require ongoing human domain oversight to maintain trust.”

Hare also warned of operational and cost management challenges.

“Agent-driven workflows spanning analytical and operational data, potentially across clouds, will introduce new challenges in observability, debugging, and cost predictability,” he said. “Dynamic agent behavior can generate opaque consumption patterns, requiring chief data and analytics officers (CDAOs) to closely manage cost attribution, usage limits, and operational guardrails as these capabilities mature.”

Adopting Google’s new architectural approach could increase dependence at the orchestration layer, resulting in issues around portability, he warned: “Exiting Google-managed semantics, Gemini agents, or BigQuery abstractions may be harder than migrating data alone.”

Bi-directional federation as strategic play

Even so, the trade-offs may be acceptable for enterprises prioritizing tighter data integration over flexibility.

As part of the new architecture, Google is also offering cross-platform data interoperability via the Apache Iceberg REST Catalog that it says will allow bi-directional federation, in turn letting enterprises access, query, and govern data across environments such as Databricks, Snowflake, and AWS without requiring data movement or cost in egress fees.

For Stephanie Walter, practice leader of the AI stack at HyperFRAME Research, this interoperability will be strategically important for enterprises scaling agents in production, especially ones that have heterogenous data environments.

Moor Insights and Strategy’s Leone, though, sees it as a different strategic play to address enterprises’ demand to access Databricks, Snowflake, and hyperscaler environments without costly data movement.

Google’s Agentic Data Cloud architecture also includes a Data Agent Kit, currently in preview, which the company says is designed to help enterprises build, deploy, and manage data-aware AI agents that can interact with governed datasets, apply business logic, and execute workflows across systems.

Robert Kramer, managing partner at KramerERP, said the Data Agent Kit will help data practitioners abstract t daily tasks, in turn lowering the barrier to operationalizing agentic AI across workflows.

However, Gartner’s Hare warned that enterprises should guard against over delegating critical data management decisions to automated agents without sufficient observability, validation controls, and human review, particularly where downstream AI systems depend on these agents for continuous data operations.

The UK’s National Cyber Security Centre (NCSC) is recommending passkeys as the default authentication method for businesses to offer consumers, citing industry progress that now makes them a more secure and user-friendly alternative to passwords.

In a blog post published this week, the agency said passkeys can now be recommended to both the public and businesses as a primary authentication method.

“Passkeys should now be consumers’ first choice of login,” the UK cybersecurity authority said in a blog post, adding that passwords are “no longer resilient enough for the contemporary world.”

“Passkeys are a newer method for logging into online accounts which do much of the heavy lifting for users, only requiring user approval rather than needing to input a password. This makes passkeys quicker and easier to use and harder for cyber attackers to compromise,” the NCSC added in the blog.

The agency said passkeys should be used wherever supported, describing them as resistant to phishing and eliminating risks associated with password reuse.

Focus on phishing-resistant authentication

The guidance is based on the agency’s assessment of how authentication methods perform against real-world attacks.

The NCSC said its analysis examines common techniques, including phishing, credential reuse, and session hijacking, and evaluates how credentials are exposed across their lifecycle, from creation and storage to use.

“Passkeys are resistant to phishing attacks and remove the risks associated with password reuse,” the agency said.

In its accompanying technical paper, the NCSC said traditional authentication methods, including passwords combined with one-time codes, remain “inherently phishable.”

By contrast, FIDO2-based credentials such as passkeys are “as secure or more secure than traditional MFA against all common credential attacks observed in the wild,” the agency said.

However, NCSC cautioned in the technical paper that “while much of the analysis in this paper also applies to enterprise authentication scenarios (for example staff authenticating to a Single Sign On), the different threat model and usage scenarios mean this paper is not intended for enterprise risk assessment.”

How passkeys change the attack model

The NCSC added that passkeys reduce risk by removing reliance on shared secrets and binding authentication to the legitimate service.

According to the agency, this prevents credential reuse and relay attacks, as authentication cannot be intercepted and reused by an attacker.

Passkeys use cryptographic key pairs stored on a user’s device, with authentication tied to device-based verification such as biometrics or PINs, the agency said.

Shift in user-level authentication

For organizations that provide online services to customers, the guidance signals a shift in how authentication is implemented at the user interface level.

“This is a fundamental architectural change, not an incremental authentication upgrade,” said Madelein van der Hout, senior analyst at Forrester. “It moves organizations beyond the passwords-plus-MFA paradigm toward a phishing-resistant foundation.”

Van der Hout said passkeys eliminate risks associated with credential theft by using device-bound cryptographic authentication rather than shared secrets.

“Organizations that treat this as a credential swap will underinvest,” she said. “Those who treat it as a broader identity modernization opportunity will get ahead.”

The NCSC said organizations should also consider how authentication is implemented across the full user journey, including account recovery and fallback mechanisms.

While passkeys reduce reliance on passwords, the agency noted that weaker processes, such as password resets or account recovery flows, can still introduce risk if not properly secured.

Adoption challenges remain

The NCSC said passkeys are not yet universally supported and recommended password managers and multi-factor authentication where passkeys cannot be used.

“Where a particular service does not support passkeys, the NCSC’s advice to consumers is to use a password manager to create stronger passwords and keep using two-step verification,” NCSC noted in the blog post.

Van der Hout said implementation challenges are likely, particularly for organizations operating across multiple platforms and user environments.

“Legacy systems and fragmented identity environments present significant obstacles,” she said.

She added that organizations must also consider non-human identities. “Any passkey strategy that ignores the machine identity layer will create new security gaps,” she said.

Device requirements and account recovery processes may also affect how passkeys are deployed, she said.

Hybrid model is expected during the transition

A full transition away from passwords is unlikely in the near term, analysts believe.

“Expect a hybrid model lasting several years,” van der Hout said, as organizations continue to support both passkeys and traditional authentication methods.

During this period, organizations will need to manage authentication across multiple login options while ensuring that fallback methods do not weaken overall security, she added

The NCSC similarly advised maintaining strong authentication practices where passkeys are not yet available.

Policy signal strengthens shift toward passwordless login

The guidance adds to broader efforts to move away from passwords in consumer authentication.

“The guidance matters because it gives security leaders leverage,” van der Hout said, including in discussions with vendors and internal stakeholders.

The NCSC said that moving toward phishing-resistant authentication could reduce a major cause of cyber compromise, particularly in services that rely on user login credentials.

The article originally appeared in CSO.