Microsoft says it has uncovered a coordinated campaign targeting software developers through malicious repositories posing as legitimate Next.js projects and technical assessments.

The campaign employs carefully crafted lures to blend into routine workflows, such as cloning repositories, opening projects, and running builds, thereby allowing the malicious code to execute undetected.

Telemetry collected during an incident investigation by Microsoft suggested the campaign’s alignment with a broader cluster of threats using job-themed tricks. “During initial incident analysis, Defender telemetry surfaced a limited set of malicious repositories directly involved in observed compromises,” the company wrote in a security blog post. “Further investigation uncovered additional related repositories that were not directly referenced in observed logs but exhibited the same execution mechanisms, loader logic, and staging infrastructure.”

The campaign exploits developers’ trust in shared code, gaining persistence within high-value developer systems that often contain source code, environment secrets, credentials, and access to build or cloud infrastructure.

Multiple triggers for remote control

Microsoft researchers found that the malicious repositories were engineered with redundancy, offering several execution paths that ultimately result in the same backdoor behavior.

In some cases, simply opening the project in Visual Studio Code was enough. The attackers abused workspace automation by embedding tasks configured to run automatically when a folder is opened and trusted. This causes code execution without the developer running anything.

Other variants rely on build processes or server startup routines, ensuring that the malicious code runs when developers perform typical actions such as launching a development server. Regardless of the trigger, the repositories retrieve additional JavaScripts from remote infrastructure and execute it in memory, reducing traces on disk.

The retrieved payload operates in stages. An initial registration component identifies the host and can deliver bootstrap instructions, after which a separate C2 controller provides persistence and enables follow-on actions such as payload delivery and data exfiltration.

Infection through a fake “coding test”

Microsoft said the investigation started with analyzing the suspicious outbound connections from Node.js processes communicating with attacker-controlled servers. Correlating network activity with process telemetry led analysts back to the original infection through recruiting exercises.

One of the repositories was hosted on Bitbucket and presented as a technical assessment, along with a related repository using the Cryptan-Platform-MVP1 naming convention. “Multiple repositories followed repeatable naming conventions and project ‘family’ patterns, enabling targeted searches for additional related repositories that were not directly referenced in observed telemetry but exhibited the same execution and staging behavior,” Microsoft wrote.

When an infection is suspected, Microsoft warns that affected organizations must immediately contain suspected endpoints, trace the initiating process tree, and hunt for repeated polling to suspicious infrastructure across the fleet. Because credential and session theft may follow, responders should evaluate identity risk, revoke sessions, and restrict high-risk SaaS actions to limit exposure during investigation.

Long-term mitigations include a focus on tightening developer trust boundaries and reducing execution risk, Microsoft added. Other recommendations include enforcing Visual Studio Code Workspace Trust defaults, applying attack surface reduction rules, enabling cloud-based reputation protections, and strengthening conditional access.

MariaDB may have started as a MySQL fork, following Oracle’s acquisition of MySQL, but with time it’s charted its own path. Over the last few major revisions, the open source RDBMS has added unique functions, greater compatibility with MySQL, and a suite of behaviors designed to make it a migration target for Oracle SQL users. Here’s a quick look at some of the best and most powerful new features in MariaDB.

Also see: 4 self-contained databases for your apps.

Opt-in Oracle compatibility

Ever since version 10.3, MariaDB has been steadily adding Oracle compatibility features, making it easier to port Oracle to MariaDB as-is.

Oracle compatibility is opt-in. All you need to do is issue the command SET SQL_MODE='ORACLE' to activate it for a given set of SQL statements. Existing MariaDB behaviors will also be preserved wherever possible.

Most Oracle compatibility features are geared to supporting Oracle SQL syntax, especially where it deviates from ANSI SQL or MariaDB. For instance, Oracle SQL allows you to call stored procedures using the name of the stored procedure rather than the CALL keyword.

But other recent changes to Oracle compatibility mode involve underlying behaviors, not just syntax. As of MariaDB 12.0, single triggers can execute on multiple INSERT/UPDATE/DELETE events, an Oracle SQL feature that’s difficult to replicate manually.

MariaDB (the company) also offers a migration tool that analyzes an Oracle SQL DDL export file (just the data definition, no actual data) and assesses how well it will run with MariaDB’s Oracle compatibility mode.

AI features: MCP servers and vector types

AI features are finding their way into (some might say infesting) most every data-centric software product. While MariaDB is no exception, its AI features look to be actual tools, not just marketing glaze.

MariaDB 11.8 added a native VECTOR data type, a way to embed information about text similarity in a database. This lets you use MariaDB as an engine for building things like natural-language queries, recommendation systems, RAG solutions, and general-purpose machine learning tasks. Much of the heavy lifting for such work can be done directly in the database, avoiding round trips to external applications.

Another recent AI addition makes MariaDB an extension of existing AI agents. The Model Context Protocol (MCP), provides a common way for LLMs to talk to external tooling—for instance, to search the web. MariaDB now offers its own MCP server components to make it easy for LLMs to query MariaDB instances. It’s also possible to use embeddings (via OpenAI, Gemini, or open Huggingface models) to perform semantic searches on documents stored in the database.

More JSON features

NoSQL databases gave developers the freedom to use open-ended schemas, defined as JSON documents, to store data. Conventional SQL databases have since added their own native JSON functionality, a useful way to get NoSQL’s flexibility without ditching conventional SQL’s formal schemas.

In MariaDB, there’s a JSON column type, which accepts text in JSON format and can be automatically validated with a JSON_VALID CHECK constraint. If you want your JSON data to follow strict data types, you can add constraints for specific keys (e.g., key year should always be a valid INTEGER).

SELECT queries can extract data from JSON columns by key:

SELECT id, name, JSON_QUERY(attr, '$.dates.release') AS release_year FROM movies

They can also filter by values:

SELECT id, name FROM movies WHERE JSON_VALUE(attr, '$.dates.release') = 1981

For more performant operations against JSON, you can create virtual columns that map to keys in the document, and also build indexes from those virtual columns:

ALTER TABLE movies ADD COLUMN
    release_year SMALLINT AS (JSON_VALUE(attr, '$.dates.release'));
CREATE INDEX releaseyears ON movies(release_year);

It’s also possible to modify the data without extracting the JSON and manipulating it. JSON_INSERT(), JSON_ARRAY_APPEND(), and JSON_REMOVE() all let you perform these kinds of in-place transformations faster and more reliably than trying to fiddle with the data manually outside of MariaDB.

Expanded optimizer hints

Experienced database developers appreciate having granular control over how queries execute. MariaDB has long had hints, or “modifiers,” for SELECT statements, such as HIGH_PRIORITY and FORCE INDEX.

With MariaDB 12.0 came so-called new-style optimizer hints, a way to apply hints to specific tables or indexes as well as globally. These hints are formatted as inline comments with /*+ and */ delimeters.

Expanded hints aren’t for everyday use. They force-enable (or disable) behaviors that typically work fine as-is, but in certain scenarios work better when explicitly controlled. For instance, an INDEX_MERGE hint tells the query optimizer which specific indexes to use—and no others—when performing index scans on multiple columns. This can speed up queries on a table with many indexes, or no composite index to cover a specific query. But don’t assume your ideas about how these optimizations work in theory will play out in practice. It’s always best to use an EXPLAIN statement along with a query optimization to find out if it does, in fact, speed things up.

Other new hints are useful for troubleshooting as well as performance. For instance, the MAX_EXECUTION_TIME() hint can abort a specific query after a certain number of milliseconds. This hint can be used to prevent “pathological” queries from tying up the system, but also as part of the process of debugging an existing query with a tendency to run wild.

A new XML type

Another forward-looking improvement, although it doesn’t actually do much yet, is a new XMLTYPE column type, introduced in MariaDB 12.3. Right now, all it does is accept a string of up to 4GB in size, and allow for selective replacement of XML with the UPDATEXML function. While there is no attempt to validate the XML or enforce a schema currently, those features are slated to land later, and to make XMLTYPE more functionally compatible with Oracle. It opens the path for future expansion.

Features still missing

As MariaDB has matured and started to take its own development path apart from MySQL, it’s introduced many features not found in MySQL, like dynamic or virtual columns. But the reverse also holds: Some MySQL features still aren’t present in MariaDB, at least not yet.

One major missing feature, MySQL resource groups, has been proposed but still needs work to be implemented. Other features will likely never be cross-compatible, like support for MySQL’s ‘packed’ (binary) storage format for JSON.

And, because MariaDB and MySQL have different and incompatible methods for global transaction IDs, you can use a MariaDB server as a replica for a MySQL server but not the other way around. On the upside, this means you can use replication as a migration strategy from MySQL to MariaDB. Just make sure you have compatible versions of both databases.

It’s tough out here for a dev/tech writer.

Back in the before days (that is, about two months ago), you could always find a variety of topics to write about. “Seven ways to improve your database design,” say. Or  “Five things I never do in code.”  There were a ton of things that developers were concerned about when it came to writing code. The study of clean code and how to write it was a constant struggle for improvement. Diligent developers were eager for new ways to be better.

Now? You aren’t writing code, and you aren’t designing databases. Your coding agent is. 

So here I am, writing about coding agents again. Which, I guess, is a good thing, because, oh my, this is all quite electrifying.

I’ve had a bunch of ideas for websites, some for fun and some that could potentially generate a modest revenue stream. This past weekend, I decided to implement one of the revenue-generating ideas. It’s up and running today. (I’m not shameless enough to post a link here.) Suffice it to say, it’s a small tool to help developers do something that no one likes to do. 

Along the way, I learned an interesting lesson.

What Claude did

The whole experience was astonishing. I’m a Claude Code user. I feel comfortable that he (and yes, I anthropomorphize him) knows what he’s doing. Plus, I have an Enterprise account that I use with a client’s project. I have a pretty solid Claude.md file that I use as a base. I gave a pretty thorough description of the project that I wanted, and told Claude to get to work. 

And in about 20 minutes, he had a website up and running, doing exactly what I wanted. Exactly. Precisely. Correctly.

It was dumbfounding.

Then, being a man of entrepreneurial spirit, I told Claude to figure out a way for me to charge for the service. He suggested a system of credits—one credit, one transaction—and a common third-party service to do the credit card work.

Claude then gave me a set of instructions to set up the credit card service on the provider’s website. And because now, given Claude’s capabilities, I am far too lazy to do all this myself, I asked him to do it all. And he did. Yes, I realize I’m giving personhood to an abstraction that is doing what humans used to do.

But what Claude did was a real eye-opener. He downloaded the service’s command-line interface and used it to do all the work (except logging in—I had to do that). He couldn’t (yet, I suppose) use the website itself. But a CLI? Child’s play. 

