Artificial intelligence has had an immediate and profound impact on software development. Coding practices, coding tools, developer roles, and the software development process itself are all being reimagined as AI agents advance on every stage of the software development life cycle, from planning and design to testing, deployment, and maintenance.

Download the May 2026 issue of the Enterprise Spotlight from the editors of CIO, Computerworld, CSO, InfoWorld, and Network World and learn how to harness the power of AI-enabled development.

Let’s be honest about what’s happening in the market: Public cloud has become the easy button for AI. It offers immediate access to compute, storage, managed services, foundation model ecosystems, automation tools, and global reach. For enterprises that want to launch quickly, it is hard to argue against it. You do not need to spend years standing up infrastructure, hiring specialized operations teams, or engineering your own scalable environment before you can test your first use case.

This is exactly why adoption continues even as confidence in cloud resilience becomes more complicated. This article about the expanding cloud market makes the point clearly. Enterprises are not pulling back from hyperscale clouds despite numerous outages. They continue to move forward because the benefits of agility, scalability, and rapid deployment are too valuable to ignore. The cloud remains deeply embedded in business operations, and for many organizations, stepping away would undo years, often decades, of progress.

That is the essence of the easy button. The cloud removes the upfront burden of building and operating the heavy machinery yourself. It centralizes capability. It shortens the time to value. It gives executive teams a way to say yes to AI projects without first funding a long infrastructure transformation. For boards and CEOs under pressure to show AI progress now, that is an attractive proposition.

The economics are not as simple

What gets lost in the excitement is that convenience has a compounding cost structure. The same characteristics that make the public cloud attractive for AI also make it expensive to operate at scale. You pay not only for raw infrastructure but also for abstraction, acceleration, service layering, managed operations, premium tools, and the provider’s margin. As AI success grows, operating costs rise as well.

This matters because AI is not a single-application story. Enterprises rarely stop at a single model, pilot, or use case. They want dozens of solutions spanning customer service, software development, supply chain planning, security operations, analytics, and internal productivity. Every dollar committed to one expensive cloud-based AI workload is a dollar unavailable for the next. That is the strategic issue too many companies overlook.

The question isn’t whether cloud can run AI. Of course it can. In many cases, it is the fastest route to value. The more important question is whether long-term operational spending leaves enough room in the budget to build a portfolio of AI solutions rather than a few isolated wins. If the answer is no, the convenience premium starts to look less like acceleration and more like a constraint.

The operational trade-off

This issue is about something larger than outages. It’s about the economic behavior of hyperscalers and the operating assumptions enterprises are being trained to accept. Major providers are under constant pressure to control costs while expanding services. That means rushed releases, tighter operational budgets, more automation, and fewer deeply experienced engineers to provide oversight. Reliability shifts from an assumed baseline to something closer to good enough.

Azure is described as generating, testing, and deploying tens of thousands of lines of AI-generated code daily. That is not a trivial operating model. It reflects a platform in continuous expansion, becoming more opaque and harder to govern, even as enterprises place increasingly strategic workloads on top of it.

This should matter to AI buyers for two reasons. First, the “easy cloud” button becomes the “cloud dependency” button. You are not just consuming compute. You are tying your AI road map to a provider’s economic incentives, operational discipline, and willingness to prioritize resilience versus revenue expansion. Second, once the cloud becomes the default home for AI, enterprises are often forced to spend more on risk mitigation. Multiregion design, failover architecture, monitoring, governance, and vendor management all contribute to the real operating cost.

None of that means enterprises should abandon public cloud. Enterprises need to enter this partnership with their eyes open and understand that the easy button is rarely the cheap button.

Cloud providers will keep getting rich

The economic logic is straightforward. Providers know enterprises are unlikely to reverse course. Cloud is too embedded, too connected, and too central to ongoing modernization efforts. Outages create frustration, but usually not enough to trigger a mass exodus. The result is a market where providers can continue to expand AI services, attract more workloads, and increase revenue while customers absorb more of the operational burden.

