A massive surge in attacks on the npm ecosystem over the past year reveals a stark shift in the software supply‑chain threat landscape.

What once amounted to sloppy typosquatting attempts has evolved into coordinated, credential-driven intrusions targeting maintainers, CI pipelines, and the trusted automation that underpins modern development.

For security leaders, these aren’t niche developer mishaps anymore — they’re a direct pathway into production systems, cloud infrastructure, and millions of downstream applications.

The goal is no longer to trick an individual developer, but to quietly inherit their authority. And with it, their distribution reach.

“NPM is an attractive target because it is the world’s largest JavaScript package repository and a key control point for distributing software,” said Melinda Marks, cybersecurity practice director at Enterprise Security Group. “Security teams need an understanding of dependencies and ways to regularly audit and mitigate risk.”

Structural weaknesses in the npm infrastructure

Nearly every enterprise relies on npm, whether directly or indirectly. According to IDC, 93% of organizations use open-source software, and npm remains the largest package registry in the JavaScript ecosystem. “Compromising a single popular package can immediately reach millions of downstream users and applications,” IDC’s research manager (DevSecOps), Katie Norton, said, turning one stolen credential into what she described as a “master key” for distribution.

That scale, however, is only part of the risk.

The exposure is amplified by structural weaknesses in how modern development pipelines are secured, Norton remarked. “Individual open-source maintainers often lack the security resources that enterprise teams rely on, leaving them susceptible to social engineering,” she said. “CI/CD runners and developer machines routinely process long-lived secrets that are stored in environment variables or configuration files and are easily harvested by malware.”

“Build systems also tend to prioritize speed and reliability over security visibility, resulting in limited monitoring and long dwell times for attackers who gain initial access,” Norton added.

While security leaders can’t patch their way out of this one, they can reduce exposure. Experts consistently point to the same priorities: treating CI runners as production assets, rotating and scoping publish tokens aggressively, disabling lifecycle scripts unless required, and pinning dependencies to immutable versions.

“These npm attacks are targeting the pre-install phase of software dependencies, so typical software supply chain security methods of code scanning cannot address these types of attacks,” Marks said. Detection requires runtime analysis and anomaly detection rather than signature-based tooling.

From typo traps to legitimate backdoors

For years, typosquatting defined the npm threat model. Attackers published packages with names just close enough to popular libraries, such as “lodsash,” “expres,” “reacts,” and waited for automation or human error to do the rest. The impact was usually limited, and remediation straightforward.

That model began to break in 2025.

Instead of impersonating popular packages, attackers increasingly compromised real ones. Phishing campaigns spoofing npm itself harvested maintainer credentials. Stolen tokens were then used to publish trojanized updates that appeared legitimate to every downstream consumer. The Shai-Hulud campaign illustrated the scale of the problem, affecting tens of thousands of repositories and leveraging compromised credentials to self-propagate across the ecosystem.

“The npm ecosystem has become the crown jewels of modern development,” said Kush Pandya, a cybersecurity researcher at Socket.dev. “When a single prolific maintainer is compromised, the blast radius spans hundreds of downstream projects.”

The result was a quiet but powerful shift: attackers no longer needed to create convincing fakes. They could ship malware through trusted channels, signed and versioned like any routine update.

Developer environments over developer laptops

Modern npm attacks increasingly activate inside CI/CD environments rather than on developer laptops. Post-install scripts, long treated as benign setup helpers, became an execution vector capable of running automatically inside GitHub Actions or GitLab CI. Once inside a runner, malicious packages could read environment variables, steal publish tokens, tamper with build artifacts, or even push additional malicious releases under the victim’s identity.

“Developer environments and CI runners are now worth more than end-user machines,” Pandya noted. “They usually have broader permissions, access to secrets, and the ability to push code into production.”

Several campaigns observed in mid-2025 were explicitly CI-aware, triggering only when they detected automated build environments. Some included delayed execution or self-expiring payloads, minimizing forensic visibility while maximizing credential theft.

For enterprises, this represents a fundamental risk shift. CI systems often operate with higher privileges than any individual user, yet are monitored far less rigorously. “They are often secured with weaker defaults: long-lived publish tokens, overly permissive CI secrets, implicit trust in lifecycle scripts and package metadata, and little isolation between builds,” Pandya noted.

According to IDC Research, organizations allocate only about 14% of AppSec budgets to supply-chain security, with only 12% of them identifying CI/CD pipeline security as a top risk.

Evasion as a first-class feature

As defenders improved at spotting suspicious packages, attackers adapted too.

Recent npm campaigns have used invisible Unicode characters to obscure dependencies, multi-stage loaders that fetch real payloads only after environment checks, and blockchain-hosted command-and-control (C2) references designed to evade takedowns. Others deployed worm-like behavior, using stolen credentials to publish additional malicious packages at scale.

Manual review has become largely ineffective against this level of tradecraft. “The days when you could skim index.js and spot a malicious eval() are gone,” Pandya said.

“Modern packages hide malicious logic behind layers of encoding, delayed execution, and environment fingerprinting.” Norton echoed the concern, noting that these attacks operate at a behavioral level where static scanning falls short. “Obfuscation techniques make malicious logic difficult to distinguish from legitimate complexity in large JavaScript projects,” she said. “CI-aware payloads and post-install scripts introduce behavior that only manifests under specific environmental conditions.”

JetBrains has released Compose Multiplatform 1.10.0, the latest version of the Kotlin-based declarative framework for building shared UIs across multiple platforms. Unveiled January 13, the update supports automatic resizing for native interop elements on both desktop and iOS deployments.

Resizing of these elements means they now can adapt their layout to their content, eliminating the need to calculate exact sizes manually and specify fixed dimensions in advance. On the desktop,SwingPaneladjusts its size based on the embedded component’s minimum, preferred, and maximum sizes. For iOS, UIKit interop views now support sizing according to the view’s fitting size (intrinsic content size). This enables proper wrapping of SwiftUI views (via UIHostingController) and basic UIView subclasses that do not depend on NSLayoutConstraints.

Instructions on getting started with Compose Multiplatform can be found at kotlang.org. Compose Multiplatform is an optional UI framework built atop Kotlin Multiplatform technology, for building applications for different platforms and reusing code. Compose Multiplatform applications will run on iOS, Android, macOS, Windows, Linux, and the web.

Also in version 1.10.0, Compose Multiplatform now uses the Web Cache API to cache successful responses for static assets and string resources. This avoids the delays associated with the browser’s default cache, which validates stored content through repeated HTTP requests and can be slow on low-bandwidth connections. The cache is cleared on every app launch or page refresh to ensure resources remain consistent with the application’s current state. This capability is an experimental feature.

