Microsoft has released code-testing-generator, an open-source agent for generating unit tests in any programming language, according to the company.

Released July 31, the code-testing-generator agent learns from the user’s repository, then plans, writes, and checks the tests to prove that they work. Currently the agent writes unit tests only. Integration tests, end-to-end tests, browser tests, and performance tests are outside its current scope, Microsoft said.

The agent coordinates test generation using the “research-plan-implement” (RPI) pipeline. First the agent searches the repository for the code that needs tests, detecting the language and test framework and looking for existing tests to guide its work, and finding the correct commands for building and running the tests.

Next the agent chooses the right amount of work from three paths:

• Direct: Read the relevant code, write the tests, and validate the result.
• Single pass: Research and plan once, then implement that plan.
• Iterative: Repeat the cycle to cover a large request or reach a coverage goal.

The agent then plans and writes the tests It starts with simple code and then moves to code with more dependencies, mapping each behavior to a test file. The agent then checks that the generated tests are useful. According to Microsoft, it checks for the following problems before it finishes:

• It considers small code changes that should make the tests fail.
• It looks for weak or missing assertions.
• It checks that every requested scenario has a matching test.
• It builds the full workspace and runs the full test suite.
• It confirms that the repository’s test command can find the new tests.

The code-testing-generator agent is available in the dotnet-test plugin in the dotnet/skills repository on GitHub. The plugin can be used in GitHub Copilot CLI and is also available in Visual Studio Code and VS Code Insiders through plugin support, which is a preview feature.

Meta has released a beta coding agent designed to handle complex software assignments across large codebases.

Available for macOS and Linux, Muse Code uses the company’s new Muse Spark 1.2 model. It includes specialized background agents that remain active throughout a session instead of being created separately for individual tasks.

The agents carry out work asynchronously and decide when to report their findings to the primary agent. Meta said keeping them active reduces repeated information gathering and the need for developer direction during difficult, multi-step tasks.

“Muse Code uses a local event log in which every model call, tool run, approval, and edit is appended,” Meta said in a post, adding that the record “makes the runtime replay-exact and restart-safe” and allows the agent to resume precisely where it stopped after a crash.

Muse Spark 1.2 is available through Muse Code and the Meta Model API, for which Meta announced expanded global access.

Training and evaluation

Meta said it co-trained Muse Spark 1.2 with Muse Code to improve the model’s performance and usability when used with the agent. The training incorporated Muse Code’s tools and agent workflows, while Meta increased the computing resources used for coding and broadened the range of development environments.

The model was also trained on longer assignments, including whole-repository generation and large end-to-end software projects.

Lian Jye Su, chief analyst at Omdia, said Meta’s co-training approach was unlikely to provide a clear advantage because rivals were also developing their coding models and agent harnesses in close coordination.

“Other vendors, such as OpenAI and Anthropic, have been treating harness engineering as part of the training process,” Su said.

Optimizing the model and agent together could improve planning and context handling, but any competitive advantage would need to be demonstrated through better results on enterprise projects while reducing the need for human intervention, said Pareekh Jain, CEO of Pareekh Consulting.

Meta reported that Muse Spark 1.2 achieved an 82.9% pass@1 score on Terminal-Bench 2.1, behind Claude Opus 5 but slightly ahead of GPT-5.6 Terra. On DeepSWE 1.1, the model scored 59.3%, trailing both rivals.

For Terminal-Bench 2.1 and DeepSWE 1.1, Meta evaluated each model with its selected coding agent rather than using the same agent throughout. It also acknowledged that rival proprietary models may have performed differently under tools and prompts designed specifically for them.

Neil Shah, vice president of research at Counterpoint Research, said cross-vendor comparisons would be more meaningful if models were evaluated with third-party tools or within the same agent harness.

“The key metric for CIOs is the pass rate against an enterprise’s own pipeline, which will determine the success of the model-and-harness bundle, or, in this case, Meta’s Muse Spark 1.2 and Muse Code,” Shah said. “This will be the real benchmark.”

Enterprise adoption hurdles

Su said security and governance requirements could slow enterprise adoption, particularly where coding agents must be connected to existing identity systems.

“Many enterprises are still less willing to open up their CI/CD environments for AI tool integration,” Su said.

Shah said companies would need controls governing how agents access repositories, along with records showing how models and agent workflows handle enterprise data. He also cited the difficulty of forecasting token consumption and its effect on costs.

Meta’s pricing structure also creates a data-governance choice. The company said the lower-priced Contributor model may be used to improve its products, while the standard tier is not used for that purpose.

The Contributor tier costs $0.10 per million input tokens and $0.20 per million output tokens, compared with $1.25 and $4.25, respectively, for the standard tier.