That burden is not limited to compute and storage invoices. It includes the architecture required to withstand provider failures, the in-house talent needed to monitor complex environments, and the governance needed to control sprawl. Building with failure in mind is now a standard cost, not an avoidable exception. That is a profound shift, and enterprises should treat it as such.

The likely outcome is that cloud providers will continue to aggressively grow their AI revenue. Enterprises will continue to buy because the alternative is slower, harder, and often politically difficult within the organization. But that revenue growth will come at a cost to enterprise buyers, who may discover too late that an expensive AI operating model reduces the total number of AI bets they can afford to place.

The smarter path forward

Rather than adopt an anti-cloud strategy, enterprises need a selective cloud strategy. Use public cloud where speed, scale, and ecosystem access matter most. Be deliberate about which AI workloads deserve that premium and which might be better served over time by private cloud, hybrid architecture, or more controlled on-premises environments. Preserve optionality. Avoid treating the first convenient platform choice as a permanent architectural truth.

Always remember that AI success is not defined by how quickly you launch the first solution. It is defined by how many useful, sustainable, and economically rational solutions you can build over the next several years. Public clouds often look like (and could be) the right choice for AI workloads. However, enterprises that conflate ease with efficiency will fund cloud providers’ growth while limiting their ability to scale AI where it matters most. Look beyond the day when an AI workload goes live.

Cloudflare is giving AI agents full autonomy to spin up new apps.

Starting today, agents working on behalf of humans can create a Cloudflare account, begin a paid subscription, register a domain, and then receive an API token to let them immediately deploy code.

To kick things off, human users must first accept the cloud company’s terms of service. From there, though, their role in the loop is optional; they don’t have to return to the dashboard, copy and paste API tokens, or enter credit card details. The AI agent just does its thing behind the scenes and has everything it needs to deploy “in one shot,” according to Cloudflare.

While this could be a boon to developers and product builders, it also signals a larger, concerning trend of over-trust in autonomous tools, to the detriment of governance and security.

For example, noted David Shipley of Beauceron Security, cyber criminals are being forced to constantly set up new infrastructure as security firms and law enforcement fight back to block online attacks and scams. “Making it even faster to build new infrastructure and deploy it quickly is a huge win for them,” he said.

Giving agents the OAuth keys

Cloudflare co-designed the new protocol in partnership with Stripe, building upon the Cloudflare Code Mode MCP server and Agent Skills. Any platform with signed-in users can integrate it with “zero friction” for the user, Cloudflare product managers Sid Chatterjee and Brendan Irvine-Broque wrote in a blog post.

The new protocol is part of Stripe Projects (still in beta), which allows humans and their agents to provision multiple services, including AgentMail, Supabase, Hugging Face, Twilio, and a couple of dozen others, generate and store credentials, and manage usage and billing from their command line interface (CLI). An agent is given an initial $100 to spend per month, per provider.

Users need only install the Stripe CLI with the Stripe Projects plugin, login to Stripe, start a new project, prompt an agent to build something new, and deploy it to a new domain. If their Stripe login email is associated with a Cloudflare account, an OAuth flow will kick off; otherwise Cloudflare will automatically create an account for the user and their agent.

From there, the autonomous agent will build and deploy a site to a new Cloudflare account, then use the Stripe Projects CLI to register the domain. Once deployed, the app will run on the newly-registered domain.

Along the way, the agent will prompt for input and approval “when necessary,” for instance, when there’s no linked payment method. As Cloudflare notes, the agent goes from “literal zero” to full deployment.

To build momentum, the company is offering $100,000 in Cloudflare credits to startups that make use of the new capability via Stripe Atlas, which helps companies incorporate in Delaware, set up banking, and engage in fundraising.

How the agent takes action

Agents interact with Stripe and Cloudflare in three steps: discovery (the agent calls a command to query the catalog of available services); authorization (the platform validates identity and issues credentials); and payment (the platform provides a payment token that providers use to bill humans when their agents start subscriptions and make purchases).

