Much of modern application development depends on APIs. In the past we may have built massive monolithic applications, but modern cloud-native development depends on collections of microservices, linked by APIs that offer everything from remote procedure calls to database operations.

This approach makes applications easier to run, allowing them to scale with user demand. It also makes them more reliable, handling failover in the event of data center outages. But it makes it harder for developers, as agile software development methods break apart those services across teams while also demanding test-driven approaches to code. An application component may be ready to test, but the services it uses might not be finished. The application might also need a third-party API that has associated costs that may not be acceptable during development.

Simulation and proxies

How does a front-end development move forward without working business logic so that developers are still productive, and product and project managers can ensure that parallel developments continue? One possibility is to build on top of mocks, with dummy APIs that simulate the operation of a specific server. Building new mocks can take as much time as building the service, so what’s needed is a quick, easy-to-use service that can provide the necessary tools between client and server and can be built into familiar development tools.

The answer is an API simulator, a generic tool that’s part of your development tools, intercepting network calls, delivering expected responses, testing out your code’s responses to various classes of error, and simulating the types of API management your code may need to work with. If there’s a specification for an API, a simulator can implement it for you so you don’t have to write mocks or spend development budget on subscriptions to third-party APIs before you need to.

A tool like this can work as a true proxy, sitting between a live API and a development environment. It can also inject errors into API responses and simulate throttling so you can add a little chaos into otherwise predictable operations.

Microsoft recently released an updated version of such a tool: Dev Proxy v2.0 (not to be confused with its similarly named Dev Tunnels). It’s a major release, as there are breaking changes. A big release means significant new features and support for the latest .NET release. If you’ve used earlier releases to test out services like the Microsoft Graph APIs, there were issues as the proxy application didn’t deliver results that were consistent with the live service. Where the Graph APIs used RFC 1123 and ISO 8601 date formats, Dev Proxy used your local PC’s own date formats, so if you were in the UK you’d get different results from someone in the US—and neither would be aligned with the actual service outputs.

Getting started with Dev Proxy

You can install the new Dev Proxy release using Windows’ package manager WinGet. This is easier than the manual option (downloading from GitHub and editing the required environment variables by hand) as the install script sets these up for you. As you’re using the Windows command line to run WinGet, restart it once installed to reload your environment without rebooting your PC. Even with WinGet, the first time you run Dev Proxy you’ll need to trust and install its security certificate before letting it through the Windows firewall.

The default configuration works with the useful (and free) JSONPlaceholder service, trapping requests and applying a simulated throttling with a 50% error rate. Microsoft suggests manually sending a GET request to its API, using either PowerShell or a Windows implementation of curl. If you prefer, you can use API tools like Postman to send requests and view responses. Dev Proxy will show either a pass through or an error on the command line.

The key to getting the most out of Dev Proxy is its configuration. You can have several different files and load the one you want to use at startup; you can run different tests with one service or tests for different services. Building a library of tests and sharing them with colleagues is a good idea as it can speed up building tests and provide a set of templates that can adapt to new projects.

There are three parts to a Dev Proxy configuration. The first is common to all configurations and details the schema used for configuration. This needs to be the version for the Dev Proxy release you’re using and a link to the file on GitHub. Next is a list of the plug-ins being used. Finally, the application configuration data: the APIs being watched, the errors being injected, and the rate limit that’s applied to calls. Plug-ins may have their own configuration data that’s applied when the plug-in is loaded.

One key feature of Dev Proxy is that it’s selective. You can let some API calls pass through, apply errors and rate limits to others, and intercept still more, redirecting calls to Dev Proxy-hosted mocks. This flexibility allows you to pick and choose what is tested and how. Finding the APIs to intercept requires using the proxy as a transparent proxy, discovering and recording all requests from a specific process. (You need to specify this, as otherwise Dev Proxy will record all network requests from every application on your PC.)

Armed with a list of URLs, you can now add the tests you want to apply to your code, intercepting requests for specific addresses and delivering mock responses. You first need to load the MockResponsePlugin and give it a list of API calls and the associated responses.

Using plug-ins

Dev Proxy’s plug-in architecture allows you to add additional features to a proxy so you can use much more complex mocks than simple response lists, for example, implementing a basic API for reading and writing to a database or even using an AI API. Others allow you to simulate using authentication or help ensure that you’re using the minimum permissions needed to access confidential and personally identifiable information.

Plug-ins don’t necessarily implement mocks. They can temporarily add telemetry that isn’t normally available to an application. For example, if you’re using it with Azure OpenAI, you can install a plug-in that helps record interactions with what can be an expensive service to use, providing telemetry and recording usage in CSV files for further analysis outside of your development toolkit. The OpenAI telemetry plug-in now also tracks cached tokens, ensuring you can track exactly how its APIs are being used. This helps predict how much token usage will cost in production.

Dev Proxy is a surprisingly powerful tool with a lot of useful features. It seems simple at first, but the combination of its plug-ins and its ability to inject errors and rate limiting into API calls allows you to simulate a wide selection of different API operating modes. Plus, Microsoft publishes instructions for building your own plug-ins. If you need something that isn’t available in the downloaded set, you can write your own.

Using the Dev Proxy Toolkit

If you’re using Visual Studio Code to build your microservices with whatever language or framework you want, you will want to install the Dev Proxy Toolkit. This provides tools for configuring and managing Dev Proxy, as well as installing it if it’s not currently available on your development PC. You can use the toolkit to edit configuration files and use the Visual Studio Code command palette to start, stop, and control the proxy. You can even watch for URLs that you might want to build proxies and mocks for. Other options include a library of JSON snippets to help add specific function to the proxy via its configuration.

If you want to work with GitHub Copilot Agent, there’s even a Model Context Protocol (MCP) server that can be installed alongside the toolkit and the proxy. This provides help while building configurations and can generate new configurations from natural language prompts.

Tools like Dev Proxy are an important part of the modern development tool chain. Distributed application development requires some thought and is hard to build out at a service level. Dev Proxy can be configured to behave differently as you move through the software development life cycle or as other application components are deployed in tests or in production. Add a set of development tools for Visual Studio Code and an MCP server, and you get tools that simplify development and make Dev Proxy an easy choice.

At Open Source Summit Europe in August, the Linux Foundation announced that DocumentDB—a MongoDB-compatible document database built on PostgreSQL—had joined the foundation as a new open source project. This new project, first announced by Microsoft in early 2025, is designed to support developers in deploying databases with their applications quickly and make querying data easier. But this move does make planning around the selection of the document database even harder. There are now more options open to you, so how do you pick the right approach that will suit you now and in the future?

Why choose a document database?

To start with, we’ll look at why you might choose to use a document database over a more traditional relational database. Document databases store data in a format that can be easier to operate using JavaScript Object Notation (JSON). For developers who are not familiar with the intricacies of relational databases or who don’t yet know what data schema they will need over time, using a document database can be faster and more effective in their workflow.

With rapid prototyping and agile development, interest in document databases grew massively. The poster child for this was MongoDB, which currently boasts more than 59,000 customers. Over the past decade, MongoDB has become one of the most popular options for developers who just wanted to get building. Other companies have launched their own document database projects, while MongoDB API-compatible services are also on the market too. The launch of DocumentDB as a Linux Foundation project will open up other new options too.

What infrastructure approach to take now?

There are two decisions to take around databases today—what you choose to run, and how you choose to run it. The latter choice covers a range of different deployment options, from implementing your own instance of a technology on your own hardware and storage, through to picking a database as a service where all the infrastructure is abstracted away and you only see an API. In between, you can look at hosting your own instances in the cloud, where you manage the software while the cloud service provider runs the infrastructure, or adopt a managed service where you still decide on the design but everything else is done for you.

In these circumstances, look at your team and how much time and resources you have available to manage infrastructure, and estimate how much you value your control over that infrastructure as well. On one side, you have the speed of delivery that managed services can provide. On the other, with more control, you can optimize your database to your application’s needs, achieving better performance.

One of the hidden challenges of using cloud services is how much you can be locked into that provider’s way of doing things. You are also beholden to their costs and pricing. If you are not able to migrate your systems away, then you may have to absorb higher costs when your provider raises prices. This can then affect your development strategies, where you have to change your plans based on matters outside your control.

This is partly why more options for running document databases—and MongoDB-compatible database services in particular—have hit the market. MongoDB’s approach to encouraging companies to move to its Atlas cloud service is popular with some, but other companies either can’t or won’t commit to the cloud. Their choice is to carry on with more expensive licenses or find an alternative approach.

What are your options for running document database instances?

While DocumentDB becoming a Linux Foundation project may encourage more migration, it is not the only option available. For organizations that already use MongoDB, shifting to another option can help them retain control over their technology strategy in the future.

The first option is to look at alternative approaches to running MongoDB itself. Alongside MongoDB-compatible APIs, you can choose to run different versions of MongoDB or alternatives to meet your document database needs. For example, you may not want to move to the cloud to run MongoDB Atlas, and it may be cost-prohibitive to stay with MongoDB Enterprise. One approach here is to use MongoDB Community Edition, as this reduces the cost of the license involved. However, this may not cover all the functionality that you need for enterprise-class workloads.

If this is the case, consider an alternative distribution that uses MongoDB but also adds enterprise-class features like backup and security functionality. One example of this is Percona Server for MongoDB, which adds that necessary support and makes functionality available while still being compatible with the SSPL. Using a different distribution offers the most compatibility with existing MongoDB applications while being a sound option for those who want to get started with MongoDB without being specifically tied to MongoDB Atlas or MongoDB Enterprise.

The second migration option is to use a service that is compatible with MongoDB’s API. For some workloads, being compatible with the API will be enough to move to another service with minimal to no impact. This is how DocumentDB works in practice. Whereas DocumentDB’s API is the same as MongoDB, its back-end infrastructure is based on PostgreSQL. Alongside the Linux Foundation DocumentDB project, there are other cloud services that provide compatibility. For example, AWS has a DocumentDB service with MongoDB support, while Microsoft has CosmosDB for MongoDB. Another option is FerretDB, which is an open-source project that replicates the MongoDB drivers and allows them to work on top of PostgreSQL.

The third option is to use an alternative document database. In the world of open source, Apache CouchDB is another document database that works with JSON and can be used for projects. It is particularly useful where applications might run on mobile devices as well as cloud instances; mobile support is a feature that MongoDB has deprecated. However, migrating to CouchDB can involve some changes to the application design. Naturally, the cost of any potential refactoring or re-design should be included in the list of considerations.

To make your choice here, consider how important compatibility with MongoDB is for your applications. If you need to implement the full MongoDB stack, then your best option is to use MongoDB or a drop-in distribution. If you just need compatibility with the APIs or drivers, then you have more options available. If you want or need to run in private cloud environments, the choice is more limited. Approaches like using databases in container environments managed with Kubernetes operators can deliver the equivalent functionality that cloud services offer, while not locking you into specific cloud service providers. This can also fit into a platform engineering model where you can automate the allocation of resources, deployment, and management for those instances over time, too.

The long-term future for MongoDB and document databases

MongoDB is still the most popular NoSQL document database for developers, sitting at #6 in the overall database ranking in the StackOverflow Survey 2025. That popularity won’t drop anytime soon. But there are more options available to run those workloads than ever before. Rather than relying on one company’s investment in the project, there is a whole community now available and invested in developing their own approaches to document databases.

The evolution of the wider technology landscape will also affect the future for document databases. The demand for AI services has increased the value that company data can provide, and turning data into vector embeddings for generative AI projects has in turn led to more document database deployments to support that data. For developers, using document databases to store their company data as vectors makes it easier to manage this data in parallel.

This rise in options should help to cement MongoDB as a technology approach for the long-term future, just as SQL has been adopted and used as a standard for relational databases for more than 50 years. But there are now more approaches to use this approach than ever before, from compatible distributions through to projects that use the APIs or support the drivers while adopting other infrastructure approaches.