“There is also a fear of vendor lock-in and reliance, as it may hurt long-term flexibility and system interoperability,” Su added.

Jain said adoption was likely to begin with narrowly defined, lower-risk work before companies allowed persistent agents to modify critical production code.

Visual Studio Code 1.132, the latest version of Microsoft’s popular, open-source code editor, has been released. The brings improvements to built-in dictation, side chats, and support for commenting on web elements in the integrated browser.

VS Code 1.132 was released August 5. The update can be downloaded for Windows, Linux, and macOS at code.visualstudio.com.

With VS Code 1.132, the built-in multilingual dictation function lets developers dictate in multiple languages using an on-device model that follows language preference or detects the language automatically. The built-in dictation converts speech to text in chat inputs, editors, and terminals. Dictation now uses multilingual Nemotron 3.5 as the default on-device model. Plus, terminal dictation now applies shell-aware cleanup, so spoken commands preserve shell syntax.

Also in VS Code 1.132, developers can open a side chat by typing /bt in the chat input. A side chat shares the context and prompt cache of the primary chat, but allows developers to ask the agent questions about the current turn without interrupting the turn. Similarly, developers can select text in a chat response to ask contextual questions about that response.

Other new capabilities and improvements in VS Code 1.132:

• The integrated browser adds support for selecting web page elements and annotating them with agent feedback. Users can trigger this mode by using the workbench.action.browser.addElementCommentToChat keyboard shortcut.
• Active development continues on the agent host, a new VS Code feature that lets users connect to the same agent session from multiple VS Code windows. The agent host runs agent harnesses such as Copilot, Claude, and Codex in a dedicated process based on the Agent Host Protocol (AHP).
• In the previous release, Microsoft introduced the hybrid Markdown editor, which combines rendered Markdown with in-place editing and agent-actionable comments. In this release, Markdown diffs can be opened in the hybrid Markdown editor. 
• Expanded terminal output in chat now reflows to the available width as the view is resized. Previously, output used a fixed width, which caused lines to wrap too early and left unused space in wider views.

A new critical vulnerability in the Ruby on Rails (“Rails”) web application framework, CVE-2026-66066, could turn a seemingly innocuous image into a front door to your secrets.

Disclosed July 30, the high severity CVE (scored 9.5 out of 10) poses a significant risk to enterprises running apps that handle user-uploaded images in Rails.

Dubbed “KindaRails2Shell,” it targets the overly-trusting Active Storage component of the open-source framework, allowing unauthenticated attackers to read sensitive files or escalate to remote code execution (RCE).

The issue has been fixed in versions 7.2.3.2, 8.0.5.1 and 8.1.3.1 of Active Storage; enterprises running Rails should update immediately.

“The ‘chef’s kiss’ is the ability for an attacker to upload an image that isn’t actually an image [but] is code that allows them to steal secrets,” said David Shipley of Beauceron Security.

Attackers get the key to the castle

Ruby on Rails is an open-source, server-side application framework used for building full-stack web apps and application programming interfaces (APIs).

It is popular among developers because it is scalable, easy to learn and use, supports quick application development, taps into an active community of more than 1,000 engineers developing and maintaining it, and has an extensive library of nearly two million lines of prebuilt code.

CVE-2026-66066 specifically targets Rails’ built-in Active Storage component, which lets users upload files to cloud services or local disks and link them to their applications. In particular, the vulnerability exploits the way Active Storage interacts with the libvips image processing library to generate images.

Libvips contains what are known as “unfuzzed” operations which have not been hardened against malicious inputs through techniques known as fuzzing that test where they crash, leak data, or otherwise behave erratically. This makes them unsafe for use with untrusted content, but Active Storage does not adequately disable them.

“CVE-2026-66066 is particularly dangerous because an attacker may not need an account or privileged access,” explained Ensar Seker, CISO at SOCRadar.

Attackers can exploit the unsafe pipeline by uploading specially crafted files that trick Active Storage into giving them access to files that the Rails process is permitted to access, even highly-sensitive ones in app processing environments.

In practical terms, this could expose environment variables, Rails application secrets, database credentials, cloud access keys, API tokens and credentials for connected services, Seker explained.

Attackers can also gain access to the secret_key_base that signs and encrypts cookies, credentials, and session data. When secret_key_base is compromised, attackers essentially hold the key to the app.

“The immediate vulnerability is an arbitrary file-read issue, but the theft of secrets such as Rails’ secret_key_base can turn information disclosure into a much broader compromise,” Seker said.

Depending on the application, attackers could potentially forge trusted application data or sessions, access databases and cloud services, move laterally into connected systems, or achieve RCE.

That escalation path is what makes the vulnerability critical, Seker said. “A seemingly routine image upload feature, such as a profile picture, avatar or thumbnail generator, could become an entry point into the application’s underlying infrastructure.”