Cloudflare emphasizes that this process builds on standards like OAuth, the OpenID Connect (OIDC) identity layer, and payment tokenization, but removes steps that would otherwise require human intervention.

During the discovery phase, agents call the Stripe Projects catalog command, then choose among available services based on human commands and preferences. However, “the user needs no prior knowledge of what services are offered by which providers, and does not need to provide any input,” Chatterjee and Irvine-Broque explained.

From there, Stripe acts as the identity provider, and credentials are securely stored and available for agents that need to make authenticated requests to Cloudflare. Stripe sets a default $100 monthly maximum that an agent can spend on any one provider. Humans can raise this limit and set up budget alerts as required.

The platform, said Cloudflare, acts as the orchestrator for signed-in users. Agents make one API call to provision a domain, storage bucket, and sandbox, then receive an authorization token.

The company argued that the new protocol standardizes what are typically “one off or bespoke” cross-product integrations. It uses OAuth, and extends further into payments and account creation in a way that “treats agents as a first-class concern.”

Concerns around security, operations

The trend of people buying products “wherever they are” will become ever more widespread, noted Shashi Bellamkonda, a principal research director at Info-Tech Research Group.

For instance, Uber has announced an Expedia integration for hotel bookings that will make it an ‘everything app.’ Other vendors are similarly expanding their partner ecosystems, because obtaining customers via other established platforms as well as their own is more cost-efficient, and “generally results in a higher lifetime value,” said Bellamkonda.

“This is Cloudflare turning every partner with signed-in users into a sales channel, and that is how you grow revenue in a developer market,” he said.

Beauceron’s Shipley agreed that Cloudflare is the “big winner” here. “Making it faster for anyone to buy your service and get using it is technology platform Nirvana.”

It’s “super cool, bleeding edge” and in theory, for legitimate developers becomes part of the even more automated build process, he said; “Vibe coders will rejoice.” But, he noted, so will cyber crooks.

Further, Bellamkonda pointed out, from an operational perspective, this could create added complexity for each vendor’s partner network when it comes to transaction execution and accountability. If issues related to provisioning or billing transactions arise, businesses must have a clearly defined process for resolving them with all parties.

“This will require considerable upfront thought on developing these comparatively new business models,” Bellamkonda said.

A supply chain attack on SAP-related npm packages has put fresh scrutiny on the developer tools and build workflows that enterprises rely on to produce software.

The campaign, referred to as “mini Shai-Hulud,” affected packages used in SAP’s JavaScript and cloud application development ecosystem.

The malicious versions added installation-time code that could steal developer credentials, GitHub and npm tokens, GitHub Actions secrets, and cloud credentials from AWS, Azure, GCP, and Kubernetes environments.

Researchers at SafeDep, Aikido Security, Wiz, and several other security firms said the affected packages included mbt@1.2.48, @cap-js/db-service@2.10.1, @cap-js/postgres@2.2.2, and @cap-js/sqlite@2.2.2.

The suspicious versions were published on April 29 and were later replaced by safe releases.

The malware encrypted stolen data and sent it to public GitHub repositories created from victims’ own accounts, according to the researchers. It also used stolen GitHub and npm tokens to add malicious GitHub Actions workflows to accessible repositories and publish poisoned package versions.

SafeDep said the attackers abused a configuration gap in npm’s OIDC trusted publishing setup for the affected @cap-js packages. The compromise of mbt, meanwhile, is suspected to involve a static npm token.

The attackers also attempted to persist through Visual Studio Code and Claude Code configuration files. The technique puts developer workstations and AI-assisted coding tools closer to the center of supply chain security concerns.

Implications for CISOs

For CISOs, the case shows how quickly a tainted dependency can move beyond the build process. It also adds to concerns that developer environments, though central to enterprise software delivery, are still not governed with the same rigor as production systems.

“The fact that the malware was designed to harvest GitHub and npm tokens, GitHub Actions secrets, and cloud credentials from AWS, Azure, GCP, and Kubernetes in a single pass tells you that attackers now treat the developer workstation as a master key,” said Sakshi Grover, senior research manager for IDC Asia Pacific Cybersecurity Services.