All of this innovation demonstrates the continued love for the document database approach, but developers want more options and choice around how they build. The open source community has stepped in to meet those needs, from adopting new distributions to delivering more choice around how to use this approach.

—

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.

It appears Meta has opted to go in a whole new direction in response to this week’s formation by The Linux Foundation of a group called the Agentic AI Foundation (AAIF), designed to help enterprises develop and manage AI agents through a “shared ecosystem of tools, standards and community-driven innovation.”

The group is made up of a who’s-who of the tech industry, ranging from AWS and OpenAI to Google, Microsoft, IBM, and Cisco. The one name missing from the list is Meta, and, according to a Bloomberg article published on Wednesday, there is a reason for that: the firm is working on a new proprietary model, code-named Avocado, that will generate revenue.

Brian Jackson, principal research director at Info-Tech Research Group, said, ”[Meta was] never interested in a truly open source model approach, just an open weights model approach. To really commit to open source, [it] would have to be willing to share its training data and give up control over model governance.”

Weights, he said, “are just the different knobs along the neural pathways that can be tweaked when training a model. Clearly, [Meta] views its training data as a competitive differentiator or sees some other risk in making it public. It also wants to maintain control over the governance of its models in terms of how they can be integrated with other vendors’ platforms.”

Jackson pointed out that, now that it sees that The Linux Foundation is going to better define a standard for truly open source models, Meta realizes it isn’t going to be able to define the space and distribute its model in the way it intended.

Open weights models vs. open source software

Asked whether developing cutting-edge open source models is becoming too expensive for anyone to contemplate doing without some sort of revenue stream, he noted that at AWS re:Invent last week, AWS CEO Matt Garman had some interesting comments about these open weights models in an analyst Q&A session.

Jackson said, “he pointed out that open source software works because the community contributes back to the projects. But with open weights models, only the provider contributes to the release. These business models are too expensive and not a long-term play,” he said, “and providers may eventually have to charge for them.”

Meta, he said, is proving Garman right. “They didn’t really have a clear business model to collect revenue on Meta’s open weights models,” he said. “Perhaps part of their strategy was to commoditize LLMs and undermine the business models of their competitors.”

But the scale of these models, said Jackson, “continues to grow, and competition is pushing AI makers to invest more into training techniques, talent, and infrastructure to support it all. So, Zuckerberg has to pivot and find a way to monetize Meta’s work here. The best way in the industry to do that is to put a gated API on your model and charge a price per token.”

Sanchit Vir Gogia, the chief analyst at Greyhound Research, said Meta’s pivot from open source AI to a closed, monetized model architecture “marks a deliberate departure from the cooperative direction that most of the AI industry is now moving toward. This is not a tactical adjustment. It is a structural shift that signals a different philosophical stance on the future of AI infrastructure.”

Meta positioning itself as ‘self-contained island’

He added that while organizations such as OpenAI, Google, Anthropic, Microsoft, and others are aligning under the Agentic AI Foundation to create open, neutral standards for agent interoperability, Meta is choosing vertical integration and platform control.

This, said Gogia, looks like a shift in how Meta wants to position its AI bets commercially. “The open source chapter, impactful as it was, always had an expiry date once performance demands, infrastructure overheads, and monetization pressure started to close in,” he noted.

Staying competitive at the frontier, he added, “now means keeping optimization in-house, running tighter R&D loops, and owning the entire stack. The move toward a closed model, with Avocado at the centre, tells us Meta no longer sees its AI as fuel for the ecosystem. It sees it as product — something to sell, protect, and scale.”

This shift is not surprising, said Gogia, “but it is consequential. It reshapes how Meta will be perceived by developers, enterprise buyers, and industry partners. Openness earned Meta trust and relevance when it was trying to gain ground. Closing the stack now allows for performance control, monetization levers, and vendor differentiation.”

In addition, he pointed out, “it also isolates Meta from the standards-led coalition building that is defining the next phase of agentic AI. That isolation may serve short-term commercial objectives, but it risks long-term architectural compatibility in a world that is trending toward interoperable intelligence.”

By staying outside of the AAIF framework, the likely result for Meta is architectural fragmentation, he noted. “Enterprises may find that agents developed within Meta’s platforms are functionally incompatible with broader industry patterns. This may benefit Meta’s platform stickiness, but it undermines the broader ecosystem’s push for composability, portability and open orchestration.”

In a world where CIOs are demanding interoperable intelligence, Gogia said, “Meta is positioning itself as a self-contained island. That may serve its own apps and ad systems, but it puts it out of sync with where collaborative infrastructure is heading.”

This article originally appeared on CIO.com.

GitHub has this week implemented the final part of a security upgrade it hopes will make the vast and hugely popular npm Node.js registry more resistant to the growing menace of supply chain compromise.

As it warned it would do two months ago, on December 9, the npm (Node Package Manager) registry finally revoked all ‘classic’ or ‘long-lived’ tokens, which until now could be used to authenticate developer packages without setting an expiration date. Developers must now shift to using either granular access tokens (GATs) with a shorter life and more limited scope, or upgrade to a completely new automated CI/CD publishing pipeline based on OpenID Connect (OIDC) and OAuth 2.0.

The move is a direct response to a recent rise in supply chain attacks, particularly September’s Shai-Hulud worm which successfully backdoored hundreds of packages after compromising developer accounts and tokens.

“Such breaches erode trust in the open source ecosystem and pose a direct threat to the integrity and security of the entire software supply chain,” said GitHub director of security research, Xavier René-Corail, at the time. “They also highlight why raising the bar on authentication and secure publishing practices is essential to strengthening the npm ecosystem against future attacks.”

Developer workload

For developers, the alteration raises two issues: what are the practical effects of the change, and will it boost security as much as claimed?

On the first point, the upgrade is significant: any CI/CD developer hitting npm publish or npm install for a package authenticated using a classic token will from this week on receive a ‘401 Unauthorized’ error. Generating new classic tokens without an expiration date will no longer be possible. Granular tokens with future expiration dates will continue to work until February 3, 2026. After that date, granular tokens will have a maximum lifespan of 90 days, at which point they will have to be rotated.

The amount of extra work all this creates for developers will depend on how many packages are involved and their organization’s size. For larger organizations, assuming they haven’t already done the legwork, this could involve auditing hundreds of packages across multiple teams. Classic tokens in these packages will have to be revoked, and a process will have to be put in place to rotate granular tokens.

Not everyone is convinced that the reform goes far enough, however. Last month, the OpenJS Foundation criticized the maturity of the tokenless OIDC security model that GitHub wants developers to move towards in the long term. Given that attackers often compromise packages after breaking into developer accounts, more emphasis should be put on multi-factor authentication (MFA) security for those accounts, the OpenJS Foundation said.

Currently, npm doesn’t mandate MFA on smaller developer accounts, and OIDC itself imposes no additional MFA stage when publishing packages. In fact, in the case of automated workflows, there is no way to add MFA to the process. And there’s also the issue that some forms of MFA are prone to man-in-the-middle attacks. This means that any authentication method used needs to be able to resist such techniques.

“We’ve seen a clear pattern emerge where threat actors target maintainers of widely used but under-resourced projects,” commented Mitun Zavery, regional vice president for supply chain security company Sonatype.

“The recent compromise of npm packages like Chalk and Debug mirrors what we observed with the XZ Utilities backdoor incident. In both cases, the adversary patiently built trust to gain control, showing that social engineering is now a key stage in supply chain compromise.”

He pointed out that the industry needs to recognize that open-source package management registries such as npm are critical infrastructure and should be resourced accordingly. Additionally, Zavery said, “organizations need to assume compromise is possible and respond by maintaining accurate software bills of materials, monitoring for suspicious dependency changes, and sandboxing builds.”

I’ve written about how coding is so over. AI is getting smarter every day, and it won’t be long before large language models (LLMs) write better code than any human.

But why is coding the one thing that AI agents seem to excel at? The reasons are simple and straightforward. 

At their core, LLMs process text. They take in massive amounts of text, learn the patterns of that text, and then use all of that information to predict what the next word will be in a given sentence. These models take your question, parse it into text tokens, and then use the trillions (quadrillions?) of vectors they have learned to understand the question and give an answer, one word, or token, at a time. It seems wild, but it is literally that simple. An LLM produces its answer one word at a time.

Doing all this ultimately comes down to just a huge amount of vector math—staggering amounts of calculations. Fortunately, GPUs are really good at vector math, and that is why AI companies have an insatiable appetite for GPUs and why Nvidia is the most valuable company in the world right now. It seems weird to me that the technology used to generate amazing video games is the same that produces amazing text answers to our questions.

Code is text

And of course, code is just words, right? In fact, that is one of the basic tenets of coding—it’s all just text. Git is designed specifically to store and manage text, and to understand the differences between two chunks of text. The tool we all work in, an integrated development environment (IDE), is really a glorified text editor with a bunch of bells and whistles attached. Coding is all about words.

In addition to being words, those words are structured consistently and succinctly—much moreso than the words we speak. Most text is messy, but all code by definition has patterns that are easier for an LLM to recognize than natural language. As a result, LLMs are naturally better at reading and writing code. LLMs can quite quickly and easily parse code, detect patterns, and reproduce those patterns on demand.

Code is plentiful

And there is an enormous amount of code out there. Just think of GitHub alone. A back-of-the-envelope calculation says there is around 100 billion lines of open-source code available for training AI. That’s a lot of code. A whole lot of code. 

And if you need an explanation of how code works, there are something like 20 million questions and even more answers on Stack Overflow for AI to learn from. There’s a reason that Stack Overflow is a shell of its former self—we all are asking AI for answers instead of our fellow developers.

Code is verifiable

In addition, code is easily verified. First, does it compile? That is always the big first test, and then we can check via testing if it actually does what we want. Unlike other domains, AI’s code output can be checked and verified fairly easily. 

If you choose to, you can even have your AI write unit and integration tests beforehand, further clarifying and defining what the AI should do. Then, tell your AI to write code that passes the tests. Eventually, AI will figure out that test-driven development is the best path to writing good code and executing on your wishes, and you won’t even have to ask it to do that.

Welcome, Skynet

And finally, code is a great use case for AI agents because developers are generally unafraid of new technology and always seem ready to try out a new tool. This becomes a virtuous circle as AI companies produce coding agents, and developers embrace those coding agents. Software development is a huge part of the economy, and AI companies are strongly incentivized to lean into lucrative markets that are accepting and enthusiastic about using AI agents.

I for one welcome our new coding agent overlords. If there is one area that I’m fine with Skynet taking over, it’s the mundane job of writing structured text that has easily verifiable outcomes. Let the bots grind out code. I’m happy to do the fun part of thinking up and designing new tools and applications.

Python and C share more than it might seem. The reference version of the Python interpreter is written in C, and many of the third-party libraries written for Python wrap C code. It’s also possible to generate C code from Python.

Generating C code with Python has typically involved libraries like Cython, which use type-annotated Python code to generate C extension modules for Python.

A new project, PythoC, takes a different approach. It uses type-hinted Python to programmatically generate C code—but chiefly for standalone use, and with many more compile-time code generation features than Cython has.

PythoC’s makers use the phrase “C level runtime, Python powered compile time” to describe their approach. The project is still in its early phases, but there are enough working features to make it worth a look.

A basic PythoC program

Here’s a simple program adapted from PythoC’s examples:

from pythoc import compile, i32

@compile
def add(x: i32, y: i32) -> i32:
    return x + y

if __name__ == "__main__":
    print(add(10, 20))

To indicate which functions in a module to compile to C, you use PythoC’s @compile decorator, supplying type hints for the result and each parameter. Note that you also need to import PythoC’s own i32 hint, instead of using Python’s native int. This means you’re using machine-native integers and not Python’s arbitrary-size ints.