And then it hit me: My website was not what potential customers would be looking for. Although what the site did was useful, no one in the age of agentic coding was going to use it. Instead, they would want some way to have their coding agent, or their build process, or some other automated thing, use my system. 

What I learned

So I told Claude to build a command-line tool to do the process. In about 20 more minutes, tools for Mac, Windows, and Linux, as well as variations for Arm and x86, were all built and ready. He changed the website to make the CLI the main thing and presented the correct download to the user depending on the OS that the incoming browser request was running on.

Again, all on a Saturday afternoon.

The lesson here isn’t that you can build a website in an afternoon—we already knew that. The lesson here is that much of what we are doing now is not coding for humans—we are now coding for other agents. (Inasmuch as what we are doing can be called “coding” anymore.)

In the coming days, and I think “days” is literal here, we will be spending a whole lot less time worrying about the usability of our websites and more time considering the efficiency of our APIs and CLIs. 

I didn’t want to deal with that credit card processor’s website. Instead, I wanted Claude to do it via their CLI, and he did. No one will want to go to my website to do the task I provide; they’ll want Claude to do it with my CLI. I imagine Claude soon will prefer to deal more efficiently with a REST API, and so I suppose I’ll have to build that. 

Or rather, Claude will build it for me. Maybe that’s why I call him “he.” It’s easier to be replaced by a someone than by a something.

Java Development Kit (JDK) 26, a planned update to standard Java due March 17, 2026, has reached its second release candidate (RC) stage. The RC is open for critical bug fixes, with the feature set having been frozen in December.

The following 10 features are officially targeted to JDK 26: a fourth preview of primitive types in patterns, instanceof, and switch, ahead-of-time object caching, an eleventh incubation of the Vector API, second previews of lazy constants and PEM (privacy-enhanced mail) encodings of cryptographic objects, a sixth preview of structured concurrency, warnings about uses of deep reflection to mutate final fields, improving throughput by reducing synchronization in the G1 garbage collector (GC), HTTP/3 for the Client API, and removal of the Java Applet API.

A short-term release of Java backed by six months of Premier-level support, JDK 26 follows the September 16 release of JDK 25, which is a Long-Term Support (LTS) release backed by several years of Premier-level support. Early-access builds of JDK 26 are available at https://jdk.java.net/26/. The initial rampdown phase began in early December, and the second rampdown phase in mid-January.

The latest feature to be added, primitive types in patterns, instanceof, and switch, is intended to enhance pattern matching by allowing primitive types in all pattern contexts, and to extend instanceof and switch to work with all primitive types. Now in a fourth preview, this feature was previously previewed in JDK 23, JDK 24, and JDK 25. The goals include enabling uniform data exploration by allowing type patterns for all types, aligning type patterns with instanceof and aligning instanceof with safe casting, and allowing pattern matching to use primitive types in both nested and top-level pattern contexts. Changes in this fourth preview include enhancing the definition of unconditional exactness and applying tighter dominance checks in switch constructs. The changes enable the compiler to identify a wider range of coding errors.

With ahead-of-time object caching, the HotSpot JVM would gain improved startup and warmup times, so it can be used with any garbage collector including the low-latency Z Garbage Collector (ZGC). This would be done by making it possible to load cached Java objects sequentially into memory from a neutral, GC-agnostic format, rather than mapping them directly into memory in a GC-specific format. Goals of this feature include allowing all garbage collectors to work smoothly with the AOT (ahead of time) cache introduced by Project Leyden, separating AOT cache from GC implementation details, and ensuring that use of the AOT cache does not materially impact startup time, relative to previous releases.

The eleventh incubation of the Vector API introduces an API to express vector computations that reliably compile at run time to optimal vector instructions on supported CPUs. This achieves performance superior to equivalent scalar computations. The incubating Vector API dates back to JDK 16, which arrived in March 2021. The API is intended to be clear and concise, to be platform-agnostic, to have reliable compilation and performance on x64 and AArch64 CPUs, and to offer graceful degradation. The long-term goal of the Vector API is to leverage Project Valhalla enhancements to the Java object model.

Also on the docket for JDK 26 is another preview of an API for lazy constants, which had been previewed in JDK 25 via a stable values capability. Lazy constants are objects that hold unmodifiable data and are treated as true constants by the JVM, enabling the same performance optimizations enabled by declaring a field final. Lazy constants offer greater flexibility as to the timing of initialization.

The second preview of PEM (privacy-enhanced mail) encodings calls for an API for encoding objects that represent cryptographic keys, certificates, and certificate revocation lists into the  PEM transport format, and for decoding from that format back into objects. The PEM API was proposed as a preview feature in JDK 25. The second preview features a number of changes, such as the PEMRecord class is now named PEM and now includes a decode()method that returns the decoded Base64 content. Also, the encryptKey methods of the EncryptedPrivateKeyInfo class now are named encrypt and now accept DEREncodable  objects rather than PrivateKey objects, enabling the encryption of KeyPair and PKCS8EncodedKeySpec objects.

The structured concurrency API simplifies concurrent programming by treating groups of related tasks running in different threads as single units of work, thereby streamlining error handling and cancellation, improving reliability, and enhancing observability. Goals include promoting a style of concurrent programming that can eliminate common risks arising from cancellation and shutdown, such as thread leaks and cancellation delays, and improving the observability of concurrent code.

New warnings about uses of deep reflection to mutate final fields are intended to prepare developers for a future release that ensures integrity by default by restricting final field mutation, in other words making final mean final, which will make Java programs safer and potentially faster. Application developers can avoid both current warnings and future restrictions by selectively enabling the ability to mutate final fields where essential.

The G1 GC proposal is intended to improve application throughput when using the G1 garbage collector by reducing the amount of synchronization required between application threads and GC threads. Goals include reducing the G1 garbage collector’s synchronization overhead, reducing the size of the injected code for G1’s write barriers, and maintaining the overall architecture of G1, with no changes to user interaction.

The G1 GC proposal notes that although G1, which is the default garbage collector of the HotSpot JVM, is designed to balance latency and throughput, achieving this balance sometimes impacts application performance adversely compared to throughput-oriented garbage collectors such as the Parallel and Serial collectors:

Relative to Parallel, G1 performs more of its work concurrently with the application, reducing the duration of GC pauses and thus improving latency. Unavoidably, this means that application threads must share the CPU with GC threads, and coordinate with them. This synchronization both lowers throughput and increases latency.

The HTTP/3 proposal calls for allowing Java libraries and applications to interact with HTTP/3 servers with minimal code changes. Goals include updating the HTTP Client API to send and receive HTTP/3 requests and responses; requiring only minor changes to the HTTP Client API and Java application code; and allowing developers to opt in to HTTP/3 as opposed to changing the default protocol version from HTTP/2 to HTTP/3.

HTTP/3 is considered a major version of the HTTP (Hypertext Transfer Protocol) data communications protocol for the web. Version 3 was built on the IETF QUIC (Quick UDP Internet Connections) transport protocol, which emphasizes flow-controlled streams, low-latency connection establishment, network path migration, and security among its capabilities.

Removal of the Java Applet API, now considered obsolete, is also targeted for JDK 26. The Applet API was deprecated for removal in JDK 17 in 2021. The API is obsolete because neither recent JDK releases nor current web browsers support applets, according to the proposal. There is no reason to keep the unused and unusable API, the proposal states.

Google has added an agent step to its Opal tool for building AI-powered mini-apps. Powered by the Gemini 3 Flash model, the new agent in Opal enables autonomous workflows that plan, reason, and execute on the user’s behalf, Google said.

Introduced February 24 and available to all Opal users, the agent step upgrades Opal workflows from static model calls to agentic intelligence, according to Google. Now, instead of manually picking a model, developers can select an agent in the “generate” step. The agent then triggers the right tools and models, such as Web Search for research or Veo for video, needed to accomplish the user’s intended mission. The agent can also make use of persistent memory, dynamic routing, and interactive chat with the user.

With persistent memory, the agent can use Google Sheets to remember information across sessions, such as style preferences or ongoing lists, thus making mini-apps smarter the more they are used. With dynamic routing, the agent evaluates work and decides which steps to trigger next, bringing autonomy to mini-apps. With interactive chat, the agent can initiate a chat with the user to gather missing information or offer choices before moving to a plan’s next stage.

Google presented an example in which creating a storybook Opal had required predefining page counts and user questions. Users now can build a Visual Storyteller Opal where the agent step autonomously decides which details it needs and suggests plot points to help direct where a story goes. This marks a shift from rigid formats to dynamic, unique narratives shaped by creative decisions, Google said.

A massive Shai-Hulud-style npm supply chain worm is hitting the software ecosystem, burrowing through developer machines, CI pipelines, and AI coding tools.

Socket researchers uncovered the active attack campaign and called it SANDWORM_MODE,  derived from the “SANDWORM_*” environment variable switches embedded in the malware’s runtime control logic.”

At least 19 typosquatted packages were published under multiple aliases, posing as popular developer utilities and AI-related tools. Once installed, the packages execute a multi-stage payload that harvests secrets from local environments and CI systems, then uses stolen tokens to modify other repositories.

The payload also implements a Shai-Hulud-style “dead switch” that remains OFF by default to trigger home directory wiping when the malware is detected. Researchers called the campaign a  “real and high-risk” threat, advising defenders to treat the packages as active compromise risks.

Typo to takeover

The campaign starts with typosquatting, where attackers publish packages with names nearly identical to legitimate ones, banking on a developer typo or an AI hallucinating wrong dependencies.

“The typosquatting targets several high-traffic developer utilities in the Node.js ecosystem, crypto tooling, and, perhaps most notably, AI coding tools that are seeing rapid adoption: three packages impersonate Claude Code and one targets OpenClaw, the viral AI agent that recently passed 210k stars on GitHub,” the researchers wrote in a blog post.

Once a malicious package is installed and executed, the malware hunts for sensitive credentials, including npm and GitHub tokens, environment secrets, and cloud keys. Those credentials are then used to push malicious changes into other repositories and inject new dependencies or workflows, expanding the infection chain.

Additionally, the campaign uses a weaponized GitHub Action that could potentially amplify the attack inside CI pipelines, extracting secrets during builds and enabling further propagation, the researchers added.

Poisoning the AI developer interface

The campaign was specifically flagged for its direct targeting of AI coding assistants. The malware deploys a malicious Model Context Protocol (MCP) server and injects it into configurations of popular AI tools, embedding itself as a trusted component in the assistant’s environment.

Once this is achieved, prompt-injection techniques can trick the AI into retrieving sensitive local data, which can include SSH keys or cloud credentials, and pass it to the attacker without the user’s knowledge.