Other improvements in Compose Multiplatform 1.10.0 include:

• The Compose Hot Reload plugin now is bundled with the Compose Multiplatform Gradle plugin. Users no longer need to configure the Hot Reload plugin separately, as it is enabled by default for Compose Multiplatform projects targeting desktop.
• The approach to previews has been unified across platforms. Developers can now use the androidx.compose.ui.tooling.preview.Preview annotation in thecommonMainsource set. Other annotations, such as org.jetbrains.compose.ui.tooling.preview.Previewand the desktop-specific androidx.compose.desktop.ui.tooling.preview.Preview, have been deprecated.
• Navigation 3, a new library for managing navigation, is now supported on non-Android targets.
• The following properties inDialogPropertieshave been promoted to stable and are no longer experimental: usePlatformInsets, useSoftwareKeyboardInset, and scrimColor. Similarly, the usePlatformDefaultWidth and usePlatformInsetsproperties in PopupProperties have also been promoted to stable.
• The deprecation level for Popup overloads without the PopupProperties parameter has been changed to ERROR to enforce the use of the updated API.
• For iOS, Compose Multiplatform now supports WindowInsetsRulers, which provides functionality to position and size UI elements based on window insets, such as the status bar, navigation bar, or on-screen keyboard.

Popular vibe coding platforms consistently generate insecure code in response to common programming prompts, including creating vulnerabilities rated as ‘critical,’ new testing has found.

Security startup Tenzai’s top-line conclusion: the tools are good at avoiding security flaws that can be solved in a generic way, but struggle where what distinguishes safe from dangerous depends on context.

The assessment, which it conducted in December 2025, compared five of the best-known vibe coding tools — Claude Code, OpenAI Codex, Cursor, Replit, and Devin — by using pre-defined prompts to build the same three test applications.

In total, the code output by the five tools across 15 applications (three each) was found to contain a total of 69 vulnerabilities. Around 45 of these were rated ‘low-medium’ in severity, with many of the remainder rated ‘high’ and around half a dozen ‘critical’.

While the number of low-medium vulnerabilities was the same for all five tools, only Claude Code (4 flaws), Devin (1) and Codex (1) generated critical-rated vulnerabilities.

The most serious vulnerabilities concerned API authorization logic (checking who is allowed to access a resource or perform an action), and business logic (permitting a user action that shouldn’t be possible), both important for e-commerce systems.

“[Code generated by AI] agents seems to be very prone to business logic vulnerabilities. While human developers bring intuitive understanding that helps them grasp how workflows should operate, agents lack this ‘common sense’ and depend mainly on explicit instructions,” said Tenzai’s researchers.

Offsetting this, the tools did a good job of avoiding common flaws that have long plagued human-coded applications, such as SQLi or XSS vulnerabilities that are both still prominently featured in the OWASP Top 10 list of web application security risks.

“Across all the applications we developed, we didn’t encounter a single exploitable SQLi or XSS vulnerability,” said Tenzai.

Human oversight

The vibe coding sales pitch is that it automates everyday programming jobs, boosting productivity. While this is undoubtedly true, Tenzai’s test shows that the idea has limits; human oversight and debugging are still needed.

This isn’t a new discovery. In the year since the concept of ‘vibe coding’ was developed, other studies have found that, without proper supervision, these tools are prone to introducing new cyber security weaknesses.

But it’s not simply that vibe coding platforms aren’t picking up security flaws in their code; in some cases, defining what counts as good or bad is simply impossible using general rules or examples.

“Take SSRF [Server-Side Request Forgery]: there’s no universal rule for distinguishing legitimate URL fetches from malicious ones. The line between safe and dangerous depends heavily on context, making generic solutions impossible,” said Tenzai. 

The obvious solution is that, having invented vibe coding agents, the industry should now focus on vibe coding checking agents, which, of course, is where Tenzai, a small startup not long out of stealth mode, thinks it has found a gap in the market for its own technology. It said, “based on our testing and recent research, no comprehensive solution to this issue currently exists. This makes it critical for developers to understand the common pitfalls of coding agents and prepare accordingly.”

Debugging AI

The deeper question raised by vibe coding isn’t how well tools work, then, but how they are used. Telling developers to keep eyes on vibe code output isn’t the same as knowing this will happen, any more than it was in the days when humans made all the mistakes.

“When implementing vibe coding approaches, companies should ensure that secure code review is part of any Secure Software Development Lifecycle and is consistently implemented,” commented Matthew Robbins, head of offensive security at security services company Talion. “Good practice frameworks should also be leveraged, such as the language-agnostic OWASP Secure Coding Practices, and language-specific frameworks such as SEI CERT coding standards.” 

Code should be tested using static and dynamic analysis before being deployed, Robbins added. The trick is to get debugging right. “Although vibe coding presents a risk, it can be managed by closely adhering to industry-standard processes and guidelines that go further than traditional debugging and quality assurance,” he noted.

However, according to Eran Kinsbruner, VP of product marketing at application testing organization Checkmarx, traditional debugging risks being overwhelmed by the AI era.

“Mandating more debugging is the wrong instinct for an AI-speed problem. Debugging assumes humans can meaningfully review AI-generated code after the fact. At the scale and velocity of vibe coding, that assumption collapses,” he said.

“The only viable response is to move security into the act of creation. In practice, this means agentic security must become a native companion to AI coding assistants, embedded directly inside AI-first development environments, not bolted on downstream.”

This article originally appeared on CSOonline.

Chinese company Zhipu AI has trained image generation model entirely on Huawei processors, demonstrating that Chinese firms can build competitive AI systems without access to advanced Western chips.

The model, released on Tuesday, marks the first time a state-of-the-art multimodal model completed its full training cycle on Chinese-made chips, Zhipu said in a statement. The Beijing-based company trained the model on Huawei’s Ascend Atlas 800T A2 devices using the MindSpore AI framework, completing the entire pipeline from data preprocessing through large-scale training without relying on Western hardware.

The achievement carries strategic significance for Zhipu, which the US Commerce Department last year added to a list of entities acting contrary to US national security or foreign policy interests over its alleged ties to China’s military. The designation effectively cut the company off from Nvidia’s H100 and A100 GPUs, which have become standard for training advanced AI models, forcing Chinese firms to develop alternatives around domestic chip architectures.