When you run this program, you’ll get 30 as the output, after a delay. The C code is compiled on the fly each time you execute the program, hence the delay. PythoC doesn’t yet have a mechanism for re-using compiled code when it’s called from Python, the way Cython does.

At first this seems like a pretty big limitation. But it’s actually the point: You can use PythoC as a code generation system for C programs that run independently, rather than C modules imported into Python.

Generating standalone C programs

Here’s a new verson of the same program, with different behaviors.

from pythoc import compile, i32, ptr, i8
from pythoc.libc.stdio import printf

@compile
def add(x: i32, y: i32) -> i32:
    return x + y

@compile
def main(argc: i32, argv: ptr[ptr[i8]]) -> i32:
    printf("%u\n", add(10, 20))

if __name__ == "__main__":
    from pythoc import compile_to_executable
    compile_to_executable()

The first thing you’ll probably notice is the block at the bottom. The compile_to_executable() function is exactly what it sounds like. Call it, and the current module is compiled to an executable of the same name, with all the @compile-decorated functions included.

Another difference is that the main() function now has the same signature as the main() function in a C program. This means the compiled executable will automatically use that as its entry point.

Finally, when you run this program, the generated executable (which shows up in a build subdirectory) doesn’t run automatically; you have to run it yourself. The aim here is to build a standalone C program, indistinguishable from one you wrote by hand in C, but using Python’s syntax.

PythoC’s emulation of C features

With only a few exceptions, PythoC can generate code that fully utilizes C’s feature set and runtime.

You’ve already seen how to use type annotations to indicate primitive data types. You can likewise use the ptr[T] annotation to describe a pointer (also shown above), and use array[T, N] for N-dimensional arrays of type T. You can make structs, unions, and enums by decorating Python classes, and all the usual operators and control-flow operations (except for goto) will work. For switch/case, just use match/case, although fall-through cases aren’t available.

Something else that’s missing is variable-length arrays. In C, this feature is only supported in C11 and beyond, and support for it in compilers is optional, so it’s not surprising PythoC doesn’t support it yet.

Compile-time code generation

It’s possible to use Cython for compile-time code generation, which means you can produce different kinds of C code, or even fall back to Python code, depending on what happens at compile time. But PythoC’s compile-time code generation has abilities Cython lacks.

Here’s an example from PythoC’s documentation:

from pythoc import compile, struct, i32, f64

def make_point(T):
    @struct(suffix=T)
    class Point:
        x: T
        y: T

    @compile(suffix=T)
    def add_points(p1: Point, p2: Point) -> Point:
        result: Point = Point()
        result.x = p1.x + p2.x
        result.y = p1.y + p2.y
        return result

    return Point, add_points

Point_i32, add_i32 = make_point(i32)
Point_f64, add_f64 = make_point(f64)

The make_point(T) function takes in some type annotation (i32, f64), and generates at compile time type-specialized versions of the Point class and add_points functions. The suffix parameter for @compile means “alter the name of the generated object so that the type is used in the name”—so, for example, Point becomes Point_i32 and Point_i64, which in C is one way to distinguish between multiple versions of the same function with a different type signature. It’s also possible to use this in conjunction with runtime dispatch to provide polymorphism.

Memory safety features

The bugs that can spring from C’s manual memory management are gloomily familiar to anyone who uses the language. Cython has memory safety features to address this, but PythoC offers unique type-based features in this vein.

One is a feature called linear types. The linear import lets you generate a “proof,” usually to accompany a memory allocation, that has to be “consumed” when the same memory is deallocated. If you don’t have a matching consume(prf) for each prf=linear(), the PythoC compiler will generate a compile-time error. The documentation for this, linked above, shows how to create simple lmalloc()/lfree() functions to allocate and free memory safely. Nothing says you must us linear types over manually using malloc()/free(), but they can automate much manual checking and centralize it at compile time rather than runtime.

Another type-based safety feature is refinement types. The idea here is that you can define a function to perform a certain kind of check—e.g., for a null pointer—with a boolean result. You can then use the refine() function to pass a value to that function and get back a type specific to that function, refined[func]. This allows the compiler to ensure that type has to be handled in some manner before being returned, and allows common checks (again for things like a non-null pointer) to be handled in a single place in your code. Cython’s type system is mostly for emulating C’s behaviors directly, and so doesn’t include anything like this.

Possible future directions for PythoC

PythoC is still quite new, so its future development is relatively open ended. One possibility is that it could integrate more closely with Python at runtime. For instance, a @cached decorator could compile modules once, ahead of time, and then re-use the compiled modules when they’re called from within Python, instead of being recompiled at each run. Of course, this would also require integration with Python’s existing module build system. While that level of integration might not be part of the project’s aim, it would make PythoC more immediately useful to those integrating C and Python.

If programming were nothing more than taking an idea and turning it into running code, AI-assisted development might fully deliver on its promise. But AI’s ability to transform natural language prompts into runnable software ultimately highlights the importance of non-mechanical aspects of programming.

Rather than reducing or eliminating the human element in software development, AI reveals the human traits that are key to successful projects. One of these is the ability to sense when a piece of software is becoming unmanageable, and to mitigate the damage.

Such discernment differentiates novice and veteran developers. Increasingly, it also differentiates software written by humans from AI-generated code.

What vibe coding is not

By now, most developers know what vibe coding is. Many of us are using it in some part of our everyday workflow. AI-assistance being a part of the software development life cycle went from revolutionary to passé in about a week. It is extraordinary how quickly software developers can absorb shocks to the industry and just keep going.

But some wags keep missing this key factor: Developers are the ones adopting and applying the technology. We can’t be replaced because at the end of the day, we are the ones holding the reins that guide the tools.

The future is AI-empowered development, not AI-replaced developers. The age-old skills that make a good developer valuable become even more important when writing and pushing functioning code gets cheaper. Leave out the developer, and you just get mountains of technical debt.

You think requirements are easy?

The big idea in AI-driven development is that now we can just build applications by describing them in plain English. The funny thing is, describing what an application does is one of the hardest parts of software development; it’s called requirements gathering.

Anyone who has spent time defining requirements knows it’s a real swampland. It’s full of “I’ll know it when I see it,” which really means, “I’ll know that’s not it when I see it.” Bridging between the technical programming and end-user fit is notoriously hard to do. Good developers are the ones who can walk between those two worlds.

But now we are riding a vibe. A vibe, in this case, is an unwritten requirement. It is always changing—and with AI, we can keep manifesting these whims at a good clip. But while we are projecting our intentions into code that we don’t see, we are producing hidden effects that add up to masses of technical debt. Eventually, it will all come back to bite us.

What developers actually do

AI researcher Gary Marcus recently posted an article on Substack, Is vibe coding dying?, where he referenced a comment from a disillusioned AI coder:

I just want to say that I am giving up on creating anything anymore. I was trying to create my little project, but every time there are more and more errors and I am sick of it. I am working on it for about 3 months, I do not have any experience with coding and was doing everything through AI (Cursor, ChatGPT etc.). But everytime I want to change a liiiiitle thing, I kill 4 days debugging other things that go south.

So I do not have any more energy in me to work on this. It is hopeless. AI is still just soooooo stupid and it will fix one thing but destroy 10 other things in your code. I am really sad, because I was enjoying it in the beginnings but now it is just pain and rage. Hat down for those people, who can create something and it is working without coding knowledge.

The reason this quote is so perfect will be clear to most software developers. This is a non-coder who believes their project failed due to their inexperience and use of AI. But developers know the “I changed X, and way over there in Y and X something broke” is a classic pitfall of software development.

Software is a bizarrely interrelated complex of things, like a quantumly entangled system. Managing this madness is a big part of what successful software developers get paid to do.

Vibe coding and technical debt

Don’t get me wrong: I appreciate the unbridled creativity that can be found in just riding a vibe on an AI platform. If you haven’t already tried it, I suggest sitting down with Roo Code and seeing how it feels to blast out working software with just a few keystrokes.

At first, vibe coding is intoxicating. You can rapidly produce all the basic application infrastructure without even thinking about it. It’s like driving a 4×4 that sails over speed bumps. Pretty soon, though, you will find yourself off-roading in the ravines of wack-a-mole fix-and-break, like the above user did. Suddenly, that landscape of magically functional code becomes a yawning chasm of technical debt that you have to figure out. And if you don’t have the coding background to understand what you’re up against, you will drown in it.

Sure, you can try using AI to fix the things that are breaking, but have you tried it? Have you ever been stuck with an AI assistant confidently running you and your code around in circles? Even with something like Gemini CLI and DevTools integration (where the AI has access to the server and client-side outputs) it can so easily descend into a maddening cycle. In the end, you are mocked by your own unwillingness to roll up your sleeves and do some work.

It’s certainly one of the strangest experiences I’ve had with a computer: relying on my own hard-won instincts to ferret out root problems the AI itself obscures.

Be careful how you use it

Some might be tempted to accuse me of being anti-AI, which is not true. I love AI for coding. I’d even say (and have said) it brings back some of the joy and sense of possibility of the early days of the Internet. By dealing with a lot of the formality of coding, AI brings more ambitious ideas and efforts into scope. It lets developers spend more time in the zone of creativity.

If I had to choose one thing that is the most compelling about AI-coding, it would be the ability to quickly scale from nothing. The moment when I get a whole, functioning something based on not much more than an idea I described? That’s a real thrill.

Weirdly, AI also makes me feel less alone at times; like there is another voice in the room.

If in the end that is what we mean by “vibe coding,” I’m all for it. I like to be in the flow just as much as anyone else. The key is to be in the flow without unwittingly amassing junkyards of bad code. At the end of the day, AI will magnify whatever we put into it. It’s like trading a handsaw for a chainsaw: Better be careful how you use it.

The balancing act hasn’t changed

Programming has always been part engineering and part craft. A good software developer brings together these two parts in one mind. Modern AI helps with both the creative and mechanical aspects of software development, but a human is still needed to unite them with understanding.

The balancing act of software development hasn’t changed; it is just operating at a higher order with AI.

Many enterprises use GitHub Action Secrets to store and protect sensitive information such as credentials, API keys, and tokens used in CI/CD workflows. These private repositories are widely assumed to be safe and locked down.

But attackers are now exploiting that blind trust, according to new research from the Wiz Customer Incident Response Team. They found that threat actors are using exposed GitHub Personal Access Tokens (PATs) to access GitHub Action Secrets and sneak into cloud environments, then run amok.

“The root cause issue is the presence of these secrets in repos,” said David Shipley of Beauceron Security. “Cloud service provider access keys are gold, they can be extraordinarily long lived, and that’s what [attackers are] sniffing around for.”

GitHub Action Secrets aren’t secrets anymore

Wiz estimates that 73% of organizations using private GitHub Action Secrets repositories store cloud service provider (CSP) credentials within them. When PATs, which allow developers and automation bots to interact with GitHub repositories and workflows, are exploited, attackers can easily move laterally to CSP control planes.

PATs can become a “powerful springboard” that allows attackers to impersonate developers and carry out a range of activities, explained Erik Avakian, technical counselor at Info-Tech Research Group. It’s like having a backstage pass into a company’s cloud environments, he said.

“Once they’re holding that valid PAT, they can do all sorts of things in GitHub that lead directly back into a company’s AWS, Azure, GCP, or other types of cloud services, because GitHub treats that PAT like the real developer,” he said.

With that access, threat actors can “poke around” various repositories and workflows and look for anything that hints at cloud access, configuration items, scripts, and hidden secrets, he noted. If they get access to real cloud credentials, they “have the keys to the company’s AWS bucket, Azure subscriptions, and other workflows.”

They can then spin up cloud resources, access databases, steal source code, install malicious files such as crypto miners, sneak in malicious workflows, or even pivot to other cloud services, while setting up persistence mechanisms so they can return whenever they want.

“At that point, basically anything you can do in the cloud, so can they,” said Avakian.