Anthropic has accused three Chinese AI developers of running large-scale campaigns to illicitly extract capabilities from its Claude model to improve their own systems. The company claims DeepSeek, Moonshot, and MiniMax used a distillation technique, where a less capable model is trained on the outputs of a more advanced one.

More than 16 million interactions were generated with Claude through around 24,000 fraudulent accounts, in violation of Anthropic’s terms of service and regional access restrictions.

Anthropic said it does not offer commercial access to Claude in China, nor to subsidiaries of these companies operating outside the country.

How Claude’s capabilities were extracted at scale

Anthropic said the three distillation campaigns followed a similar playbook, where they used fraudulent accounts and proxy services to access Claude at scale while evading detection, and targeting Claude’s agentic reasoning, tool use, and coding capabilities.

The DeepSeek campaign involved over 150,000 exchanges, focused on extracting reasoning capabilities across diverse tasks. The activity generated synchronized traffic across accounts, with identical patterns, shared payment methods, and coordinated timing suggested load balancing to increase throughput, improve reliability, and avoid detection. 

Moonshot AI’s activity involved over 3.4 million exchanges targeting agentic reasoning and tool use, coding and data analysis, computer-use agent development, and computer vision to reconstruct Claude’s reasoning traces. MiniMax was the largest of the three, involving more than 13 million exchanges, and was squarely targeted at agentic coding and tool use and orchestration. Detected while the campaign was active, Anthropic said MiniMax redirected nearly half of its traffic to Claude’s newly released model within 24 hours.

To carry out the campaigns, Anthropic said the companies relied on commercial proxy services that resell access to Claude and other frontier AI models at scale, referred to as hydra cluster architectures.

Back to the basics of AI model training

Industry experts note that the allegations raise a broader and unresolved question around how AI systems are trained. Most large language models, including leading commercial systems, are themselves trained on vast amounts of publicly available internet data, often without explicit consent from original authors.

“Just as many of the foundation models have been built by indexing the vastness of the internet, often without the explicit consent of creators or piggybacking on other search engines’ content, the newer entrants are in many instances going through the same routes of distillation and optimization,” said Neil Shah, vice president at Counterpoint Research. He added that there is a fundamental disagreement, which is mostly legally undefined, about who owns the synthetic data and whether it is okay if it is used for training, especially open models.

Export controls and national security

Anthropic has framed the alleged distillation campaigns partly through a national security lens, arguing that illicitly distilled models could undermine US efforts to control the spread of advanced AI capabilities, especially if influenced by the Chinese Communist Party. However, experts note that current US export controls are largely focused on hardware, and not on large language models.

“It is critical to separate hardware restrictions from service access. US export controls have concentrated primarily on advanced semiconductors, high-performance computing infrastructure, and, in certain regulatory moments, specific categories of advanced AI model weights. There is no universal prohibition on offering API access to large language models in China,” explained Sanchit Vir Gogia, CEO and chief analyst at Greyhound Research.

However, this does not mean developers are insulated. Gogia added that the Bureau of Industry and Security continues to refine licensing frameworks related to advanced computing commodities and high-capability systems. Also, if a company knowingly supports training activity for restricted entities, especially those tied to military or strategic objectives, exposure becomes plausible even without hardware shipment.

To safeguard themselves, many US AI providers already restrict availability in China through business policy and compliance posture, even beyond what is strictly required.

“For developers, the risk is indirect but real: if your product routes access to restricted geographies or entities, facilitates prohibited end uses, or helps others evade provider geo-restrictions, you can trigger account termination, contractual liability, and potentially regulatory scrutiny depending on who the end user is and what the system enables,” said global partner/senior managing director – India at Ankura Consulting.

Implications for teams building with LLMs

For developers building or training models using large language models, the Anthropic allegations highlight a growing grey area. Developers commonly use LLM APIs for application development, testing, or evaluation. But providers are scrutinizing large-scale, automated use of model outputs to train competing systems.

For instance, Anthropic is responding by investing in defensive techniques. For detection, the company has built several classifiers and behavioural fingerprinting systems designed to identify distillation attack patterns in API traffic. It has also strengthened verification for educational accounts, security research programs, and startup organizations, citing them as the pathways most commonly exploited for setting up fraudulent accounts. The company is also implementing product, API, and model-level safeguards designed to reduce the efficacy of model outputs for illicit distillation, without degrading the experience for legitimate customers.

Developers, too, should ensure their model training stays safe, compliant, and defensible.

Jaju stated that, to start with, developers should review API/service terms and assume no training on outputs unless explicitly permitted. They should maintain a clear record of where every training/example item came from, with licensing/terms attached. Separate operational logs from training datasets should be maintained along with set retention limits.

“Geopolitical diligence cannot be an afterthought. Restricted party screening, export compliance reviews, and region-specific access controls are increasingly part of AI governance, especially for enterprises operating across borders,” added Gogia.

Experts say that if questioned by a regulator or acquirer to explain the training pipeline, developers should be able to provide the same with documentation and without caveats.

High inference latency and spiraling GPU costs have emerged as the primary bottlenecks for IT leaders deploying agentic AI systems. These workflows often generate thousands of tokens per query, creating a performance gap that current hardware struggles to bridge.

Now, researchers from the University of Maryland, Lawrence Livermore National Labs, Columbia University, and TogetherAI say they can triple inference speed on reasoning benchmarks by fine-tuning pretrained models so that acceleration is embedded into their weights, removing the need for speculative decoding or auxiliary draft models.

In a paper published this month, the team describes a multi-token prediction technique that converts standard next-token models into parallel decoders using a special added mask token and an online self-distillation objective.

In benchmark tests, the approach delivered more than 3x acceleration with minimal accuracy loss, a trade-off that could appeal to enterprises struggling to balance cost and model quality in production AI systems.

The final model reportedly retains the same implementation as the pretrained initial checkpoint and is deployable without the addition of any auxiliary verifier or other specialized inference code.

How the technique works

Traditional LLMs generate one token per forward pass, a design that inherently caps throughput.

This serial bottleneck is especially problematic for reasoning models, which generate thousands of tokens during a “chain of thought,” even for short final responses. Producing multiple tokens in one pass reduces both latency and cost.

To ensure coherence, the researchers rely on a student–teacher setup. Using a zookeeper analogy, they note that a model predicting multiple words independently might nonsensically output that a zookeeper fed “meat to a panda.” The teacher model evaluates these multi-token spans to ensure they make sense together.

“We propose an RL-inspired training paradigm in which a student model generates a span of simultaneous token predictions,” the researchers said in the paper. “To avoid the pitfalls of the standard offline objective, the student output is scored by an LM critic/teacher, rather than being scored against a known ground-truth token sequence.”

“By comparing the student’s predictions against the next-token suggestions made by the teacher, we produce an on-policy reward signal that enables the student to quickly improve the quality of its multi-token predictions,” they added.

At inference time, the system uses a confidence-adaptive (ConfAdapt) decoding strategy that dynamically determines how many tokens to emit per pass. When the model is highly confident, it outputs larger chunks. When uncertainty rises, it falls back to smaller steps, preserving accuracy while maintaining speed gains.

In experiments on GSM8K math reasoning benchmarks, an 8B parameter model achieved more than 3x acceleration with less than a 3 percent drop in accuracy. A smaller 4B parameter model reached similar speedups, though with a larger 7 percent drop in accuracy. More aggressive configurations pushed acceleration to 5x, though at steeper accuracy costs.

Unlike speculative decoding, which requires auxiliary speculator models and specialized inference pipelines, this approach trains a single model that retains the same implementation as the original checkpoint and requires no auxiliary verifier.

What this means for enterprise AI

Analysts say the bigger question is whether this approach meaningfully changes how inference stacks are designed in production.

“Speculative decoding attempts to break that constraint by introducing a draft model that proposes tokens and a target model that verifies them,” said Sanchit Vir Gogia, chief analyst at Greyhound Research. “In theory, this yields lossless acceleration. In practice, verification cost, batching interaction, and draft-target drift reduce realized gains.”

By contrast, he said, the multi-token approach retains the autoregressive backbone but shifts optimization into the training phase.

“The economic impact depends on entropy distribution across the output,” Gogia said. “In reasoning-heavy or structured tasks, predictable spans can be emitted in larger blocks with limited degradation. In higher-entropy, open-ended generation, acceleration shrinks. This is selective compression, not universal speed.”

That distinction matters for enterprise deployments.

“ConfAdapt is fundamentally entropy-sensitive,” Gogia said. “Its strategic advantage is maximized in workloads characterized by structured scaffolding, deterministic language segments, and advisory outputs subject to human oversight.”

Enterprises, Gogia said, should view the technique as a calibrated efficiency lever rather than a universal acceleration switch.

Snowflake has extended support for Cortex Code CLI, its terminal-based AI coding agent, to dbt and Apache Airflow to help data practitioners streamline engineering workflows.

“With this extended support, developers unlock secure, context-aware AI assistance within their preferred data engineering systems — empowering teams to work with data wherever it lives, and build, manage, and optimize production-grade workflows more efficiently,” the company said in a statement.

Apache Airflow and dbt are widely used building blocks of enterprise data stacks. While dbt provides a SQL-based framework for transforming raw warehouse data into analytics-ready models with testing and version control, Airflow orchestrates and schedules complex data pipelines across systems.

Avoiding context switching for developers

The development could be a big boon for data practitioners and developers.

“These (dbt and Airflow) are the control planes of modern data stacks. Embedding AI assistance directly into transformation and orchestration layers reduces friction, speeds development, and improves governance,” said Phil Fersht, CEO of HFS Research.

Explaining further how Cortex Code CLI’s integration reduces friction and accelerates development, HyperFRAME Research’s leader of the AI stack, Stephanie Walter, pointed out that developers can now avoid context switching.

Before the integration, developers could access Cortex Code CLI through tools like VS Code and Cursor, but the AI-assistance remained “essentially Snowflake‑centric”, offering little awareness of how dbt models or Airflow DAGs were structured, Walter said.

This meant that developers and data practitioners had to generate code in one environment, copy it over to dbt or Airflow, and then manually rework it to fit the transformation or orchestration logic they were maintaining, Walter noted, adding that this was an inefficient, fragmented workflow that kept AI assistance disconnected from real production pipelines.

Snowflake to own the developer experience

The integration could be seen as a strategic move by Snowflake to own the developer experience around data workflows and not just the warehouse.

“Snowflake wants to be the intelligence layer across the modern data stack, even when components sit outside its core platform. The endgame is platform gravity. If developers rely on Cortex to build and maintain pipelines, Snowflake increases its strategic control over data logic, governance, and AI enablement, regardless of where raw data physically resides,” Fersht said.

As a result, Fersht added, the move should intensify competition around the AI-native data stack: “Databricks has long positioned itself around openness and lakehouse flexibility. Snowflake moving Cortex Code CLI into dbt and Airflow narrows that differentiation by signaling it can operate across heterogeneous environments.”

