Author: Mark Silvester

Pulumi now allows developers to use Terraform modules directly, without converting them first. This preview feature allows Pulumi programs written in TypeScript, Python, Go, C# or Java to consume Terraform modules as-is, removing one of the key barriers to adoption.

Writing in the announcement post, Pulumi engineer Anton Tayanovskyy said the feature “addresses one of the most significant challenges our users face when migrating from Terraform to Pulumi” particularly for teams with deep investments in Terraform modules. He explained that it “gives you the best of both worlds: the ability to start new projects in Pulumi immediately while preserving your existing Terraform modules until you’re ready to migrate them”.

Support is provided through the pulumi package add terraform-module command, available from CLI version 3.178.0. Under the hood, Pulumi wraps Terraform’s execution engine using the terraform-module provider. This allows infrastructure defined in .tf modules to behave like native Pulumi components, while still integrating with Pulumi’s state backend, secrets management and automation workflows.

Enterprise accounts lead Dipali Patel described the announcement as a turning point, writing on LinkedIn that “Pulumi just made your Terraform life way easier,” and calling it “the ultimate ‘no excuses’ moment to start modernising your Infra as Code, without the pain of a full rewrite.” Her comments highlight a recognition among teams of the value in tooling that supports gradual transitions over all-or-nothing migrations.

The official Pulumi LinkedIn account echoed that message, stating the new functionality solves “one of the biggest challenges in migrating complex infrastructure.” Pulumi has positioned itself as a platform that allows developers to work in general-purpose languages without giving up compatibility with existing tools and ecosystems.

The feature remains in preview, and Pulumi has been clear about its limitations. The GitHub documentation notes that “Terraform modules have insufficient metadata to precisely identify the type of every module output,” and recommends overriding inferred types manually where needed. Feedback is actively encouraged as the company works to improve compatibility and stability.

Pulumi’s support for Terraform modules mirrors similar features in other widely used tools. CDK for Terraform allows infrastructure to be defined in TypeScript, Python, Java, C# or Go while using existing Terraform modules from the Terraform Registry. Terragrunt also supports referencing remote Terraform modules, helping teams manage shared infrastructure configurations more easily. By enabling direct module support, Pulumi aligns with this broader trend of integrating with Terraform ecosystems rather than replacing them.

The feature allows Pulumi to interoperate more easily with existing Terraform code, offering teams a way to incorporate familiar modules while exploring Pulumi’s language-based approach. It is intended to support gradual adoption without requiring full migration up front.

Microsoft has released the Azure DevOps Model Context Provider (MCP) Server in public preview.

The release enables GitHub Copilot to access and interact with Azure DevOps project data using natural language prompts within developer environments such as VS Code.

The MCP Server acts as a local bridge between GitHub Copilot in Agent Mode and a developer’s Azure DevOps instance. It makes structured project data such as work items, pull requests, test plans, builds, and wiki entries available as context for the AI assistant. This allows developers to query, create and update project information conversationally without leaving their IDE. According to Microsoft product manager Dan Hellem, “This lets the assistant give better, more accurate, and more relevant answers tailored to your specific Azure DevOps project.”

The MCP Server runs locally, which ensures that project data does not leave the developer’s network. It is installed as a Node.js service and integrates with Copilot through a configuration file and Azure CLI authentication.

This initial version provides functionality for core components within Azure DevOps. Developers can list projects, repositories, builds, releases, test plans, teams and iterations. Work items can be created and edited through natural language, with Copilot able to suggest the content automatically. Test cases and pull requests can also be generated and linked to backlog items. In a LinkedIn post, Lyon Till, Senior Software Engineer at Microsoft, described the experience as “No more context switching – manage your entire DevOps workflow without leaving VS Code or Visual Studio.”

To get started, developers install the MCP Server from the official GitHub repository, sign in using the Azure CLI, configure their local mcp.json file and start the service. Once running, Copilot Agent Mode can handle commands such as “list work items assigned to me” or “create a user story for login failure handling”, translating these into authenticated REST API calls to Azure DevOps.

The preview release is currently limited to Azure DevOps Services. On-premises Azure DevOps Server is not supported. Microsoft is inviting early adopters to share feedback and feature requests via GitHub Issues.

A separate MCP Server for Azure resource queries was launched in May, allowing developers to retrieve information about services such as Key Vault, Cosmos DB and Storage Accounts using natural language. The Azure DevOps MCP Server builds on the same underlying approach.

Documentation, setup guidance, and source code are available on GitHub. The preview is open to developers using Azure DevOps Services and GitHub Copilot Business or Enterprise licences.

Docker has introduced a new range of security-focused base images designed for production use, aiming to reduce vulnerabilities and support secure software supply chains across containerised applications.

Docker Hardened Images (DHI) are a curated set of minimal images built from source using a distroless approach. By removing shells, package managers, and other unnecessary components, the images are designed to reduce the attack surface of containerised workloads significantly.

According to Docker, the hardened images reduce the vulnerability footprint by up to 95% compared to traditional base images. Each image is maintained with automated patching and ongoing security updates, aiming for a near-zero number of known CVEs. Critical and high-severity vulnerabilities are patched within seven days, backed by a defined service-level agreement.

The hardened images are designed to be drop-in replacements for popular base images, such as Alpine and Debian. Docker has focused on ensuring compatibility with existing Dockerfiles to minimise disruption to build pipelines. A customisation layer allows teams to add their own certificates, packages, and configuration files on top of the secure base.