Easily evading detection

Wiz found that a threat actor with basic read permissions via a PAT can use GitHub’s API code search to discover secret names embedded directly in a workflow’s yaml code, accessed via “${{ secrets.SECRET_NAME }}.”

The danger is that this secret discovery method is difficult to monitor because search API calls are not logged. Further, GitHub-hosted Actions run from GitHub-managed resources that use legitimate, shared IP addresses not flagged as malicious. Attackers can abuse secrets, impersonate workflow origins to exploit trust, and potentially access other resources if code is misconfigured or reused elsewhere in the workflows. They can also persistently access the system.

In addition, if the exploited PAT has write permissions, attackers can execute malicious code and remove workflow logs and runs, pull requests, and ‘created branches’ (isolated copies of codebases for dev experimentation). Because workflow logs are rarely streamed into security incident and event management (SIEM) platforms, attackers can easily evade detection.

Also, notably, a developer’s PAT with access to a GitHub organization makes private repositories vulnerable; Wiz research found that 45% of organizations have plain-text cloud keys stored privately, while only 8% are in public repositories.

Shipley noted: “In some developers’ minds, a private repo equals safe, but it’s clearly not safe.”

How enterprise leaders can respond

To protect themselves against these threats, enterprises should treat PATs as they would any other privileged credentials, Avakian noted. Cloud infrastructure and cloud development environments should be properly locked down, essentially “zero trustifying” them through micro segmentation and privileged user management to contain them and prevent lateral pivoting.

“Like any other credentials, tokens are best secured when they have reasonable expiration dates,” said Avakian. “Making tokens expire, rotating them, and using short-lived credentials will help thwart these types of risks.”

Least privilege everything and give accounts only the rights they need, rather than an ‘admin everything’ approach, Avakian advised. More importantly, move cloud secrets out of GitHub workflows and ensure that the proper amount of monitoring and log review processes are in place to flag surprise or unexpected workflow or cloud creation events.

Beauceron’s Shipley agreed, saying that enterprises need a multi-pronged strategy, good monitoring, instant response plans, and developer training processes that are reinforced with “meaningful consequences” for non-compliance. Developers must be motivated to follow secure coding best practices; building a strong security culture in developer teams is huge. “You can’t buy a blinky box for that part of the problem,” he said.

“Criminals have stepped up their game,” said Shipley. “Organizations don’t have a choice. They have to invest in these areas, or they will pay.”

Also, stop blindly trusting GitHub repos, he added. “The nature of repos is that they live forever. If you don’t know if you have cloud secrets inside your repos, you need to go and find them. If they’re there, you need to change them yesterday, and you need to stop adding new ones.”

If there is an upside, he noted, it’s that enterprises are “victims of their own success” as they’ve raised the bar with multi-factor authentication (MFA). Gains in general security awareness makes it more difficult for criminals to obtain access and identities and compromise systems.

“In some ways, this is a good sign,” said Shipley. “In a hilarious kind of way, it means [the criminals] are now moving into deeper levels requiring more effort.”

The Linux Foundation has announced the formation of the Agentic AI Foundation (AAIF), which is intended to provide a neutral, open foundation to ensure that agentic AI evolves transparently and collaboratively.

Announced December 9, the AAIF is anchored by founding contributions including Anthropic’s Model Context Protocol, an open protocol for integrating LLM applications and external data sources and tools; Block’s goose, an AI coding agent; and OpenAI’s AGENTS.md, an open format for guiding coding agents. These inaugural projects lay the groundwork for a shared ecosystem of tools, standards, and community-driven innovation, according to the Linux Foundation. “Bringing these projects together under the AAIF ensures they can grow with the transparency and stability that only open governance provides,” said Linux Foundation Executive Director Jim Zemlin in a statement.

Founding AAIF members include Amazon Web Services, Anthropic, Bloomberg, Cloudflare, Google, IBM, JetBrains, Microsoft, OpenAI, and Salesforce. The advent of agentic AI represents a new era of autonomous decision-making and coordination across AI systems that will transform and revolutionize entire industries, the Linux Foundation said.

AWS kicked off re:Invent 2025 with a defensive urgency that is unusual for the cloud leader, arriving in Las Vegas under pressure to prove it can still set the agenda for enterprise AI.

With Microsoft and Google tightening their grip on CIOs’ mindshare through integrated AI stacks and workflow-ready agent platforms, AWS CEO Matt Garman and his lieutenants rolled out new chips, models, and platform enhancements, trying to knit the updates into a tighter pitch that AWS can still offer CIOs the broadest and most production-ready AI foundation.

Analysts remain unconvinced that AWS succeeded.

“We are closer, but not done,” said David Linthicum, independent consultant and retired chief cloud strategy officer at Deloitte.

Big swing but off target

Garman’s biggest swing, at least the one that got it “closer”, came in the form of Nova Forge,  a new service with which AWS is attempting to confront one of its strategic weaknesses: the absence of a unified narrative that ties data, analytics, AI, and agents into a single, coherent pathway for enterprises to adopt.

It’s this cohesion that Microsoft has been selling aggressively to CIOs with its recently launched IQ set of offerings.

Unlike Microsoft’s IQ stack, which ties agents to a unified semantic data layer, governance, and ready-made business-context tools, Nova Forge aims to provide enterprises raw frontier-model training power in the form of a toolkit to build custom models with proprietary data, rather than a pre-wired, workflow-ready AI platform.

But it still requires too much engineering lift to adopt, analysts say.

AWS is finally positioning agentic AI, Bedrock, and the data layer as a unified stack instead of disconnected services, but according to Linthicum, “It’s still a collection of parts that enterprises must assemble.”

There’ll still be a lot of work for enterprises wanting to make use of the new services AWS introduced, said Phil Fersht, CEO of HFS Research.

“Enterprise customers still need strong architecture discipline to bring the parts together. If you want flexibility and depth, AWS is now a solid choice. If you want a fully packaged, single-pane experience, the integration still feels heavier than what some competitors offer,” he said.

Powerful tools instead of turnkey solutions

The engineering effort needed to make use of new features and services echoed across other AWS announcements, with the risk that they will confuse CIOs rather than simplify their AI roadmap.

On day two of the event, Swami Sivasubramanian’s announced new features across Bedrock AgentCore, Bedrock, and SageMaker AI to help enterprises move their agentic AI pilots to production, but still focused on providing tools that accelerate tasks for developers rather than offering “plug-and-play agents” by default, Linthicum said.

The story didn’t change when it came to AWS’s update to vibe-coding tool Kiro or the new developer-focused agents it introduced to simplify devops, said Paul Nashawaty, principal analyst at The Cube Research.

“AWS clearly wants to line up against Copilot Studio and Gemini Agents. Functionally, the gap is closing,” said Nashawaty. “The difference is still the engineering lift. Microsoft and Google simply have tighter productivity integrations. AWS is getting there, but teams may still spend a bit more time wiring things together depending on their app landscape.”

Similarly, AWS made very little progress toward delivering a more unified AI platform strategy. Analysts had looked to the hyperscaler to address complexity around the fragmentation of its tools and services by offering more opinionated MLops paths, deeper integration between Bedrock and SageMaker, and ready-to-use patterns that help enterprises progress from building models to deploying real agents at scale.

Linthicum was dissatisfied with efforts by AWS to better document and support the connective tissue between Bedrock, SageMaker, and the data plane. “The fragmentation hasn’t vanished,” he said. “There are still multiple ways to do almost everything.”

The approach taken by AWS contrasts sharply with those of Microsoft and Google to present more opinionated end-to-end stories, Linthicum said, calling out Azure’s tight integration around Fabric and Google’s around its data and Vertex AI stack.

Build or buy?

For CIOs who were waiting to see what AWS delivered before finalizing their enterprise AI roadmap, they are back at a familiar fork: powerful primitives versus turnkey platforms.

They will need to assess whether their teams have the architectural discipline, MLops depth, and data governance foundation to fully capitalize on AWS’s latest additions to its growing modular stack, said Jim Hare, VP analyst at Gartner.

“For CIOs prioritizing long-term control and customization, AWS offers unmatched flexibility; for those seeking speed, simplicity, and seamless integration, Microsoft or Google may remain the more pragmatic choice in 2026,” Hare said.

The decision, as so often, comes down to whether the enterprise wants to build its AI platform or just buy one.

This article first appeared on CIO.com.

Download the December 2025 issue of the Enterprise Spotlight from the editors of CIO, Computerworld, CSO, InfoWorld, and Network World.

Amazon’s Nova 2 announcement at AWS re:Invent 2025 is exactly the type of AI offering we expected from AWS and, frankly, exactly what should make thoughtful architects nervous. Nova 2 is positioned as a frontier-grade model, tightly integrated with Amazon Bedrock. It’s part of a growing ecosystem of “frontier agents” and the AgentCore framework unveiled at re:Invent 2025. The story is compelling: better models, better tools, and a single platform to build, deploy, and scale agentic AI.

And yet, there’s a problem. It isn’t that Nova 2 is technically weak. The problem is that it is strategically strong in all the wrong ways for customers who care about independence, portability, and long-term value. AWS is not just selling you a model; the company is selling you an entire worldview where your agentic fabric, data flows, and operational patterns are deeply rooted in one cloud.

Vendor lock-in versus actual value

Lock-in is a spectrum, and the ecosystem of Nova 2, Bedrock, and AgentCore pushes you far toward the “tightly coupled” end of that spectrum. On paper, you get convenience: native integrations, managed infrastructure, observability, and security primitives that understand the agentic constructs AWS has defined. In practice, you are anchoring the core of your emerging AI capability into APIs, runtimes, and orchestration semantics that exist only within AWS.

The question I want enterprises to ask is simple: Are you optimizing for the next six quarters or the next six years? It’s likely that during the next six quarters, Nova 2 and its ecosystem will make you more productive. But during the next six years, the cost of migrating away from this ecosystem—or even meaningfully using a second cloud for AI—will rise dramatically. Your agents will be written to AWS’s tool APIs, observability model, security posture, and the way AWS wires agents to data and events. That is not theoretical lock-in; it is baked into every line of code and every workflow you build.

If you view AI as a transient experiment, this may not bother you. If you believe, as I do, that agentic systems will become the operational nervous system of most enterprises, then concentrating that critical capability inside a single vendor’s ecosystem is a strategic risk, not a feature.

Agentic fabric: native versus portable

The notion of an “agentic fabric” is useful: a mesh of agents that can reason, act, and collaborate across data sources, applications, and infrastructure. AWS’s vision is a cloud-native fabric where agents are first-class citizens inside services like Bedrock, wired to Lambda, Step Functions, EventBridge, and a growing set of AI-ready data services. The fabric is smooth—as long as you stay inside their walls.

The alternative is a cloud-portable fabric. Instead of building directly against closed, vendor-specific agent frameworks, you define agents in terms of more open abstractions: model-agnostic interfaces, cross-cloud orchestration, and data access layers that do not assume a particular vendor’s storage or event model. You might still run agents on AWS, but you can also run them on other clouds, on-premises, or at the edge without rewriting them from scratch.

Nova 2 and the surrounding tools tilt you hard toward cloud-native and away from cloud-portable. When your agents depend on AWS-specific features—say, Bedrock’s proprietary agent orchestration primitives or AWS-only plug-in patterns—your portability story collapses. The cost to move is not just “change the model endpoint”; it becomes “re-implement how the agent thinks, acts, and integrates.” That type of cost kills multicloud strategies in practice, even when they look good on PowerPoint.

Operational burden or simplification

AWS is selling Nova 2 and AgentCore as simplifying complexity and, in some respects, that is true. You get unified observability, integrated security, and pre-packaged patterns for building safe, production-grade agents. But let’s be very clear about what is happening. AWS is not removing complexity, it is encapsulating it inside black boxes you do not control.

