The Road to Macstock takes us to Dave Hamilton, who previews his Macstock session, “From Curiosity to Capability,” which will focus on practical AI workflows anyone can use. Dave discusses how generative AI has changed coding, project management, proposals, productivity, and procrastination for him. The session will encourage experimentation as a way to get involved as AI tools rapidly evolve.
A tiny microscope weighing just five grams could give neuroscientists an unprecedented view of how individual brain cells control behavior while animals move naturally. Researchers at the University of Colorado Anschutz Medical Campus and the University of Colorado Boulder have developed a head-mounted device that can both record neural activity and selectively activate individual neurons during movement. The technology could help scientists investigate how brain circuits generate behavior and how those circuits become disrupted in conditions such as Alzheimer’s disease, Parkinson’s disease and epilepsy.
The device, called Opto2P-FCM, combines two powerful techniques that have traditionally been difficult to use together in a freely moving animal. Two-photon microscopy provides detailed images of living brain tissue at cellular resolution, while optogenetics uses light-sensitive proteins to control selected neurons. By integrating both capabilities into a miniature instrument, the researchers can observe specific cells as they become active and then stimulate chosen neurons to test how they influence the surrounding network.
“These miniature microscopes have been increasingly used to study the neural basis of behavior in freely moving animals,” said Emily Gibson, PhD, associate professor of biomedical engineering at CU Anschutz and the study’s senior author. “This new microscope allows deeper penetration and higher resolution images in the brain. Importantly, it can also excite select neurons using optogenetics.”
For decades, conventional two-photon microscopes have been regarded as the gold standard for imaging neurons in living brains. These systems use infrared laser light to produce high-resolution images deep within tissue, allowing researchers to track calcium signals and other indicators of neural activity. However, conventional microscopes are generally large, stationary instruments. Animals must often remain immobilized beneath the objective, making it difficult to study brain activity during walking, exploration, social interaction or other natural behaviors.
Miniature microscopes have helped overcome that limitation by moving the imaging system onto the animal’s head. Yet reducing the size and weight of the equipment has often required compromises. Some compact systems provide lower-resolution images, while others can record neural activity but cannot stimulate precisely selected cells. The Colorado team designed Opto2P-FCM to address both problems through a dual-path optical architecture that separates imaging from stimulation.
In the imaging pathway, infrared light is directed through the brain to generate two-photon signals from fluorescent markers inside neurons. These markers can report changes in calcium concentration, which occur when neurons fire. The resulting signals are collected to create detailed images of neural activity at the level of individual cells. A separate optical pathway delivers patterned light for optogenetic stimulation, allowing researchers to activate specific neurons without disrupting the imaging beam or overwhelming the detectors.
This separation is technically important because imaging and stimulation place different demands on an optical system. High-resolution imaging requires precise focusing, efficient light collection and minimal optical distortion. Optogenetic activation, by contrast, requires intense, accurately positioned light capable of reaching the light-sensitive proteins expressed by selected neurons. Designing both functions into a device small enough to be carried by an animal required careful control of the alignment, geometry and weight of every optical component.
“This microscope is a game changer,” said Juliet Gopinath, PhD, professor of electrical, computer and energy engineering and physics at CU Boulder and a study co-author. “Being able to demonstrate a state-of-the-art instrument for both read-out and photo-stimulation of neurons is amazing.” The research team included engineers, physicists and neuroscientists who worked together to solve problems involving miniature lenses, mechanical tolerances, optical alignment and three-dimensional fabrication.
The device weighs approximately five grams, but its small size made construction unusually demanding. Mo Zohrabi, PhD, a senior research scientist at CU Boulder and co-first author, said the team initially thought such an instrument might be impossible to build because of the tight tolerances required by the optics and available 3D-printing technology. Gregory Futia, PhD, a senior research associate at CU Anschutz and co-first author, said that every component had to be designed and accounted for with extreme precision. Even slight misalignment could reduce image quality or prevent the stimulation beam from reaching the intended cells.
The researchers believe the platform could transform experiments designed to distinguish correlation from causation in the brain. Recording a neuron’s activity can show that it is associated with a behavior, but it does not prove that the cell helps produce that behavior. With optogenetic stimulation, scientists can activate a selected population and observe whether movement, decision-making or other actions change. At the same time, the microscope can record how neighboring neurons respond, providing a view of how local circuits coordinate activity.
The current Opto2P-FCM system is a prototype, and the researchers are working on future versions that could be smaller, lighter and faster. They also hope to expand the field of view so that more neurons can be monitored at once. Such improvements could make it possible to track larger networks over longer periods while animals engage in increasingly complex behaviors. By combining cellular-resolution observation with targeted manipulation in a freely moving subject, the technology may help reveal how healthy neural circuits operate and how neurological disease changes the communication between them.
Subject of Research: Miniature two-photon microscopy, optogenetics, neural circuits and brain activity during natural movement
Article Title: New Miniature Microscope Allows Scientists to Watch and Control Brain Cells During Natural Movement
References: Optica, “New Miniature Microscope Allows Scientists to Watch and Control Brain Cells During Natural Movement,” article publication date: Aug. 7, 2026
Cities may soon be able to identify their hottest walking routes with the same precision used to map traffic or public transport. HeiGIT, the Heidelberg Institute for Geoinformation Technology, has added a tree-shade indicator to its free Climate Action Navigator, a digital platform designed to help municipalities and civil society organizations understand how urban environments affect everyday life. The new tool provides a street-level view of where pedestrian paths are protected by tree canopies and where people are exposed to direct sunlight, offering planners a detailed basis for decisions about urban greening, heat adaptation and safer walking routes.
The need for such information is becoming increasingly urgent as cities experience more frequent and intense heat waves. A citywide estimate of tree cover can suggest that an urban area is relatively green while concealing major differences between neighborhoods. In one district, a large park or wooded hillside may raise the average, even though the streets used daily by residents remain almost entirely unshaded. The Climate Action Navigator is designed to reveal these local contrasts by measuring shade along pedestrian routes rather than relying only on broad land-cover statistics.
In Innsbruck, Austria, tree cover extends across approximately 30 percent of the city’s relevant areas, but the distribution is far from even. Much of the shaded pedestrian network lies outside the central urban area, while heavily used streets in the city center can remain exposed to full sun. This distinction matters because people experience heat at the scale of individual journeys: walking to school, commuting to work, visiting shops or reaching public transport. Two routes separated by only a few streets may therefore offer very different levels of thermal comfort and protection from solar radiation.
The indicator is also intended to connect physical infrastructure with human behavior and well-being. Shaded paths can make walking more attractive during hot weather, potentially influencing whether people choose to travel on foot, wait for public transport or avoid certain destinations altogether. Claudia Schmiedeberg of the GLEN Study said that understanding the social effects of climate change requires examining how local surroundings shape daily decisions over time. Combining the tree-shade data with longitudinal survey information could help researchers investigate whether residents in greener neighborhoods adapt differently to heat, and whether unequal access to shade contributes to wider social disparities.
Technically, the tool identifies pedestrian walkways that directly overlap with tree canopies at least two meters high. The height threshold is designed to distinguish trees capable of producing meaningful overhead shade from low shrubs, grass and ground vegetation. The analysis uses high-resolution global canopy datasets and applies the same processing method across different cities. This allows a small town, a regional center and a major capital to be compared using a consistent measure rather than relying on incompatible local mapping systems.
The calculation also models a high-noon scenario, when the sun is strongest and shadows are generally shortest. By estimating shade under these demanding conditions, the indicator focuses on a daily period when heat exposure may be especially severe. It measures the availability of shade at what the developers describe as the weakest point of the day, creating a conservative benchmark for planning. The result is not a complete simulation of human thermal comfort, which also depends on air temperature, humidity, wind, pavement materials and building geometry, but it provides a clear spatial signal of where tree canopy is present above pedestrian infrastructure.
Early comparisons show how sharply shade levels can differ between cities. In the historic city of Maribor, Slovenia, approximately 35 percent of the pedestrian network is covered by trees. In Tempe, Arizona, a university city located in a hot and generally arid region, the corresponding figure is just above 7 percent. Such numbers do not by themselves determine whether a city is comfortable or unsafe, but they provide a comparable starting point for identifying exposure. When combined with information about schools, care facilities, public transport stops or tourist destinations, the data can show which groups and routes may require priority attention.
Urban planners could use the indicator to decide where new trees would provide the greatest benefit, while also recognizing streets where existing canopy already supports walking during hot periods. Linking shade maps with school catchment areas, for example, could reveal whether children have protected routes to school or must travel through long stretches of direct sunlight. Tourism agencies and local authorities could also use the information to recommend cooler walking routes to major attractions. In this way, the platform is intended not only to document an environmental problem but also to support targeted interventions, from tree planting and maintenance to short-term route guidance.
Jim Walker of the Walk21 Foundation said the indicator offers comparable, street-by-street evidence that can help administrations prioritize infrastructure investment during the hottest months. Its developers argue that global canopy datasets make it possible to overcome the local data shortages that often prevent smaller municipalities from conducting detailed climate assessments. Dr. Kirsten von Elverfeldt, community engagement manager at HeiGIT, said the goal was to make granular diagnostic information freely available so that greening initiatives can be directed toward the places where they are most needed.
The Climate Action Navigator is open to the public, allowing users to explore how their municipality performs and compare different urban areas. The platform’s tree-shade indicator does not replace on-the-ground assessments, but it can help transform an abstract climate challenge into a visible pattern of shaded and exposed streets. As heat increasingly shapes how people move through cities, that ability to see the difference at walking level could make urban climate planning more precise, more equitable and more immediately actionable.
Subject of Research: Not applicable
Article Title: New Global Tool Maps Tree Shade Street by Street to Reveal Cities’ Heat Exposure
News Publication Date: August 11, 2026
Web References: Climate Action Navigator: https://heigit.org/ ; Tree shade indicator video: https://www.youtube.com/watch?v=vAQxEnAgM44 ; Innsbruck example: plugin/hiwalk?share-id=f50386c3-4ea6-45b8-946a-6fedfae38dc8 ; Maribor example: plugin/hiwalk?share-id=f675a5bd-f15f-429c-81f4-80cac6c7051a ; Tempe example: plugin/hiwalk?share-id=31880ebb-1c6d-40e1-89cf-ffac9bceb607
Anthropic is making Claude Code’s auto mode the default for its paid and enterprise users, allowing the coding agent to execute more actions without requiring developers to approve each one.
“Starting August 14, 2026, auto mode becomes the default permission mode for new sessions on Pro, Max, and Team plans,” the company wrote in the coding agent’s documentation, adding that the same change is planned for Claude Enterprise, API, and cloud platform users within the next month.
That essentially means developers using those plans will no longer have to manually approve every tool call or action Claude Code wants to make while executing a task.
Instead, each tool call is evaluated by an automated classifier designed to determine whether the action is safe to execute. Actions considered irreversible, destructive, or outside the agent’s environment can still be blocked, with Claude Code either attempting a safer approach or asking the developer for approval, the company wrote in a blog post.
“If it can’t make progress — three blocks in a row, or twenty across a session — Claude Code falls back to manual approvals,” it explained.
This reduction in manual intervention, Anthropic further added, is intended to make the coding agent more suitable for long-running tasks as well as cut down on “permission fatigue” that it says has been threatening to reduce its security posture.
According to its internal data, Claude Code users typically approve 97% of permission prompts, while only 3% are rejected. It also found that 49.5% of active CLI users had created a Bash allow-rule by June, while 62% had used “bypassPermissions” or selected “don’t ask again” for Bash.
In contrast, the default auto mode, in an Anthropic-controlled study involving 1,053 paid professional testers, caught 89% of deliberate dangerous commands compared to just 13.6% being detected by human reviewers.
More productivity but with tradeoffs
Analysts too see auto mode as a step toward making coding agents more autonomous, but with tradeoffs.
“Developers should see fewer permission pop-ups and spend less time watching Claude, meaning they can give it larger tasks and let it edit files, run tests, and execute routine commands with fewer interruptions. That way, developers can finish and ship more work using this mode because they aren’t constantly interrupted by approval windows,” said Pareekh Jain, principal analyst at Pareekh Consulting.
However, that same classifier in auto mode that reduces permission pop-ups could also result in more latency for routine or quick tasks, as trusted workflows also pass through it, adding an extra execution step, noted Manoj Chandra Jha, principal analyst at Nord-IQ Research.
Another tradeoff of reducing real-time approvals, according to Amit Kumar Jena, AI development manager at IT consulting firm Kanerika, is that it could make it harder for enterprises to maintain effective human oversight as agents take on longer-running tasks. “Reviewing four hours of unattended agent output is a harder skill, and most teams haven’t built it,” Jena said.
Better governance for CIOs
For CIOs, though, auto mode can strengthen governance in software development.
Rather than policing individual developer actions, CIOs can define permission boundaries centrally and have the classifier enforce them across agent sessions, said Jha.
That makes the current opt-in period for Enterprise and API users particularly important, as CIOs can establish permission policies before auto mode becomes the default, Jha added.
At the same time, however, CIOs also need to understand the limits of those policies, Jena pointed out.
“Auto mode has three levels of restrictions, with hard-deny rules blocking actions unconditionally, while soft-deny rules can be overridden by a developer’s allow rule. As a result, CIOs should use hard-deny or managed-settings rules for actions that must never be permitted,” he said.
Auto mode changes the security risk profile
Those centralized policy controls, which Anthropic claims should make Claude Code more secure, according to analysts, change the security risk profile of the coding agent rather than eliminate risk.
While the classifier and the policy controls reduce the risk of human failures or everyday risks, it also creates a single point of failure, Jain said.
That means if that single point has a blind spot or an attack manages to bypass it, the agent could still execute harmful actions without human approval or recognition, Jha echoed.
That said, Anthropic is not removing developers’ ability to control how Claude Code operates.
Users who have already set a different default may receive a one-time prompt asking whether they want to move to auto mode, while those who have pinned their existing preference will see no change. The company is also making the transition easier by absorbing the small amount of additional token usage generated by the classifier for Pro, Max, and Team users, with the change effective immediately.
Google announced that its Ask Advisor AI agent will compare campaign performance in Google Analytics against anonymized averages from similar businesses.
It used to be that the value and reputation of coding contest winners was very high. That’s no longer the case. Who cares how fast you can produce code that implements an algorithm or solves a problem? Your competition is no longer other people, at least not by themselves, but AI combined with insightful prompting and good taste.
Historically we wrote all our code ourselves and then we tested it ourselves. Yes, there was a period when we outsourced punching our cards to what was essentially a secretarial pool, but we were still writing out the code and doing all the thinking involved in the programming. Over the years we outsourced some of the testing to a QA department, allowed software to guess at what we were typing and complete it, and allowed code-checking software to run in the background as we typed.
Allowing software to help us by guessing what we mean advanced from word completion to line completion to function completion to program generation over a matter of about a decade. Currently a good model running in a good agent harness or IDE can look at your code, suggest improvements, compile and test the improved code, iterate on that, and then come up with something better, faster, more efficient, and more solid.
That shifts the burden from actually programming to reviewing and testing the code. If you don’t even review and test the code, then what you’re doing is vibe coding. Vibe coding doesn’t give you a lot of control over the end product. It is only really efficient at generating quick prototypes and creating technical debt. It’s just not enough structure.
One attempt to add more structure and to control what the model actually generates is specification-driven development (SDD). SDD works, because a spec grounds the model in a single source of truth. However, SDD often comes at the expense of taking too much effort and really being overkill for what you usually need.
Meanwhile, we have perhaps a dozen options for IDEs and another dozen options for agent harnesses and many dozens of models that do a good job of generating code. Here I’ll provide a brief tour of six of them: GitHub Copilot, Google Antigravity, JetBrains Air, Kiro, Zed, and Zenflow.
GitHub Copilot
First offered as a plug-in to Visual Studio Code in 2021, GitHub Copilot was one of the first AI plug-ins for coding assistance. Today, you can use GitHub Copilot in a slew of IDEs for code completion, generation, explanation, and debugging. In addition to VS Code, GitHub Copilot is available for Visual Studio, Vim, Neovim, and the JetBrains suite of IDEs. You can also use Copilot on the command line, both through the GitHub Copilot CLI and as an extension to the GitHub CLI. You can also use it directly on the GitHub website.
Currently there are about two dozen supported AI models in GitHub Copilot, including models from OpenAI, Anthropic, and Google. In Visual Studio Code you can add more models than the ones available by default with your Copilot subscription. For example, if you open the Manage Language Models panel in VS Code, you can select models from Foundry Local via AI Toolkit, GitHub Models via AI Toolkit, Microsoft Foundry via AI Toolkit, and, at least in my case, local models via Ollama. Local Ollama models don’t count against your Copilot plan, but they do occupy GPU or unified memory, depending on your hardware configuration.
GitHub Copilot currently has three default operating modes: Plan, Ask, and Agent. Plan mode researches and outlines multi-step plans. Ask mode chats with you without making changes. And Agent mode edits files in your workspace. You may also have custom modes, some of which are supplied by plug-ins; I have 16 of these. You can create your own custom modes if you wish.
GitHub Copilot currently has nine categories of default tools used by agents; each category may have many actual tools listed. Additional tools come from connected Model Context Protocol (MCP) servers and installed plug-ins. My installation currently has 346 tools available, which is nuts. At one point VS Code would warn you if you had too many tools active, but that doesn’t seem to be happening anymore.
AI agents are autonomous helpers that perceive their environment, decide on a course of action, and execute it. They break large tasks into smaller steps, draw on available tools and resources, reason about approach, and adjust their plans on the fly, all while following user directives until the goal is met. While most agentic code edits complete in seconds or minutes, some can run for hours with only a few requests for permission.
In light of that, it’s not surprising that GitHub switched to usage-based billing for GitHub Copilot. Effective June 1, 2026, GitHub tracks your token consumption rather than your Premium Request Units. Code completions and next edit suggestions are exempt from token limits.
Visual Studio Code with GitHub Copilot Chat selected in the right-hand panel. Note that Claude Code and OpenAI Codex chat share the right-hand sidebar. Also note the large selection of plug-ins at the very left.
Foundry
Google Antigravity
The original Google Antigravity (from way back in November 2025) was built as an agentic development platform, essentially a version of the VS Code “Code – OSS” IDE that Google developers use internally, which was repurposed for the sorts of repositories that mere mortals work with on normal-sized products. (Google’s internal software mono-repository is so large and complex that ordinary software tools can’t work with it; Googlers use Piper, an internal tool for version control, rather than Git.)
On May 19, 2026, Antigravity became the basis for a new ecosystem. Google Antigravity 2.0 is a standalone desktop application that is an independent, agent-focused surface, evolved from Antigravity’s Agent Manager. The new Google Antigravity IDE is a separate download that looks similar to the previous Antigravity. The Google Antigravity CLI is a way to invoke, monitor, and interact with Antigravity agents from your terminal. In addition, the Google Antigravity SDK is available to build custom agents.
Google Gemini 3.6 Flash is the default model on Google Antigravity. According to Google it’s their strongest agentic and coding model yet, as well as being faster than other frontier models on Antigravity. Gemini 3.6 Flash can be selected at three effort levels: low, medium, and high. Antigravity also supports Gemini 3.5 at low, medium, and high levels; Gemini 3.1 Pro at two effort levels; Anthropic’s Claude Sonnet 4.6 and Opus 4.6 with thinking enabled; and GPT-OSS-120B at medium effort. The general guidance is to use the lowest level of effort that will successfully execute your task to minimize token use.
The “+” dropdown in the prompt box allows you to add context to the prompt. Both Antigravity 2.0 and Antigravity IDE allow you to add media, mentions, and actions. Antigravity 2.0 also allows you to enable the browser from the “+” dropdown; it simply adds the /browser slash command to the prompt.
The Antigravity browser subagent is the rough equivalent of Playwright or the Microsoft Foundry Browser Automation tool. It can click, scroll, type, read console logs, capture the DOM, take screenshots, and record video. The browser subagent also integrates natively with the Chrome DevTools MCP.
The other internal slash commands for both SKUs are /goal, which means to run until the specified task is completely finished, not asking for intermediate input from the user; /grill-me, which means to ask questions back to align on the specific details of the plan before implementing it; and /schedule, which means to run an instruction as a one-time timer in the future or on some recurring schedule (via Scheduled Tasks). Any skills provided by plug-ins or by installed Model Context Protocol servers can also be selected by typing a slash into the prompt box.
Antigravity 2.0 and Antigravity IDE support skills both at the workspace and global levels. A skill requires a SKILL.md file with YAML frontmatter at the top, and supports optional scripts, examples, and resources. The YAML description field is key to allowing an agent to recognize when the skill is relevant. Skills that come with MCPs or plug-ins take no effort to install. Creating custom skills requires you to add a named skill directory and the SKILL.md file.
I asked Google Antigravity 2.0 for a project review. Gemini 3.5 Flash (high) came up with four sophisticated improvements to the code, and implemented them when I said to proceed.
Foundry
The new Antigravity IDE looks similar to the previous Antigravity. Note that the agent panel on the right synchronizes sessions with Antigravity 2.0.
Foundry
Antigravity CLI with the keyboard shortcuts displayed.
Foundry
JetBrains Air
JetBrains Air is an agentic development environment that allows you to delegate coding tasks to AI agents. It supports four agent providers: OpenAI Codex, Anthropic Claude, Google Gemini, and JetBrains’ own Junie. You can provide your own subscriptions or API keys for OpenAI, Anthropic, and Google to Air, or rely on JetBrains’ hosting via a subscription.
When you create a new task for JetBrains Air, it can run in a local workspace, a Git worktree, or an isolated Docker container. Once you have set it up properly, you can also run a new task in the cloud, starting either from your local machine or from a browser.
You can select an agent provider and model at this time. You can switch the agent only when you create a new task; you can change models within an agent at any time. There are four levels of permissions ranging from plan first to full access. For some agents you can select an effort level. You can provide context to the chat from a number of sources, including files and folders, documentation, Git branches, and several others.
To test Air, I gave it the prompt “try to improve on the performance of this pi calculator. Do your work in a new directory called air.” I used Claude Sonnet 4.6 (1M context window) and high effort with Ask permissions, running the task locally. It did a rather good job, although I got further optimizations later on with other environments.
JetBrains Air was able to improve on the work of GitHub Copilot fairly independently.
Foundry
Kiro
Developed by “a small, opinionated team within AWS” and described as an autonomous agent or virtual developer that learns over time while working independently, Kiro is available both as an IDE (based on Code OSS) and as a CLI tool. Kiro CLI (kiro-cli) doesn’t deal with specs at this point, although it does have a planner agent and agent steering. Kiro IDE (kiro) explicitly supports both vibe coding and spec-driven development (SDD). (See screenshot below.)
Kiro SDD generates three markdown files that together comprise the specification: requirements.md, which captures user stories and acceptance criteria in structured EARS (Easy Approach to Requirements Syntax) notation; design.md, which documents technical architecture, sequence diagrams, and implementation considerations; and tasks.md, which provides a detailed implementation plan with discrete, trackable tasks.
EARS notation captures user stories and follows the pattern:
WHEN [condition/event] THE SYSTEM SHALL [expected behavior]
This format is clear and testable. Kiro can generate property-based tests (PBT) based on your EARS-formatted requirements. These are more comprehensive than the usual unit tests.
In addition, Kiro SDD can generate three markdown files that together define the steering for the agents. Steering gives Kiro persistent knowledge about your workspace and its conventions.
A product overview file (product.md) defines the purpose, target users, key features, and business objectives of your project. A technology stack file (tech.md) specifies your chosen frameworks, libraries, development tools, and technical constraints. And a project structure file (structure.md) documents your file organization, naming conventions, import patterns, and architectural decisions.
With my free plan, Kiro IDE currently supports two Anthropic Claude models, Sonnet 4.5 and Sonnet 4.0, plus five open-weight models. It can automatically select models if you wish. The documentation also lists OpenAI’s GPT-5.6 Sol, Terra, and Luna, Claude Opus 4.5, 4.6, 4.7, 4.8, and 5.0, and Claude Haiku 4.5, all of which can be activated with a Pro ($20/month) or better plan.
Kiro IDE supports over a dozen context providers for chat requests, including generic context such as #codebase and #spec and specific context such as #code (snippets). It supports skills that follow the open Agent Skills standard, and Model Context Protocol servers that follow the MCP standard.
Kiro IDE supports both vibe-coding and spec-driven development flows.
Foundry
Zed
Over the last few years my colleague Serdar Yegulalp and I have both reviewed Zed favorably, citing both its raw speed (it was written in Rust) and its integration with a flock of language models, mostly using a “bring your own key” paradigm. You need to subscribe if you want to use a Zed-hosted model.
The team behind Zed previously created the hackable text editor, Atom, and the software platform for building JavaScript-based desktop apps, Electron, both for GitHub. They also built Tree-sitter, an advanced syntax parsing framework that has become the standard mechanism for code analysis and syntax highlighting across modern code editors. While Atom has been discontinued, both Electron and Tree-sitter are still active.
It’s Wednesday so there’s a new release of Zed out; the current version (as I write) is v1.13.2. Recent milestones include support for Anthropic’s Claude Opus 5, OpenAI’s GPT-5.6, llama.cpp as a model provider, and automatic agent context compaction. Some older major features include support for skills, collaboration, and remote development. If you’re interested in particular features, read the Zed documentation or the Zed GitHub Repository.
To test Zed’s agentic capabilities, I pointed it at the C++ π calculation program I’ve been using to test agentic development tools, then used Zed’s new code-review skill to evaluate the program. After thoroughly reviewing Zed’s proposed changes, I gave it the go-ahead to implement and test them. I used the recommended model at the time, Claude Sonnet 4.6.
Looking at Zed. The results of a code review on the π calculation program that I’ve been using as a testbed are on the right. Note the use of a code-review skill at the top right.
Foundry
After reviewing the suggestions from the code review, I gave Zed (using Claude Sonnet 4.6) permission to implement the suggestions and validate the changes.
Foundry
Zenflow
Zenflow is a free platform that coordinates AI agents to build software using spec-driven development (SDD) workflows. Another term for coordination is orchestration, hence Zenflow is also described as an orchestration layer.
Zenflow was developed by the Zencoder team. Thus Zencoder plug-ins work in Zenflow, and features from Zenflow (such as guided workflows) have been added to Zencoder. The CEO of Zencoder, Andrew Filev, told me that his team of experienced engineers had been using Zenflow for their own product development for over a year when I questioned whether it is ready for production code.
The high-level description of the relationship between Zencoder and Zenflow is that Zenflow is the workflow brain and Zencoder executes the work. You may have noticed some naming confusion: Zencoder is not only the name of the company and of its AI plug-in for IDEs, but it is also the name of its in-house coding agent, which is one of four options for Zenflow (the others are Claude Code, Codex, and Gemini) and one of about nine models available to the Zencoder plug-in.
When you start a Zenflow project, you’re offered a choice of standard workflows: Quick Change, Fix Bug, Spec and Build, or Full SDD Workflow, depending on scope. The wider the scope, the more structure you need in the workflow to keep the implementation from drifting away from the requirements. You can also define your own custom workflows, perhaps to conform to your shop’s standards.
Zenflow can run multiple tasks in parallel in isolated environments. The agents coordinate within workflows without corrupting your codebase.
Zenflow also automates verification of its changes. Every workflow runs automated tests and cross-agent code review. Failed tests trigger automatic fixes. Your code ships only after passing all the verification gates.
Zenflow projects are broken down into tasks, and those are divided into subtasks and chats. Each task runs inside its own isolated Git worktree. You can view the status of all tasks in Kanban boards or stacked list views.
Zenflow supports multiple workflows, from quick changes all the way up to full spec-driven development. You can also define custom workflows.
Foundry
Choosing an AI coding environment
Which AI-supported development environment should you choose? As we’ve seen, there are plenty of good options.
GitHub Copilot is one of the most mature AI coding plug-ins for VS Code, and it supports a wide range of AI models.
Google Antigravity 2.0 is a standalone desktop application that is an independent, agent-focused surface. Antigravity IDE is a separate download that looks and feels similar to the original Antigravity. Antigravity CLI is a way to invoke, monitor, and interact with Antigravity agents from your terminal. These tools are among the best ways to take advantage of Gemini models.
JetBrains Air is a relatively new agentic development environment that allows you to provide your own subscriptions or API keys for OpenAI, Anthropic, and Google models.
Kiro IDE supports both vibe-coding and spec-driven development flows. With my free plan, Kiro IDE currently supports two Claude models.
Zed is about the fastest IDE I have used, and it integrates with a flock of language models, mostly using a “bring your own key” paradigm. Its advanced features include collaborative coding and remote development.
Zenflow supports multiple workflows, from quick changes all the way up to full spec-driven development. You can also define custom workflows. Zenflow works with the Zencoder coding agent as well as Claude Code, Codex, and Gemini.
There is no winner: It’s really a matter of which tool fits your use case and makes you happy. If I could have everything I wanted in one tool, I would take the speed and power of Zed, the spec-driven development capabilities of Kiro and Zenflow, and the agentic capabilities of GitHub Copilot, Google Antigravity 2.0, and JetBrains Air.
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.”
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.
JetBrains is warning of a critical security vulnerability in its TeamCity DevOps platform that could allow unauthenticated attackers to execute arbitrary operating system commands on vulnerable servers.
“If exploited, this vulnerability may allow an unauthenticated attacker with HTTP(S) access to a TeamCity server to bypass authentication checks and execute arbitrary commands,“ the company said in a security advisory.
The flaw, tracked as CVE-2026-63077, affects all TeamCity On-Premises deployments and has been fixed in versions 2025.11.7 and 2026.1.3.
JetBrains warned that the flaw potentially exposes build environments, stored credentials, and software supply chains. Customers unable to upgrade are advised to deploy a security patch plugin immediately.
TeamCity Cloud customers are not required to take any action, the company reassured.
RCE achieved without authentication
According to JetBrains, the vulnerability resides in the TeamCity agent polling protocol, allowing an attacker with HTTP(S) access to bypass authentication and execute code with the privileges of the TeamCity server process.
The vulnerability carries a CVSS score of 9.8 out of 10 as it requires no authentication or user interaction, making internet-exposed TeamCity servers particularly attractive targets. Classified under CWE-502 (deserialization of unstructured data), the flaw can be used to send specially crafted data through the affected agent polling protocol to trigger remote code execution (RCE).
“Depending on the privileges granted to the TeamCity server process, a successful attack could expose TeamCity data, configurations, and stored credentials, modify server state, and potentially compromise the integrity of build artifacts and downstream CI/CD pipelines,” the company added.
The issue was privately reported on July 10 by security researcher Antoni Tremblay through JetBrains’ coordinated disclosure process.
JetBrains said it had found no evidence of active exploitation at the time of publishing the advisory.
Developers have two mitigation paths
JetBrains is recommending that customers upgrade directly to TeamCity 2025.11.7 or 2026.1.3, both of which include a permanent fix for the vulnerability.
Organizations unable to upgrade immediately can instead deploy a security patch plugin, which is available for TeamCity versions 2017.1 and later. Servers running versions 2017.1 through 2018.1 require a restart after installing the plugin, while newer supported releases can enable the fix without restarting, the company added.
The company also advised administrators whose TeamCity servers are publicly accessible to restrict external access if neither mitigation can be applied immediately.
“As a general best practice, we strongly recommend limiting network access to TeamCity servers to trusted networks wherever possible,” the company said. “We also recommend running the TeamCity server with the minimum operating system privileges required for normal operation.”
Given the vulnerability’s pre-authentication nature and the history of threat actors rapidly weaponizing TeamCity flaws, organizations running self-hosted CI/CD infrastructure are advised to prioritize emergency patching over routine maintenance windows.
The advisory also recommended running TeamCity servers on dedicated hosts separate from build agents, as per official instructions.
A critical vulnerability in the open-source AI agent platform Ruflo could allow unauthenticated attackers to take control of enterprise AI environments by exploiting an exposed Model Context Protocol (MCP) bridge, according to research published by Noma Security.
The flaw, tracked as CVE-2026-59726 and dubbed RufRoot, carries a maximum CVSS score of 10.0 and affects Ruflo versions prior to 3.16.3, Noma Security wrote in a blog post.
The vulnerability allows attackers to execute arbitrary code, steal large language model (LLM) API keys, access user conversations, hijack AI agents, and manipulate the platform’s persistent AI memory through a single HTTP request.
The researchers said the issue stems from an unauthenticated MCP Bridge that is exposed by default and provides direct access to the tools AI agents use to interact with enterprise systems.
“The MCP Bridge isn’t a random auxiliary debug interface; rather, it is Ruflo’s central nervous system. Every tool call, every agent action, every memory operation goes through the MCP bridge,” the researchers wrote. “Mistakenly giving unauthenticated access to the MCP Bridge means giving unauthenticated access to everything.”
One request leads to full compromise
According to Noma Security, Ruflo’s built-in MCP Bridge is an Express.js server that handles every tool invocation made by AI agents. The bridge exposes 233 tools covering shell access, database operations, agent management, and memory storage.
The researchers said the bridge’s /mcp endpoint accepts tool invocations without authentication. In a proof-of-concept demonstration, they used Ruflo’s terminal_execute tool to obtain command execution inside the container with a single HTTP request.
“Because the MCP Bridge requires direct access to the underlying system resources to execute these commands, it creates a high-stakes security boundary,” the researchers wrote. “When an attacker can reach this endpoint without authentication, they gain a direct pipeline to the underlying host infrastructure.”
The researchers said they were able to enumerate available tools, steal LLM provider API keys from environment variables, deploy attacker-controlled AI agent swarms, retrieve user conversations stored in MongoDB, and establish persistence.
The researchers also demonstrated what they described as AI memory poisoning by inserting malicious entries into Ruflo’s AgentDB pattern store, allowing future AI responses to incorporate attacker-controlled instructions.
Every stage of the attack chain was validated against a default Ruflo deployment running on AWS EC2, according to the researchers.
Beyond Ruflo: A broader MCP security challenge
While the authentication flaw is specific to Ruflo, security practitioners say the research highlights broader risks surrounding AI orchestration platforms and MCP infrastructure.
“MCP adoption has outpaced the security defaults built into a lot of orchestration tools,” said Amit Jena, AI Development Manager at Kanerika. “These platforms shipped fast, prioritized ease of setup over authentication, and assumed the network boundary would protect them. That assumption breaks down once the tool sits on a server reachable from a corporate network, which is increasingly where enterprises are running them.”
Jena said the research also points to a security concern that extends beyond a single product.
“The memory poisoning problem isn’t product-specific, and that’s the part worth paying attention to,” he said. “Any platform that gives agents a persistent, writable memory store needs to treat that store as a security boundary: who can write to it, and can you tell system-generated memory from memory an attacker planted. Very few platforms are doing that today.”
He added that, unlike traditional persistence techniques, poisoned AI memory can remain inside a trusted data store and continue influencing future agent behavior after the original intrusion has ended.
Patch addresses attack chain
Noma Security said it disclosed the vulnerability responsibly to Ruflo, which released fixes within hours along with a public security advisory.
According to the researchers, the updated release changes the MCP Bridge to bind to the loopback interface by default and fail closed if administrators attempt to expose it publicly without configuring authentication.
Noma Security also urged organizations running Ruflo to immediately close firewall access to ports 3001 and 27017, rotate all LLM API keys, audit AgentDB for malicious entries because “a patched redeploy alone doesn’t undo poisoning,” and inspect MongoDB for signs of tampering.
Jena said organizations should also review how AI orchestration platforms are deployed and managed.
“If a component can execute a shell command or query a database, it gets the same authentication, network segmentation, and logging as any other privileged system in the environment,” he said. He also recommended that security teams inventory the tools exposed through AI agent deployments, audit persistent AI memory separately from software patching, and narrowly scope and rotate LLM provider credentials following any suspected exposure.
One percent of AI-active developers now generate 46 times more AI-written lines of code per day than the median active user, according to the Cursor Developer Habits Report. The bottleneck is no longer writing software. It is understanding what happens after that software ships.
Every new service, dependency, feature flag, generated abstraction, and deployment path increases the number of ways a production system can fail. AI has compressed the time it takes to create that complexity. It has not compressed the time it takes to understand it.
The result is a production environment that changes faster than engineers can rebuild a mental model of it. AI can help in this situation because most debugging practices were designed for a slower world.
Debugging yesterday and today
For decades, debugging was largely a spatial problem. A failure in Service A belonged to the team that owned Service A. They knew the deployment history, the operational quirks, the useful log queries, and the odd behaviors that never made it into the runbook. Incident response reflected that assumption. Teams owned services. Runbooks were scoped to those services. On-call rotations mirrored organizational boundaries.
That model still works when failures stay local. If a deployment introduces a memory leak, or a bad configuration causes a service to crash, the symptom and the cause usually live in the same place. The owning team can investigate, identify the issue, and restore service. Those incidents are becoming a smaller share of production failures.
AI-generated code is not inherently less reliable than human-written code. The change is volume and speed. Teams can now introduce more code, touch more systems at once, and evolve architectures faster than before. As systems become more interconnected, failures increasingly surface somewhere other than where they start.
A single-hop incident is local. The service experiencing the failure is also the service causing it. Investigation stays inside one team’s boundary.
A multi-hop incident looks different. The checkout API begins timing out. Nothing appears wrong inside checkout. Latency is normal. Error rates are low. The actual problem is a queue consumer silently dropping messages because a schema change deployed two days earlier was only partially backward compatible. The queue team sees healthy throughput. The data platform team never receives a page because nothing in its service violates an alert threshold. Every team is right about its own system, yet nobody can explain why customers cannot complete purchases.
The problem is not a lack of evidence. Modern production systems produce more telemetry than any human can use during an incident. The problem is knowing which evidence matters, which signals are coincidental, and how separate clues connect into a causal chain.
The role of AI in production ops
That changes the role AI should play. AI should not be treated as a magic on-call engineer. A frontier model does not know your architecture. It does not remember prior incidents. It does not know which dashboards lie, which services fail together, what changed last week, or which dependencies matter most. On its own, it reasons inside a vacuum.
The useful version of AI in production is more specific. It can assemble context, test hypotheses, trace dependencies, compare the current incident against past incidents, and rule out explanations that do not fit the timing or blast radius. It can do the work that currently eats the first 20 minutes of an incident: gathering evidence, checking recent changes, mapping dependencies, and narrowing the search space.
Humans still make the decisions that require judgment. They decide whether the evidence is strong enough to act, whether a rollback is worth the risk, whether to wake another team, and whether the safest move is mitigation or deeper investigation. But they should not have to spend half the incident reconstructing a system the organization already operates.
That is the larger productivity shift.
If AI can absorb more of the troubleshooting tax, engineers can focus on the work that actually compounds. They can simplify fragile architectures. They can improve instrumentation in the places where incidents repeatedly go dark. They can design safer degradation paths, sharper alerts, better rollback patterns, and evals that catch semantic failures before customers do. They can feed production knowledge back into development, so code assistants and review processes understand which services are risky, which patterns have caused outages, and which dependencies deserve extra scrutiny.
This is the work engineers rarely get enough time to do because they are stuck resolving the same classes of incidents again and again.
Letting the engineers engineer
The goal is not to remove engineers from production. The goal is to stop wasting their judgment on work the system should already be doing. AI should make incidents shorter, but that is only the first-order benefit. The larger benefit is giving senior engineers more time to prevent future incidents instead of being pulled into every confusing one.
As AI accelerates software creation, production operations need the same kind of acceleration on the other side. Not just faster debugging. Better allocation of human attention.
The AI code avalanche will not be managed by asking engineers to troubleshoot forever at machine speed. It will be managed by making production systems more legible, more resilient, and less dependent on whichever expert happens to be awake.
—
New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.
Microsoft has shipped Visual Code 1.131, an update to its code editor with improvements for monitoring subagents, dictation, and Markdown editing.
Released July 29, Visual Studio Code 1.131 can be downloaded for Windows, Linux, or Mac at code.visualstudio.com.
An enhancement to the Agents window in VS Code 1.131 allows developers to see what a running subagent is doing without opening its conversation. For each subagent, the main conversation now shows the model used by the subagent, how long the subagent has been running, and the tool the subagent is actively calling.
A preview of built-in dictation across VS Code gives developers dictation capabilities without having to install the VS Code Speech extension. The transcription service works in chat inputs, text editors, and the terminal, Microsoft said. A single speech session and microphone selection are shared across all three surfaces, which prevents overlapping recordings and keeps dictated text in the intended location, according to the company. This is an experimental feature.
VS Code 1.131 also introduces a hybrid Markdown editor in the Agents window, allow users to view Markdown files, edit them in place, and add comments that an agent can act on. By using “Reopen editor with”, developers can switch easily between the text editor and the new Markdown editor, both in the Agents window and editor windows. The hybrid Markdown editor is an experimental feature.
For accessibility, screen reader users now can read terminal output at their own pace while commands continue to produce output. Set terminal.integrated.accessibleViewPreserveCursorPosition to always preserve the cursor position in the terminal Accessible View, including when new content arrives. Existing true and falsevalues continue to work. Terminal live updates also use a non-interrupting ARIA status announcement instead of an assertive alert. Output remains available to screen readers without repeatedly interrupting other speech.
VS Code 1.131 followed VS Code 1.130 by one week. VS Code 1.132 should arrive soon.
Model Context Protocol (MCP), the emerging standard for connecting AI models to external tools and enterprise data, is undergoing its biggest architectural overhaul yet.
The latest release candidate, scheduled for release on July 28, removes protocol-level sessions in favor of a stateless architecture, a change which industry experts say is intended to make MCP easier to deploy across standard cloud infrastructure as enterprises move AI pilots into production.
“The session-based model made sense when MCP servers were local processes on a developer’s laptop. In production, it became an operational tax,” said Muskan Bandta, cloud associate at ZopDev.
“When your infrastructure team asks whether MCP services can scale like other cloud applications, the answer used to be ‘not quite.’ With the move to a stateless architecture, the answer is now yes,” Bandta added.
Earlier versions of the protocol maintained information about every client connection, meaning servers had to keep track of each session throughout an interaction. While that approach worked well for local development, it complicated deployments across multiple servers because requests often had to be routed back to the same machine, limiting scalability and making MCP a less natural fit for modern cloud architectures.
“Under the new stateless design, every request contains the information needed for any available server to process it independently. Applications that need to maintain context across multiple requests can still do so, but developers must now manage that state explicitly rather than relying on the protocol itself,” she said.
This transition to a stateless design goes beyond simplifying infrastructure by fundamentally changing how AI applications manage and share context across tools, according to Amit Jena, AI development manager at IT consulting firm Kanerika.
Instead of keeping application state hidden inside protocol sessions, the new design makes it explicit, allowing AI models to access, reason over, and pass that information between tools, giving developers greater control over how context is preserved and shared across tools, Jena said.
It should also make AI workflows more portable, resilient, and easier to orchestrate across distributed environments, he said.
MCP’s new features
Other changes to MCP include the addition of a Multi Round-Trip Requests (MRTR) mechanism that changes how AI agents request additional information they need to complete a task.
Instead of relying on a persistent connection between the client and server throughout the interaction, the new mechanism lets the server request additional input through a standard request-response exchange before continuing the task, Jena said.
Routable transport headers, another addition, enable API gateways and other networking infrastructure to identify and route MCP requests without inspecting their contents.
They reduce processing overhead, lower latency, and let enterprise teams enforce routing, rate-limiting and security policies more efficiently using existing API management infrastructure, Jena said.
MCP is also getting an updated authorization framework built around OAuth 2.1 and OpenID Connect; interactive MCP Apps; and deterministic caching of tool and resource listings to improve LLM prompt-cache hit rates, potentially saving on token costs.
Rebuilding the trust boundary
The MCP release steering committee also decided to deprecate some legacy features, including Roots, Sampling, Logging, the older HTTP+SSE transport and Dynamic Client Registration, although these will continue to work in this version and any other released over the next year.
The deprecation of Sampling is likely to have the biggest impact because it changes who is responsible for interacting with foundation models, said Jena.
“Sampling let MCP servers invoke the LLM through the client, which meant the server had a callback path into the model without owning that connection. Deprecating it means rebuilding that trust boundary,” Jena said. “Your server now calls the model provider directly. That changes your network architecture, your auth model, and depending on how you’ve built cost attribution, your billing flow.”
The year-long transition period will be enough for teams to audit their sampling dependencies now, said Jena: “The risk is that teams who haven’t implemented sampling themselves won’t know if a third-party MCP server they’re depending on uses it.”
Updated MCP SDKs
To accompany the protocol update, there are updated MCP SDKs for Python, Typescript, Go, and C#. These support both the old and new protocol versions, so new clients can continue communicating with older servers, while updated servers will also support older clients, reducing the risk of immediate disruptions.
That backward compatibility should make the transition largely incremental, except for enterprises that built custom infrastructure around MCP’s earlier session-based architecture, Bandta said.
Identifying and auditing those session dependencies may not be easy, Jena warned.
“Session management complexity tends to be hidden across multiple layers — the gateway config, the deployment scripts, the monitoring dashboards. The code change is small; finding everywhere the assumption lives is what takes time,” he said.
Enterprise software developers continue to be in danger of falling victim to slopsquatting, where AI coding tools hallucinate the existence of nonexistent libraries and hackers create malicious packages in response.
The top AI coding tools are remarkably consistent in their hallucinations: Researcher Aleksandr Churilov found the same 127 fake package names generated by five different LLMs.
Slopsquatting is a relatively new form of malware attack that involves the creation of malicious packages in response to the hallucinations of AI coding tools, causing the malicious packages to be incorporated into legitimate applications.
As of April this year, 53 of those names — 41 on the PyPI software repository and 12 on npm —are still available for registration.
According to the study, there are two reasons for this amount of conformity in the output of the models. First, models may learn the same incorrect package references from shared public training material, such as tutorials and documentation.
Second, they may independently extrapolate plausible names from ecosystem conventions. In this way, they could produce names that look correct, even if they don’t actually exist.
While Churilov’s research will worry CISOs and security-conscious developers, there is some relief. The research has not yet found any evidence that any of the remaining 53 names have been registered maliciously, nor used in an attack.
Login