Snowflake has also introduced a subscription plan for Cortex Code CLI to allow customers who don’t already have a Snowflake workload to try the AI coding agent across their data workflows.

Details of the subscription plan are yet to be disclosed by the cloud data warehouse provider.

Standardizing on a single cloud infrastructure is much easier than pursuing a multicloud strategy. In a single-cloud environment, IT leaders can optimize skill sets, centralize data more easily, secure infrastructure with fewer tools, and gain many other operational benefits. Yet 89% of enterprises report they are pivoting to multicloud adoption. Reasons for choosing to operate across multiple clouds include mitigating risk, reducing service interruptions, and avoiding vendor lock-in.

Vendors have responded to multicloud complexities with “single pane of glass” tools that operate across cloud providers. For example, AIOps platforms can centralize observability and data monitoring, while many data security posture management (DSPM) platforms are multicloud. Establishing platform engineering practices, shifting finops left as a key architecture practice, and automating CI/CD deployments are three ways devops teams can reduce overhead in managing multiple clouds.

Generative AI tools, including AI copilots and AI agents, are also becoming invaluable. World-class IT departments are using genAI to write agile requirements, develop software, automate testing, and maintain documentation.

I asked IT leaders how they are using generative AI to increase efficiency and simplify complexity management in multicloud architectures.

1. Evaluate cloud service and code portability

Architects have the difficult job of understanding tradeoffs between proprietary cloud services and cross-cloud platforms. For example, should developers use AWS Glue, Azure Data Factory, or Google Cloud Data Fusion to develop data pipelines on the respective platforms, or should they adopt a data integration platform that works across clouds?

Generative AI opens the door to a third option for code creation and translation. Consider a developer writing code to extract, transform, and load (ETL) for one cloud during development, then transitioning to another cloud provider if the architecture changes.

“Managing multicloud is like learning multiple languages from AWS, Azure, Oracle, and others, and it’s rare to have teams that can traverse these environments fluidly and effectively. Plus, services and concepts are not portable among clouds, especially in cloud-native PaaS services that go beyond IaaS,” says Harshit Omar, co-founder and CTO at FluidCloud.

One way to work around this issue is to assign an AI agent to support the developer or architect in evaluating platform selections. This AI agent would review standards, decision criteria, and requirements to recommend solutions and articulate tradeoffs.

“GenAI can help by acting like a devops copilot that understands the user’s intent and design preferences, whether the goal is to optimize for cost, performance, or security, and automatically generates the right infrastructure patterns, says Omar. “Teams spend less time hunting around for multicloud linguists and more time executing on the infrastructure updates and optimizing workloads for the best environments for their business.”

Recommendation: Porting across clouds will be a more realistic option for straightforward configurations and implementations. Using cloud architecture agents and code translation AI tools can help with multicloud portability.

Also see: How to excel in multicloud: The new checklist.

2. Shift from coding to improving resiliency

Developing APIs, applications, and data pipelines is getting easier with genAI tools. According to The 2025 State of AI Code Quality report, 82% of developers use AI coding tools daily or weekly, and 70% report improved code quality. Whereas automation helped IT shift left efforts to focus on customer experience and improving data quality, code generators could help them shift right to improve operational resiliency.

“GenAI is creating a new skill set in which knowledge workers learn to code through prompts and specs, while AI handles cloud-specific mechanics,” says Ed Frederici, CTO of Appfire. “In the future, the true measure of success won’t just be cost savings, but also resilient systems, stronger governance, and empowered teams that understand AI as their toolset rather than the quirks of every cloud, helping them work with greater confidence and impact.”

Recommendation: GenAI can improve resiliency by translating governance policies into cloud-specific implementations.

3. Create multicloud configurations from standard requirements

Standardizing infrastructure and service configurations across different clouds requires expertise in different naming conventions, architecture, tools, APIs, and other paradigms. Look for genAI tools to act as a translator to streamline configurations, especially for organizations that can templatize their requirements.

Jed Dougherty, head of AI architecture at Dataiku, says managing multiple clouds can be an exercise in frustration because each cloud has its own approach to security, access, pricing, and services. Dougherty expects genAI will simplify the translation process: “Imagine genAI automatically translating a complicated AWS IAM role into an Azure Role Definition, or an AWS CloudFormation template into a Google Deployment Manager Configuration.”

Recommendation: Look for genAI tools to build automations and cloud configurations from a single set of requirements, translated into cloud-specific implementations.

4. Simplify operations and automation

CI/CD, infrastructure-as-code, and process automation are key tools for driving efficiency, especially when tasks span multiple cloud environments. Many of these tools use basic flows and rules to streamline tasks or orchestrate operations, which can create boundary cases that cause process-blocking errors. Adding genAI to these automations can enable more robust automations and expand their applicability.

“Managing multicloud environments has traditionally been complex, requiring multiple tools for orchestration, compliance, and cost control, says Mehdi Goodarzi, SVP and global head of AI at Hexaware. “GenAI is now changing this by introducing automation, contextual insights, and intelligent governance into the ecosystem. It simplifies visibility, proactively addresses performance and security issues, and seamlessly orchestrates workloads across providers. Together, this evolution transforms multicloud from a resource-intensive necessity into a powerful enabler of agility, resilience, and business growth.”

Recommendation: Look for genAI capabilities that provide recommended actions in their flows and error handling. Devops can then generate risk and accuracy scores to help decide which actions to automate and which require human intervention.

5. Improve problem resolution with genAI observability

Site reliability engineers (SREs) are expected to perform during outages or performance issues, but they prefer reviewing system performance and proactively recommending improvements to developers before issues arise. Improving application observability has helped SREs, but it’s also created data management challenges.

“Multicloud chaos is fundamentally a data problem, and genAI’s edge is building a unified semantic layer over configs, logs, schemas, and lineage,” says Tobie Morgan Hitchcock, co-founder and CEO of SurrealDB. “Natural-language SRE copilots will infer topology, data gravity, compliance, and cost to propose placements, generate runbooks, and continuously remediate drift across clouds.”

Inconsistent and unstandardized observability data can lead to false alarms and misdiagnosis. But going back to development teams to adhere to data standards and naming conventions has a cost.

“Today’s multicloud operations overwhelm teams with noisy, disconnected alerts that bury the real issues,” says Kyle Campos, CPTO of CloudBolt. “GenAI changes that by interpreting complex, cross-cloud telemetry and surfacing only high-value incidents and optimization opportunities with meaningful context. Results include less alert fatigue, faster resolution, and a measurable boost in day-two operations impact—a critical step in how enterprises build, manage, and continuously optimize across clouds.”

Recommendation: SREs should dedicate time to testing AI agents and other genAI capabilities that simplify and accelerate the use of observability data to improve application performance.

6. Reduce the gap between policy and compliance

Each cloud provider has its own tools for implementing policies and reviewing compliance. When these policies are updated, the security and operations teams must update their implementations one by one, which is inefficient.

“Enterprises stitch together three divergent stacks from AWS, Azure, and GCP, resulting in rising operational complexity, brittle cross-cloud integrations, and cost drag driven by data gravity, egress, and persistent skills shortages,” says Pranay Ahlawat, chief technology and AI officer at Commvault. “GenAI can auto-generate portable IaC/policy to translate intent into native controls and remediate drift across clouds, which can improve compliance and cost posture.”

Recommendation: Regulated businesses will need compliance and security tools that enable the implementation of policies once, then deploy and report across cloud capabilities. Look for genAI capabilities in these tools to support reporting and configuration.

7. Enable continuous finops monitoring

Cloud cost reports with recommendations are available natively in each cloud provider’s reporting tools and in dedicated finops tools that aggregate the relevant data. Organizations with significant variable costs, especially as they scale AI programs, need more than reports to continuously optimize costs and workloads.

“Traditionally, organizations struggle to monitor, provision, and optimize workloads across multiple clouds, as they juggle different APIs, tools, and costs,” says Kevin Cochrane, CMO of Vultr. “GenAI simplifies this by providing intelligent recommendations, predictive scaling, and automated policy enforcement across environments. This reduces operational overhead, minimizes misconfigurations, and ensures workloads run efficiently and cost-effectively, allowing teams to focus on AI innovation rather than managing complexity.”

Recommendation: Smaller organizations should assign the responsibility for reviewing cloud costs to tools such as Azure Advisor, Google Cloud Recommender, and AWS Cost Explorer. Larger organizations should review the genAI capabilities in finops tools designed for financial and engineering end-users.

Can genAI fully address multicloud complexities?

GenAI is currently being embedded across development and operational tools, but it’s not a silver bullet. Regarding multicloud, Ahlawat from Comvault says genAI doesn’t eliminate structural constraints such as data gravity, latency, commitments, or the talent gap. “Organizations still need strong guardrails and platform engineering to manage overall operational complexity,” he says.

We can also expect public clouds to release additional differentiating capabilities, so even as tools powered by genAI simplify today’s challenges, new ones will emerge.

The tech industry always values innovation, but Microsoft’s latest adoption of new technology may come at an unusually high cost. The company’s aggressive moves to embed its AI assistant, Copilot, into Windows 11 and Microsoft 365 have polarized users and drawn regulatory scrutiny. The Federal Trade Commission (FTC) is looking at whether Microsoft’s tactics in the AI arms race, and its cloud and software bundling practices, cross legal boundaries into monopolistic behavior. The core issue is the tight integration of AI features into its flagship products, often without full or enthusiastic user consent.

Microsoft has been touting Copilot as the next revolution in productivity, seamlessly augmenting workflows across Windows 11 and Microsoft 365 (formerly Office 365). However, this future-forward strategy comes with a less discussed side effect: forcing AI on users who may not want it or on those who are wary of its utility, privacy implications, and resource consumption.

Across technical forums and customer surveys, a chorus of user complaints has emerged. Customers report that Copilot is not merely an optional feature but a deeply integrated part of the operating system and Office suite, making it difficult or even impossible for everyday users to disable or ignore. This sense of coercion is compounded by reports that Microsoft has been counting AI-enabled licenses—as opposed to actual usage—in its quarterly sales tallies, further incentivizing the company to push Copilot upon its massive customer base.

It’s not just a question of choice, either. Many enterprise customers and individual users have voiced frustration with AI rollouts being prioritized over security and performance updates, even as some remain skeptical about AI’s productivity benefits. The perception is that Microsoft is turning a must-have productivity and operating system suite into a vehicle for AI market dominance rather than letting its customer base adopt AI at its own pace.

The Windows 10 exodus