When those black boxes malfunction, drift, or change, you are at the mercy of AWS’s release cadence and operational practices. You will still need teams who understand the behavior of your agents in detail, but you will be diagnosing problems in systems whose core behavior is defined by a vendor’s code and policies, not your own. That is a different kind of fragility. Instead of owning complexity you can see and manage, you’re renting complexity and hoping it behaves.

On top of that, operations teams now have to understand not only distributed cloud-native systems, but emergent, probabilistic agent behavior embedded within them. If your observability, governance, and control mechanisms are all bound to AWS-specific services, you lose the ability to build a unified operations view across clouds and on-prem systems. AWS wants to be your single pane of glass, but the reality is that most large enterprises need several panes, and those panes must interoperate.

Taking the long view

When you adopt Nova 2 and its ecosystem as your primary agentic platform, you are choosing a vertically integrated stack. The immediate upsides are undeniable: optimized performance, deep integrations, turnkey security patterns, and less glue code. For many teams, particularly those that are small, under-resourced, or deeply aligned with AWS already, this is a rational short-term decision.

But the downsides show up over time, and they show up at the architectural level, not in developer convenience. You lose leverage on pricing as your dependence on AWS-specific agent capabilities grows. You will find it harder to adopt innovations that emerge on other clouds or in open source communities, because your systems are built around a specific model of agents and tools. You will discover that “multicloud” has devolved into “one primary cloud for anything that matters and some residual workloads elsewhere,” which is exactly the outcome the big clouds are optimizing for.

If you want more open and portable approaches, you pay more up front. You build or adopt neutral orchestration layers, use frameworks that abstract model providers, and design observability that spans heterogeneous environments. You resist the gravitational pull of single-vendor AI fabrics, even when they look impressively polished. The payoff is flexibility: the ability to change direction when economics, regulation, or innovation demand it, without rewriting the nervous system of your enterprise.

When I reviewed Amazon Q Developer in 2024, I noted that it was able to generate whole functions in common programming languages with only a few fixes. It was useful for completing lines of code, doc strings, and if/for/while/try code blocks as you type. It could also scan for vulnerabilities and help you fix code problems. However, it could not generate full functions for some use cases, but instead reverted to line-by-line suggestions.

At the time, Amazon Q Developer was “powered by Amazon Bedrock” and trained on “high-quality AWS content.” I never knew what the first really meant, but that’s now moot: Amazon Q Developer now gives you a choice of Claude Sonnet versions, including 4.5, which is competitive with GPT-5 Codex.

At this point, completing lines of code qualifies as a “gimme,” the equivalent of a two-foot putt in golf. Generating whole functions is easy, generating complex applications is moderately difficult, and fixing reported bugs in large repositories ranges from moderately difficult to difficult.

Some of the current differentiators for coding agents are their ability to call tools (e.g. read files, run applications, show edit diffs, and understand Git and GitHub) and their ability to define and use Model Context Protocol (MCP) servers. MCP servers are tools that allow AI models to interact with external services, such as databases, APIs, and enterprise systems, using a standard, unified protocol. Another differentiator is the ability to run tools and projects in an isolated environment.

At risk of giving away the punch line, Amazon Q Developer supports tools, supports MCP servers but makes it harder than necessary to configure them, and doesn’t have the best implementation of isolated cloud environments. It’s still useful, however, and we can only hope that AWS will fill in the obvious gaps.

Amazon Q Developer competes with Google Jules, OpenAI Codex Cloud and OpenAI Codex CLI, Claude Code, Windsurf, Augment Code, Amp, Cline, Zencoder, and Gemini CLI. The current Amazon Q Developer versions as of this writing are Plug-in 1.104.0 and CLI 1.19.6.

Amazon Q Developer in editors

Amazon Q Developer runs in JetBrains IDEs, Visual Studio Code, Visual Studio, Eclipse, and the command line (CLI). By the way, the Q CLI has been rebranded as Kiro CLI with a version bump to 1.20; one change from the Q CLI / Kiro CLI I’ve been testing is the addition of an “auto” model option.

Amazon Q Developer generates real-time code suggestions ranging from snippets to full functions based on your comments and existing code. It also supports inline chat directly in the code editor, and CLI completions and natural language to Bash translation in the command line. Q Developer can write unit tests, optimize code, and scan for vulnerabilities. If you enable agentic coding, Q Developer can perform tasks on your behalf by reading and writing files, generating code diffs, and running shell commands, while incorporating your feedback and providing real-time updates along the way.

You can use chat and inline chat for any programming language. Inline code suggestions work best with C, C++, C#, Dart, Go, Java, JavaScript, Kotlin, Lua, PHP, PowerShell, Python, R, Ruby, Rust, Scala, Shell, SQL, Swift, SystemVerilog, TypeScript, CDK (TypeScript, Python), HCL (Terraform), JSON, and YAML. The chat works in at least 13 natural languages and automatically responds in the language you use for your query. This is a major improvement over last year’s language capabilities.

Foundry

Testing Amazon Q Developer Chat

To compare Amazon Q Developer Chat with Codex Chat I tried essentially the same prompt to create a command-line program to calculate pi.

Generate a C++ program to calculate the value of pi to the number of decimal digits specified in the command line. Make sure the program will be accurate to at least 1000 digits. Use the algorithm that is most efficient at run-time, regardless of the amount of code required. Save the program in the AmazonQ folder.

I used the Claude Sonnet 4.5 model, which I expected to do well on this task. Amazon Q Developer responded with the following.

I'll create a C++ program using the Chudnovsky algorithm, which is one of the fastest known algorithms for calculating π. It uses the GMP library for arbitrary precision arithmetic.
Creating the AmazonQ directory if it doesn't exist
Creating the C++ program that uses the Chudnovsky algorithm for calculating pi to arbitrary precision
Creating a Makefile to simplify compilation of the pi calculator
Creating a README with build and usage instructions
I've created a C++ program that calculates π using the Chudnovsky algorithm, which is one of the most efficient algorithms for computing π (converges at ~14 digits per iteration).
Files created in 
/Users/martinheller/Code/AmazonQ/:
• pi_calculator.cpp
 - Main program using GMP for arbitrary precision
• Makefile
 - For easy compilation
• README.md
 - Build and usage instructions
To use:
1.	Install GMP: brew install gmp
2.	Build: make
3.	Run: ./pi_calculator 1000 (for 1000 digits)
The program accurately handles 1000+ digits and uses the fastest known algorithm for runtime efficiency.

That sounded more promising than Codex’s first try, but it didn’t compile. For background, you should know that GMP has both C and C++ libraries; I only installed the C library, but Amazon Q Developer didn’t know that. I asked it to fix the build bug after highlighting that output, but it didn’t take the context. No matter, it still fixed the problem:

Let me try to build it first to see the specific error:
Attempting to build the program to identify the specific build error
Removing the unnecessary gmpxx.h include and fixing the C constant calculation
Removing -lgmpxx from the Makefile since we don't need the C++ wrapper
Building the program again to verify the fix works
Testing the program with 100 digits to verify it works correctly
Testing the program with the correct path
Running the pi calculator to verify it works
Fixed. The build issue was the missing 
gmpxx.h header. I removed the unnecessary C++ wrapper include and simplified the constant calculation. The program now builds and runs correctly, calculating π to the specified precision.

I asked Amazon Q Developer Chat to time the program for 100 and 10,000 digits so that I could compare the efficiency with the MPFR/GMP implementation that Codex generated on its second try. Unsurprisingly, the calculation was a lot slower for 10,000 digits. I asked Q Developer how it might make this calculation more efficient for very high numbers of digits.

Yes, there are several optimizations for very high digit counts:
1. Binary Splitting - The most significant optimization. Instead of computing terms sequentially, recursively split the sum into halves and combine. This reduces complexity from O(n²) to O(n log n) for n terms.
2. Use MPFR instead of GMP - MPFR is optimized for floating-point operations and has better performance for transcendental functions.
3. Avoid Redundant Factorial Calculations - Your current code recalculates factorials from scratch each iteration. Binary splitting naturally avoids this.
4. Memory Management - Reuse mpz_t variables instead of allocating/deallocating in loops.
5. Parallel Computation - For extremely large calculations (millions of digits), parallelize the binary split recursion.
I can see you already have a more optimized version in 
Code/Codex/pi_mpfr.cpp that uses binary splitting with MPFR. That implementation will be significantly faster for large digit counts (10,000+).

Oops. I didn’t mean to leave that file open where Amazon Q Developer could see it. Nevertheless, Q Developer/Claude Sonnet 4.5 answered correctly for all five points.

Foundry

Testing the Amazon Q Developer CLI

Before testing the Amazon Q Developer CLI (again) I checked its menu bar icon drop-down for updates. It was already up-to-date. Then I ran q in iTerm2 and asked it for help information.

Foundry

For a first test I changed to the Cline rep directory, started the Q CLI, switched Q to the claude-sonnet-4.5 model (from the default 4.0), and asked it to explain the current repository.

Foundry

Then I repeated the experiment to have Q explain the amazon-q-developer-cli repository.

Foundry

Next, I cloned the websocket repository from my own fork of the project, switched to that directory, ran the Q CLI, switched to the claude-sonnet-4.5 model, and asked Q to pick an open issue in the websocket repo and fix it in a new branch. Q struggled a bit with some of the issues, but found a problem with the chat example that it was able to fix.

Foundry

I had to push the branch to my GitHub repository myself:

martinheller@Mac websocket % git push
fatal: The current branch fix-chat-example-checkorigin has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin fix-chat-example-checkorigin

To have this happen automatically for branches without a tracking
upstream, see 'push.autoSetupRemote' in 'git help config'.

martinheller@Mac websocket % git push --set-upstream origin fix-chat-example-checkorigin
Enumerating objects: 9, done.
Counting objects: 100% (9/9), done.
Delta compression using up to 12 threads
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 686 bytes | 137.00 KiB/s, done.
Total 5 (delta 4), reused 0 (delta 0), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (4/4), completed with 4 local objects.
remote:
remote: Create a pull request for 'fix-chat-example-checkorigin' on GitHub by visiting:
remote:      https://github.com/meheller/websocket/pull/new/fix-chat-example-checkorigin
remote:
To https://github.com/meheller/websocket.git
 * [new branch]      fix-chat-example-checkorigin -> fix-chat-example-checkorigin
branch 'fix-chat-example-checkorigin' set up to track 'origin/fix-chat-example-checkorigin'.
martinheller@Mac websocket %

I didn’t create a pull request for the upstream gorilla/websocket repo that I had forked from, since that repo hadn’t changed in eight months, which tells me that the repo is inactive.

Amazon Q Developer CLI with claude-sonnet-4.5 didn’t do as good a job on this task as Codex Cloud. Codex Cloud operated directly on the GitHub repository and was able to fix a bug that Sonnet misunderstood and skipped.

I looked at the GitHub blame view for the new branch of my fork of websocket. The fix is in lines 38 through 40.

Foundry

Amazon Q Developer agentic and MCP capabilities

The Amazon Q Developer CLI (newly renamed Kiro CLI) currently has the following built-in tools available to agents:

• fs_read – Read files, directories, and images
• fs_write – Create and edit files
• execute_bash – Execute shell commands
• use_aws – Make AWS CLI API calls
• knowledge – Store and retrieve information across sessions
• introspect – Provide information about Q CLI capabilities

In the built-in default agent, only fs_read can run without asking permission, but all tools are available, as well as legacy MCP servers. You can define your own agents, and set a default agent.

In addition, you can define and use MCP servers and tools, both in the CLI and the IDE. Oddly, the Amazon Q Developer plug-in for VS Code does not use any of the MCP or extensive tool capabilities of VS Code. Instead, it and the Q CLI / Kiro CLI use their own JSON MCP configuration files, which look about the same as Claude’s and the MCP specification’s config files. (If you’re interested, you can find the MCP specification here.)