Followign that listing, Zhipu began collaborating with Huawei on GLM-Image. Huawei’s Ascend processors have become the primary alternative for Chinese AI companies restricted from purchasing Nvidia’s hardware. The model’s successful training on Ascend chips provides a data point that Chinese firms can develop competitive AI systems despite restricted access to Western chips.

“This proves the feasibility of training high-performance multimodal generative models on a domestically developed full-stack computing platform,” Zhipu’s statement added.

Zhipu has made GLM-Image available through an API for 0.1 yuan (approximately $0.014) per generated image. The company released the model weights on GitHub, Hugging Face, and ModelScope Community for independent deployment.

The pricing positions GLM-Image as a cost-effective option for enterprises generating marketing materials, presentations, and other text-heavy visual content at scale.

Technical approach and benchmark performance

GLM-Image employs a hybrid architecture combining a 9-billion-parameter autoregressive model with a 7-billion-parameter diffusion decoder, according to Zhipu’s technical report. The autoregressive component handles instruction understanding and overall image composition, while the diffusion decoder focuses on rendering fine details and accurate text.

The architecture addresses challenges in generating knowledge-intensive visual content where both semantic understanding and precise text rendering matter, such as presentation slides, infographics, and commercial posters.

On the CVTG-2K benchmark, which measures accuracy in placing text across multiple image locations, GLM-Image achieved a Word Accuracy score of 0.9116, ranking first among open-source models. The model also led the LongText-Bench test for rendering extended text passages, scoring 0.952 for English and 0.979 for Chinese across eight scenarios including signs, posters, and dialog boxes.

The model natively supports multiple resolutions from 1024×1024 to 2048×2048 pixels without requiring retraining, the report added.

Hardware optimization strategy

Training GLM-Image on Ascend hardware required Zhipu to develop custom optimization techniques for Huawei’s chip architecture. The company built a training suite that implements dynamic graph multi-level pipelined deployment, enabling different stages of the training process to run concurrently and reducing bottlenecks.

Zhipu also created high-performance fusion operators compatible with Ascend’s architecture and employed multi-stream parallelism to overlap communication and computation operations during distributed training. These optimizations aim to extract maximum performance from hardware that operates differently from the Nvidia GPUs most AI frameworks target by default.

The technical approach validates that competitive AI models can be trained on China’s domestic chip ecosystem, though at what cost in development time and engineering effort remains unclear.

Zhipu did not say how many processors or how long it took to train its model, nor how the requirements compared to equivalent Nvidia-based systems.

Implications for global AI development

For multinational enterprises operating in China, GLM-Image’s training on domestic hardware provides evidence that Chinese AI infrastructure can support state-of-the-art model development. Companies with Chinese operations may need to evaluate whether to develop strategies around platforms like Huawei’s Ascend and frameworks like MindSpore.

The release comes as Chinese companies invest in domestic AI infrastructure alternatives. Whether export controls will slow or accelerate the development of parallel AI ecosystems remains a subject of policy debate.

Last week it was looms. This week it is potato chips.

I’m a huge fan of EconTalk, a podcast hosted by Russ Roberts. Russ is a great guy and his guests are invariably interesting. One of my all-time favorite episodes is Brendan O’Donohoe on Potato Chips and Salty Snacks, in which O’Donohoe and Roberts talk about how potato chips are made. Now that might not sound interesting, but I found it fascinating. First, O’Donohoe is both an expert and an enthusiast about potato chips. (Who isn’t?) More interestingly, he provides valuable insights into how the process has become increasingly efficient over time. 

The main thrust of improving the production of potato chips was discovering the bottleneck and then fixing that step in the process until it was no longer the bottleneck. Once that bottleneck was removed, something else was found to be the bottleneck. Then you’d fix that, and so on, until the process is so efficient that it isn’t worth taking the time to fix the bottleneck that is barely a bottleneck at all anymore.

After I wrote the loom article last week, it occurred to me that the process of software development is no different. And thus, to improve it, we should find the bottleneck, figure out a way to make it no longer the bottleneck, and repeat. 

And it seems obvious to me that the actual coding of the application is the narrow, high-pressure point in the software development pipeline. In a process full of friction, writing the code is usually the bottleneck that determines when a project gets finished.

So what happens if writing code ceases to be the bottleneck? Well, I think we are just about there with agentic coding, no? For the sake of argument, and to keep this column rolling, let’s assume that such is the case. Let’s take it as granted that writing code becomes something that happens over days and weeks, and not weeks, months, or even years. 

What would that mean?

Well, first of all, requirements would have to become more specific. Right now, developers tend to accept requirements that are more vague than they might like because they know that things can be continuously refined and that we can “figure that all out as we go.” That won’t work with coding agents.

If an agentic coding system is fed vague inputs, it will produce vague outputs, right? Garbage in, garbage out is as true a statement as there is in computing. Thus, what you tell your coding agent to do will have to be clear and specific. Getting that right will be the new skill that software development teams have to develop. You might even view it as “coding in English.”

The next result is that a lot more software will be created, some of it good, some of it bad. Right now, I suspect there are many ideas for software—both features for existing software and whole new applications—that aren’t being built because the actual writing of the code is too costly or too difficult for the folks with the ideas. 

Sure, this is going to lead to a lot more “AI slop” software—easy execution always amplifies bad judgment—but there will also be a lot more great ideas that actually come to fruition. Existing software will end up with a lot more features than human developers alone could deliver. It will be the job of product managers to make sure that the product stays useful. (As a former product manager myself, I can say it would be great to be able to plow more quickly through a backlog of ideas.)

Developers will shift their focus from coding clean and well-organized implementations to making sure that the agents produce clean and well-organized implementations. Instead of writing most of the code, developers will spend their time reviewing, rejecting, constraining, and refactoring the agents’ output. Or better still, they will spend their time directing the agents to do that.

Ultimately, the next bottleneck will become proper thinking about what should be done. When you can do everything, deciding what not to do becomes the really difficult decision. Deciding what not to do is a problem today. Imagine how much harder it will be when, instead of choosing three things out of seven, product managers need to choose 30 things out of 70. 

Developers choose Rust because they can use it to write software that is memory-safe, correct, and—above all—fast. But the Rust compiler isn’t always the fastest car in the garage. The larger a Rust program is, and the more dependencies it has, the longer its compile time will be. A development process that once was a sprint slows to a creep.

Now for the good news: None of this is inevitable. Used smartly, many of the slowest parts of the Rust toolchain can be made quite snappy. Here’s a compendium of common techniques for speeding up Rust compilation. They are organized by strategy and general theme, and you can put them to work right now in your Rust projects.

1. Start with the basics