Microsoft’s infatuation with AI coincides with the strategic end of life for Windows 10. Support for the popular operating system (still used on hundreds of millions of PCs) has been discontinued, hastening a mass migration to Windows 11. And Windows 11, as most customers have discovered, is not compatible with everyone’s machine. Unlike earlier upgrades that could run on older hardware, Windows 11’s requirements, such as TPM 2.0 and recent-generation CPUs, have left a vast number of otherwise functional PCs stranded.

For many customers, the price of admission to Copilot and continued security updates isn’t just about software. The only way for them to qualify for Windows 11 is often to buy a new PC. This adds expense for consumers, businesses, and schools, sometimes with little perceived benefit beyond the Copilot-infused experience Microsoft is selling. If ever there were an example of a forced upgrade, this is it.

A longer shadow looms over Microsoft’s strategy, which seems aimed not only at technological progress but also at creating a captive upgrade market. Industry voices already have questions: Is forcing hardware upgrades about the user experience or a clever way to boost revenues through software, OEM deals, and hardware sales?

FTC’s expanding antitrust probe

Into this volatile mix steps the FTC, which in recent months has dramatically ramped up its antitrust scrutiny of Microsoft’s practices. The FTC has been interviewing Microsoft’s rivals, gathering evidence, and issuing civil investigative demands that reach into the company’s core AI operations, software licensing deals, cloud service integrations, and even its investment decisions regarding AI partners such as OpenAI.

At issue, according to several sources and public reports, is whether Microsoft is illegally tying its products and services together in ways that stifle genuine competition. The agency is investigating whether Microsoft bundles productivity tools such as the Office 365 suite to boost its Azure cloud business, levies exit fees on customers who try to switch providers, and deliberately creates compatibility barriers that prevent its software—including AI-driven features—from running smoothly on other vendors’ cloud services.

This is not Microsoft’s first confrontation with antitrust authorities. What’s different in 2026 is the added layer of complexity AI brings. The FTC is especially interested in whether Microsoft’s integration of Copilot into core products amounts to a new form of digital tying that nudges or forces customers to use Microsoft’s AI, cementing its market share and data dominance and erecting new barriers to rival AI offerings.

Consent, competition, and regulation

For Microsoft, the stakes could not be higher. On the one hand, the company wants to lead in AI by developing new capabilities and automating tedious workflows to reduce friction for users. On the other hand, the perception—not entirely unfounded—is that Microsoft is using its dominant position in operating systems and productivity suites to force Copilot down users’ throats.

From an antitrust standpoint, customer consent matters. When users feel forced to upgrade software and hardware primarily to access features they may not value—or worse, that they actively resent—regulators take note. The FTC’s investigation signals that the days of quietly leveraging ecosystem dominance to win new markets are waning, especially as enterprises and public institutions grow wary of becoming collateral damage in Big Tech’s battles for AI supremacy.

Microsoft’s defense so far is that integration is about product improvement, not power consolidation. It cites technical reasons for incompatibilities and claims that AI-powered features require tight integration for security and performance. But as the investigation drags on, it becomes clearer that the company’s AI-first play has opened the door to regulatory, reputational, and commercial risks that may yet reshape the trajectory of its AI ambitions.

In pushing Copilot as an embedded feature of Windows 11 and Microsoft 365, Microsoft hoped to shape the market’s future. But consumer pushback, stringent hardware requirements, and intensifying government scrutiny suggest the company may have overplayed its hand. Whether the FTC concludes that these practices rise to the level of antitrust violations remains to be seen, but for now, Microsoft is learning in real time that the path to AI leadership can be rocky, especially when the customers and regulators who helped shape its empire may ultimately decide its fate.

With every passing year, data continues to grow more important and more central to practically every aspect of corporate operations. As the AI race continues full-steam ahead, it will be mission-critical for CIOs and other technical business decision-makers to get things right when it comes to their data infrastructure.

Without the right plumbing, even the best, most robust data estate can become rusty. So, as your organization wraps up its 2026 planning, don’t lose sight of just how essential your database strategy is to both your near-term and long-term business success.

To navigate this shifting environment, enterprises need a pragmatic, actionable framework. The following five-part checklist offers a starting point for database success, helping CIOs, CTOs, IT executives, and data leaders reduce licensing risk, simplify operations, and future-proof their data infrastructure for the AI era.

Embrace community-led open source to reduce costs and avoid licensing risks

One of the most important strategic decisions that business leaders can make regarding their database estates is to embrace community-led open source. While “open” is almost always preferable to proprietary, it’s important to remember that not all open source is equal. As we’ve seen with the licensing changes made by “open source” organizations like Redis, Elastic, and others, single-vendor open source solutions can become proprietary (or simply more restrictive) on a whim, leaving many end users trapped.

With community or foundation-led open source projects, such as PostgreSQL and Valkey, this kind of uncertainty is removed, allowing organizations to rest easy knowing that the licensing they initially opted into will not be changed at the insistence of a board.

And although open source is an excellent way to drive down the total cost of ownership, going open source isn’t solely about cost cutting. Open source also offers a degree of flexibility, autonomy, and freedom that is essential to future-proof your organization. And perhaps most importantly, community-led open source comes with the power of rapid, crowd-sourced innovation, where industry needs drive feature development and ensure continued relevance and efficacy as technology evolves.

Lean on platform engineering to streamline your database stack

Database sprawl is now the norm. Developers have easy access to dozens of database technologies, each suited for different workloads. But when teams deploy databases independently, without consistent controls, it creates fragmentation. And that means uneven performance, inconsistent security standards, and unpredictable access patterns.

Platform engineering offers a solution. By treating the data platform as a product with its own service catalog, guardrails, and life-cycle policies, enterprises can provide developers with self-service database capabilities while retaining governance and consistency.

When done right, platform engineering offers:

• Standardized, version-controlled templates for each supported database.
• Clear definitions of what the platform team owns versus what application teams own.
• Self-service provisioning with pre-approved configurations for compliance, security, and performance.
• Built-in resilience features—backups, failover, encryption—that developers don’t have to reinvent.

Centralize observability and management for a unified view of your database estate

In a world where enterprises run PostgreSQL alongside MySQL, MongoDB, serverless cloud DBaaS, and specialized analytics engines, visibility becomes both mission-critical and hard to achieve. Teams often run multiple monitoring tools (one for each system), which creates blind spots and slows down troubleshooting.

Centralized observability brings coherence to a fragmented landscape. Whether it be via adjacent tooling, third-party services, or both, look for solutions that offer multi-database support. Many tools and services today go all-in on one database management system, but leaning too heavily on such specialized solutions will only further segment your ecosystem.

A modern observability strategy should include unified dashboards across multiple database engines and normalized metrics to enable apples-to-apples comparisons, for starters. The cost of siloed data is rising. Centralize your operations before the increasingly costly inefficiencies pile up.

Prepare for a world where AI workloads reign supreme

Organizations would be wise to build for a world in which AI workloads are abundant and open source is the gold standard for handling all data types from structured, transactional data to vector data and beyond. Evaluate and adopt open-source databases that are well-suited to AI workloads and include vector search capabilities (e.g., PostgreSQL and pgvector). Ensure compatibility with popular data science ecosystems (e.g., Python, Jupyter, TensorFlow, PyTorch). And look for open-source solutions that promote extensibility and integrations to ensure database capabilities can grow and expand organically with the evolving technological landscape.

The best thing that open-source solutions like PostgreSQL have to offer for AI workload readiness is the ability to evolve, transform, and expand functionality in step with industry needs. With community-led innovation, your organization will never find itself left behind in the pursuit of new database capabilities.

Leverage automation to accelerate operations and democratize data access

Database teams are under enormous pressure, burdened by performance tuning, capacity planning, diagnosing slow queries, responding to incidents, and managing cross-environment differences. Traditional monitoring tools generate alerts but rarely insights, and certainly not predictions.

AI-powered operations tools and other forms of automation are quickly becoming a major competitive differentiator for organizations looking to accelerate their database ops. Modern systems can detect anomalies across logs, metrics, and query patterns and recommend optimizations before human engineers spot the issue.

Automation also enables teams across the business (e.g., data scientists, engineers, analysts, product owners) to experiment, build, and iterate quickly. But manual provisioning and heavy governance checks slow everything down. Automation enables fast, safe, democratized access to data systems.

Caution is paramount, however, when looking at automation in the database space. Few modern workloads can tolerate downtime, so organizations should prioritize automation that enables, rather than replaces, humans—such as tools focused on observability. Automation that runs through logs and identifies patterns, inefficiencies, and the like will become vital to modern database management in the near future. Other forms of automation, on the other hand (such as “self-healing” databases) still pose too much risk for the average organization to tolerate.

Finally, ensure that all forms of automation used in your environment are transparent and auditable, and allow room for human oversight, once again opting for openness wherever possible.

Open, integrated, and AI-ready database systems prevail

When making your database decisions in the months and years ahead, it’s vitally important that businesses prioritize flexibility, autonomy, and AI-readiness to keep pace with today’s rapidly evolving tech landscape. Any factors that might compromise one’s agility or nimbleness, such as vendor lock-in or restrictive proprietary licensing, can seriously jeopardize one’s ability to future-proof infrastructure.

At the same time, as SaaS costs continue to soar and the number of databases and adjacent tools within organizations continues to balloon, managing total cost of ownership becomes mission critical. With that being said, AI readiness remains a priority for most organizations, which risk falling behind the competition as a result of late adoption.

In all these pursuits, open and integrated solutions prevail. Open-source tools and integrated infrastructure are the difference between siloed systems that suffer from immense drag and streamlined database operations that are ready for whatever the future may bring.

—

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

Microsoft has introduced C++ symbol context and CMake build configuration awareness for GitHub Copilot in Visual Studio Code.

The C++ code understanding improvements were announced on February 19. The updates to GitHub Copilot in VS Code bring the same C++ intelligence as the Microsoft’s C/C++ and CMake Tools extensions directly into agent mode by surfacing key language and build system capabilities as tools the agent can invoke. The goal is making AI-assisted C++ workflows more consistent and performant by grounding them in the same symbol and build context developers already use and trust, Microsoft said.

These tools are available as a part of the C/C++ DevTools extension for VS Code, which ships as part of C/C++ Extension Pack for VS Code. Through the new C++ code understanding tools, agent mode now has access to rich C++ symbol context. Instead of relying solely on text search or file search, the agent can reason about C++ code at the symbol level across a workspace and intelligently perform code editing operations across a codebase.  

Current C++ code understanding tools available for GitHub Copilot Chat include the following:

• Get symbol definition, which retrieves detailed information about a C++ symbol including where it is defined and its associated metadata.
• Get symbol references, which finds all references to a given symbol across the codebase.
• Get symbol call hierarchy, which surfaces incoming and outgoing calls for a function to understand call patterns and dependencies.

To enable these tools, developers can select the “Enable Cpp Code Editing Tools” setting in the VS Code user settings.