How to identify if you’re vulnerable

Applications are impacted when they are configured to use libvips for Active Storage image processing (the default behavior since Rails 7.0) and accept image uploads from untrusted or unauthenticated users. Enterprises should audit every internal and third-party app to determine whether they are configured this way, Seker advised, and patch Rails and Active Storage immediately. They should also examine every feature accepting images, including avatars, support attachments, product images, and administrative upload functions.

Upgrading Rails alone is not sufficient when an older libvips installation remains underneath it; libvips must be version 8.13 or later, he said.

Forensic guidance and tooling from the Rails project can help enterprises determine whether apps are vulnerable or files are exploitable, Seker noted. It’s also important to review app, proxy, object-storage, and image-processing logs for suspicious uploads or unusual requests.

Additionally, admins should rotate secret_key_base and every other credential available in Rails, invalidate active sessions, and investigate downstream systems for potentially exposed credentials.

“Security teams should treat this as a potential secret-exposure incident, not merely a patch-management exercise,” Seker said.

Don’t trust image processing pipelines

Complex image libraries support many formats and rely on numerous parsers and third-party components, creating a broad attack surface, Seker noted. Therefore, the libraries “should be treated as untrusted code execution territory.”

Image processing should be isolated in dedicated sandboxes, containers, or restricted to workers with minimal filesystem access, he advised. There should be no unnecessary network connectivity or access to an app’s files or secrets. Strict allowlists should be applied, file content human-validated, and uploads scanned before processing and stored outside app directories. 

Additional controls should include short-lived and narrowly scoped credentials, outbound network restrictions, dependency and software composition monitoring, and automated tests that confirm that dangerous codecs or operations are disabled post-upgrade, Seker said.

“The broader lesson is that organizations cannot assess exposure solely by asking whether they ‘use Rails,’” he noted, pointing out that two applications running the same Rails version may have very different exposure depending on their image processor, upload paths, and operating system packages. This makes visibility into runtime configuration, libraries, and app functionality critical.

This incident also demonstrates the importance of secret rotation in vulnerability response, he added. “When a vulnerability enables arbitrary file access, installing the patch closes the entry point but does not revoke credentials that may already have been copied.”

Don’t just assume you’re safe

This vulnerability illustrates a perfect use case for a software bill of materials (SBOM), which can speed up discovery of vulnerable software and triage it, Beauceron’s Shipley noted. And enterprises could also adopt intelligent web application firewall monitoring and intervention in addition to isolating systems and patching.

“The words you never want to hear in any critical vulnerability are ‘arbitrary code execution’ and ‘remote code execution’,” he said. “Either of those can mean bad news.”

What’s also interesting here is that the disclosure process was hijacked, he pointed out. Rails published technical details about the flaw and forensic tools to assess application vulnerability to it and to look for evidence of data exfiltration nearly a month before it planned to, because several researchers had reverse-engineered the attack and published proof of concept code.

The fact that proofs of concept are now available “materially increases the likelihood of opportunistic scanning and exploitation attempts,” Seker noted.

Therefore, he said, “even organizations that see no obvious evidence of compromise should not assume that patching alone removes the risk created by previously exposed secrets.”

This article originally appeared on CSOonline.

AWS on Tuesday released Kiro Crew, an open-source orchestration platform designed to help enterprises move beyond interactive AI coding assistants toward long-running, autonomous engineering workflows that span repositories, developer tools, and multiple work sessions.

Rather than simply generating code, Kiro Crew coordinates multiple AI agents, schedules recurring work, preserves project context across sessions, and integrates with developer tools to investigate incidents, monitor pull requests (PRs), triage tickets, and automate software engineering tasks while developers are away from their keyboards, according to the hyperscaler.

“Kiro Crew is a persistent, open-source development workspace for work that is bigger than a single task in a single session,” Darko Mesaros, distinguished developer advocate at AWS, told InfoWorld. “Think of it as an application layer that turns AI coding agents into always-working, self-learning, autonomous teammates.”

To support that model, the offering ships with persistent memory, multi-agent orchestration tools, approval workflows, scheduling, security controls such as sandboxing and signed audit logs, and a web and desktop dashboard for monitoring agent activity, the hyperscaler said in a statement.

Kiro Crew was originally developed inside Amazon as an internal project called MeshClaw and was later adopted by more than 39,000 Amazon builders in less than six months.

It can be deployed entirely inside customer environments, including laptops, containers, or virtual machines, without requiring an AWS account or AWS-managed control plane, AWS said.

To demonstrate how the new offering can be used, AWS is also launching a set of reference applications built on top of it, including DevFleets for worktree management, Issue Radar for issue and pull-request triage, and Task Runner for executing long-running engineering tasks.