The single most effective thing you can do without changing anything about your existing work habits is to keep your Rust toolchain updated. You may already be doing this, but it’s worth a reminder.

Running rustup update periodically ensures you’re using the latest version of the compiler. This matters because Rust’s compiler team is constantly updating and optimizing the compilation process. Those optimizations aren’t just rolled into rustc itself, but also into LLVM, the framework rustc builds on top of.

If you’re reluctant to update the toolchain aggressively, because it might affect your project’s requirements, pin your project toolchain to a specific version, like so:

[toolchain]
channel = "1.85"

2. Don’t do anything you don’t have to

The golden rule of performance in computing, no matter what you’re doing: the less you do, the better. This absolutely applies to compiling Rust projects, since very often, a complete compilation isn’t needed.

Instead of a full compilation, you can run cargo check to perform most of the checks you need. This will ensure your code would compile, without having to actually compile the code. The former chiefly involves rustc’s checking mechanisms; the latter involves the LLVM-driven build process, which is far slower.

Note that cargo check will not skip compilation of as-yet-unbuilt dependencies. If they need to be built to run the check, they will be. But after the first cargo check to get caught up on that process, future check runs will complete far faster.

Another common way to avoid rebuilding is to use a compiler caching tool. The sccache project supports caching Rust compiler artifacts, along with several other popular languages with similar coompiler behaviors (C, C++, etc.). However, you get the best results with sccache or something like it when you use it as a build cache for multiple users—e.g., a development team in an organization with a shared file system. Used on one system alone, it doesn’t yield much of an advantage, unless you’re sharing build artifacts for the same versions of crates across multiple projects.

Another powerful way to avoid unneeded compilation is to wrap your dependencies as dynamically linked libraries (“dynlibs”). This isn’t native to Rust’s toolchain, though—it’s accomplished with a third party tool, cargo add-dynamic. Using the tool means you won’t get some of the benefits of compiling dependencies statically, like being able to inline code from crates. But it also speeds up the linking process dramatically, and while linking does get pushed off to runtime, its costs are typically minimal. The creator of cargo add-dynamic has written in detail about the ins and outs of this technique, using the polars data science library as an example.

3. Divide and conquer

The larger a project is, the less likely you need to recompile the entire thing if it’s divided along clean architectural lines. If you have a project with an MVC design, and you’re only making changes to the views that don’t involve altering its APIs, you can just recompile that portion of the project as you alter it.

To achieve something like this in Rust, you’d split up your project into multiple subcrates using Cargo workspaces. You’ll need to manually refactor existing single-crate projects, as there’s no native automated way to do this (unless you ask your friendly neighborhood LLM to help!). You’ll also benefit most from this selective recompilation in a project where you can split the codebase cleanly across well-defined boundaries, and where the project is big enough to justify partitioning. This blog post describes a fantastic (if extreme) application of this principle to efficiently compile SQL code converted at scale to Rust.

Another potential divide-and-conquer technique is parallel compilation, which is slowly becoming a feature that’s supported “out of the box” in the Rust compiler, instead of something you need to enable manually. If you use parallel compilation nightly, more of the parallel features are enabled by default; otherwise, you can use the compiler flag -Z threads= to enable it manually, where is how many threads to use.

To that end, don’t put too much emphasis on manually adding parallel code generation unless it provides a demonstrable benefit. One way to test this would be to run a completely clean build with parallelism at both full and half utilization—e.g., for an 8-core system, use 8 and 4 threads for the build process—and see if there’s any discernable benefit.

4. Analyze, analyze, analyze

It’s hard to know what to optimize without measurements. Fortunately, Rust’s cargo build comes with a powerful build-time reporting tool, the --timings switch. Run it and you’ll get a detailed HTML-formatted report that can help you pin down exactly what’s taking so long in the compilation process.

Sometimes the culprit isn’t merely in a given crate, but in a procedural macro used by some crate. A nightly-only flag for the compiler, -Zmacro-stats, generates information about the number of lines of code a given macro generates. This tells you how much code is being expanded from macros. That information may be a hint as to why a given crate may be the source of unexpectedly high compile times.

Another useful measure is to gauge how long each compilation step takes. The -Z time-passes compiler flag displays the elapsed time for each step, including LLVM’s overhead and the work done by the linker. Don’t sleep on how much time the linker takes; it’s an oft-underrated choke point for compilation. You can try switching linkers—experiment with lld or mold to see if your link times pick up.

5. Use platform-specific optimizations

If you’re stuck using Microsoft Windows (or if you actually want to use it), software projects belong on a new file system created specifically for development scenarios. The Dev Drive, as it’s called, uses a new file system, called ReFS, which has more proactive automatic-repair behavior (you don’t need to manually scan volumes), and also automatically reduces interference from Windows’s antivirus scanning.

Linux users can set up an in-memory temporary filesystem and use it for fast caching of compiled artifacts. The downside: Anything stored there is lost after rebooting. However, if you keep long uptimes for your workstation, you’ll only need to rebuild the cache once after rebooting.

Conclusion

The Rust compiler team keeps making strides to improve compilation times without requiring intervention from the developer. But there will always be places where the compiler alone can’t do the heavy lifting to make things faster. The more proactive you are about discovering where your project is slow to compile, the faster your Rust software will be.

Anthropic has introduced Cowork, a research-preview feature aimed at extending Claude Code’s capabilities beyond programming to everyday enterprise workflows.

The new flavor of the coding assistant will enable users to automate tasks such as summarizing calendars, creating reports, and organizing files, once an organization provides it access to a particular folder. Cowork can also connect to relevant tools, databases, and applications.

It can even be paired with Claude in Chrome to complete tasks that require browser access, the company wrote in a blog post, adding that users can assign tasks in parallel without waiting for the AI-based assistant to finish a particular task.

Useful for a wider range of functions

The introduction of Cowork, according to analysts, signals Anthropic’s push to make AI assistants useful for a wider range of business functions.

“Cowork reflects an intent to make Claude materially useful in everyday enterprise workflows by moving beyond conversation to scoped action, particularly around document and file-centric work that dominates knowledge roles,” said Vershita Srivastava, practice director at Everest Group.

Roles such as research, project management office (PMO), operations, and analytics, where guardrails can be clearly defined, can also reap benefits from the new tool and will probably see the most uptake, Srivastava added.

Seconding Srivastava, The Futurum Group’s practice leader for data, AI, and infrastructure, Bradley Shimmin pointed out that Cowork could be useful for developers as well and can be seen as a natural evolution of Anthropic’s “computer-use” capability and command-line utilities.