Microsoft also has integrated CMake build and test configuration tools with GitHub Copilot in VS Code. Now GitHub Copilot Chat can leverage the build configurations identified and provided by the CMake Tools extension to build and test a project using the exact configuration already selected in VS Code. By working with the same CMake Tools integration developers use in the editor, GitHub Copilot avoids relying on ad hoc command-line invocations and stays aligned with chosen targets, presets, and build state, Microsoft said.

The current tools available to GitHub Copilot Chat for build configuration include:

• Build with CMake, which builds a CMake project using the active configuration.
• Run CTests, which runs CTest tests using the active test suite.
• List Build Targets, which lists the available set of build targets for a CMake project.
• List CTest tests, which lists the available set of tests for a CMake project.

Here’s a little bit of snark from developer John Crickett on X:

Software engineers: Context switching kills productivity. Also software engineers: I’m now managing 19 AI agents and doing 1,800 commits a day.

Crickett’s quip lands perfectly because it is not actually a joke. It’s a preview of the next management fad, wherein we replace one bad productivity proxy (lines of code) with an even worse one (agent output), then act surprised when quality collapses.

And yes, I know, nobody is doing 1,800 meaningful commits. But that’s the point. The metric is already being gamed, and agents make gaming effortless. If your organization starts celebrating “commit velocity” in the agent era, you are not measuring productivity. You are measuring how quickly your team can manufacture liability.

The great promise of generative artificial intelligence was that it would finally clear our backlogs. Coding agents would churn out boilerplate at superhuman speeds, and teams would finally ship exactly what the business wants. The reality, as we settle into 2026, is far more uncomfortable. Artificial intelligence is not going to save developer productivity because writing code was never the bottleneck in software engineering. The true bottleneck is validation. Integration. Deep system understanding. Generating code without a rigorous validation framework is not engineering. It is simply mass-producing technical debt.

So what do we change?

Thinking correctly about code

First, as I argued recently, we need to stop thinking about code as an asset in isolation. Every single line of code is surface area that must be secured, observed, maintained, and stitched into everything around it. As such, making code cheaper to write doesn’t reduce the total amount of work but instead increases it because you end up manufacturing more liability per hour.

For years, we treated developers like highly paid Jira ticket translators. The assumption was that you could take a well-defined requirement, convert it to syntax, and ship it. Crickett rightfully points out that if this is all you are doing, then you are absolutely replaceable. A machine can do basic translation, and a machine is perfectly happy to do it all day without complaining.

What a machine cannot do, however, is understand critical business context. AI cannot feel the financial cost of a compliance mistake or look at a customer workflow and instinctively recognize that the underlying requirement is fundamentally wrong. For this we need people, and we need people to thoughtfully consider exactly what they want AI to do.

Crickett frames this transition as a necessary move toward spec-driven development. He’s right, but we need to be incredibly clear about what a specification means in the agent era. It’s not one more Jira ticket but, rather, a set of constraints tight enough to ensure an LLM can’t escape them. In other words, it’s an executable definition of done, backed entirely by tests, API contracts, and strict production signals. This is the exact type of foundational work we have underinvested in for decades because it doesn’t look like raw output; it looks like process. You know, that “boring stuff” that slows you down.

You can see the friction playing out in real time just by looking at the comments to Crickett’s tweet. You’ll find people desperately trying to square the circle of agentic development. One commenter tries to reframe the chaos by calling it architecture versus engineering. Another insists that managing 19 agents is actually orchestrating, not context switching. A third bluntly states that running more than five agents simultaneously starts to look like vibe coding, which is merely a polite phrase for gambling with production systems. They are all highlighting the core issue: You haven’t eliminated the work. You’ve just moved it from implementation to supervision and review.

The more you parallelize your code generation, the more “review debt” you create.

Observability to the rescue

This is where Charity Majors, the co-founder and CTO of Honeycomb, becomes frustrated. Majors has argued for years that you can’t really know if code works until you run it in production, under real load, with real users, and real failure modes. When you use AI agents, the burden of development shifts entirely from writing to validating. Humans are notoriously bad at validating code merely by reading large pull requests. We validate systems by observing their behavior in the wild.

Now take that idea one step further into the agent era. For decades, one of the most common debugging techniques was entirely social. A production alert goes off. You look at the version control history, find the person who wrote the code, ask them what they were trying to accomplish, and reconstruct the architectural intent. But what happens to that workflow when no one actually wrote the code? What happens when a human merely skimmed a 3,000-line agent-generated pull request, hit merge, and moved on to the next ticket? When an incident happens, where is the deep knowledge that used to live inside the author?

This is precisely why rich observability is not a nice-to-have feature in the agent era. It’s the only viable substitute for the missing human. In the agent era, we need instrumentation that captures intent and business outcomes, not just generic logs that say something happened. We need distributed traces and high-cardinality events rich enough that we can answer exactly what changed, what it affected, and why it failed. Otherwise, we’re attempting to operate a black box built by another black box.

Majors also offers essential operational advice: Deploy freezes are a complete hack. The common human instinct when change feels risky is to stop deploying. But if you keep merging agent-generated code while not deploying it, you’re simply batching risk, not reducing it. When you finally execute a deploy, you’ll have absolutely no idea which specific AI hallucination just took down your payment gateway. So if you want to freeze anything, freeze merges. Better yet, make the merge and the deploy feel like one singular atomic action. The faster that loop runs, the less variance you have, and the easier it is to pinpoint exactly what broke.

Golden paths are the way

The fix for this impending chaos is not to rely on heroic engineers. As Majors points out, resilient engineering requires a commitment to platform engineering and golden paths (something I’ve also argued). Such golden paths make right behavior incredibly easy and the wrong behavior incredibly hard. The most productive teams of the next decade will not be the ones with the most freedom to use whatever framework an agent suggests, but instead those that operate safely inside the best constraints.

So how do you measure success in the agentic era?

The metrics that matter are still the boring ones because they measure actual business outcomes. The DORA metrics remain the best sanity check we have because they tie delivery speed directly to system stability. They measure deployment frequency, lead time for changes, change failure rate, and time to restore service. None of those metrics cares about the number of commits your agents produced today. They only care about whether your system can absorb change without breaking.

So, yes, use coding agents. Use them aggressively! But don’t confuse code generation with productivity. Productivity is what happens after code generation, when code is constrained, validated, observed, deployed, rolled back, and understood. That’s the key to enterprise safety and developer productivity.

There is a growing belief that AI will dramatically reduce the need for experienced software engineers. It won’t.

The demonstrations are compelling. We see AI connected to Figma for design context, Jira for tickets, source control for repository history, and CI/CD pipelines for deployment. A feature request goes in, code comes out, and a pull request appears. The workflow looks increasingly automated.

On the surface, this automation appears to be the natural evolution of software development. In practice, however, it is far more constrained.

The assumption behind these demonstrations is that the inputs are complete. The Jira ticket captures every business rule. The acceptance criteria anticipate every edge case. The design system is fully consistent. All dependencies are documented. There are no unanswered questions. There is no ambiguity.

In more than twenty years of building software across enterprise systems, I have never seen a ticket that meets that standard.

Real tickets are approximations. They capture intent, not full reality. They rely on knowledge that exists in conversations, prior decisions, Slack threads, and architectural conventions that were never formally documented. They reflect trade-offs that were negotiated informally. They assume the context that experienced engineers carry implicitly.

Automation assumes clarity, but most real-world software development operates under ambiguity. This has many implications for software development organizations, but the most important is that experienced engineers are still needed. In fact, they are more valuable than ever.

The price of imprecision

The ambiguity inherent in software development tasks does not mean AI-driven automation will not work. It means its effectiveness is directly tied to how precisely the problem is defined. If you want AI to autonomously build a feature, your instructions must approach the level of a complete technical specification. Every edge case must be identified in advance. Every assumption must be explicit. Every open question must be resolved before implementation begins.

The intelligence of the output never exceeds the precision of the input.

That principle applies broadly. With AI, however, the gap between incomplete input and confident output can be harder to detect because the result looks polished and authoritative.

I have used AI to build entire features. When you describe the problem clearly enough, AI will generate code that compiles, runs, and often handles more scenarios than you initially considered. It feels efficient. It feels modern. It feels inexpensive.

However, the result is frequently more complex than what I would have written myself.

There is a quiet truth about developers that rarely gets stated openly: we are lazy. At least, I am. I do not want to write more code than necessary. I want the smallest solution that solves the problem cleanly. That instinct is not about shortcuts; it is about discipline. When I invest time thinking about structure before writing code, the implementation becomes smaller. Clear boundaries eliminate duplication. Accurate modelling removes defensive branching. Thoughtful constraints reduce the need for additional layers.

Good architecture allows you to write less.

AI optimizes differently. It optimizes for coverage and robustness. It anticipates variations. It introduces abstractions to cover broader cases. The generated output is rarely incorrect, but it is often comprehensive in ways that exceed the immediate need. That comes with a cost. 

When requirements change, you must modify logic you did not consciously design. When a bug surfaces, you are debugging control flow that you never fully reasoned through. When another engineer asks why a specific abstraction exists, the explanation may be that it was part of the generated solution rather than a deliberate architectural decision.

AI reduces the cost of writing code. It does not reduce the cost of owning it.

Ownership includes understanding. It includes the ability to reason about how a change will propagate through the system. It includes confidence that simplifying logic will not introduce unintended consequences. This understanding and confidence reside in engineers, not AI.

Acceleration amplifies architecture – good or bad

If your system’s boundaries are clear and your domain model coherent, AI increases your leverage. It allows you to extend that structure more quickly. If the architecture is loosely defined, AI accelerates the accumulation of complexity. The tool does not change direction; it increases velocity.

That amplification becomes especially visible in larger organizations, where architecture is not a diagram but accumulated history.

Enterprise systems are rarely greenfield. They evolve over the years. They carry decisions made under old constraints. They include integrations that cannot be easily rewritten. Much of what keeps them stable is not captured in documentation; it exists in memory. It is the knowledge of why a certain boundary was introduced, why a dependency was restricted, and why a previous refactor failed.

AI does not have access to that lived architectural memory unless it has been painstakingly encoded somewhere. Even then, it interprets patterns statistically rather than contextually. It does not remember the outage caused by an overly coupled service. It does not remember the internal debate that led to isolating a pricing engine. It does not remember why a team chose simplicity over extensibility in a specific module.

Experienced engineers remember those things.

That memory shapes decisions in subtle ways. It influences whether a new abstraction is worth introducing. It informs whether a shortcut is acceptable. It determines whether a proposed simplification might destabilize another part of the system. These considerations rarely appear in Jira tickets, yet they materially affect implementation quality.

