News For Dev-ops

Copilot CLI is becoming the default agent harness in GitHub Copilot for JetBrains, and our local harness will be deprecated. This change provides greater consistency across all GitHub Copilot surfaces and is an important step toward faster feature parity and higher-quality results in GitHub Copilot for JetBrains. Copilot CLI sessions run independently in the background on your machine and use the Copilot CLI agent harness, while the IDE starts, monitors, and steers them. This is the same architecture used across GitHub Copilot today and adopting it in JetBrains lets us ship the same capabilities to JetBrains developers at a faster pace. Why we're making this change Copilot is not the same product it was a year ago. Agentic coding — long, multi-step sessions that plan, edit, and verify work autonomously — is now the core of the experience, and the harness that runs those sessions matters more than ever. Until recently, JetBrains has used its own local harness. Maintaining a sepa...

During an exchange of war stories, a colleague of mine told one from back in the days when Windows included a processor emulator for x86-32 on systems that natively ran some other processor. (This has happened many times. And no, I don't know which processor this particular story applied to.) This particular emulator employed binary translation, generating native code to perform the equivalent operations of the original x86-32 code. This offered a significant performance improvement over emulation via interpreter. You can imagine that x86-32 is just a bytecode, and the emulator is a JIT compiler. Anyway, my colleague found that there was one program that needed to allocate around 64KB of memory on the stack and initialize it. The standard way of doing this is to perform a stack probe to ensure that 64KB of memory is available , then subtracting 65536 from the stack pointer, and then initializing the memory in a small, tight loop. But using a loop to initialize the memory was to...

Amazon FSx for OpenZFS now supports on-demand data replication across AWS opt-in Regions, enabling you to easily and efficiently transfer incremental point-in-time snapshots of your volumes beyond AWS Regions that are enabled by default. On-demand data replication provides a simple and resilient way to implement disaster recovery, replicate production data to a different Region or account, and enable lower latency data access for your global customer base or workforce. Amazon FSx for OpenZFS provides fully managed, cost-effective, shared file storage powered by the popular OpenZFS file system, with rich data management capabilities like snapshots, data cloning, and compression, along with sub-millisecond latencies and up to 10 GB/s of throughput. Opt-in Regions are AWS Regions that are disabled by default, in contrast to regions that are enabled by default. Previously, on-demand data replication was supported only between accounts in AWS Regions that are enabled by default. Starting...

Amazon CloudWatch now lets you ingest metrics via the OpenTelemetry Protocol (OTLP) and query them using Prometheus Query Language (PromQL). You pay per GB ingested, with 15 months of storage included. Custom OTel metrics and AWS vended metrics from more than 70 services are queryable together in PromQL. CloudWatch provides a Prometheus-compatible query API that works with Grafana and other Prometheus-compatible tools. For Amazon EKS customers, Container Insights with OpenTelemetry provides curated dashboards and metrics enriched with OpenTelemetry semantic conventions. You can enable it from the EKS console or via CloudFormation, CDK, or Helm. If you're already using CloudWatch Container Insights, you can dual-publish Classic and OTel metrics simultaneously and migrate alarms and dashboards on your own schedule. Available in all commercial AWS Regions except Middle East (UAE), Middle East (Bahrain), and Israel (Tel Aviv). For pricing details, see the Amazon CloudWatch pricin...

AWS DevOps Agent now supports custom SRE agents, bring-your-own sub-agents, and headless access via MCP and A2A protocols. These capabilities enable teams to automate recurring SRE workflows, extend DevOps Agent by connecting it to other agents, and access its capabilities from the tools they already use, including Kiro, Claude, and other coding assistants. With custom SRE agents, teams can create and schedule agents within Agent Spaces that run on a cadence. For example, create a daily database health report that checks for slow queries and parameters that need tuning, or build an agent that reviews logs from the past 24 hours and flags anomalies. In headless mode, developers can invoke DevOps Agent from the tools and agents they already use via A2A or MCP protocols. For example, the Kiro power for AWS DevOps Agent lets developers check production health and investigate issues without leaving their IDE. Teams can also connect their own sub-agents built with Amazon Bedrock or third-p...

Themes are personal. Some of us live in dark mode, some swear by high contrast, and some of us have very strong opinions about that one shade of blue from years ago. The new themes in Visual Studio 2026 are built on Fluent, which gives us a much more consistent and accessible foundation, but we have heard from plenty of you who want more control over specific colors. Accent colors, hover states, the line between the shell and the tab headers… the small things that make an IDE feel like yours . So, we did something about it. Visual Studio now has a new Theme colors options page that lets you customize any Fluent color token directly inside the IDE. No extensions, no JSON files to hunt down, no restarts. Just open the page, find the token you want, and pick a new color. Where to find it Open it from Tools > Options > Environment > Visual Experience > Theme colors . You'll see every Fluent color token in the active theme listed in a searchable grid. Pick one, change ...