Since Cowork can access core operating system functionality, rather than just using a browser to look at your computer system and take pictures of your screen, it can be used to automate and operationalize tasks that sit adjacent to the agentic software development workflows, Shimmin said.

“For example, you may want to take some JSON data that is part of a project and quickly convert it into a markdown format so that non-developers can easily read that information.”

However, Anthropic has warned that giving Cowork access to a system or environment requires caution, as it can misunderstand prompts and end up executing “destructive” commands, such as deleting files, although it does ask users before executing a command or task.

The company also flagged the risk of prompt injection attacks, where malicious content could alter Claude’s plans despite the tool’s built-in defenses.

To counter such issues, Anthropic could build in an undo feature allowing users to retrieve files when deleted or un-send an email when the product is made generally available, said Jason Andersen, principal analyst at Moor Insights and Strategy.

The undo feature would take care of both prompt injection attacks as well as human error, Andersen added. Currently, the new flavor of the assistant is available to Claude Max subscribers via the macOS application.

Java Development Kit (JDK) 27, a release of standard Java planned for arrival in September, already has a feature proposed for it: a post-quantum hybrid key exchange capability to bolster network security.

The feature, post-quantum hybrid key xxchange for TLS 1.3, was listed on the OpenJDK page for JDK 27 on January 13. It would enhance the security of Java applications requiring network communications by implementing hybrid key exchange algorithms. These algorithms defend against future quantum computing attacks by combining a quantum-resistant algorithm with a traditional algorithm. Applications that use javax.net.ssl APIs will benefit from the improved algorithms by default, without change to existing code, according to the JEP (JDK Enhancement Proposal).

JDK 27 will be a non-LTS (Long-Term Support) release backed by six months of support, the same as JDK 26, which is due March 17. The current standard Java release, JDK 25, is an LTS release backed by multiple years of support. Other possible features for JDK 27 are preview features in JDK 26. These include:

• PEM (privacy-enhanced mail) encodings of cryptographic objects
• Structured concurrency
• Lazy constants, and
• Primitive types in patterns, instanceof, and switch.

Another strong possibility is the Vector API, now being incubated in JDK 26. Oracle, the steward of standard Java, last week detailed its plans for improving Java in 2026, with work on features such as value types, structured concurrency, and AOT (ahead-of-time) compilation. These features may not necessarily arrive in 2026, however.

Google has published the first draft of Universal Commerce Protocol (UCP), an open standard to help AI agents order and pay for goods and services online.

It co-developed the new protocol with industry leaders including Shopify, Etsy, Wayfair, Target and Walmart. It also has support from payment system providers including Adyen, American Express, Mastercard, Stripe, and Visa, and online retailers including Best Buy, Flipkart, Macy’s, The Home Depot, and Zalando.

Google’s move has been eagerly awaited by retailers according to retail technology consultant, Miya Knights. “Retailers are keen to start experimenting with agentic commerce, selling directly through AI platforms like ChatGPT, Gemini, and Perplexity. They will embrace and experiment with it. They want to know how to show up and convert in consumer searches.”

Security shopping list

However, it will present challenges for CIOs, in particular in maintaining security, she said. UCP as implemented by Google means retailers will be exposing REST (Representational State Transfer) endpoints to create, update, or complete checkout sessions. “That’s an additional attack surface beyond your web/app checkout. API gateways, WAF/bot mitigation, and rate limits become part of checkout security, not just a ‘nice-to-have’. This means that CIOs will have to implement new reference architectures and runtime controls; new privacy, consent, and contracts protocols; and new fraud stack component integration.”

Info-Tech Research Group principal research director Julie Geller also sees new security challenges ahead. “This is a major shift in posture. It pushes retail IT teams toward deliberate agent gateways, controlled interfaces where agent identity, permissions, and transaction scope are clearly defined. The security challenge isn’t the volume of bot traffic, but non-human actors executing high-value actions like checkout and payments. That requires a different way of thinking about security, shifting the focus away from simple bot detection toward authorization, policy enforcement, and visibility,” she said.

The introduction of UCP will undoubtedly mean smoother integration of AI into retail systems but, besides security challenges, there will be other issues for CIOs to grapple with.

Geller said that one of the issues she foresees with UCP is that “it works too well”. By this she means that the integration is so smooth that there are governance issues. “When agents can act quickly and upstream of traditional control points, small configuration issues can surface as revenue, pricing, or customer experience problems almost immediately. This creates a shift in responsibility for IT departments. The question stops being whether integration is possible and becomes how variance is contained and accountability is maintained when execution happens outside the retailer’s own digital properties. Most retail IT architectures were not designed for that level of delegated autonomy.”

Google’s AI rival OpenAI launched a new feature last October that allowed users to discover and use third-party applications directly within the chat interface, at the same time publishing an early draft of a specification co-developed with Stripe, Agentic Commerce Protocol, to help AI agents make online transactions.

Knights expects the introduction of UCP to accelerate interest in and adoption of agentic commerce among retailers. “Google said that it had already worked with market leaders Etsy, Wayfair, Target, and Walmart to develop the UCP standard. This will force competitors to accelerate their agentic commerce strategies, and will help Google steal a march on competitors, given that it is the market leader,” she said.

For online retailers’ IT departments, it’s going to mean extra work, though, in implementing the new protocols and in ensuring their e-commerce sites are visible to consumers and bots alike.

In today’s fast-paced digital landscape, building agile, scalable and maintainable software systems is paramount. Organizations often start with monolithic applications for their simplicity, but soon face challenges as these systems grow more complex. A distributed monolith, where the application is split into components but remains tightly coupled and interdependent, can hamper agility and scalability. Transitioning from this state to a composable architecture on AWS empowers teams to deliver resilient, scalable and business-aligned software solutions.

This article walks through the conceptual and practical journey of moving from a distributed monolith to a composable architecture on AWS, highlighting key principles, architectural patterns, AWS services and operational practices.

Understanding the distributed monolith problem

A distributed monolith is a system composed of multiple services or components, deployed independently but tightly coupled through synchronous dependencies such as direct API calls or shared databases. Unlike a true microservices architecture, where services are autonomous and loosely coupled, distributed monoliths share many pitfalls of monoliths, including:

• Tight coupling: Components depend heavily on the internals of others, creating fragile dependencies.
• Deployment friction: Changes require coordinated deployments across services.
• Operational complexity: Dysfunctional distributed components make troubleshooting and scaling difficult.
• Slow innovation: Teams struggle to iterate rapidly due to the interconnected system nature.