Like Claude Code, the Q CLI / Kiro CLI has text commands to manage MCP server configurations; the Amazon Q Developer editor plug-ins have forms for that. Both require you to know the command that invokes the MCP server, but you can look that up for public MCP servers. The MCP standards organization maintains a registry of public MCP servers; so do GitHub (also here) and Anthropic (Claude).

Amazon Q Developer productivity effects

According to AWS, their internal developers have improved productivity using Q both quantitatively and qualitatively. One huge win was to ingest their internal Amazon knowledge repository (millions of documents) into Amazon Q Business so that developers could get answers based on information spread across those repositories. They reported “we reduced the time Amazon developers spent waiting for technical answers by over 450k hours and reduced the interruptions to ‘flow state’ of existing team members.”

AWS also unlocked “possibilities for large-scale technical modernization that previously seemed impractical,” which “fundamentally changed how [they] think about technical debt and system modernization.” Another effect was reducing the time to learn new languages and codebases. “One developer reported cutting their typical three-week ramp-up time for learning a new programming language down to just one week using Q Developer.”

With the Amazon Q Developer CLI agent, another internal developer was able to work with an unfamiliar codebase to build and implement a non-trivial feature within two days using Rust, a programming language they didn’t know, stating, “If I’d done this ‘the old fashioned way,’ I would estimate it would have taken me five to six weeks due to language and codebase ramp up time. More realistically, I wouldn’t have done it at all, because I don’t have that kind of time to devote.”

Amazon Q Developer on AWS

AWS notes that Amazon Q Developer is an expert on AWS. Q is available in the AWS Management Console (and in Microsoft Teams and Slack) to help optimize users’ cloud costs and resources, provide guidance on architectural best practices, investigate operational incidents, and diagnose and resolve networking issues. Of course, it’s easy for AWS to train its own model on its own documentation, procedures, best practices, and APIs. It might be a bit harder for customers.

Amazon Q Developer .NET porting and Java upgrades

Amazon Q Developer has agents that can help port .NET code from Windows to Linux, and help upgrade code from Java 8 to Java 17. These agents have upgraded more than 1,000 production Java applications, according to AWS.

Amazon Q Developer, data, and AI

In addition to straight code, Amazon Q Developer knows about data integration workflows. It can generate ETL scripts, troubleshoot errors, translate natural language to SQL queries, and work with data across 20+ data sources. It probably doesn’t hurt that AWS offers 20+ data sources as paid services. Q Developer can help you build machine learning models and also reduce the time to build, train, evaluate, and deploy AI models in SageMaker Studio.

Amazon Q Developer pricing

The Amazon Q Developer perpetual Free Tier gives you 50 agentic chat interactions per month. You can also transform up to 1,000 lines of code per month. The Pro Tier has expanded limits for $19 per month per user. I was able to perform this review using the free tier.

Conclusion

Amazon Q Developer has improved significantly over the last year. I can certainly recommend it to AWS customers. The free tier was good enough for me, but if I was using it all day, every day I’d most likely have to upgrade to the pro tier.

IBM has agreed to acquire cloud-native enterprise data streaming platform Confluent in a move designed to expand its portfolio of tools for building AI applications

The company said Monday in a release that it sees Confluent as a natural fit for its hybrid cloud and AI strategy, adding that the acquisition is expected to “drive substantial product synergies” across its portfolio.

Confluent connects data sources and cleans up data. It built its service on Apache Kafka, an open-source distributed event streaming platform, sparing its customers the hassle of buying and managing their own server clusters in return for a monthly fee per cluster, plus additional fees for data stored and data moved in or out. 

IBM expects the deal, which it valued at $11 billion, to close by the middle of next year.

Confluent CEO and co-founder Jay Kreps stated in an email sent internally to staff about the acquisition, “IBM sees the same future we do: one in which enterprises run on continuous, event-driven intelligence, with data moving freely and reliably across every part of the business.”

It’s a good move for IBM, noted Scott Bickley, an advisory fellow at Info-Tech Research Group. “[Confluent] fills a critical gap within the watsonx platform, IBM’s next-gen AI platform, by providing the ability to monitor real-time data,” he said, and is based on the industry standard for managing and processing real-time data streams. 

He added, “IBM already has the pieces of the puzzle required to build and train AI models; Confluent provides the connective tissue to saturate those models with continuous live data from across an organization’s entire operation, regardless of the source. This capability should pave the road ahead for more complex AI agents and applications that will be able to react to data in real time.”

Bickley also pointed out that the company is playing the long game with this acquisition, which is its largest in recent history. “IBM effectively positions itself proactively to compete against the AI-native big data companies like Snowflake and Databricks, who are all racing towards the same ‘holy grail’ of realizing AI agents that can consume, process, and react to real-time data within the context of their clients’ trained models and operating parameters,” he said, adding that IBM is betting that a full-stack vertical AI platform, watsonx, will be more appealing to enterprise buyers than a composable solution comprised of various independent components.

It is a deal that works for both parties.

The move, he noted, also complements previous acquisitions such as the $34.5 billion acquisition of Red Hat and the more recent $6.4 billion acquisition of Hashicorp, all of which are built upon dominant open source standards including Linux, Terraform/Vault, and Kafka. This allows IBM to offer a stand-alone vertical, hybrid cloud strategy with full-stack AI capabilities apart from the ERP vendor space and the point solutions currently available.

In addition, said Andrew Humphreys, senior director analyst at Gartner, with IBM MQ, IBM already competes with Confluent in the event broker market, the underpinning technology for event driven architectures. “Although there is some overlap, IBM MQ and Kakfa address different use cases and problems for customers, so IBM has the opportunity to bring these offerings together to deliver a comprehensive set of event broker offerings that address the full breadth of event driven architecture use cases,” he said.

Vital layer in the watsonx stack filled

Mitch Ashley, VP and practice lead at Futurum Research, noted that the acquisition of Confluent fills a vital layer in the watsonx stack and gives IBM an open source-based backbone for real time, governed data in motion. It also aligns IBM’s recent data acquisitions into a coherent architecture. “The value here is not just Kafka as a technology, but the ability to deliver fresh, contextual data into every part of IBM’s AI portfolio with consistency and control,” he said.

The acquisition, wrote Sanchit Vir Gogia, the chief analyst at Greyhound Research, in a report released soon after the purchase was announced, “marks a turning point that has little to do with price tags or portfolio expansion. What it truly reveals is a change in who controls the lifeblood of modern digital enterprises. That lifeblood is real-time data.”

It is not a tactical buy, he noted, it’s the strategic completion of an architecture years in the making. “For enterprise leaders, this changes the map,” he predicted. “AI no longer sits at the edge of architecture. It moves to the center, and Confluent becomes the layer that makes that center responsive, contextual, and live. This acquisition allows IBM to deliver AI that doesn’t just predict, but listens, grounded in data that is clean, connected, and always in motion.”

Added Stephen Catanzano, senior analyst, data & AI with Omdia, “all the major players are really building end to end data platforms at this point. … This is data in motion, so it really fills out the gap that [IBM] have to manage both moving data and static data, unstructured and structured.”

“People really want to apply generative AI and agentic AI with moving data and streaming data. And they (IBM) took the biggest player off the market,” he said.

In addition to all this, Bickley said, the timing was right in that Confluent has been experiencing a slowing of revenue growth and was reportedly shopping itself already.

“At the end of the day, this deal works for both parties,” he said. “IBM is now playing a high-stakes game and has placed its bet that having the best AI models is not enough; it is the control of the data flow that will matter.”

This story originally appeared on CIO.com.

Java Development Kit (JDK) 26, a planned update to standard Java due March 17, 2026, has reached an initial rampdown phase for bug fixes, with the feature set now frozen. 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 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 and latency 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.

The R language for statistical computing has creeped back into the top 10 in Tiobe’s monthly index of programming language popularity.

In the December 2025 index, published December 7, R ranks 10th with a 1.96% rating. R has cracked the Tiobe index’s top 10 before, such as in April 2020 and July 2020, but not in recent years. The rival Pypl Popularity of Programming Language Index, meanwhile, has R ranked fifth this month with a 5.84% share.

“Programming language R is known for fitting statisticians and data scientists like a glove,” said Paul Jansen, CEO of software quality services vendor Tiobe, in a bulletin accompanying the December index. “As statistics and large-scale data visualization become increasingly important, R has regained popularity.”

Jansen noted that R is sometimes frowned upon by “traditional” software engineers due to an unconventional syntax and limited scalability for large production systems. But for domain experts R remains a powerful and elegant tool, and continues to thrive at universities and in research-driven industries, he added. Although data science rival Python has eclipsed R in terms of general adoption, Jansen said R has carved out a solid and enduring niche, excelling at rapid experimentation, statistical modeling, and exploratory data analysis.

“We have seen many Tiobe index top 10 entrants rising and falling,” Jansen wrote. “It will be interesting to see whether R can maintain its current position.”

The Tiobe Programming Community Index bases language popularity on a formula that assesses the number of skilled engineers worldwide, courses, and third-party vendors pertinent to a language. Popular websites including Google, Amazon, Wikipedia, Bing, and more than 20 others are used to calculate its ratings.

The Tiobe index top 10 for December 2025:

1. Python, 23.64%
2. C, 10.11%
3. C++, 8.95%
4. Java, 8.7%
5. C#, 7.26%
6. JavaScript, 2.96%
7. Visual Basic, 2.81%
8. SQL, 2.1%
9. Perl, 1.97%
10. R, 1.96%

The Pypl index analyzes how often language tutorials are searched on Google. The Pypl index top 10 for December 2025:

1. Python, 26.91%
2. C/C++, 13.02%
3. Objective-C, 11.37%
4. Java, 11.36%
5. R, 5.84%
6. JavaScript, 5.16%
7. Swift, 3.53%
8. C#, 3.18%
9. PHP, 2.98%
10. Rust, 2.6%

A security flaw in the widely-used Apache Tika XML document extraction utility, originally made public last summer, is wider in scope and more serious than first thought, the project’s maintainers have warned.

Their new alert relates to two entwined flaws, the first CVE-2025-54988 from August, rated 8.4 in severity, and the second, CVE-2025-66516 made public last week, rated 10.

CVE-2025-54988 is a weakness in the tika-parser-pdf-module used to process PDFs in Apache Tika from version 1.13 to and including version 3.2.1.  It is one module in Tika’s wider ecosystem that is used to normalize data from 1,000 proprietary formats so that software tools can index and read them.

Unfortunately, that same document processing capability makes the software a prime target for campaigns using XML External Entity (XXE) injection attacks, a recurring issue in this class of utility.

In the case of CVE-2025-54988, this could have allowed an attacker to execute an External Entity (XXE) injection attack by hiding XML Forms Architecture (XFA) instructions inside a malicious PDF.

Through this, “an attacker may be able to read sensitive data or trigger malicious requests to internal resources or third-party servers,” said the CVE. Attackers could exploit the flaw to retrieve data from the tool’s document processing pipeline, exfiltrating it via Tika’s processing of the malicious PDF.

CVE superset

The maintainers have now realized that the XXE injection flaw is not limited to this module. It affects additional Tika components, namely Apache Tika tika-core, versions 1.13 to 3.2.1, and tika-parsers versions 1.13 to 1.28.5. In addition, legacy Tika parsers versions 1.13 to 1.28.5 are also affected.

Unusually – and confusingly – this means there are now two CVEs for the same issue, with the second, CVE-2025-66516, a superset of the first. Presumably, the reasoning behind issuing a second CVE is that it draws attention to the fact that people who patched CVE-2025-54988 are still at risk because of the additional vulnerable components listed in CVE-2025-66516.

So far, there’s no evidence that the XXE injection weakness in these CVEs is being exploited by attackers in the wild. However, the risk is that this will quickly change should the vulnerability be reverse engineered or proofs-of-concept appear.