A single compromised developer identity in a CI/CD pipeline can give attackers a route into the wider software supply chain, allowing them to push malicious code into packages that downstream developers may install with little visibility into tampering.

That lack of visibility remains a concern, Grover said, citing IDC’s Asia Pacific Security Survey 2025, which found that 46% of enterprises plan to deploy AI for third-party and supply chain risk analysis over the next 12 to 24 months. For now, she said, many organizations are still in the planning stage and have yet to operationalize AI-driven defenses against attacks such as the mini Shai-Hulud campaign.

Sunil Varkey, a cybersecurity analyst, described the campaign as a case of “living off the developer,” where attackers target developers, their tools, and automation rather than only the software package itself.

Varkey said the attackers went beyond poisoning npm packages by compromising maintainer GitHub accounts, abusing loosely configured npm OIDC Trusted Publishing, and using preinstall hooks to publish credential-stealing malware.

The more troubling element, he said, was the use of Visual Studio Code and Claude Code configuration files, specifically .vscode/tasks.json and .claude/settings.json, for persistence and propagation. That allowed the malware to execute when an infected repository was opened in Visual Studio Code, or when a Claude Code session started, he said.

“The attacker is turning the modern developer experience itself into an attack vector,” Varkey said.

The article originally appeared in CSO.

At Kubecon Europe recently, Linux kernel maintainer Greg Kroah-Hartman said something that surprised me. After more than a year of AI-based pull requests and security reports that were worthless, living up to their nickname of “slop,” suddenly in the last month or so Kroah-Hartman discovered that those reports had become useful. At the time he didn’t know why, but guessed it was the result of improved tools and a deeper understanding of how to use them.

Since then, of course, we’ve learned about Anthropic’s Claude Mythos and seen the resulting scramble across closed-source and open-source projects to patch the significant bugs and issues Mythos has unveiled. The fixes and updates needed by large projects can be managed by their equally large teams, with corporate input as well as volunteers from around the world. But how do smaller projects deal with the rise in reported critical vulnerabilities, when they’re usually run by one or two people, often working in their spare time?

It’s a crisis of developer productivity. We need code that’s fixed and we need it now, but we don’t have enough skilled developers to deliver those fixes in the limited time available.

Can agents solve the problem?

Agent harnesses have become increasingly powerful tools, providing frameworks for orchestrating and managing teams of agents. General purpose tools like OpenClaw have proven to be particularly popular, though they can be expensive to run, with operations using up a substantial number of tokens across models and services. However, like most general purpose AI applications based on large language models (LLMs), inaccuracies and hallucinations can affect outputs.

Even so, an approach like this that’s grounded both in a defined methodology and in a significant corpus of data could help us meet the sudden demand for increased developer productivity — using the structured nature of code and APIs as grounding and the combinations of skills that go into building a modern software development team and addressing the various aspects of the software development life cycle.

What’s needed is a way to take advantage of those tools to build on techniques like spec-driven development and agent harnesses to provide developers with their own team of agents. Soon, agents may provide that force multiplier needed to keep ahead of AI red teams and at the same time help clear out large amount of technical debt.

Here comes the Squad

One interesting example of this approach is Squad, an open-source project from Brady Gaster, Principal PM Architect in the CoreAI Apps and Agents team at Microsoft. Squad builds an agent harness around GitHub Copilot, orchestrating a team of agents to work on your code with you. Designed to be installed with a single CLI call, Squad creates agents to handle application development: a developer lead, a front-end developer, a back-end developer, and a test engineer. Other roles, like documentation, can also be managed by Squad.

The intent is to replicate the structure of a team building a web application, using natural language inputs to define the task, with the agent harness then coordinating Squad’s agents to build and test the necessary code. Gaster has made some interesting decisions as part of the tool’s architecture, such as requiring a separate agent to fix issues detected by another agent’s tests.