These issues arise when teams attempt to scale monolithic applications prematurely without fully embracing decoupling and domain-driven principles.

Principles of composable architecture

Composable architecture embraces modularity and loose coupling by treating every component as an independent building block. The focus lies in business alignment and agility rather than just code decomposition.

Key characteristics

• Independent deployability: Each component or microservice can be developed, deployed and scaled independently.
• Domain-driven design (DDD): Using bounded contexts and ubiquitous language to define clear service boundaries aligned with business domains.
• API-led communication: Interactions happen via well-defined APIs or event-driven messaging, avoiding direct code or database sharing.
• Data decentralization: Each service manages its own data to prevent tight coupling through shared databases.

These principles enable systems where components can be composed, replaced or upgraded without impacting the whole system.

AWS services enabling composable architecture

AWS offers a rich ecosystem tailored for building composable systems:

• AWS Lambda: Serverless compute enabling event-driven, stateless functions as microservices.
• Amazon API Gateway: Creating and managing APIs for service communication.
• Amazon DynamoDB: A NoSQL database that supports single-table design for efficient data access per service.
• Amazon EventBridge: Event bus enabling loosely coupled event-driven architectures.
• AWS Step Functions: Orchestrating workflows across microservices.
• AWS Cloud Development Kit (CDK): Infrastructure as code for automated, repeatable service deployments.
• Amazon SNS/SQS: Messaging services for asynchronous communication between components.

These services help build fully decoupled architectures with scalable and maintainable infrastructure.

The transformation journey, step-by-step

1. Assess and identify boundaries

Start by analyzing the existing application to find natural business or functional boundaries. Use Domain-Driven Design to define bounded contexts that encapsulate specific business capabilities.

Aim to reduce inter-service dependencies by identifying:

• Shared databases that need decoupling.
• Synchronous calls that can be turned into asynchronous messaging.
• Code or library dependencies crossing service boundaries.

2. Separate and modularize codebase

Refactor the code into separate repositories or modules, each representing a bounded context or microservice. This clear separation supports independent deployment pipelines and ownership.

import * as cdk from 'aws-cdk-lib';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as apigw from 'aws-cdk-lib/aws-apigateway';

export class OrderServiceStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    const orderLambda = new lambda.Function(this, 'OrderHandler', {
      runtime: lambda.Runtime.NODEJS_18_X,
      handler: 'order.handler',
      code: lambda.Code.fromAsset('lambda/order-service'),
    });

    new apigw.LambdaRestApi(this, 'OrderAPI', {
      handler: orderLambda,
      restApiName: 'Order Service',
    });
  }
}

Consolidate infra-as-code with AWS CDK to manage each microservice’s infrastructure, including APIs, storage and permissions.

3. Implement API-first communication

Replace direct code or database calls with API calls or events. For example:

• Use REST or GraphQL APIs via API Gateway.
• Emit business events via EventBridge or SNS for asynchronous processing.

Use SQS for message queuing to handle transient workloads.

const AWS = require('aws-sdk');
const eventBridge = new AWS.EventBridge();

exports.handler = async (event) => {
  const orderDetails = event.detail;

  const params = {
    Entries: [
      {
        Source: 'order.service',
        DetailType: 'OrderCreated',
        Detail: JSON.stringify(orderDetails),
        EventBusName: 'default',
      },
    ],
  };

  await eventBridge.putEvents(params).promise();

  return { statusCode: 200, body: 'Order event sent' };
};

This shift fosters loose coupling and enables scalability.

4. Decentralize data ownership

Assign each microservice its own DynamoDB table or data store. Avoid cross-service database joins or queries.

Adopt a single-table design in DynamoDB to optimize data retrieval patterns within each service boundary. This approach improves scalability and performance at the data layer.

5. Migrate incrementally

Migrating a distributed monolith at once is risky. Instead:

• Start with migrating low-risk or well-bounded components.
• Implement a strangler pattern to route traffic gradually to new microservices.
• Refactor and evolve incrementally while monitoring performance and errors.

Use Case: Migrating an e-commerce platform

An e-commerce platform began as a large monolith with intertwined order processing and customer management. Source

Challenge: Frequent downtime due to deployment coupling; slow feature delivery.

Approach

• Applied Domain-Driven Design to split Order, Customer and Payment domains.
• Used AWS Lambda and API Gateway for new microservices.
• Deployed EventBridge for asynchronous events like OrderPlaced, triggering inventory updates.
• Adopted DynamoDB single-table design per microservice.

Outcome: Reduced deployment risk, improved team autonomy and scaled individual services based on demand.

Benefits of Composable Architecture on AWS

• Improved agility: Teams can develop and deploy services independently, accelerating release cycles.
• Scalability: Scale services on demand based on their usage patterns.
• Resilience: Failures remain isolated, reducing system-wide outages.
• Operational simplicity: Decoupling simplifies troubleshooting and makes infrastructure management easier.
• Business alignment: Services reflect real-world domains, improving code understanding and maintenance.

Challenges and Considerations

A composable architecture also introduces complexity:

• Increased operational overhead: Managing many services requires sophisticated CI/CD, monitoring and automation.
• Proper observability: Monitoring your services, application and infrastructure is also very critical and you can use some full-stack observability tools such as those reviewed and rated by Gartner’s Peer Insights.
• Security: More communication points demand stringent security measures.
• Data consistency: Eventual consistency and distributed transactions need careful design.
• Skill requirements: Teams must be proficient with distributed systems, cloud-native patterns and AWS tooling.

These challenges can be mitigated with proper tooling, automation and training.

Conclusion

Transitioning from a distributed monolith to a composable architecture on AWS is a strategic journey that demands careful planning and execution. By applying domain-driven design principles, leveraging AWS’s serverless and managed services and embracing modular, loosely coupled components, organizations can build scalable, resilient and flexible software systems aligned with evolving business needs. This transformation not only solves traditional monolithic pain points but also unlocks agility and innovation potential critical for today’s competitive environment.

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

For years, enterprises enthusiastically adopted a cloud-first approach, eager to take advantage of the flexibility and rapid innovation public cloud platforms offered. But as artificial intelligence operations transition from experiments to business imperatives, organizations are discovering that the old assumptions about where AI belongs (primarily in the public cloud) no longer hold true. AI is, in fact, becoming the great normalizer of platform selection. Its unprecedented costs, demands for low latency, and new concerns about resilience and data sovereignty are pushing enterprises to reconsider the cloud as the default choice for their most strategic workloads. Having long advocated this perspective, even as it ran counter to prevailing wisdom, I’m heartened to see industry consensus shifting in this direction.