CVE-2025-66516 is rated an unusual maximum 10.0 in severity, which makes patching it a priority for anyone using this software in their environment. Users should update to Tika-core version 3.2.2, tika-parser-pdf-module version 3.2.2 (standalone PDF module), or tika-parsers versions 2.0.0 if on legacy.

However, patching will only help developers looking after applications known to be using Apache Tika. The danger is that its use might not be listed in all application configuration files, creating a blind spot whereby its use is not picked up. The only mitigation against this uncertainty would be for developers to turn off the XML parsing capability in their applications via the tika-config.xml configuration file.

This article originally appeared on CSOonline.

Enterprises are testing AI in all sorts of applications, but too few of their proofs of concept (PoCs) are making into production: just 12%, according to an IDC study.

Amazon Web Services is concerned about this too, with VP of agentic AI Swami Sivasubramanian devoting much of his keynote speech to it at AWS re:Invent last week.

The failures are not down to lack of talent or investment, but how organizations plan and build their PoCs, he said: “Most experiments and PoCs are not designed to be production ready.”

Production workloads, for one, require development teams to deploy not just a handful of agent instances, but often hundreds or thousands of them simultaneously — each performing coordinated tasks, passing context between one another, and interacting with a sprawling web of enterprise systems.

This is a far cry from most PoCs, which might be built around a single agent executing a narrow workflow.

Another hurdle, according to Sivasubramanian, is the complexity that agents in production workloads must contend with, including “a massive amount of data and edge cases”.  

This is unlike PoCs which operate in artificially clean environments and run on sanitized datasets with handcrafted prompts and predictable inputs — all of which hide the realities of live data, such as inconsistent formats, missing fields, conflicting records, and unexpected behaviours.

Then there’s identity and access management. A prototype might get by with a single over-permissioned test account. Production can’t.

“In production, you need rock-solid identity and access management to authenticate users, authorize which tools agents can access on their behalf, and manage these credentials across AWS and third-party services,” Sivasubramanian said.

Even if those hurdles are cleared, the integration of agents into production workloads still remains a key challenge.

“And then of course as you move to production, your agent is not going to live in isolation. It will be part of a wider system, one that can’t fall apart if an integration breaks,” Sivasubramanian said.

Typically, in a PoC, engineers can manually wire data flows, push inputs, and dump outputs to a file or a test interface. If something breaks, they reboot it and move on. That workflow collapses under production conditions: Agents become part of a larger, interdependent system that cannot fall apart every time an integration hiccups.

Moving from PoC to production

Yet Sivasubramanian argued that the gulf between PoC and production can be narrowed.

In his view, enterprises can close the gap by equipping teams with tooling that bakes production readiness into the development process itself, focusing on agility while still being accurate and reliable.

To address concerns around the agility of building agentic systems with accuracy, AWS added an episodic memory feature to Bedrock AgentCore, which lifts the burden of building custom memory scaffolding off developers.

Instead of expecting teams to stitch together their own vector stores, summarization logic, and retrieval layers, the managed module automatically captures interaction traces, compresses them into reusable “episodes,” and brings forward the right context as agents work through new tasks.

In a similar vein, Sivasubramanian also announced the serverless model customization capability in SageMaker AI to help developers automate data prep, training, evaluation, and deployment.

This automation, according to Scott Wheeler, cloud practice leader at AI and data consultancy firm Asperitas, will remove the heavy infrastructure and MLops overhead that often stall fine-tuning efforts, accelerating agentic systems deployment.

The push toward reducing MLops didn’t stop there. Sivasubramanian said that AWS is adding Reinforcement Fine-Tuning (RFT) in Bedrock, enabling developers to shape model behaviour using an automated reinforcement learning (RL) stack.

Wheeler welcomed this, saying it will remove most of the complexity of building a RL stack, including infrastructure, math, and training-pipelines.

SageMaker HyperPod also gained checkpointless training, which enables developers to accelerate the model training process.

To address reliability, Sivasubramanian said that AWS is adding Policy and Evaluations capabilities to Bedrock AgentCore’s Gateway. While Policy will help developers enforce guardrails by intercepting tool calls, Evaluations will help developers simulates real-world agent behavior to catch issues before deployment.

Challenges remain

However, analysts warn that operationalizing autonomous agents remains far from frictionless.

Episodic memory, though a conceptually important feature, is not magic, said David Linthicum, independent consultant and retired chief cloud strategy officer at Deloitte. “It’s impact is proportional to how well enterprises capture, label, and govern behavioural data. That’s the real bottleneck.”

“Without serious data engineering and telemetry work, it risks becoming sophisticated shelfware,” Linthicum said.

He also found fault with RFT in Bedrock, saying that though the feature tries to abstract complexity from RL workflows, it doesn’t remove the most complex parts of the process, such as defining rewards that reflect business value, building robust evaluation, and managing drift.

“That’s where PoCs usually die,” he said.

It is a similar story with the model customization capability in SageMaker AI.

Although it collapses MLOps complexity, it amplified Linthicum’s and Wheeler’s concerns in other areas.

“Now that you have automated not just inference, but design choices, data synthesis, and evaluation, governance teams will demand line-of-sight into what was tuned, which data was generated, and why a given model was selected,” Linthicum said.

Wheeler said that industry sectors with strict regulatory expectations will probably treat the capability as an assistive tool that still requires human review, not a set-and-forget automation: “In short, the value is real, but trust and auditability, not automation, will determine adoption speed,” he said.

The pace at which large language models (LLMs) evolve is making it virtually impossible to keep up. Allie Miller, for example, recently ranked her go-to LLMs for a variety of tasks but noted, “I’m sure it’ll change next week.” Why? Because one will get faster or come up with enhanced training in a particular area. What won’t change, however, is the grounding these LLMs need in high-value enterprise data, which means, of course, that the real trick isn’t keeping up with LLM advances, but figuring out how to put memory to use for AI.

If the LLM is the CPU, as it were, then memory is the hard drive, the context, and the accumulated wisdom that allows an agent to usefully function. If you strip an agent of its memory, it is nothing more than a very expensive random number generator. At the same time, however, infusing memory into these increasingly agentic systems also creates a new, massive attack surface.

Most organizations are treating agent memory like a scratchpad or a feature behind an SDK. We need to start treating it as a database—and not just any database, but likely the most dangerous (and potentially powerful) one you own.

The soft underbelly of agentic AI

Not long ago, I argued that the humble database is becoming AI’s hippocampus, the external memory that gives stateless models something resembling long-term recall. That was before the current wave of agentic systems really hit. Now the stakes are higher.

As my colleague Richmond Alake keeps pointing out in his ongoing “agent memory” work, there is a crucial distinction between LLM memory and agent memory. LLM memory is really just parametric weights and a short-lived context window. It vanishes when the session ends. Agent memory is different. It is a persistent cognitive architecture that lets agents accumulate knowledge, maintain contextual awareness, and adapt behavior based on historical interactions.

Alake calls the emerging discipline “memory engineering” and frames it as the successor to prompt or context engineering. Instead of just stuffing more tokens into a context window, you build a data-to-memory pipeline that intentionally transforms raw data into structured, durable memories: short term, long term, shared, and so on.

That may sound like AI jargon, but it is really a database problem in disguise. Once an agent can write back to its own memory, every interaction is a potential state change in a system that will be consulted for future decisions. At that point, you are not tuning prompts. You are running a live, continuously updated database of things the agent believes about the world.

If that database is wrong, your agent will be confidently wrong. If that database is compromised, your agent will be consistently dangerous. The threats generally fall into three buckets:

Memory poisoning. Instead of trying to break your firewall, an attacker “teaches” the agent something false through normal interaction. OWASP (Open Worldwide Application Security Project) defines memory poisoning as corrupting stored data so that an agent makes flawed decisions later. Tools like Promptfoo now have dedicated red-team plug-ins that do nothing but test whether your agent can be tricked into overwriting valid memories with malicious ones. If that happens, every subsequent action that consults the poisoned memory will be skewed.

Tool misuse. Agents increasingly get access to tools: SQL endpoints, shell commands, CRM APIs, deployment systems. When an attacker can nudge an agent into calling the right tool in the wrong context, the result looks indistinguishable from an insider who “fat-fingered” a command. OWASP calls this class of problems tool misuse and agent hijacking: The agent is not escaping its permissions; it is simply using them for the attacker’s benefit.

Privilege creep and compromise. Over time, agents accumulate roles, secrets, and mental snapshots of sensitive data. If you let an agent assist the CFO one day and a junior analyst the next, you have to assume the agent now “remembers” things it should never share downstream. Security taxonomies for agentic AI explicitly call out privilege compromise and access creep as emerging risks, especially when dynamic roles or poorly audited policies are involved.

New words, old problems

The point is not that these threats exist. The point is that they are all fundamentally data problems. If you look past the AI wrapper, these are exactly the things your data governance team has been chasing for years.

I’ve been suggesting that enterprises are shifting from “spin up fast” to “get to governed data fast” as the core selection criterion for AI platforms. That is even more true for agentic systems. Agents operate at machine speed with human data. If the data is wrong, stale, or mislabelled, the agents will be wrong, stale, and will misbehave much faster than any human could manage.

“Fast” without “governed” is just high-velocity negligence.

The catch is that most agent frameworks ship with their own little memory stores: a default vector database here, a JSON file there, a quick in-memory cache that quietly turns into production later. From a data governance perspective, these are shadow databases. They often have no schema, no access control lists, and no serious audit trail.

We are, in effect, standing up a second data stack specifically for agents, then wondering why no one in security feels comfortable letting those agents near anything important. We should not be doing this. If your agents are going to hold memories that affect real decisions, that memory belongs inside the same governed-data infrastructure that already handles your customer records, HR data, and financials. Agents are new. The way to secure them is not.

Revenge of the incumbents

The industry is slowly waking up to the fact that “agent memory” is just a rebrand of “persistence.” If you squint, what the big cloud providers are doing already looks like database design. Amazon’s Bedrock AgentCore, for example, introduces a “memory resource” as a logical container. It explicitly defines retention periods, security boundaries, and how raw interactions are transformed into durable insights. That is database language, even if it comes wrapped in AI branding.

It makes little sense to treat vector embeddings as some distinct, separate class of data that sits outside your core database. What’s the point if your core transactional engine can handle vector search, JSON, and graph queries natively? By converging memory into the database that already holds your customer records, you inherit decades of security hardening for free. As Brij Pandey notes, databases have been at the center of application architecture for years, and agentic AI doesn’t change that gravity—it reinforces it.

Yet, many developers still bypass this stack. They spin up standalone vector databases or use the default storage of frameworks like LangChain, creating unmanaged heaps of embeddings with no schema and no audit trail. This is the “high-velocity negligence” I mentioned above. The solution is straightforward: Treat agent memory as a first-class database. In practice this means:

Define a schema for thoughts. You typically treat memory as unstructured text, but that’s a mistake. Agent memory needs structure. Who said this? When? What is the confidence level? Just as you wouldn’t dump financial records into a text file, you shouldn’t dump agent memories into a generic vector store. You need metadata to manage the life cycle of a thought.

Create a memory firewall. Treat every write into long-term memory as untrusted input. You need a “firewall” logic layer that enforces schema, validates constraints, and runs data loss prevention checks before an agent is allowed to remember something. You can even use dedicated security models to scan for signs of prompt injection or memory poisoning before the data hits the disk.

Put access control in the database, not the prompt. This involves implementing row-level security for the agent’s brain. Before an agent helps a user with “level 1” clearance (a junior analyst), it must be effectively lobotomized of all “level 2” memories (the CFO) for that session. The database layer, not the prompt, must enforce this. If the agent tries to query a memory it shouldn’t have, the database should return zero results.