This approach is designed to prevent an agent from looping around the same set of statistically generated outputs. Instead, a new agent offers a new context window and a new set of seeds, allowing it to generate different solutions to the same inputs. Only then will Squad generate a pull request for human review. You the developer are still in the loop, but you’re the senior developer and architect to Squad’s team of junior engineers.

Another interesting architectural decision was to ignore the convention of having agent-to-agent chats as a tool for synchronizing decisions. Experience inside Microsoft has shown this approach to be fragile. As a result, Squad treats agents as a set of asynchronous distributed computing tasks, using external persistent storage to hold details of architectural and other decisions. The shared storage, based on a strict format that can be accessed by different generations of the Squad agents, ensures that decisions can be passed between projects and that context is preserved between sessions.

Having a defined source of context also ensures that when any member of your team clones your application repository, their Squad agents have access to the same “memory” and can start working as soon as the Squad CLI is loaded or launched from Visual Studio Code or GitHub Copilot. It’s an efficient approach that saves time and ensures that everyone on the project and using Squad has the same starting point.

Getting started with Squad

To get started with Squad, you need to have an up-to-date Node.js installation on your development machine, along with a Git repository to store code and the Markdown documents used by Squad to store its context. With those in place, a single call to npm installs the Squad CLI, ready for use.

You set up the Squad environment with its init command. You can run Squad from its CLI or from inside Visual Studio Code and GitHub Copilot, where it’s available as an agent. You can also use Squad from the GitHub Copilot CLI, which gives you an interactive view of how the various Squad agents work.

Squad’s CLI works well for basic projects but using Squad as part of Copilot also gives access to additional resources, including Model Context Protocol (MCP) servers, which can help with more complex application developments as well as providing more useful grounding for specific Squad agents. However, there’s enough flexibility here to fit Squad into your existing toolchain, allowing you to make it part of your workflow, rather than vice versa.

There is a third way to use Squad: working with the Squad SDK to build your own automation framework around the Squad tooling. Here you’ll use TypeScript to manage agent creation, as well as writing your own routers and coordination services. The Squad SDK is a powerful tool that can be used as part of more formal development processes, for example integrating into a CI/CD pipeline to help triage a high volume of pull requests. As all three ways of working with Squad use the same back end, they all share the same memories, so will respond to inputs in similar ways.

Using Squad to write and fix code

I used Squad from the Copilot CLI, building a basic Node Express application, with a web front end. What was perhaps most interesting about the process was that the Squad harness allowed its role-based agents to work in parallel: an agent building back-end code to support service APIs could run at the same time as an agent that was building a React-based user interface. The initial squad of agents that Squad generated included an architect as well as front-end and back-end developers.

Squad’s output was, at least in my test applications, clear and easy to understand, ready to be used as the basis for a more complex application. It was delivered quickly, using a test-driven approach to ensure that code performed as intended, with no obvious bugs. By taking a formal approach to software development, Squad can reduce risks and explain its actions to a human user. It can also be used to document the code it delivers, using another specialized agent to deliver documentation.

There’s plenty of human supervision in the process, though there’s also the option of handing over control of repetitive tasks to Squad. After some time, you can build up enough trust that you don’t need to approve every new file or directory. A squad works in the context of your Git repository, but if you want more security you can choose to run your squad inside a dev container, keeping it in an isolated environment.

Here comes the artificial junior developer

We’re still at the very beginning of the process of using AI-based tooling as part of our development workflows, but the available tools are starting to mature very quickly — both as models improve and as we learn how to build the long workflows needed to implement agent-based applications.

Squad’s approach to development mixes well-understood software development methodologies with the team structure necessary to deliver applications. For now, as Squad is alpha code, it’s something to experiment with in limited, well-understood use cases.

But as our understanding of how to use AI-powered development tools grows, it’s easy to see how AI coding might evolve to become something like Squad — a way of harnessing agents to behave like a pocket development team that keeps a human in the loop as development lead to a team of artificial junior developers. And maybe we’ll be able to keep up with Claude Mythos and its descendants.