AI workloads are different from traditional applications in many ways, most notably their hunger for compute and data. Running large-scale training or inference jobs in the public cloud can quickly lead to skyrocketing costs, sometimes outstripping what comparable on-premises infrastructure would demand. According to Deloitte, “some enterprises are seeing monthly [cloud] bills in the tens of millions,” with costs often surpassing 60% to 70% of the total cost to acquire and maintain equivalent on-premises systems. That kind of economic pressure openly challenges the cloud-first edict, particularly when predictability and budget control are required.

Moreover, AI’s need for ultra-low latency to support operations such as real-time decision-making and its requirement for reliable, always-on performance in mission-critical environments often make on-premises solutions more viable. The same Deloitte report observes that “applications requiring response times of 10 milliseconds or below cannot tolerate the inherent delays of cloud-based processing.”

Conventional, not controversial

It wasn’t so long ago that expressing skepticism about cloud-only strategies drew resistance. For the better part of a decade, cloud held near-religious status in enterprise strategy meetings. I recall regularly making the case for hybrid cloud, influenced not by nostalgia but by a pragmatic understanding of the architectural realities many organizations faced. Today, it’s clear that more decision-makers and respected consulting voices are coming to similar conclusions.

Notably, Deloitte’s analysis now explicitly recommends a “three-tier approach” that combines cloud for elasticity, on-premises for consistency in production workloads, and edge deployments for immediate or ultra-low-latency AI needs. This is architecture tailored for a world where AI—not generic IT workloads—drives technology decisions. ZDNet, summarizing these industry movements, notes that “cloud-first strategies can’t handle AI economics,” and forward-looking companies are now “contemplating a shift away from mainly cloud to a hybrid mix of cloud and on-premises.”

AI as the platform equalizer

The radical resource requirements and operational constraints of AI have stripped away much of the mythology that cloud is best for everything or that on-premises is purely legacy. Every choice is now fundamentally workload-driven: AI must go where it can run most cost-effectively, safely, and responsively. Sometimes that’s in the cloud; just as often, it’s in non-cloud deployments or a combination thereof.

This new reality is forcing organizations to undertake careful assessments before making platform decisions for AI. The days when IT leaders could simply sign off on wholesale cloud migrations, confident it was always the most strategic choice, are over. In the age of AI, the optimal approach is usually hybrid.

Having openly championed this hybrid path even when it was unpopular, I welcome the growing acceptance of these ideas among decision-makers and industry analysts. Enterprises now have a rationale for an integrated, best-of-both-worlds platform, not as a retreat from cloud, but as a progression toward mature, sustainable AI. Hybrid approaches allow organizations to optimize costs, address regulatory and latency needs, and retain vital security controls, while also continuing to leverage the cloud’s strengths for experimentation and growth.

Artificial intelligence, with its intense resource demands and complex risk profile, has normalized a pragmatic approach to platform architecture. Ignore the rhetoric. Hybrid is the future for organizations that intend to scale AI, strike the right cost-performance balance, and adapt to ever-changing requirements. With authoritative references both validating and reinforcing this view, it’s clear that what was once dissent is now fast becoming conventional wisdom. I’m pleased to witness this change. Proof that the path to successful AI lies not in cloud-only solutions, but in the thoughtful combination of cloud and non-cloud strategies.

Software development used to be simpler, with fewer choices about which platforms and languages to learn. You were either a Java, .NET, or LAMP developer. You focused on AWS, Azure, or Google Cloud. Full-stack developers learned the intricacies of selected JavaScript frameworks, relational databases, and CI/CD tools.

In the best of times, developers advanced their technology skills with their employer’s funding and time to experiment. They attended conferences, took courses, and learned the low-code development platforms their employers invested in.

Only now are many developers realizing they must radically upskill due to new AI capabilities. Others may be out of work and should use the time to develop new skills to improve their employability. AI is taking a bite out of employment, and more than 100,000 tech employees have been laid off in 2025, according to layoffs.fyi.

As more coding is done with code generators, vibe coding tools, and low-code automation platforms, the choice of what to learn isn’t straightforward.

Gauging the market for new skills

Should developers follow their passions and interests? Or is it more pragmatic to review what skills and certifications are in demand and focus your learning in these areas?

Developers should look beyond today’s job specifications and anticipate where demand is likely to grow over the next few years. As more enterprise platforms deliver agentic AI capabilities, there will be a shift in what businesses will develop themselves and which platforms they invest in. 

“When evaluating where to build skills, developers should look beyond tools and focus on ecosystems that foster learning, collaboration, and adaptability,” says Gloria Ramchandani, SVP of product at Copado. “Choose platforms that encourage experimentation across low-code, automation, and cloud development, because the future favors hybrid roles that blend creativity, technical depth, and soft skills. Invest in communities where you can learn from peers, share best practices, and grow with technology.”

Ways to track the skills market include the Stack Overflow Developer Survey and the State of Developer Ecosystem Report. Review DORA’s State of AI-Assisted Software Development and Stanford University’s AI Index Report for detailed benchmarks on AI models and platforms.

Junior developers should go deep fast

Developers should also optimize learning based on their experience levels. One strategy for junior developers is to broaden their skill set and go deep into implementation details. Junior developers should prioritize learning tools that go deep into a skill or tool without requiring a significant time investment.

“New or junior developers, as strange as this may sound, should pick up tools that are well covered with YouTube tutorial videos,” says Matthew Makai, VP of developer relations at Digital Ocean. “No-code and low-code tools, IDEs, and developer services are difficult to learn from text-based tutorials alone. Videos can show you specific ways that more experienced developers use those tools that you can readily copy to build your own projects.”

A second consideration for junior developers is to learn new implementation domains. For example, application developers may want to learn more about API development, data pipelines, platform integrations, and AI agent development to demonstrate a broad range of software development skills.

“When choosing which new platforms to learn, focus on durable thinking over transient tools,” says Facundo Giuliani, developer relations engineer at Storyblok. “The most valuable skills lie in understanding system design, data flow, and how to combine automation, AI, and APIs to create outcomes. Low-code and no-code tools are great entry points, but the long-term edge comes from mastering composability, reasoning, and interoperability—the skills that apply across any emerging tech stack.”

Dave Killeen of Pendo recommends this test for developers evaluating platforms: Can you go from idea to working prototype in under a day with this platform? “The platforms worth mastering are the ones that collapse the feedback loop. Whether it’s low-code, AI-assisted development, or cloud platforms, choose what helps you iterate and validate assumptions in hours, not sprints.”