Audit the “chain of thought.” In traditional security, we audit who accessed a table. In agentic security, we must audit why. We need lineage that traces an agent’s real-world action back to the specific memory that triggered it. If an agent leaks data, you need to be able to debug its memory, find the poisoned record, and surgically excise it.

Baked-in trust

We tend to talk about AI trust in abstract terms: ethics, alignment, transparency. Those concepts matter. But for agentic systems operating in real enterprises, trust is concrete.

We are at the stage in the hype cycle where everyone wants to build agents that “just handle it” behind the scenes. That is understandable. Agents really can automate workflows and applications that used to require teams of people. But behind every impressive demo is a growing memory store full of facts, impressions, intermediate plans, and cached tool results. That store is either being treated like a first-class database or not.

Enterprises that already know how to manage data lineage, access control, retention, and audit have a structural advantage as we move into this agentic era. They do not have to reinvent governance. They only have to extend it to a new kind of workload.

If you are designing agent systems today, start with the memory layer. Decide what it is, where it lives, how it is structured, and how it is governed. Then, and only then, let the agents loose.

Today’s AI coding agents are impressive. They can generate complex multi-line blocks of code, refactor according to internal style, explain their reasoning in plain English, and more. However, AI agents will take you only so far unless they also can interface with modern devops tools.

This is where the Model Context Protocol (MCP) comes in. MCP is a proposed universal standard for connecting AI assistants with external tools and data. Interest has heated up since the protocol’s debut in late November 2024, with major tech companies rallying MCP support within new releases, alongside strong community interest.

For devops, MCP gives AI agents new abilities across common operations: Git version control, continuous integration and delivery (CI/CD), infrastructure as code (IaC), observability, accessing documentation, and more. By linking natural language commands to multi-step, back-end processes, MCP essentially enables “chatops 2.0.”

Below, we’ll explore official MCP servers that have emerged across popular devops tools and platforms, offering a cross-section of servers that cater to different devops capabilities. Most are straightforward to configure and authorize within MCP-compatible, AI-assisted development tools that support remote servers, like Claude Code, GitHub Copilot, Cursor, or Windsurf.

GitHub MCP server

It’s rare to meet a developer who doesn’t use GitHub in some form or fashion. As such, GitHub’s official MCP server is quickly becoming a popular way for AI agents to interact with code repositories.

GitHub’s remote MCP server exposes a range of tools that let agents perform repository operations, create or comment on issues, open or merge pull requests, and retrieve project metadata on collaborators, commits, or security advisories.

It also includes endpoints for CI/CD management through GitHub Actions. For example, a command like “cancel the current running action” could invoke the cancel_workflow_run tool within the GitHub Actions tool set.

Compared to other MCP servers, GitHub’s server offers unusually rich capabilities that mirror the APIs of the GitHub platform. However, for safety, you can always configure a --read-only flag to prevent agents from performing mutations.

Notion MCP server

Although not strictly devops at its core, Notion has become commonplace for team visibility across disciplines. For devops, the official Notion MCP server can help agents surface relevant notes and process documentation.

For instance, you could instruct an agent to reference internal style guides or operational runbooks stored in Notion, or issue a command like “Add a page titled ‘MCP servers we use’ under the page ‘DevOps’,” which would trigger a corresponding action through Notion’s API.

You can call Notion’s remote MCP server from your IDE, or build it locally and run it using the official Docker image. Notion’s MCP can be treated as a low-risk server as it has configurable scopes and tokens for managing Notion pages and blocks.

Atlassian Remote MCP server

Another interesting MCP server is the Atlassian Remote MCP server, which connects IDEs or AI agent platforms with Atlassian Cloud products such as Jira, the project management tool, and Confluence, the collaboration platform.

Atlassian’s MCP server, documented here, lets external AI tools interface with Jira to create, summarize, or update issues. It can also retrieve or reference Confluence pages and chain together related actions through the MCP client, like retrieving documentation from Confluence before updating a linked Jira issue.

You could imagine telling an agent, “Update my Jira issue on user testing for the payments app based on this latest bug report,” and pointing it to relevant logs. The server would then handle the update within Jira.

Currently in beta and available only to Atlassian Cloud customers, the Atlassian MCP server supports many MCP-compatible clients and uses OAuth 2.1 authorization for secure access.

Argo CD MCP server

The Argo CD MCP server is developed by Akuity, the original creators of Argo CD, the popular open-source CI/CD tool that powers many Kubernetes-native GitOps workflows. The MCP server wraps calls to the Argo CD API, and provides tools that allow users of AI assistants to interact with Argo CD in natural language.

Akuity’s MCP server has two main tools for applications (the deployments Argo CD manages) and resources (the underlying Kubernetes objects). The application management tool lets agents retrieve application information, create and delete applications, and perform other operations. The resource management tool allows agents to retrieve resource information, logs, and events for specific applications, and run actions on specific resources.

Using the Argo CD MCP server, you can do a lot of the same things you’d typically do in the Argo CD UI or CLI, but driven by natural language. For example, Akuity shares sample prompts such as “Show me the resource tree for guestbook” or “Sync the staging app.”

For such commands to work, you’ll need to integrate the Argo CD MCP server and have access to a running Argo CD instance with the proper credentials configured.

Lastly, although Argo CD is a popular choice, it’s not the only widely used CI/CD tool. Jenkins users may be interested to know that there is a community-maintained MCP Server Plugin for Jenkins.

Grafana MCP server

Grafana, the popular data visualization and monitoring tool, is a mainstay among devops and site reliability teams. Using the official MCP server for Grafana, agents can surface observability data to inform development and operations workflows.

The Grafana MCP server lets agents query full or partial details from dashboards, which combine system performance metrics and health data monitoring from various sources. It can also fetch information on data sources, query other monitoring systems, incident details, and more.

The tool set is configurable, so you can choose what permissions the agent has. Plus, Grafana has optimized how the MCP server structures responses to minimize context window usage and reduce runaway token costs.

For example, an MCP client might call the get_dashboard_property tool to retrieve a specific portion of a dashboard by its UID.

Terraform MCP server

Although alternatives have emerged, HashiCorp’s Terraform remains a leading choice for infrastructure as code. That makes its official MCP server an intriguing option for AI agents to generate and manage Terraform configurations.

The Terraform MCP server integrates with both the Terraform Registry APIs and Terraform Enterprise/HCP services, allowing agents to query module and provider metadata, inspect workspace states, and trigger runs with human approval. It also exposes Terraform resources such as runs, registries, providers, policies, modules, variables, and workspaces.

For example, a command like “generate Terraform code for a new run” could use the create_run operation, after which the agent might validate and plan the configuration before applying it.

The Terraform MCP server ships with an AGENTS.md file, which acts as a readme for agents to interpret tools. At the time of writing, the Terraform MCP is intended only for local use, rather than remote or hosted deployments.

Alternatively, if you’re using OpenTofu for IaC, consider checking out the OpenTofu MCP server. Some advantages of OpenTofu’s MCP are that it can be run locally or deployed in the cloud, it’s globally distributed on Cloudflare Workers, and it’s 100% open source.

GitLab MCP server

Another Git version control and devops platform is GitLab, which offers an MCP server for its Premium and Ultimate customers. The GitLab MCP server, currently in beta, enables AI agents to gather project information and perform operations on GitLab APIs in a secure way.

The GitLab MCP server allows some state changes, such as creating issues or merge requests. The other functions are mainly for data retrieval: retrieving information on issues, merge requests, commits, diffs, and pipeline information. It also includes a general search tool, which can handle a request like “Search issues for ‘failed test’ across GitLab.”

GitLab’s MCP documentation is thorough, with plenty of sample natural language expressions that the MCP server can satisfy. The server supports OAuth 2.0 Dynamic Client Registration.

Snyk MCP server

Snyk, maker of the Snyk security platform for developers, provides an MCP server with the ability to scan and fix vulnerabilities in code, open source dependencies, IaC code, containers, and software bill of materials (SBOM) files. It also supports creating an AI bill of materials (AIBOM) and other security-related operations.

For AI-assisted devsecops, integrating the Snyk MCP server could let an agent automatically run security scans as part of a CI/CD workflow. These scans can even be orchestrated across other MCP servers, like fetching repository details via the GitHub MCP server before initiating a Snyk scan.

A prompt like “Scan the repo ‘Authentication Microservice’ for security vulns” could instruct an agent to locate the repository using GitHub MCP, then invoke Snyk tools such as snyk_sca_scan or snyk_code_scan to identify known vulnerabilities, injection flaws, leaked credentials, and other risks.

The Snyk MCP server runs locally and uses the Snyk CLI to execute these commands through authenticated API calls. Snyk does not offer a hosted, remote version of the MCP server.

AWS MCP servers

The cloud hyperscalers have worked quickly to release MCP servers that integrate with their ecosystems. AWS, for instance, has rolled out dozens of specialized AWS MCP servers to allow AI agents to interact with all manner of AWS services. Some are provided as fully managed services by AWS, while others can be run locally.

For instance, the Lambda Tool MCP server allows agents to list and invoke Lambda functions, while the AWS S3 Tables MCP server could be used by an agent to query S3 table buckets or create new S3 tables from CSV files. The AWS Knowledge MCP server connects agents with all of the latest AWS documentation, API references, and architectural guidance.

A query to this knowledge server, like “pull up the API reference for AWS’s managed Prometheus tool” would correspond with the correct up-to-date information, optimized for agentic consumption.

Users of Microsoft Azure might want to evaluate the Azure DevOps MCP server. Other clouds, like Alibaba, Cloudflare, and Google, are currently experimenting with MCP servers as well.

Pulumi MCP server

Pulumi, another popular option for IaC, has also launched an official MCP server. The MCP server allows agents to query a Pulumi organization’s registry, which provides access to cloud resources and infrastructure, and execute Pulumi commands.

For example, in this walk-through, Pulumi shows how a developer could use its MCP server to provision an Azure Kubernetes Service (AKS) cluster. The developer issues natural-language instructions to an AI assistant, prompting the AI to execute MCP tools that invoke Pulumi CLI commands.

MCP caveats

Just as vibe coding isn’t a fit for every project, MCP isn’t the best option for every use case either. According to MCP experts, these servers can be unnecessary when they sidestep standard CLIs.

They can also introduce major security risks. This tracks with AI use in general, as 62% of IT leaders cite security and privacy risks as the top AI concern, according to the AI in DevOps report by Enterprise Management Associates (EMA).

As such, it’s best to test out these MCP servers with low-risk permissions, like read-only capabilities, before testing write functions. And use them only with trusted LLMs and trusted MCP clients.

Also, beware of exposing high-value, long-lived privileges to MCP clients. Because AI coding agents are based on nondeterministic LLMs, their behavior can be unpredictable. Throw in autonomous control over mutable devops functions, and you could land in all kinds of trouble, ranging from broken deployments to runaway token usage.

Lastly, using the official MCPs above, as opposed to community-supported libraries, will probably guarantee longer longevity and ongoing maintenance, too.

Early MCP success stories

Although it’s still early days with MCP and agents, there’s a sense of cautious optimism as proven MCP workflows emerge.

Take Block’s journey. Through company-wide use of its MCP-compatible agent, Goose, 12,000 employees are now utilizing agents and MCP for “increasingly creative and practical ways to remove bottlenecks and focus on higher-value work,” writes Angie Jones, head of developer relations.

Other engineers report using MCP servers to enhance workflows that are devops-adjacent, like the Filesystem MCP server for accessing local files, the Linear MCP server for issue tracking, the Chrome DevTools MCP server for browser debugging, and the Playwright MCP server for continuous testing.

And beyond the official MCP servers mentioned above, many community-supported MCPs are emerging for Docker, Kubernetes, and other cloud-native infrastructure utilities.

Devops comes with toil and cost. So, the case to level it up with MCP is strong. As long as you keep controls safe, it should be fun to see how these MCP servers integrate into your work and impact your productivity. Happy MCP-opsing.