DHI images also include signed Software Bill of Materials (SBOMs) and provenance metadata, supporting increased transparency and supply chain visibility. These features may be particularly relevant for teams operating in regulated industries or security-sensitive environments, where additional assurance and traceability are valued.

Docker has announced early integration partners, including Microsoft, GitLab, JFrog, NGINX, Sysdig, Wiz, and Sonatype. These collaborations aim to ensure DHI works seamlessly with popular security and CI/CD tooling.

In internal testing, Docker reports that swapping a standard Node.js image for a hardened variant led to a 98% reduction in the number of installed packages and the elimination of known CVEs. The initial catalogue includes hardened images for common runtimes, including Python, Go, and Java.

DHI is now available via Docker Hub, with access determined by Docker’s subscription tiers. The setup documentation and customisation tools are included as part of the release.

GitHub recently introduced a prototype AI coding agent designed to fix bugs and propose code changes through pull requests autonomously.

Unlike GitHub Copilot, which assists developers in real time, the new agent operates independently, scanning codebases, identifying issues, and submitting suggested fixes as pull requests. This represents a shift from developer assistance to a more autonomous code-maintenance model.

According to GitHub, the agent builds on the capabilities of Copilot and leverages CodeQL for semantic code analysis, which enables understanding the meaning and structure of code beyond simple text matching. It is also integrated with a software library of common vulnerability and bug patterns. Once it detects a relevant issue, the agent formulates a potential fix and opens a pull request, complete with code changes and a descriptive message outlining the rationale. Developers can then review, modify, or merge the pull request as needed.

The announcement coincides with the rise of autonomous AI agents in software development. Tools like SWE-agent from Princeton have demonstrated early results in multi-step bug fixing and test-driven development. These tools are part of a broader trend towards software that can not only assist but also act, handling iterative development tasks with minimal human oversight. GitHub CEO Thomas Dohmke described this shift by stating, “Instead of you just asking a question and it gives you an answer, you give it a problem and then it iterates on that problem together with the code that it has access to”.

The GitHub team emphasised that this prototype is still in early development and is being tested internally. It is not yet available for public use, and GitHub has not announced a timeline for broader rollout. However, the company said that the technology represents a long-term investment in reducing the manual burden of software maintenance and improving code health at scale.

Developers have shown interest in GitHub’s coding agent as a way to automate routine bug fixing. In a Reddit thread, early users described successful test runs and called the tool a potential “game changer.” However, some raised concerns about trust, testing coverage, and change management. A GitHub Community discussion also highlighted worries around the implications of AI-generated pull requests, particularly in complex codebases.

The move aligns with GitHub’s broader AI strategy, which includes integrating large language models into workflows beyond code generation, such as documentation, issue triaging, and now, autonomous pull request creation. As part of this strategy, GitHub continues to explore how AI can take on repetitive engineering tasks, freeing developers to focus on higher-level design and problem-solving.

Cisco’s innovation arm, Outshift, has unveiled JARVIS. An AI-powered assistant designed to streamline platform-engineering workflows. JARVIS offers a conversational interface that simplifies complex tasks, reducing both execution time and cognitive overhead.

Cisco has developed JARVIS as a member of the platform-engineering team. JARVIS can integrate with over 40 tools and, among other tasks, can seamlessly provision infrastructure, onboard new applications to CI and retrieve important documents with all instructions originating from natural language. The team at Cisco communicate with JARVIS using tools they already use every day, such as Jira, Webex and Backstage. The team can assign Jira tickets to JARVIS, and it executes the work.

The results have been significant. In a LangChain blog post, they reported that “Tasks that previously took a week, such as setting up CI/CD pipelines, can now be completed in under an hour.” According to a  NetworkWorld blog post, “Engineers spend up to 70% of their time on repetitive tasks rather than innovation. JARVIS automates these workflows, turning day-long processes into minute-long ones.”

JARVIS is powered by a hybrid AI architecture that combines multiple techniques. Built using LangGraph, the main engine behind JARVIS is large language models (LLMs) that provide the natural-language processing capability to best interpret developer requests. However, the responses generated by the LLMs are not immediately trusted. JARVIS implements three additional safeguards to ensure accuracy and reliability. First, it uses rule-based validation through symbolic logic to confirm that outputs adhere to predefined standards, such as naming conventions. Second, it enforces clearly defined, repeatable workflows to ensure tasks are executed consistently, without allowing the AI to improvise. Finally, it introduces agent supervision, where one agent reviews and verifies the work of another, adding an additional layer of quality control.

To answer knowledge questions, JARVIS leverages retrieval-augmented generation (RAG) by allowing its AI agents to supplement their in-memory knowledge by looking up information from external sources of structured data like wikis and codebases.

At present, JARVIS is only used internally at Cisco. However, the company has announced plans to open-source key components such as its integration with Backstage and standalone agents. The project is also contributing to the Internet of Agents initiative of intelligent software agents that can communicate and collaborate across shared protocols.

Bill Gates, co-founder of Microsoft, sees AI agents like JARVIS as a part of the future. In a 2024 blog post, he noted, “Agents are not only going to change how everyone interacts with computers. They’re also going to upend the software industry, bringing about the biggest revolution in computing since we went from typing commands to tapping on icons.”