The more AI-driven the workflow becomes, the more valuable that architectural memory becomes. Without it, teams risk repeating past mistakes more efficiently. When implementation accelerates but contextual awareness does not, fragility scales.

There is also an organizational shift embedded in this change. If teams want AI to implement features autonomously, they must dramatically improve how requirements are written. Tickets must move closer to formal specifications. Ambiguity must be resolved earlier. Decisions that were once clarified during implementation must now be clarified before prompting a model.

Someone still needs to decide what the system should do. Someone still needs to define boundaries. Someone still needs to determine how a new feature integrates with existing constraints. AI does not remove that responsibility. It simply changes where friction appears.

A new, old kind of engineering expertise

For years, technical depth was often demonstrated by the ability to write complex-looking code, to master framework internals, or to assemble sophisticated reactive flows. Those skills still matter, but they are no longer differentiators in the same way. AI can assist with all of them.

What remains scarce is judgment.

Judgment is the ability to recognize when a solution is heavier than the problem requires. It is the ability to model a domain accurately before introducing abstractions. It is the discipline to choose restraint over cleverness. It is the awareness that every additional layer becomes a future maintenance cost.

In my 20-plus years of working as a software engineer, I have seen the tools evolve dramatically. We have moved from manual infrastructure management to cloud platforms, from verbose frameworks to declarative ones, from hand-written configuration to generated scaffolding. Each wave promised increased productivity. Each wave delivered it.

What never changed was the need for someone to think deliberately about structure before scale magnified its flaws.

AI is another wave of leverage. It raises the floor of productivity. It lowers the barrier to experimentation. It makes scaffolding and boilerplate nearly trivial. But durable systems are not defined by how quickly they were assembled. They are defined by how intentionally they were structured. Working software is not the same as durable software.

AI makes it cheap to build software. It does not make it cheap to think. And thinking remains the part of the job that determines whether a system merely functions today or continues to function tomorrow.

Today, it is nearly impossible for anyone in a software development role to avoid AI technology. That’s not a bad thing; individuals and teams can realize numerous potential benefits from AI-driven development.

One thing is certain: Software developers who haven’t already done so must adapt their skills to meet the demands of this new era. And they should do it quickly.

The Stack Overflow 2025 Developer Survey, based on responses from more than 49,000 professional developers worldwide, showed that 84 percent of respondents were using or planning to use AI tools in their development workflow.

That’s an increase from the previous year, when 76 percent of respondents used or planned to use AI. By late 2025, about half of the survey respondents said they were already using AI tools daily.

“Developers everywhere are being pushed to adjust their skills for a world where AI is now part of the daily workflow,” says Chris Camacho, COO and co-founder of security-platform provider Abstract Security.

“In our industry, the shift is obvious,” Camacho says. “Internal workforce studies across several large enterprises show that a strong majority of developers are already using some form of AI assistance, and more than half of those companies now list AI and data-related skills as top hiring priorities. It feels similar to the early cloud wave, but the adoption curve is moving much faster.”

Developers are already feeling the shift from a development workflow based on writing code to one where they supervise, constrain, and reason about code generated by agents, says Sameer Agarwal, CTO and co-founder of Deductive AI, a provider of development tools. “The skill set that matters is changing accordingly,” he says.

Many developers are already adapting their skills to better fit in the world of AI-driven development. We asked developers and tech leaders how they are making the shift.

Structured training

Formal and ongoing training, whether it’s offered within your organization or externally, is one of the best ways to keep up with the latest trends in using AI coding agents.

“Inside engineering teams, the best learning will come from structured internal training,” Agarwal says. “We’re already seeing that many enterprises are beginning to run sessions on prompt design, agent behavior, reliability risks, and the failure modes of AI-generated code.” The most valuable courses are no longer about how to use AI coding agents, he says. Instead, they now cover debugging AI agents and evaluating the quality and relevance of their actions.

Every developer can benefit from an organized approach to learning, says Brady Lewis, senior director of AI innovation at fractional marketing firm Marketri. “A structured path for acquiring knowledge, by way of traditional coursework and/or specific certification programs in the areas of machine learning, data engineering, and/or statistics, provides developers with a basis upon which they can build applications that act as interfaces to AI models,” he says.

Structured learning does not require developers to become data scientists, Lewis says. Instead, it will educate developers on the limitations of AI systems in order to make application design more predictable and resilient.

Also see: AI developer certifications tech companies want.

Employer support for early adopters

Much of the AI training a developer receives might come from employers, as they look to broaden the use of AI in development.

“As the need for internal AI training programs continues to grow, an increasing number of employers are differentiating themselves by offering additional support to employees who are early adopters of their internal training programs,” Lewis says.

In addition to the learning, some of this training could open the door to other opportunities.

Many organizations are still trying to understand their standards regarding AI, Lewis says, “and developers who are engaged early in developing these standards have a greater impact than those who are not.”

Mentorship programs

Team-based mentorship programs can also help spread knowledge about AI tools and processes.

“A quiet trend happening inside many teams is that junior developers are asking fewer questions because AI tools can answer quickly,” Camacho says. “This may speed up a task, but it slows down long-term growth. The strongest teams I know are pairing juniors and seniors more often, encouraging code reviews that focus on how AI suggestions were validated.”

As the number of companies implementing AI-driven processes continues to grow, “there are also increasing opportunities for mentorship,” Lewis says. “Developers who partner with those leading the charge in developing AI-based processes can often receive important hands-on experience faster than those who are learning in isolation.”

Continuous learning is becoming a baseline expectation, Camacho says. “Developers need stronger literacy around data, safety, and security because AI features depend on them,” he says. “Teams that keep mentorship at the center will grow faster than those that rely entirely on tools.”

Also see: What you need to know about AI governance.

Support from AI providers

To help adapt to AI-driven development, why not go directly to the AI providers?

“My approach to adapting my skills and resume to AI was to go directly to the sources of the latest AI technologies and read their documentation and training materials,” says Chris Minnick, a software developer and CEO of WatzThis, a provider of books about software development and related topics.

“For example, OpenAI has OpenAI Academy, and most companies that do work in AI have similar resources,” Minnick says. “I didn’t consider going back to college because college courses can’t possibly keep up with the pace of change. I did study for and earn the Amazon AWS AI Practitioner certification, which is their foundational certification for showing that you’re familiar with how to use the AWS AI-related tools and with how generative AI works.”

Adapting to the AI-first mindset

For many developers, the first move in the transition to AI-driven development may be the most challenging, because it requires a shift in mindset.

Software developers first need to accept that their work will fundamentally change, says Ray Kok, CEO of Mendix, a provider of development platforms. The AI-first mindset is a muscle that must be exercised daily, he says.

Developers also need to train themselves on the higher levels of abstraction for software development, Kok says.”Get out of your programming mindset and start adopting model-based software development as a complementary tool for software composition and application development,” he says.

“I’m seeing developers adapt fastest when they shift from learning individual AI tools to understanding the underlying behaviors of AI systems,” Lewis says. “The developers who do well focus less on memorizing syntax and more on learning how orchestration, data quality, and workflow structure affect the reliability of AI-assisted development.”

Learning by trial and error

One way to become more familiar with AI-driven development is by taking on projects, on a trial-and-error basis, to see what works and what doesn’t work.

“I think where developers can adapt and improve their skills is the same as any great developer has done in the past: by dipping their toes in the water, reading the documentation/user stories, then jumping into building projects,” says Jackson White, founder and chief developer at Launch Turtle, a provider of website and application development services.

“The first AI-driven website I built with Launch Turtle was terrible, and lots had to be mended with traditional coding practices,” White says. “However, as both models and my own prompting became more sophisticated through the process of trial and error, AI has been able to take over substantially heavier loads. I think other developers would find similar results.”

Developers would be wise to focus on self-guided, experiential learning, says Joshua McKenty, CEO and co-founder of Polyguard, a company providing defenses against deepfakes and AI-powered fraud. “Get your hands dirty!” he says. “Try a new AI tool every few weeks. Ask one AI chatbot for help using another. The true sign of mastery is when you know how to use a tool—and when not to. So push these tools to their limits, and learn what happens when you hit them.”

Don’t forget to update your resume

Employers want to know about your experience with AI-driven development, so including this on your resume is important.

“As more companies build internal AI capabilities and as the demand for AI capabilities continues to grow, resumes are changing too,” Lewis says. “Developers that highlight real-world experience in these areas—agentic patterns, workflow design, prompt evaluation, quality control—are putting themselves far ahead of developers who simply list AI tools.”

Hiring managers are increasingly looking for developers who can articulate how, where, and why AI adds value; where it introduces risk; and how to make it reliable in the real world, Lewis says.

“It’s essential to update your resume as you gain new AI skills, especially if you’re looking for a job or if you might soon be looking for a job,” Minnick says. Even for job listings that don’t specifically mention AI skills, understanding how to use and integrate generative AI into software is rapidly becoming a standard requirement for software development jobs, he says.

A new security bypass has users installing AI agent OpenClaw — whether they intended to or not.

Researchers have discovered that a compromised npm publish token pushed an update for the widely-used Cline command line interface (CLI) containing a malicious postinstall script. That script installs the wildly popular, but increasingly condemned, agentic application OpenClaw on the unsuspecting user’s machine.

This can be extremely dangerous, as OpenClaw has broad system access and deep integrations with messaging platforms including WhatsApp, Telegram, Slack, Discord, iMessage, Teams, and others.

According to research by security platform Socket, the script was live for eight hours on the registry.

It should be emphasized that, in this case, OpenClaw wasn’t inherently malicious. However, it does represent yet another chapter in OpenClaw’s shaky security saga, and situations like this could earn it ‘potentially unwanted application’ (PUA) status.

“I mean, they effectively turned OpenClaw into malware that EDR [endpoint detection and response ] isn’t going to stop,” said David Shipley of Beauceron Security. It is “deviously, terrifyingly brilliant.”

Users love OpenClaw; attackers do, too

OpenClaw (formerly Clawdbot and Moltbot) is a free, open-source, autonomous AI agent that launched on January 29 and almost immediately went viral. According to its developer, Peter Steinberger, its repo had more than 2 million visitors over the course of a single week, and it’s estimated that it has been downloaded 720,000 times a week.

OpenClaw runs locally on a user’s hardware rather than in the cloud, and can perform autonomous, real-world actions on their behalf, such as reading emails, browsing web pages, running apps, or managing calendars.

However, almost immediately after release, it raised serious security issues: It is prone to prompt injection attacks, authentication bypasses, and server-side request forgery (SSRF), among other attacks. Many enterprises have responded by severely restricting, or outright banning, the AI agent.

While, in the Cline situation, it was merely installed, but not inherently malicious, “the attacker had the ability to install anything,” Socket’s Sarah Gooding wrote. “This time it was OpenClaw. Next time it might be something malicious.”

