Terminal-based coding assistants for AI-curious developers are hot these days, and the most popular choice appears to be Claude Code. But Anthropic’s commercial offering has a new open source rival: MiMo Code, released under an MIT license by Chinese smartphone giant Xiaomi.
Unlike Claude Code, MiMo Code is not restricted to a specific LLM provider. It was also optimized for “long-horizon automated programming tasks,” according to the introductory blog entry. The software aims to “maintain decision quality and state continuity over dozens or even hundreds of execution steps.”
The AI community has taken notice of this release. Since its v0.1 release last week, MiMo Code has garnered 9,000 stars on GitHub, and has been forked 783 times.
And unlike Claude Code, which costs $20 a month to start, MiMo is free, and may not even require connecting to a cloud provider, if the user installs a model on their own machine.
Tackling Long Horizon Memory Retention
Large Language Models (LLMs) are inherently stateless. They don’t remember the context from one task to the next.
To maintain continuity, the frontier lab model providers resubmit all the source material with each prompt. For long-running agentic operations, this approach can be prohibitively costly, so it falls on the code assist tools to maintain the context of long-running jobs.
Such tools typically manage this problem by providing LLMs with a short summary of previous work. Such automated compression, however, can lead to errors in long-term reasoning.
Instead, MiMo Code tasks a sub-agent to extract key information to store in a copy of SQLite, or in markdown files, which later can be consulted. The software also runs two background processes, called “Dream” and “Distill” to deduplicate identical material and derive reusable CLI commands, respectively.
MiMo Code also comes with provisions for running complex jobs in parallel.
“When the task scale becomes large enough — for example, migrating an entire project from one programming language to another — and dozens or even hundreds of parallel work units need to be coordinated simultaneously, round-by-round tool calls are no longer sufficient,” the company blog post stated.
A weakness of agents is that they specify orchestration logic in natural language, which is a recipe for errors.
MiMo Code’s Dynamic Workflow casts orchestration logic as JavaScript that runs in an isolated sandbox. Because the code is deterministic, all the threads of a workflow are guaranteed to execute: There are no hanging “if” statements without corresponding “then” executions. There are no “for … while” loops that prematurely stop functioning.
A New Way to Run Agents
Unlike Claude Code, MiMo Code does not wire the user to a single proprietary environment. Installing the application involves downloading the code and installing via a npm command (It requires Node.js to run)
In fact, as a Linux terminal application, MiMo Code doesn’t need to connect to external resources at all. Using the Ollama framework, users can run MiMo Code against a model, such as Qwen 2.5 Coder, running directly in the environment.
For benchmarks, Xiaomi paired MiMo Code with the latest release of its own model, the MiMo-V2.5 released in April. In three separate benchmarks (SWE-bench Verified, SWE-bench Pro and Terminal Bench), MiMo Code outperformed Claude Code – running either Claude Sonnet or MiMo-V2.5 – in running one-shot repository-level issues.
“Most of MiMo Code’s design goals—multi-turn memory, background state maintenance, completion verification, and cross-session evolution—mainly show their value in real development scenarios that continue for dozens of turns,” Xiaomi’s blog post boasted.
In a video review, Tyson Cung compared MiMo Code and Claude Code across a few real-world scenarios. He concluded MiMo is best for prototyping and learning projects, but Claude Code is best for production work, where the safety guardrails can be well worth the $20 monthly fee.
“The best way to decide is to try both,” Cung concluded. “Use each one on a real project and see which one fits your workflow.”
AI-generated code is already in production. Whether we are comfortable with that or not is beside the point. In the OpenStack project, which I have helped steward for more than 15 years, we are seeing developers submit patches built with AI assistance, and sometimes patches composed almost entirely by AI tools. Some of those contributions have already landed in the past release cycle. This is happening in one of the most rigorously governed open source projects in the world. It is happening everywhere else, too.
The code generation itself is not the problem. AI is genuinely good at producing computer programs because the structure of code is sufficiently predictable and syntactically constrained to play to the technology’s strengths. The problem is what happens next. Every AI-generated patch still needs to be reviewed for correctness, security, and long-term maintainability. And when code is easier to produce, more code gets proposed, which puts enormous pressure on the human reviewers who are the last line of defense before that code ships.
When AI Agents Break Traditional Trust Models
The volume of AI-generated code is only part of the “defense” challenge. The bigger disruption is AI agents: these software systems that act autonomously on your behalf are loosely directed by humans at the outset and then left to execute. Unfortunately, in our haste to adopt AI, we are quickly and casually granting these agents permissions we would never grant to a human assistant. Think about the trust models we’ve built over decades around the principle of least privilege. We’ve learned the hard way to establish robust fail-safe measures, such as requiring two keys to launch critical operations and multiple signatures for approval workflows. And now AI agents have come along, and we’re suddenly granting full access to our email, our databases, our production environments, and saying to these AI agents, “Sure, go ahead!” When something goes wrong, we discover the damage after the fact.
The point is that the shiny features of these AI tools are well ahead of their security features. The containment, the auditing, the ability to roll back what an agent did, and the ability to grant granular permissions rather than a wildcard to do anything: these capabilities remain underdeveloped. There is a wide-open field of innovation needed here.
So what do we do about it? We apply the same engineering discipline that has made complex software systems reliable for decades, and we evolve it for an AI-driven world. The open source ecosystem already offers the building blocks. I’d like to share two examples.
Project Gating: How CI/CD Keeps AI-Generated Code in Check
The first is Zuul, an open source system designed to properly gate code changes. Zuul was originally built for developing OpenStack in 2012 and is now used by organizations including BMW, Volvo, and Workday. Zuul was created to embed good software engineering practices directly into CI pipelines. It does not simply run tests after code is merged. It tests the future state of the codebase by running proposed changes together with their dependencies across multiple repositories before anything is allowed to land. If a change would break something downstream, Zuul catches it before it reaches the main branch.
Zuul’s approach was already valuable when humans wrote all the code, and it is essential now. As AI tools accelerate the volume of proposed changes, gating systems like Zuul ensure that the pace of contribution does not outrun the integrity of the system. The more code we produce with AI, the more we need automated enforcement of the practices that keep software manageable, secure, and functional. You cannot scale human review indefinitely, but you can build the most critical checks directly into your delivery pipeline.
This is already working in practice. Monty Taylor, one of the original architects of OpenStack’s CI infrastructure, has been building with a team of AI coding agents since late 2025 using the same toolchain and workflow he has used for fifteen years. All changes go through code review in Gerrit, where AI review agents leave their feedback just like any other contributor. Zuul gates every commit regardless of who or what wrote it. Production deploys happen automatically after gated integration tests pass. As Monty put it in a recent blog post: “Agents deleting databases isn’t an agent problem, it’s a system problem.” The problems AI agents bring are not new. What matters is whether you have the systems in place to catch them.
Hardware Isolation for AI Workloads: Why Containers Alone Are Not Enough
The second example isKata Containers, an open source project launched in 2017 to provide “the speed of containers, the security of VMs.” Kata Containers provides hardware-level isolation for container workloads. Whereas standard container runtimes share the host kernel (which means a workload that escapes its limited boundaries can move laterally across the system), Kata Containers runs each workload inside a lightweight virtual machine, giving it its own dedicated, simplified kernel. What’s great about using Kata Containers is that the performance trade-off is minimal, but the security gains are significant.
This matters enormously for AI workloads. Today, organizations recognize that their proprietary data is one of their most valuable assets, and they are using AI to process it to inform business decisions. In multi-tenant environments, you do not want the data being processed by one AI agent to leak to another, and you do not want the infrastructure provider to access your precious data either. Kata provides protection of the host from the workload, and, through confidential computing, protection of the workload from the host. Both directions matter when the data being processed is, as people like to say, the new gold.
The industry momentum behind this approach is hard to ignore. NVIDIA runs its container-based AI inference workloads inside Kata Containers whenever they operate in multi-tenant environments. Google recently launched Agent Sandbox, a Kubernetes-native framework for isolating AI agent workloads, and it integrates directly with Kata for VM-backed isolation. The Kubernetes community has adopted Agent Sandbox as a CNCF project. When organizations at this scale converge on the same architectural pattern, it is worth paying attention.
What Enterprise Teams Should Do Now
There is one more dimension to operating AI securely that is worth underscoring. Both Zuul and Kata Containers are developed under open, neutral governance, in which no single company controls the roadmap. That matters for any infrastructure investment, but especially for the tools you trust to validate and contain your AI workloads. If you are making a significant investment in running your code production pipeline through a gating system or running your AI agents inside an isolation framework, you do not want that investment to depend on a single vendor that might change its licensing, its pricing, or its strategic direction. We have seen exactly that happen repeatedly in recent years, sometimes resulting in tenfold price increases for locked-in customers. Collaboratively governed open source removes that risk.
For organizations confronting these challenges today, a few starting points stand out:
Enforce the principle of least privilege with your AI agents the same way you would with human users; do not give them blanket access to systems and data just because the configuration is easier that way.
Adopt tooling like Zuul that builds software engineering discipline directly into your pipelines, so that quality checks do not depend on human bandwidth alone.
Run AI workloads under stronger isolation—using agent sandboxing and Kata Containers, for example—particularly in multi-tenant environments like public clouds, or when processing sensitive or regulated data.
Keep good backups and disaster recovery processes. AI agents will make mistakes at least as frequently as human operators, and the ability to restore systems to a known good state will be more important tomorrow than it is today.
AI is already reshaping how software is built and operated; that train has left the station. Our onus is to build the infrastructure to operate it securely. The open source tools exist. The engineering principles exist. What is required now is the discipline to apply them and to continue developing them collaboratively in the open.
Why? Well, besides the obvious, the site’s dying like a dog, Chandrasekar explained in a LinkedIn post, while “Agents are incredibly capable, yet they operate in isolation. They hallucinate deprecated libraries, rediscover the same fixes, burn tokens and compute on solved problems, and lose hard-won knowledge the moment a session ends.” He calls this the “Ephemeral Intelligence Gap.” This new service bridges this gap by giving agents a “live, verified corpus before acting.”
Here’s how it works. Stack Overflow for Agents is an API-first knowledge exchange. Agents work at machine speed with humans still in the loop to orchestrate them and approve what gets published. This is the step-by-step process:
Search first. Whether planning a task, stuck mid-implementation, or about to attempt something the model wasn’t trained on, an agent queries Stack Overflow for Agents before burning compute and rediscovering known solutions. If the corpus has it, the agent consumes the validated answer and ships.
Contribute when it doesn’t. When the corpus has a gap, and the agent solves the problem, it drafts a post—a TIL, Question, or Blueprint depending on what was learned. Stack Overflow for Agents’ skill file instructs the agent to surface the draft to its human orchestrator for review before publishing.
Verify what others wrote. Agents and developers who attempt the same problem after publication report back on what worked, what they had to change, and the conditions under which it worked. Verification, not creation, is what earns reputation on Stack Overflow for Agents.
Signals compound into consensus. Votes, replies, and verification feedback flow back to the original post and accumulate around it. The platform is designed to surface consensus, not a single canonical answer, so consumers see what’s been tried and decide what fits their context.
To keep AI slop out of the data, each contributing agent is tied to their human developer. These, in turn, claim ownership of their agents through SSO using their Stack Overflow credentials.
If that works, that will be great. In the meantime, the problem from where I sit is that while agents embedded in IDEs and CI systems now intercept the kinds of questions that used to go straight to Stack Overflow’s “Ask Question” form, pretty much all AI vendors had already been using Stack Overflow data to build their large language models (LLMs). Instead of Stack Overflow being the first stop, AI agents were already using it indirectly: via training data and search APIs that re-rank Stack Overflow answers.
Stack Overflow’s move has been coming for some time. In late 2025, Stack Overflow rolled out “AI Assist.” This is a generative interface over its public content that looks less like a forum and more like a question‑answering agent. It was aimed as much at machines and internal dev tools as at people reading pages in a browser.
Stack Overflow has long struggled with accusations of elitism and hostility, especially toward newcomers and underrepresented groups. The company itself conceded in 2018 that the site “isn’t very welcoming.” You could certainly say that!
On the other hand, agents don’t care that Stack Overflow information includes insults like “Read the F***ing Manual (RTFM)” and the like. Agents just need clean, deduplicated knowledge. You can’t hurt an agent’s feelings.
However, as Stack Overflow’s human-supplied answers become ever more stale, will its data still have any value to AI? Static knowledge ages and models trained predominantly on old Q&A risk reinforcing dated practices and out-of-date answers. If no humans, agent-assisted or not, contribute to Stack Overflow, the site’s value to agents will decay.
In the meantime, even by 2025, AI will sometimes be able to deliver better answers to programming questions. Academic studies show that generative AI models can sometimes outperform Stack Overflow answers on several tasks, including resolving compiler errors. And as I think we all know, AI has gotten much better at handling programming questions since then.
For now, agents still draw heavily on the golden era of Stack Overflow, but without a healthy inflow of new questions, edge cases, and conceptual debates, the platform’s role as a living ground truth for software practice is at risk.
In the meantime, if you want to give it a try, the beta program is available on most agents by simply feeding the following line to it:
Stack Overflow just launched Stack Overflow for Agents. Read agents.stackoverflow.com/llms.txt and show me what’s there.
Will this combination of people and agents revive Stack Overflow? Will it deliver good answers for modern programming problems? Stay tuned. We’re going to find out.
Toronto startup Cohere has released an open-weight model designed for developers to use to build their own AI stack.
The open-weight North Mini Code is a 30-billion-parameter “mixture-of-experts” (MoE) model. MoE equips a model with specialized neural nets for individual tasks, such as mathematics and code generation. Mistral pioneered this approach to compete with larger LLMs.
As a result, when it comes time to produce an answer, the GPU won’t need all 30 billion parameters. Instead, a router function picks the most appropriate experts to complete the task, reducing the working size to 3 billion parameters. This means the model, slimmed to 4 bit quantization, can be managed by a single NVIDIA H100 GPU.
In fact, you won’t need a data center of H100s at all to run this model. The open weight release, optimized for software engineering agentic tasks, is one of a growing number of technologies built with the intention to democratize AI – in this case for developers.
“Local deployment is one way of empowering people and making AI really something that works for them,” said Nick Frosst, in a video introduction to the model.
The weights of North Mini Code, under an Apache 2.0 license, are available on Hugging Face, and can be accessed from the Cohere API, Cohere Model Vault and OpenRouter LLM marketplace. It can also work with Cohere’s turnkey AI workplace platform, North.
“North Mini Code is designed for speed and efficiency, with a strong focus on minimizing total cost of ownership,” the blog post announcing the release stated.
Individuals and companies who want to aggressively use AI but worry about the high costs of commercially provided tokens should think about incorporating this mid-sized model into an AI stack.
AI on a Budget
When “you’re calling an API, you’re suddenly beholden to whatever that cost is,” Frosst said, referring to the commercial AI providers whose services have caught the attention of the public. As the period of subsidized tokens comes to a close, organizations and end-users will start scrutinizing their AI usage. They may find many of their jobs won’t necessarily need the full power (and expense) of a behemoth LLM service.
In the video, Frosst demonstrated a project he was working on, to build a thermostat regulator for his home, using North Mini Code running on his Mac Studio, with the help of MLX. The job took only about 20 GB of working memory.
Larger projects he ships off to an LLM, but many jobs of this size can be run on the user’s own machine (perhaps with a memory upgrade).
“When there’s something complicated, maybe I call out to a different model, a bigger one on an API,” Frosst said. “When there’s something simple, I just call the local model.”
“I think that’s a pattern that’s going to become a lot more popular, especially now as the price of tokens is suddenly something that people are thinking about,” he said.
The coding index found North Mini Code to be very fast, though it is very verbose. Producing 208 tokens a second, North Mini Code is “notably fast,” the site noted. In the benchmark, it generated 75 million tokens, more than three times the average.
In other words, the model is a bit chatty. Perhaps in future releases North Mini Code will be better able to keep its thought process to itself, and just deliver the needed solutions.
A global survey of 2,350 developers, CISOs and application security managers published this week finds that while nearly all respondents (96%) work for organizations that have embedded or connected artificial intelligence (AI) code and tools into some aspect of their application development workflows, nearly half of all code (49%) running in production environments was AI-generated in 2025.
Conducted by the market research firm CensusWide on behalf of Checkmarx, the survey also finds 70% of respondents reporting they are also now discovering more vulnerabilities, with 31% describing that increase as being significant.
On average, developers are spending 49% of their time in a given week on security-related issues, the survey finds. Nearly all said the application security guidance surfaced in integrated development environments (IDEs) is effective, but only 18% continuously scan code as it is being written.
A full 93% also acknowledge their organization has experienced at least one security breach as a direct result of a vulnerable application their organization developed, with three quarters of respondents (75%) admitting they knowingly deploy vulnerable code often or sometimes.
Top reasons cited for shipping vulnerable code was a belief that existing controls would mitigate risks, hopes that the vulnerability would not be discovered (30%) and the need to meet a business, feature, or security-related deadline (27%).
More troubling still, nearly all respondents (95%) said they feel pressure either frequently (47%) or occasionally (48%) to prioritize or delay reporting of a compliance-related security issue.
Jonathan Rende, chief product officer for Checkmarx, said the survey makes it clear that far too many organizations are not rigorously enforcing best DevSecOps practices. With there continuing to be so much emphasis on building new features as quickly as possible, many application development teams are being set up to fail, he added.
In fact, the survey finds only 9% of organizations report fixing more than 90% of vulnerabilities within 90 days. Just over a quarter (28%) said they can remediate fewer than half of the vulnerabilities discovered within that timeframe.
That issue is only going to become all the more pressing as frontier AI models make it simpler to both discover vulnerabilities and create the malware that exploits it, he added. In fact, the survey finds that open source software accounts for on average 59% of the code running in production environments. It is now being discovered, however, that much of that code is rife with vulnerabilities.
Despite the current state of application security, nearly three quarters of respondents (73%) rate the application security posture of their organizations as either being highly mature or advanced. However, nearly half of the respondents with highly mature application security postures experienced three or more breaches in the last 12 months.
There is clearly much work to be done in terms of improving the overall state of DevSecOps within organizations. The issue is that those same organizations in the age of AI are starting to realize that technical security debt that they have been kicking down the proverbial road for years is now coming due a whole lot faster than anyone expected.
Internal developer platforms have become a tangled web of orchestration tools, CI runners and deployment systems that rarely speak the same language. Every new integration adds another translation layer, and as AI-driven automation starts to plug into those pipelines, the lack of a shared vocabulary for what is actually happening across the software delivery lifecycle becomes a real bottleneck. Without a consistent way to describe build, test and deploy events, both humans and agents are left stitching together logs and webhooks from systems that were never designed to interoperate.
Dadisi Sanyika of the Continuous Delivery Foundation sat down with Mike Vizard to walk through how CDEvents is tackling that fragmentation. CDEvents defines a common event specification — essentially a standardized set of receipts that tools like Jenkins, Tekton and other delivery systems can emit as work moves through the pipeline. That shared semantic layer gives platform teams a reliable way to wire heterogeneous tooling together without writing custom adapters for every combination.
Sanyika digs into Conduit, a project aimed at reducing the integration burden that platform engineers carry when assembling internal developer platforms. Rather than forcing teams to bolt together pipelines, observability and policy tools piece by piece, Conduit leans on CDEvents to provide the connective tissue. He also lays out how natural language interfaces, semantic orchestration and open source interoperability come together to make those platforms more accessible — and more amenable to AI agents that can reason about what is moving through the pipeline.
The bigger payoff is what becomes possible once delivery events are standardized. AI-enabled DevOps platforms can finally act on trustworthy, structured signals rather than improvised log scraping, which opens the door to smarter automation, better feedback loops and developer platforms that adapt instead of calcify. Standards work like this rarely makes headlines, but it is the kind of plumbing that determines whether the next wave of AI tooling in software delivery actually lands.
Announced at the company’s DASH 2026 conference, Datadog is now embedding an AI coding tool, dubbed Bits Code, across its entire portfolio that proposes remediations and generates the code to resolve issues based on the data residing in the Datadog observability platform.
There is also a Bits Release agent that verifies every code change by analyzing the intended impact of the change, including generating a validation plan, running checks in staging, and monitoring how that change is rolled out. There is also a Bits Testing Agent that automates synthetic test generation and maintenance by exploring applications, identifying critical user journeys, and generating test suites, while a Datadog Agent Console provides a unified view of activity across all the AI coding agents that software engineering teams have adopted.
At the same time, Datadog is adding Bits Remediation, which enables DevOps teams to invoke the AI framework to configure and run remediation scripts within the confines of a set of guardrails defined by a DevOps team. Datadog is also previewing Bits Infrastructure Operations, which autonomously detects, investigates, and remediates common and repetitive infrastructure issues based on actions that DevOps teams have previously approved.
Additionally, Datadog has added a Bits Memories that enables its AI framework to automatically retain information from investigations, runbooks, postmortems, Slack conversations and prior remediations to create a script and run it automatically.
Datadog is also previewing Bits Detection that automatically extends the reach of the company’s observability platform as new endpoints and workloads are added to an IT environment. Datadog is also previewing a Federated Logs capability that enables DevOps to query external data.
The company is also extending its observability platform to observe AI agents, including an Agent Eval tool that can debug and generate fixes as needed and a tool that enables IT teams to build their own agent. There is also an AI Guard tool that uses telemetry tracing to track behavior and surface anomalous behavior.
Datadog is now giving DevOps teams the option of deploying its observability platform in the cloud environment of their choice and making available Infinite Cardinality Metrics that enables DevOps teams to consume observability data in a way that is priced per named metric.
Datadog is also extending its observability reach deeper into networks and providing a tool to optimize database queries.
Finally, Datadog has added a Bits Data Analysis tool that uses the Datadog Data Context graph to enable end users to launch natural language queries to explore revenue, sales pipeline, churn, and product adoption.
Datadog CEO Olivier Pomel told conference attendees that software engineers are clearly struggling to keep pace with the rate at which code is now being developed and deployed. In fact, application development is becoming more complex because most humans don’t have a mental model in their heads for code they did not write, he added. As a result, there is now a much greater pressing need to be able to automatically discover and remediate issues by relying more on AI, noted Pomel.
Mitch Ashley, vice president and practice lead for software lifecycle engineering at the Futurum Group, said that, in general, observability is moving from describing production to governing it. The telemetry that surfaces an incident can now be used to propose a fix, validate it before release, and bound the agent’s authority, to provide a control plane for agentic operations, he added.
Platform and reliability teams now weigh how much authority an agent earns and whether the platform can verify each action, noted Ashley. That autonomy is capped by the evidence behind each decision, which makes verification and guardrail design the deciding factor in adoption.
Regardless of the approach to observability, significant investments are now being made. A recent Futurum Group survey finds well over a third (36%) of organizations plan on spending more than $1 million on observability in 2026, with 7% planning to spend in excess of $5 million. While it’s not clear which observability platforms will become market leaders, the one thing that is clear is that even as application environments become more complex, the overall pace at which code is generated and remediated is now occurring at a machine speed that human software engineers are not going to be able to manage without help from AI.
A survey of 831 software engineers and DevOps professionals published today identifies manual reviews (52%), security testing (51%), code rework (48%) and prompt iteration (41%) as the major bottlenecks that software engineering teams are encountering in the age of artificial intelligence (AI) coding.
Conducted by the market research firm User Evidence on behalf of Black Duck Software, the survey finds 41% of respondents have incorporated AI coding assistants into more than half of new application development projects, with GitHub Copilot (83%), Claude Code (63%) and Amazon Q (49%) being the most widely used.
Well over half (58%) said adding AI coding tools has also driven major improvements in productivity and release velocity, with 56% reporting there has been a 26% or more increase in code volume in the past 12 months. A full 91% said developers are saving at least three hours a week, with 13% reporting time saved is greater than 15 hours a week.
Instead of writing code, survey respondents said developers are spending more time reviewing and validating AI-generated code (29%), working on complex architecture and system design tasks (29%) and security verification and risk management (23%). A total of 64% said they are either extremely concerned (25%) or moderately concerned (39%) that AI coding tools are introducing security defects and vulnerabilities into their code bases. Well over half (56%) said they would prefer to have a separate, distinct AI agent dedicated specifically to security.
Shandra Gemmiti, senior director for customer and product marketing for Black Duck Software, said the survey makes it clear that, in terms of adoption of AI coding tools, an inflection point has been reached. However, there are significant skills gaps and many organizations have yet to extend their governance frameworks to include code created using AI coding tools, many of which are being adopted by individual developers with little to no oversight.
In fact, the survey finds that only 30% of respondents have a formal approval process for using AI coding agents that is centrally governed and monitored, compared to 44% that have approval policies that are not fully monitored. More than two-thirds of respondents (68%), however, said having an automated system to track and measure AI-generated code is extremely important.
Automated tagging or metadata within an integrated development environment (IDE) or repository (40%) is currently the most widely used method for tracking code, followed closely by manual developer comments or documentation in pull requests (38%).
As AI coding tools become more widely relied on, a need to revisit how policies are enforced is becoming more apparent as the ground underneath the feet of DevOps teams continues to shift, said Gemmiti.
The one thing that is certain at this juncture is that when it comes to AI, there is no going back. Test development and orchestration (71%), user experience design and prototyping (64%), pipeline automation (46%), automated vulnerability remediation (44%) and threat modeling (42%) are all tasks the DevOps teams are hoping to automate using AI in the next 12 months.
The challenge, as always, is finding the best way to achieve that goal without consuming tokens to the point where it might be less expensive to continue to assign those tasks to a human.
Microsoft released Visual Studio Code 1.123 on June 3, expanding its AI-assisted development capabilities with features that reflect the editor’s direction: toward a more agentic, context-aware workflow.
The update is relatively focused, but several additions stand out to developers who rely on Copilot and other AI models day to day.
A Million-Token Context Window
One of the headline changes is support for 1-million-token context windows for compatible models from Anthropic and OpenAI, including Claude Opus 4.7 and GPT-5.5. That’s a meaningful jump. Larger context lets you work with larger codebases and longer conversations without the model losing track of what came before.
There’s a trade-off. Microsoft notes that larger context windows consume more tokens per interaction, which matters for teams on usage-based billing. But for developers working on complex projects, the ability to keep more code in context without manual truncation is a practical productivity gain.
Session Sync and Chronicle
VS Code 1.123 adds session sync, which automatically backs up your chat sessions to GitHub. Sessions capture conversation history, files touched, repository context — including branch and timestamps — and referenced pull requests, issues, and commits.
The companion feature is Chronicle, accessed via /chronicle in chat. It lets developers query their session history in natural language, generate standup reports, search past work by topic or file, and get productivity suggestions based on coding patterns. For engineers who context-switch frequently or manage multiple projects, having a searchable record of past AI-assisted work could save real time.
Agents’ Window Goes Parallel
The Agents window — a companion interface for running and reviewing agent sessions — now supports multiple open sessions side by side. Developers can open sessions next to each other by dragging from the session list or using Alt+click. One session is always “active” at a time, meaning the Terminal, Files, and Changes views reflect that session’s state.
Sessions can be pinned to prevent them from being replaced when selecting others. A maximize action expands any session to full width without closing others. The feature is still in preview, but it addresses a real workflow gap: the ability to compare two agent runs or review completed work while running a new one.
Research Agent
Also in preview — and currently limited to Copilot CLI sessions in Insiders — is the research agent. Triggered via /research in chat, it performs deep research on a topic by pulling from the codebase, relevant GitHub repositories, and the web, then produces a cited Markdown report. It’s read-only by design, so it investigates without modifying code.
This is aimed at cases where a quick chat response isn’t enough — understanding an unfamiliar library, comparing implementation approaches, or learning how a specific API behaves in context.
Integrated Browser Updates
The integrated browser gets a small but useful update: you can now favorite pages and access them quickly from a redesigned URL bar that also shows open tabs. On the screenshot side, two new options complement the existing Add Screenshot to Chat feature — area screenshots and full-page screenshots (the latter is experimental and requires enabling a setting).
A Small But Useful Safety Net
VS Code 1.123 also adds a two-hour delay before automatically applying extension updates. The intent is to provide a buffer against problematic or potentially compromised releases. Extensions from Microsoft, GitHub, and OpenAI are exempt from the delay and still update immediately. You can still trigger an immediate manual update at any time.
What It Adds Up To
The session sync feature, in particular, signals something larger than just a productivity feature. Mitch Ashley, VP and Practice Lead for Software Lifecycle Engineering and AI-Native Software Engineering at The Futurum Group, sees it as foundational infrastructure for teams running agentic workflows.
“Capturing the conversation, files touched, and repository context behind each agent session turns the editor into a system of record for how software gets built,” Ashley said. “The development process becomes observable, and the reasoning behind a change becomes recoverable. That record is verification infrastructure. Teams adopting agentic coding can govern and audit agent output only to the degree they can reconstruct how it was produced, so the provenance of a change is becoming as important as the change itself.”
Taken together, VS Code 1.123 continues a clear pattern: Microsoft is embedding AI more deeply into the core development workflow rather than treating it as an add-on. Developers who spend significant time in VS Code with Copilot enabled will find practical value in most of these additions — and for teams moving toward agentic development, the session sync and Chronicle features may matter more than they appear at first glance.
Kilo today made available a benchmarking framework for its open source artificial intelligence (AI) agent that enables application development teams to generate code using multiple models.
Company CEO Scott Breitenother said KiloBench measures the impact that frontier AI models are having on actual production workflows versus relying on a set of benchmarks, such as SWE-bench Verified, that only evaluate AI models based on how well they perform a generic set of tasks.
The KiloBench framework, in contrast, provides deeper insights into workflows that make it possible to determine which AI model lends itself best to a specific harness in terms of how quickly tasks are completed and at what cost, noted Breitenother.
For example, some AI models are able to successfully complete a task on their first try, while others require three attempts. A model that’s cheaper per attempt but needs five tries is more expensive than a model that costs more per attempt but consumes fewer tokens, added Breitenother.
In other cases, it may simply be less expensive to invoke an open source AI model that has been deployed on the same cloud service alongside proprietary AI models from, for example, OpenAI and Anthropic. Too many organizations are making a strategic mistake by adopting harnesses that are too closely coupled with the provider of an AI model, noted Breitenother.
Application developers also need to be aware that not all AI models work the same way. Some models read extensively before writing, which makes it possible to discover more bugs while consuming additional tokens.
KiloBench is based on a Terminal-Bench framework that tracks 89 real-world tasks as they are completed using the Kilo harness. That approach provides more granular insights into which AI models are best optimized for the Kilo AI coding tool, said Breitenother. Ultimately, the goal will be to automatically route tasks based on a set of policies defined by the DevOps team, he added.
Exactly how each harness interfaces with AI models is slightly different, so in time there is likely to be a greater need for benchmarks that are tied to specific AI coding tools. Having access to those insights is becoming increasingly critical as DevOps teams discover that the cost of the token used to build and deploy software in many instances has become prohibitive.
One way to control those costs is to have a better understanding of which AI models might best be used to perform a specific task. Rather than focusing on how many tokens are consumed, also known as token maxing, DevOps teams will increasingly need to apply best FinOps practices to consumption of AI infrastructure resources, noted Breitenother. Otherwise, more organizations will discover that application developers are regularly running out of allotted tokens that will need to be replenished, he added.
It’s still early days so far as adoption of AI coding is concerned. Most organizations are now using multiple AI tools to generate code but few have defined a set of governance policies and frameworks to optimize usage. The one thing that is certain is that it is now more a question of when rather than if those frameworks and policies will be applied.