In The Sorcerer’s Apprentice, Mickey Mouse uses a magic spell to do his chores. The spell animates a broom that is tasked with carrying water from the well. While the animated broom is managed, it gets the job done; when Mickey falls asleep, the broom carries on its work. When Mickey can’t stop the broom, he chops it to bits with an axe, but all the pieces re-animate and carry on as before. Finally the Sorcerer intervenes to stop the broom and clean up the mess.

Similarly, AI promises to lighten the burden of operating databases. For example, using AI to write SQL queries or optimize performance are obvious areas to apply this technology. There is a huge amount of SQL on the internet that can be used to train models around what good queries should look like, and transforming natural language into accurate SQL has a lot of promise.

Further, using AI to handle database management issues should deliver faster performance, more reliable systems, and more efficient use of resources. Customers demand more help around those pain points, and they expect that any supplier can respond to those issues faster with AI. For problems that companies view as “low hanging fruit,” they expect self-service AI to solve those problems on demand rather than waiting.

AI promise meets real-world challenge

Already, we have seen AI get deployed around SQL and database management. BIRD (BIg bench for laRge-scale Database grounded text-to-SQL evaluation) publishes its benchmark around how models perform, with the current top AI performing at nearly 82% execution accuracy, based on a Valid Efficiency Score (VES). (See the paper on BIRD for details.) How good is a VES of 82%? Currently, human database engineers have a VES of nearly 93%.

The current gap between human and AI performance will shrink over time. But it is currently a great example of the Pareto Principle at work — from around 20% of your effort, you can get 80% of your results. To achieve that remaining 20% of results, you have to put in 80% of your effort. With AI, dealing with the simpler issues is where you can achieve the best results, but the harder problems still need a human in the loop to solve the problem or reach the intended goal.

For database management, this is something that we have seen at Percona. Using previous consulting engagements and service delivery projects as a base, we looked at how to automate steps around database management so customers could use AI to solve problems. Once we had the model developed, we tested it internally on database installations. We found that AI did help our team to deliver more efficiently around those simple problems, speeding up how fast they could respond.

At the same time, while these AI systems could make progress on more complex requests, they could not complete the “last mile” by themselves at the start. To overcome this, we looked at how the AI models used data to formulate responses and what sources the model called on most often. This led to more refinement and improvement in the systems alongside a human decision-maker that could understand what the AI was recommending, why it would be suitable, and where it could be improved.

Databases are essential components in the technology stack. As systems of record and sources for data analysis, they have to be reliable, available, and secure. Any decision around databases — from which database you choose for the job through to choices on management or optimization — can have a big impact. Any change has to be managed, or the result can be a broken application.

AI and the future of databases

Database management needs AI. The demand from customers for faster fixes and better performance is not going away, and those customers expect their suppliers to use AI in the same way they might use AI internally. For companies involved in service and support around IT including databases, applying AI to solve problems faster isn’t something that you can avoid. However, the human in the loop model will be essential for these service and support requirements for the foreseeable future. With databases so critical to how applications function and support the business, fully automating service with AI is not yet reliable for 100% of requests. As AI improves, the speed will benefit the majority of potential issues. However, the more complex problems will still require human expertise and control.

The demands of database customers will force teams to use AI. Whether this is internal teams that adopt AI to help them manage database deployment within internal developer platforms, or external service providers that support customers around problems. Customers will move to alternatives if they can’t get the speed of response that they expect. This could be through adopting another service provider for a database like PostgreSQL, or moving to a cloud or managed service provider that can offer better response times. 

Mickey used magic to try and solve a problem, but he did not foresee all of the potential consequences. For those who are not database specialists, AI can help them write SQL, manage common tasks, or solve some of the simple problems, but there will always be edge cases where human skills and understanding will be needed. Arthur C. Clarke’s Third Law states that any sufficiently advanced technology is indistinguishable from magic, but the combination of AI and human skill around databases will have the greatest long-term impact without resorting to sorcery.

—

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

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.