The Cline CLI is widely-used across the developer ecosystem, with about 90,000 weekly downloads from npm. The compromised token pushed cline@2.3.0, which contained a modified package.json with a postinstall script that installed the latest version of OpenClaw, to the npm registry. The addition of that script was the only modification to the package; otherwise the CLI binary and other contents were identical to the legitimate prior release, Gooding noted, making it easy to miss.

The compromised package was pushed on February 17, although the underlying problem had been discovered six weeks prior by security researcher Adnan Khan. The package sat live on the registry for an estimated eight hours before it was deprecated and Cline published a corrected version (2.4.0).

Khan had initially published his research about the vulnerable workflow on February 9, after unsuccessful attempts to get a response to his reports from Cline, and Cline fixed it within 30 minutes. However, while the patch closed the entry point, the token could have been stolen during an attacker’s initial reconnaissance, meaning the fix came too late to prevent the February 17 publish (which, ultimately, was the day it was exploited).

“Cline had no prior install scripts, so a new one appearing was an anomalous signal worth investigating,” Gooding noted, adding that Socket has marked the unauthorized publish as malware.

For devs who installed or updated the Cline CLI in the roughly eight-hour window on February 17, Socket advises:

• Update to the latest version: npm install “-g cline@latest.”
• If on version 2.3.0, update to 2.4.0 or higher.
• Check for and immediately remove OpenClaw if it hadn’t been intentionally installed (“npm uninstall -g openclaw”).

Gooding noted, “nothing ran automatically beyond the install,” but added there was still a risk: “OpenClaw is a capable agentic tool with broad system permissions, not a trivial package to have silently dropped onto a developer’s machine.”

A no-win scenario

EDR, managed detection and response (MDR), and other security providers are going to be forced to declare OpenClaw as either a PUA or “flat out as malware, which, honestly, it can be,” said Shipley, or these kinds of attack win.

“I hate to give it to attackers, but you kind of have to on this one,” he said. “This is why agentic AI is going to get so many people pwned.”

Ultimately, it’s a no-win scenario, Shipley noted, particularly if any organization was “so foolish” as to have allowed OpenClaw into their enterprise environment and built business-reliant work processes on it.

As he put it: “Attackers combined the two biggest dumpster fires in 2026 cybersecurity into a city-scale landfill fire by chaining supply chain hacks via npm and the smoking-hot-vibe-coded AI agent disaster of OpenClaw.”

This article originally appeared on CSOonline.

The Electronic Frontier Foundation (EFF) Thursday changed its policies regarding AI-generated code to “explicitly require that contributors understand the code they submit to us and that comments and documentation be authored by a human.”

The EFF policy statement was vague about how it would determine compliance, but analysts and others watching the space speculate that spot checks are the most likely route. 

The statement specifically said that the organization is not banning AI coding from its contributors, but it seemed to do so reluctantly, saying that such a ban is “against our general ethos” and that AI’s current popularity made such a ban problematic. “[AI tools] use has become so pervasive [that] a blanket ban is impractical to enforce,” EFF said, adding that the companies creating these AI tools are “speedrunning their profits over people. We are once again in ‘just trust us’ territory of Big Tech being obtuse about the power it wields.”

The spot check model is similar to the strategy of tax revenue agencies, where the fear of being audited makes more people compliant.

Cybersecurity consultant Brian Levine, executive director of FormerGov, said that the new approach is probably the best option for the EFF.

“EFF is trying to require one thing AI can’t provide: accountability. This might be one of the first real attempts to make vibe coding usable at scale,” he said. “If developers know they’ll be held responsible for the code they paste in, the quality bar should go up fast. Guardrails don’t kill innovation, they keep the whole ecosystem from drowning in AI‑generated sludge.”

He added, “Enforcement is the hard part. There’s no magic scanner that can reliably detect AI‑generated code and there may never be such a scanner. The only workable model is cultural: require contributors to explain their code, justify their choices, and demonstrate they understand what they’re submitting. You can’t always detect AI, but you can absolutely detect when someone doesn’t know what they shipped.”

EFF is ‘just relying on trust’

An EFF spokesperson, Jacob Hoffman-Andrews, EFF senior staff technologist, said his team was not focusing on ways to verify compliance, nor on ways to punish those who do not comply. “The number of contributors is small enough that we are just relying on trust,” Hoffman-Andrews said. 

If the group finds someone who has violated the rule, it would explain the rules to the person and ask them to try to be compliant. “It’s a volunteer community with a culture and shared expectations,” he said. “We tell them, ‘This is how we expect you to behave.’”

Brian Jackson, a principal research director at Info-Tech Research Group, said that enterprises will likely enjoy the secondary benefit of policies such as the EFF’s, which would improve a lot of open source submissions.

Many enterprises don’t have to worry about whether a developer understands their code, as long as it passes an exhaustive list of tests, including functionality, cybersecurity, and compliance, he pointed out. 

“At the enterprise level, there is real accountability, real productivity gains. Does this code exfiltrate data to an unwanted third party? Does the security test fail?” Jackson said. “They care about the quality requirements that are not being hit.” 

Focus on the docs, not the code

The problem of low-quality code being used by enterprises and other businesses, often dubbed AI slop, is a growing concern. 

Faizel Khan, lead engineer at Landing Point, said the EFF decision to focus on the documentation and the explanations for the code, as opposed to the code itself, is the right one. 

“Code can be validated with tests and tooling, but if the explanation is wrong or misleading, it creates a lasting maintenance debt because future developers will trust the docs,” Khan said. “That’s one of the easiest places for LLMs to sound confident and still be incorrect.”

Khan suggested some easy questions that submitters need to be forced to answer. “Give targeted review questions,” he said. “Why this approach? What edge cases did you consider? Why these tests? If the contributor can’t answer, don’t merge. Require a PR summary: What changed, why it changed, key risks, and what tests prove it works.”

Independent cybersecurity and risk advisor Steven Eric Fisher, former director of cybersecurity, risk, and compliance for Walmart, said that what EFF has cleverly done is focus not on the code as much as overall coding integrity.

“EFF’s policy is pushing that integrity work back on the submitter, versus loading OSS maintainers with that full burden and validation,” Fisher said, noting that current AI models are not very good with detailed documentation, comments, and articulated explanations. “So that deficiency works as a rate limiter, and somewhat of a validation of work threshold,” he explained. It may be effective right now, he added, but only until the tech catches up to produce detailed documentation, comments, and reasoning explanation and justification threads.

Consultant Ken Garnett, founder of Garnett Digital Strategies, agreed with Fisher, suggesting that the EFF employed what might be considered a Judo move.

Sidesteps detection problem

EFF “largely sidesteps the detection problem entirely and that’s precisely its strength. Rather than trying to identify AI-generated code after the fact, which is unreliable and increasingly impractical, they’ve done something more fundamental: they’ve redesigned the workflow itself,” Garnett said. “The accountability checkpoint has been moved upstream, before a reviewer ever touches the work.”

The review conversation itself acts as an enforcement mechanism, he explained. If a developer submits code they don’t understand, they’ll be exposed when a maintainer asks them to explain a design decision.

This approach delivers “disclosure plus trust, with selective scrutiny,” Garnett said, noting that the policy shifts the incentive structure upstream through the disclosure requirement, verifies human accountability independently through the human-authored documentation rule, and relies on spot checking for the rest. 

Nik Kale, principal engineer at Cisco and member of the Coalition for Secure AI (CoSAI) and ACM’s AI Security (AISec) program committee, said that he liked the EFF’s new policy precisely because it didn’t make the obvious move and try to ban AI.

“If you submit code and can’t explain it when asked, that’s a policy violation regardless of whether AI was involved. That’s actually more enforceable than a detection-based approach because it doesn’t depend on identifying the tool. It depends on identifying whether the contributor can stand behind their work,” Kale said. “For enterprises watching this, the takeaway is straightforward. If you’re consuming open source, and every enterprise is, you should care deeply about whether the projects you depend on have contribution governance policies. And if you’re producing open source internally, you need one of your own. EFF’s approach, disclosure plus accountability, is a solid template.”

In a bid to ease the adoption of its Kotlin programming language by Java developers, JetBrains has introduced a Java to Kotlin converter extension for Microsoft’s Visual Studio Code editor. Long established as an alternative to Java, Kotlin is widely used in Java spaces such as Android mobile application development.

Introduced February 19, the Java to Kotlin converter extension is downloadable from the Visual Studio Marketplace. Developers using it can convert individual Java files into Kotlin code with a context menu action, reducing the manual effort of migrating legacy codebases or switching languages in the middle of a project. The extension uses the same underlying engine used in JetBrains IDEs and draws on large language models (LLMs) to provide idiomatic conversion suggestions, providing one-click, review-before-you-commit Java to Kotlin migration inside VS Code, according to JetBrains.

Developers can expect a reliable conversion that respects Kotlin idioms and syntax requirements, Alina Dolgikh, Kotlin product manager at JetBrains, said. The extension was developed out of recognition that many developers use VS Code for a variety of projects and tasks, even if JetBrains’s IntelliJ Idea IDE remains the premier IDE for Kotlin, she said.

The Java to Kotlin converter extension gives the following settings to VS Code:

• j2k.provider: The LLM backend to use for the Java to Kotlin conversion. Default: GitHub Copilot.
• j2k.model: The model tag to use with the selected provider. Default: codellama:instruct.
• j2k.ollama.baseUrl: The base URL of the target instance, when the provider selected is Ollama.
• j2k.openRouter.baseUrl: The base URL of the target instance, when the provider selected is OpenRouter.
• j2k.apiKey: The API key to use with the selected provider (stored in VS Code Secrets).

AI agents need skills — specific procedural knowledge — to perform tasks well, but they can’t teach themselves, a new research suggests.

The authors of the research have developed a new benchmark, SkillsBench, which evaluates agentic AI performance on 84 tasks across 11 domains including healthcare, manufacturing, cybersecurity and software engineering.  The researchers looked at each task under three conditions: no skills (agent receives instructions only), with curated skills (provided with a directory, code snippets and resources to help it) and self-generated skills (agent has no skills but is prompted to develop them).

Typical tasks included conducting a security audit of npm dependencies for vulnerabilities, or analyzing differential protein expression in cancer cell line data.

The best performances came from agents with curated skills, which scored an average of 16.2 percentage points higher than agents with no skills, an indication that AI cannot yet do without human intervention. Even so, in 16 out of the 84 tasks human guidance had a negative impact on results.

Performance varied widely across industry sectors, with curated skills having the biggest impact in healthcare tasks, but only a small one for software engineering.

Agents asked to generate their own skills demonstrated no increase in performance, showing that AI still requires some human prompting to get the job done.

This article first appeared on Computerworld.