Preparing for senior-level dev responsibilities

Developers looking to advance to senior-level roles, or those already at that level, need to demonstrate a strong understanding of software engineering principles.

“Developers should focus on platforms that build transferable skills and teach core concepts like API integration, workflow automation, and modular design rather than locking them into one ecosystem,” says Phillip Goericke, CTO of NMI. Seek technologies that reinforce abstraction layers and extensibility, showing how concrete implementations emerge from abstract ideas. Prioritize environments that enable rapid prototyping and scalable, secure design, strengthen understanding of common programming structures, and develop critical thinking to narrow focus when solving real problems.”

Josh Mason, CTO of Recordpoint, adds, “Optimize for skills that travel: machine learning concepts, data modeling, API design, testing, and security.”

Developers must also explore how to use generative AI tools to write agile requirements, develop software, automate testing, maintain documentation, and drive other efficiencies across the software development life cycle (SDLC). Developer experiences are evolving from IDEs focused on writing code to natural language dialogs, code validation tools, and AI agents performing development tasks. 

“AI SDLC tools are just another new way for developers to use powerful assistants in their development pipelines, much like the modern IDE,” says Simon Margolis, associate CTO of AI and machine learning at SADA. “The developer’s core goal doesn’t change: applying logic to command tools, whether using English and Gemini CLI or writing Python directly.”

Diving into SaaS and low-code development

Some developers have staked their careers on building skills and delivering results from enterprise SaaS platforms. On the other hand, some developers have focused on pro-code development and open source frameworks, leaving low-code and proprietary platforms aside.

Developers should cast a wide net when learning to increase job opportunities and be open-minded about platforms, especially if they want to work in large enterprises. Some enterprise SaaS platforms with extended development capabilities include SAP, Salesforce, and Workday. Here’s a primer on the breadth of their development capabilities.

• Business Technology Platform (BTP) from SAP includes SAP Build for developing AI agents and solutions, SAP Integration Suite for connecting to other enterprise systems, and SAP Business Data Cloud for data governance and connecting to third-party data sources.
• Salesforce’s developer platforms include AgentForce 360 for developing AI agents, Mulesoft for implementing integrations, and Data 360 for connecting to third-party data sources.
• Build, the developer platform at Workday, incorporates multiple technologies including Extend for developing solutions, Orchestrate for workflow automation, Data Cloud for zero-copy access to selected data lakes, and Flowise for developing agents.

Developers should also consider learning enterprise-ready low-code platforms that embrace AI, such as Appian, OutSystems, Pega, and Quickbase.

“The biggest hurdle is not understanding the platform, and actually, the tool set in most platforms is pretty simple,” says Matt Grippo, SVP of core software at Workday. “The part that takes a little bit more knowledge is understanding the environment, the security model, and the business processes you have to work with.”

With LLMs and agentic AI capabilities being introduced by SaaS and low-code development platforms, developers may be considering whether learning them is a smart career path.

“I don’t believe that AI will replace developers,” says Dr. Philipp Herzig, CTO at SAP SE. “AI can generate code, but the abstraction is only as good as understanding what’s going on under the hood. There are tons of new challenges in this new AI stack, so while it’s easy to get started, much hard work is still required to make it enterprise-ready, make it at scale for the organization, and that’s where the complexity lies.”

Focus on the role, not just the tools

Developers looking to upskill should also focus on going upstack. Coding is a means of solving business challenges, testing new ideas, developing new customer experiences, automating workflows, delivering insights from data, and enabling innovation. In addition to coding skills, companies will expect developers to have strong business acumen and to participate more in agile planning for what gets developed.

“Technology will keep evolving, but your real edge is curiosity, critical thinking, and how you build with purpose,” says Christian Birkhold, VP of product management at KNIME. “Master AI to move faster, but never stop understanding what it builds. Sweat the details, stay close to the code, and master the fundamentals—that’s how you stay in control when everything else accelerates.”

Developers must embrace lifelong learning, as the problems to be solved, the tools, and the business opportunities are changing rapidly because of AI. Developers must learn new software development tools, strengthen their understanding of AI capabilities, and adopt a solutions-oriented mindset to expand their devops career paths.

Oracle’s Java team in 2026 will work toward milestones including a preview of value types, an incubation of code reflection, shipping AOT (ahead-of-time) code compilation, and finalizing the structured concurrency API.

These efforts and many others under OpenJDK projects such as Project Loom, for exploring JVM (Java Virtual Machine) features and APIs for implementing lightweight user-mode threads, and Project Valhalla, for augmenting the Java object model with value objects, were cited in a January 8 video presentation by Nicolai Parlog, a Java developer advocate at Oracle. Work on these features, though, does not imply they will be released in 2026.

AOT code compilation is part of Project Leyden, which is intended to improve startup time, time to peak performance, and the footprint of Java programs. The goals for AOT code compilation include improving startup and warmup time by making native code from a previous application run instantly available, when the HotSpot JVM starts. Project Leyden also will explore code cache portability and iterative training, allowing frameworks to train the cache. Inspectability of training data also will be examined.

Plans for Project Amber, which focuses on producing smaller, productivity-oriented Java language features, include exploring string templates and filing JEPs (JDK Enhancement Proposals) for constant patterns and interfaces. There may also be updates on record-esque classes and interfaces and on more inclusive pattern matching.

With Project Loom, Parlog said that the structured concurrency API, for concurrent programming, will preview with small changes in JDK 26 and will likely be finalized by the end of the year. Currently in a rampdown phase, JDK 26 is due for a production release on March 17. Also on the agenda for Loom is exploring more applications of virtual threads.

For Project Panama, which focuses on improving connections between the JVM and non-Java APIs, the vector API planned for JDK 26 will see its 11th incubation. Also on the agenda for Panama in 2026 are general improvements to the jextract tool for parsing header files of native libraries and generating code. Improvements also are eyed for the Foreign Function and Memory API, which enables Java programs to interoperate with code and data outside the Java runtime.

For Project Babylon, which aims at extending Java to foreign programming models such as SQL, plans include incubating code reflection, which allows third-party frameworks to reflect over Java code in a lambda expression and process it. The Babylon team will also be working on proofs of concept for using code reflection to run machine learning models on the GPU.

With Project Valhalla, developers will work to deliver a preview of value types in the second half of this year, after which work will focus on null-aware types, array improvements, and unification of primitives and wrappers. Value objects are class instances that have only final fields and lack object identity. They allow developers to opt into a programming model for domain values in which objects are distinguished solely by the values of their fields.