Rather than standalone products, these apps combine purpose-built user interfaces with Kiro Crew’s orchestration engine, memory, scheduling, integrations, and backend services to automate specific engineering workflows, Mesaros said, adding that the hyperscaler is expected to add more such apps in the future.

Boosting developer productivity

Such applications, according to Michael Leone, principal analyst at Moor Strategy and Insights, would help platform engineering, DevOps, and site reliability engineering (SRE) teams, where much of the work involves repetitive, long-running operational tasks rather than writing entirely new software.

“These tasks can include dependency upgrades, framework migrations, flaky test cleanup, triaging and routing a ticket queue, and the first pass on an incident investigation,” Leone said.

“It’s a strong fit for long-running migrations that require checkpoints and retries over hours without supervision,” echoed Manoj Chandra Jha, principal analyst at Nord-IQ Research.

Taken together, those capabilities could significantly reduce software release cycles as well as the time developers spend supervising AI tools and reconnecting context between engineering workflows, according to Dave McCarthy, vice president of enterprise infrastructure at IDC.

“It eliminates context-switching and babysitting single prompts. Work continues asynchronously in the background while developers are in meetings, off the clock, or asleep, allowing teams to return to completed progress rather than a stalled process,” McCarthy said.

That, in turn, will allow developers to spend more time on higher-value engineering tasks, such as designing systems, making architectural decisions, and solving complex engineering problems, echoed Ashish Chaturvedi, executive research leader at HFS Research.

Why CIOs should care

Kiro Crew’s open-source, self-hosted architecture could help enterprises looking to bring governance and visibility to the growing use of AI coding agents, analysts said.

“Agent use inside most companies right now is shadow IT, with individual developers wiring up their own agents against their own credentials and nobody tracking it. A shared workspace with approval gates and logging gives you one place to see what ran, what it touched, and who authorized it,” said Leone.

Those governance capabilities, combined with the ability to run inside customer-controlled environments, according to Chaturvedi, could also help CIOs address security and compliance concerns: “Being open source and self-hostable, a CIO can run it on their own infrastructure and keep code and credentials inside their perimeter rather than sending them to a black-box agent.”

That reduction in security concerns, combined with Kiro Crew’s human-approval workflows, could provide enterprises with a lower-risk path to broader agent adoption, Jha said. “Since it embeds consistency and security screening at scale, and because review remains human-approved, it’s a low-risk entry point for demonstrating agentic ROI before extending trust to higher-stakes, unattended workflows.”

Not without trade-offs

Despite its benefits, the adoption of Kiro Crew comes with trade-offs, analysts warned.

Adopting Kiro Crew may not be a simple plug-and-play operation, said Stephanie Walter, practice lead for AI Stack at HyperFRAME Research. Rather, it introduces yet another orchestration layer for enterprises to manage and secure, she said.

Enterprises would need to draft up policies covering least-privilege access, human approvals, memory retention, code provenance, and auditability before allowing persistent agents to operate across source code repositories and CI/CD pipelines, Walter said.

More so because most enterprises, Walter added, are still not operationally ready to manage swarms of autonomous AI agents: “Many are still struggling to measure the cost and value of individual AI agents. Parallel agents multiply model calls, compute, CI activity, API usage, tool access, and human review, not just token consumption.”

Open architecture, but questions remain

Even for organizations that are ready to experiment with autonomous coding agents, integrating Kiro Crew into existing development environments may require additional work.

Although AWS built Kiro Crew around open standards such as Agent Client Protocol (ACP) and Model Context Protocol (MCP), the platform runs on the proprietary Kiro CLI at launch, according to Mesaros.

That means enterprises using other AI coding agents, such as Claude Code, Codex, or Devin, may need to build and validate their own connectors before they can use Kiro Crew as their orchestration layer.

“The dependency is real. AWS says Crew runs on the Kiro CLI at launch, and that CLI is proprietary and metered by credits, so it’s the harness actually wired up on day one. Until someone runs a different agent under Crew and shows it working, the open part stops at the orchestration layer,” said Leone.

For enterprises and development teams already using Kiro, however, adoption is expected to be more straightforward, as Kiro Crew can reuse existing .kiro configurations, including steering files, skills, and custom agents, without requiring additional setup, according to Mesaros.

The new offering, due to its open-source nature, is free as well, Mesaros pointed out, adding that customers need to pay only for the AI coding agents and tools they choose to connect to Crew.

AWS said it will govern the project through a publicly listed steering committee operating under an open governance model, with proposals submitted as pull requests and debated openly.

Kiro and AWS engineers will initially maintain the project, with trusted community contributors expected to join the maintainer group over time, it added.