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.

The article originally appeared on CSO.

OpenAI has cut API prices for its GPT-5.6 Terra and Luna models by 20% and 80%, respectively, while also reducing the number of usage credits the models consume in ChatGPT Work and Codex, in an effort to effectively increase the amount of AI work enterprise subscribers can perform without paying more.

“Starting July 30, API pricing is $2 per million input tokens and $12 per million output tokens for Terra, and $0.20 per million input tokens and $1.20 per million output tokens for Luna,” the company wrote in a blog post.

Prior to this update, enterprise customers paid $2.50 per million input tokens and $15 per million output tokens for GPT-5.6 Terra. For Luna, pricing stood at $1 per million input tokens and $6 per million output tokens.

These lower prices and effective reduction in credit consumption, OpenAI said, are the result of improvements in serving efficiency that allow it to deliver “more intelligence per dollar” for its most advanced family of AI models.

The efficiency gains, the company added, stem from optimizations across its AI training and inference stack, including software and GPU infrastructure, with GPT-5.6 Sol helping optimize production GPU kernels used to run AI workloads and reduce inference costs without compromising model performance.

Enterprises likely to spend differently, not less

Analysts say the price cuts are less about reducing enterprise AI spending and more about lowering the cost of deploying AI at scale.

“For CIOs, the biggest impact is likely to be scaling AI adoption rather than simply cutting costs or lowering AI budgets. Lower prices make it easier to move pilots into production, expand AI across more employees and business processes, and economically deploy more complex agentic workflows that require multiple model calls,” said Pareekh Jain, principal analyst at Pareekh Consulting.

“Instead of shrinking AI budgets, most enterprises will reinvest the savings into higher AI usage, allowing agents to perform more reasoning, automation, and multi-step workflows while delivering more business value for roughly the same spend,” Jain noted, saying the likely outcome reflects the Jevons paradox, the economic principle that efficiency improvements often increase overall consumption of a resource rather than reducing it.

Echoing Jain’s view, Chandrika Dutt, research director at Avasant, pointed out that enterprise teams are likely to use the leeway from the pricing change to build increasingly sophisticated agentic workflows that were previously difficult to justify economically.

CIOs need flexible AI architectures to benefit

More broadly, CIOs should view OpenAI’s pricing update as yet another sign that inference costs are likely to keep falling over the next 24 months across model providers, such as Anthropic, Google, and Microsoft, with a sharp increase being unlikely.

“These price decreases are broadly sustainable in the long run. New chips, better software, and more efficient model designs will keep driving down the cost per token, and heavy competition makes big price hikes risky for any single provider and thus unlikely,” Jain pointed out.

For enterprises and their leaders, that should mean designing AI strategies that prioritize AI FinOps and flexible architectures so models can be swapped as price-performance continues to improve across vendors, Jain added.

The larger and more advanced model in the GPT-5.6 family, named Sol, though, is not undergoing any pricing changes. Instead, OpenAI has introduced a new Fast mode for the model, replacing Priority Processing in the API. Existing API requests tagged “priority,” though, will continue to work, it added.

For a long time, I thought of observability as something mainly owned by backend, platform or site reliability teams. Frontend engineers built the interface, handled browser behavior and called APIs. When something failed deeper in the system, another team looked at server logs and infrastructure dashboards.

That division works until the application is technically available, but the user experience is not.

A page may load while its most important data arrives several seconds late. A request may succeed after multiple retries, leaving the user staring at a spinner. One cloud service may slow down while the rest of the page continues working. From an infrastructure perspective, nothing may qualify as an outage. From the user’s perspective, the application is already failing.

As I gained more experience building applications that depended on cloud services and APIs, my view of frontend ownership changed. A frontend team does not need to operate every service it depends on, but it does need enough visibility to understand how those services affect the experience it delivers.

Observability gives frontend engineers that visibility. It helps connect what happens in the browser with what happens across the systems behind it. More importantly, it gives teams evidence they can use not only to debug problems, but also to make better decisions about how the frontend should behave when dependencies are slow, unavailable or inconsistent.

The browser sees a different version of the system

Server-side monitoring tells us what happened inside a service. It does not always tell us what happened across the user’s complete journey.

A backend dashboard might show that an API responded in 300 milliseconds. The browser may still take much longer to display useful content because of network latency, JavaScript execution, rendering work or additional requests. A successful response can also produce a broken experience if the returned data is incomplete or the interface fails while processing it.

This is why client-side telemetry matters. Browser error reporting can capture exceptions that never reach a server. Performance measurements can show how long users wait for content to become visible or interactive. Request data can reveal which dependencies are slow, unreliable or frequently retried.

Standard browser APIs provide useful starting points. The W3C User Timing API allows developers to mark and measure meaningful operations in an application. A team can measure how long it takes to load a dashboard, complete a search or render a critical section of a page.

Web Vitals can also help teams examine loading performance, responsiveness and visual stability using measurements tied more closely to the user experience. These metrics are useful because they move the conversation beyond whether a request succeeded. They help answer whether the page became useful quickly and respond when the user tried to interact with it.

The goal is not to collect every browser event. That can produce a large amount of data without producing much insight. It is better to begin with a small set of questions.

How long does the user wait before the main content appears? How often does a form submission fail? Which request prevents a page from becoming usable? Are users on certain devices or network conditions affected more often?

These questions make telemetry easier to design and easier to interpret. “The API is available” is a service-level statement. “The user can complete the task without an unexpected delay” is an experience-level statement. Frontend observability helps connect the two.

Logs and traces connect the frontend to its dependencies

Client-side logs are most valuable when they include enough context to reconstruct what the user was doing. A useful error record might include the application version, route, operation, request status and a correlation identifier. Browser information may also help when an issue affects only certain environments.

At the same time, frontend telemetry should be designed carefully. Logs should avoid form contents, authentication tokens, passwords and other sensitive information. Collecting more data does not automatically make an investigation easier. The right context is more useful than a large amount of unstructured information.

Correlation identifiers are particularly helpful. When the frontend includes an identifier with a request and that identifier continues through downstream services, teams can connect a browser failure to backend logs and distributed traces. Instead of comparing timestamps across several dashboards, engineers can follow one request across the system.

A distributed trace can show that a user action triggered an API gateway, an application service, a database call and another cloud dependency. It can also show where the request spent most of its time or where an error first appeared.

OpenTelemetry provides a vendor-neutral approach for generating and connecting telemetry such as traces, metrics and logs. It also supports JavaScript and browser instrumentation, which makes it relevant to frontend teams that want to connect browser activity with backend services.

Frontend engineers do not need to become observability platform specialists. They do need agreement with backend and platform teams on basics such as trace propagation, naming conventions, safe logging fields and where telemetry can be reviewed during an investigation.

Consider a page that occasionally loads without its main data. The frontend may record that a critical request timed out after several seconds. A correlation identifier from that request may lead to a trace showing that the gateway responded normally, but a downstream dependency exceeded its timeout.

Without connected telemetry, the report might remain, “The page sometimes does not load.” With connected telemetry, the team has a specific failure path, a measurable delay and enough evidence to decide what needs to change.

That evidence can support two actions. The service team can investigate the slow dependency. The frontend team can improve the experience by adding a timeout state, retry option or partial fallback. Observability makes both responses more precise.

Observability should influence architecture, not only debugging

The immediate benefit of observability is faster incident investigation. The larger benefit is better architectural decision-making.

When telemetry repeatedly shows that one dependency is slow, the frontend team can reconsider how tightly the interface depends on it. The page might render primary content first and load secondary information later. Cached data might be acceptable for a noncritical section. A timeout might lead to a smaller fallback instead of blocking the entire screen.

Observability can also expose hidden coupling. If unrelated components fail whenever one shared request slows down, the page may have been designed as a single loading unit. Breaking the experience into independently recoverable sections can make the interface more resilient.

The same evidence can improve retry behavior. Automatic retries may help with a temporary network failure, but they can also add more traffic to an already slow service. Telemetry can show whether retries recover requests, how long the recovery takes and whether users leave the page before it succeeds.

Service-level visibility matters as well. Frontend teams should understand the availability and latency expectations of the services they use. They should also understand what those services return during partial failures.

If a dependency may respond slowly, the interface needs a loading strategy. If data may be stale, the interface needs to communicate freshness. If a service is optional, the page should not collapse when it is unavailable.

Good observability also improves conversations between teams. Instead of saying, “The page feels slow,” frontend engineers can explain which user action is affected, how often it happens and where the delay appears. Debugging becomes a discussion based on evidence rather than guesswork.

A practical starting point can be small. Capture unhandled browser errors. Measure a few important user journeys. Record failures for critical network requests. Propagate a correlation identifier across frontend and backend systems. Review those signals with the teams that own dependent services.

From there, instrumentation should grow in response to real questions. Add a measurement when a workflow is difficult to understand. Add a trace when a request crosses several systems. Add a dashboard when a signal is important enough to review regularly.

Frontend observability is not about turning every frontend engineer into an operations engineer. It is about recognizing that the browser is part of the production system and often the only place where the complete user experience is visible.

When frontend teams can connect what users experience with the services behind it, they can debug more effectively, design interfaces that degrade gracefully and make better architectural decisions. Observability becomes more than a way to explain incidents. It becomes an input into how frontend systems are designed.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

A few years ago, I sat in a postmortem that I still think about. We’d had a production incident where a routine deploy had quietly shipped with the wrong configuration, and it took us longer to notice and roll back than anyone was comfortable admitting. But when we traced the root cause, almost none of it was the feature code. It was the scaffolding around it: a Kubernetes manifest no longer matched our cluster, a CI pipeline whose green checkmark didn’t actually verify the thing we assumed it did, and a secrets-management step that three different services each did three different ways. The code itself had been fine for a week. Everything around the code is what failed us.

I have seen some version of that retro at nearly every company I’ve worked at over the last 15 years across a large IT services firm, a medical-device maker, a healthcare-technology company, a cloud-migration startup, and now a large SaaS platform. The names and the tech stacks changed. The pattern didn’t. Smart engineers spending a startling share of their week not on the problem they were hired to solve, but on the accidental complexity of shipping it.

For a long time, I assumed the answer was better documentation, or a stricter DevOps culture, or just hiring people who were more comfortable with YAML. I was wrong on all three counts. What actually changed my mind was reframing the problem entirely: the friction wasn’t a knowledge gap or a discipline gap. It was a product gap. Nobody owned the developer’s experience of shipping software the way a product manager owns a customer’s experience of using an app. And the discipline that closes that gap now has a name: platform engineering, which Gartner describes as having “emerged in response to this increasing cognitive load resulting from the complexity of modern software tools and architectures.” Gartner isn’t shy about how fast it’s spreading, either: the firm predicts that “by 2026, 80% of large software engineering organizations will establish platform engineering teams,” up from 45% in 2022. If that number is even close to right, the interesting question is no longer whether to build a platform team but whether you’ll build a good one.

The moment “DevOps” quietly stopped scaling

I want to be careful here, because “DevOps is dead” is a lazy headline and I don’t believe it. The principles behind DevOps include shared ownership, automation, and tight feedback loops. These are as right today as they were when the movement started.

What broke, in my experience, was the operating model. The original promise was “you build it, you run it.” Every team owns its own deployment, its own observability, its own on call. That works beautifully when you have a handful of teams and a shared oral tradition. It falls apart when you have 50 teams, because now you have 50 slightly different ways of doing the same undifferentiated work. 50 ways to define a service. 50 subtly wrong Kubernetes configurations. 50 on-call rotations paging fifty engineers about the same class of problem at 3 a.m.

The cognitive load of “run it yourself” grew faster than most teams could absorb. That framing of cognitive load as the thing you’re actually optimizing for comes from “Team Topologies,” a book that reshaped how I think about org design more than any purely technical text I’ve read. Its fourth principle is blunt about the limit: “Teams can only handle so much complexity before breaking down,” and “competent teams become ineffective when leaders keep adding to their plate without taking anything away.” That last line described my own teams so precisely it stung. “Team Topologies” also gave me the vocabulary I’d been missing. It names four fundamental team types, and it defines a platform team as “a grouping of other team types that provide a compelling internal product to accelerate delivery by stream-aligned teams”. Read that definition again: a compelling internal product. Not a shared-services desk, not a Terraform repo with a wiki. A product. That single word is the whole argument.

Treating the platform as a product changes everything

Here’s the shift that took me embarrassingly long to internalize: if the platform is a product, then developers are its customers, and you don’t get to tell your customers they’re holding it wrong.

That one reframing has downstream consequences that surprised me.

The first is that adoption has to be earned, not mandated. Early in my time working on internal tooling, I helped build a platform capability that we were quite proud of, and then we did what infrastructure teams love to do: we announced it, and assumed people would come. They didn’t. Teams routed around it, because the golden path we’d paved was, frankly, gravel. The lesson landed hard. A platform that developers have to be forced onto is not a platform, it’s a tax. When we went back and rebuilt it so that the paved path was genuinely the easiest path. This is the same instinct behind Backstage, the developer portal that was built at Spotify and is now a CNCF project; its own pitch is that it “restores order to your microservices and infrastructure” so product teams can ship quickly. Order you have to opt into isn’t order. The tool wins when choosing it is the lazy option.

The second consequence is that “self-service” has to mean what it says. It’s an overused word, so I hold it to the CNCF’s definition from its platforms white paper: “A platform should be self-serviceable. Users must be able to request and receive capabilities autonomously and automatically.” Autonomously and automatically. If a developer has to file a ticket and wait on my team to provision a database, I haven’t built a platform instead I’ve built a slower version of the help desk. The same white paper states the north star plainly: “An essential goal of a platform is to reduce the cognitive load on product teams.” I’ve started using that sentence as a litmus test. For any capability we’re tempted to add, I ask whether it removes load from a product team or quietly adds some. A surprising number of well-meaning platform features fail that test.

The third consequence is that you have to measure the platform the way you’d measure any product and resist measuring the things that only flatter the platform team. “How many clusters are we running” is an output my team cares about and nobody else does. The metrics that matter describe the developer’s lived experience, and the most durable set I know of comes from DORA, the long-running research program into software delivery performance. Its metrics have evolved from the original “four keys” have grown to five. The core throughput measures still ask exactly the right questions: change lead time (“the amount of time it takes for a change to go from committed to version control to deployed in production”), deployment frequency, and failed deployment recovery time, balanced against a change fail rate. I’ve found those double as a remarkably honest scorecard for a platform team, precisely because they refuse to reward busywork. You cannot game your way to a good lead time by shipping more internal tools nobody uses.

The fourth consequence is the hardest culturally: a platform product needs a roadmap, user research, and the willingness to say no. I’ve watched platform efforts collapse into a junk drawer of one-off requests, each reasonable on its own, that together add up to an incoherent pile of tools nobody can hold in their head. Saying no to a well-intentioned request is a product-management skill, and platform teams that never develop it end up rebuilding the very sprawl they were created to eliminate. The best platform leads I’ve worked with spend as much time talking to their internal users as any consumer-facing PM does.

What I’d tell my younger self

If I could go back to that retro years ago, I’d say a few things to the version of me who thought this was a documentation problem.

Start with the paved road, not the platform. You don’t need to build an internal developer portal in quarter one. You need to find the single most painful, most repeated piece of undifferentiated work is the distance between “here is my container” and “it is running safely in production”. Earn the next piece of scope by delivering that one well. Platforms that begin as grand architectures tend to die as grand architectures; the ones that survive start as one genuinely useful paved road that people choose on their own.

Resist the urge to abstract away everything. The goal of a good platform is not to hide Kubernetes so completely that no one understands what’s happening beneath them; that just trades one kind of fragility for another. The goal is to remove the toil while leaving the understanding intact. When the abstraction leaks you want engineers who can reason about what’s underneath, not a room full of people who only ever knew the buttons. I’ve paid for both mistakes: platforms too thin to help, and platforms so thick that an incident turned into an archaeology dig.

And treat “developer experience” as a first-class business metric, not a morale nicety. Every hour an engineer spends fighting the delivery pipeline is an hour not spent on the thing your customers actually pay you for. When I frame platform investment that way to leadership as reclaiming a meaningful fraction of my most expensive people’s time that’s when the conversation stops being about cost and starts being about leverage. It is genuinely one of the highest-return investments an engineering organization can make, and it almost never shows up as a line item that looks like one.

The platform team is not the group that keeps the lights on. It’s the group that decides how fast everyone else can move. Once I started treating it as the most important product my organization ships internally, almost every other decision got easier. I just wish it hadn’t taken me a missed release and a room full of frustrated engineers to see it.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

KotlinLLM, a research prototype for delegating runtime logic to a large language model (LLM) from Kotlin code, is now going open source and public, JetBrains announced.

Revealed July 28, KotlinLLM is an IntelliJ IDEA plugin prototype for experimenting with LLM-driven “Smart macros” in Kotlin, enabling code generation, runtime updates, and hot-reloading. In software engineering, LLMs are commonly used during development for code completion, code generation, and program comprehension, JetBrains noted, but using an LLM at run time of a compiled application is much less common. The existing options for doing this have the following trade-offs, according to JetBrains:

• Direct runtime delegation is slow, non-deterministic, and costly, and makes the application depend on an LLM service at run time.
• External agent workflows keep the generated logic outside the codebase, where it is harder to review, test, and ship.
• Most prior work (byLLM, nightjar, Healer) targets interpreted languages like Python, not a compiled, statically typed language like Kotlin.

KotlinLLM addresses these limitations in three ways, JetBrains said:

• The call site shows that a feature is LLM-backed, so it is visible in code review.
• Generated behavior is saved as an ordinary Kotlin source, not kept only in the runtime session. It can be committed, reviewed, tested, and distributed like any other code.
• Once generated, the code runs as plain Kotlin without the plugin. For scenarios that are already covered, there is no further LLM call, so no added latency or cost, and the result is reproducible.

KotlinLLM is open source under Apache License 2.0. The repository contains the KotlinLLM IntelliJ IDEA plugin, the Smart macro API, and example projects.

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.

The article originally appeared on CSO.

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.

The demo videos always end at the same moment. A figma frame turns into a passing test in twelve minutes. Someone in the room says the word “productivity.” The recording stops.

The parts that come after that moment are the parts I actually get paged about. Who owns the ticket the agent opened at 3:14 a.m.? Which model call produced the assertion in test case 47? What closes the 17 draft tickets a stuck run left behind before the next sprint planning notices them? None of that shows up in the demo. All of it shows up on the on-call rotation. After 20 years of leading test automation across consumer-scale platforms, I have a strong bias about which slide in the deck predicts whether a pipeline ships or stalls. It is never the architecture slide. It is the runbook.

This piece is about the runbook. I built an unattended agentic test pipeline over the Model Context Protocol — a five-agent SDLC (product manager, QA engineer, automation engineer, developer, pull-request reviewer) coordinating through MCP servers for Jira, Figma, Confluence, TestRail and GitHub, with hosted Claude as the orchestration model and an open-weights Hermes-3 as a validation baseline — and I ran it as an independent research project long enough to learn which production constraints the agent literature glosses over. What follows is the short list of things I now insist on before I let any agentic pipeline touch a shared system.

Composition contracts, or why the agent lied to itself

The most expensive failure mode I have seen in a multi-agent pipeline is not the model getting an answer wrong. It is agent A getting an answer right and agent B misreading it.

I watched this happen inside a run last month. The requirements agent produced a clean output with a field called acceptance_criteria that was a list of strings. The ticket agent expected acceptance_criteria to be a single markdown blob. Neither agent was wrong in isolation. Both were passing their own unit tests. What the pipeline produced was a Jira ticket whose acceptance criteria read, in full, the four characters [” — the JSON serialization of an empty first element. The test-plan agent read that, generated one test, marked it green and moved on. It took me until the pull-request stage to notice.

This is a composition fault. It is the natural failure mode of any system where independent components hand off structured data across a boundary they don’t jointly own. Distributed systems people have written about this for years — Martin Fowler’s tolerant reader pattern is the classical treatment — but the LLM literature mostly still treats it as a prompt problem. It isn’t. You cannot fix it with a better system prompt. You fix it with a typed handoff contract that both agents agree to before they run, plus a validator between them that fails loud when the shape drifts.

The heuristic I now use: Every agent-to-agent boundary gets a schema and a validator. Every agent gets a golden-input regression suite that catches contract drift before it reaches a downstream agent. Neither of those is glamorous. Both are the difference between a pipeline that produces work and a pipeline that produces a very expensive game of telephone.

If you want to know whether a team’s agentic pipeline is going to survive the first quarter, ask them what the contract is between agent one and agent two. If the answer is “the model figures it out,” budget for the cleanup.

Provenance, or the audit trail nobody wrote

The second thing I insist on now is that every artifact the pipeline produces has to answer three questions without a human doing archaeology: which agent produced it, which model call produced it and which upstream inputs the agent was looking at when it did.

This sounds like a nice-to-have. It is not.

Somewhere around week three of running the pipeline I hit a subtle case: the requirements agent was quoting a Confluence page back to itself. The MCP server for Confluence had returned an empty result on a first call, the agent had written a placeholder requirement, the second call had succeeded, the agent had retrieved its own placeholder and by the third pass it was citing that placeholder as source truth. The ticket said, entirely in earnest, that the requirement came from the design owner. It hadn’t come from anywhere. It had come from itself, four minutes ago.

You cannot debug that class of failure with logs of what the model said. You need logs of what the model was looking at. That means capturing the tool-call ID for every MCP call, stamping every artifact with the set of tool-call IDs it derived from and refusing to accept any retrieved fact into a downstream stage that cannot be traced to a real external source. I call it the prove-the-source rule. It’s boring. It’s a two-line requirement in the runbook. It is also the single guardrail that has saved me the most on-call time.

There is a nice side effect. When editors, reviewers or auditors ask where a decision came from, the pipeline can show them. That matters if you work anywhere near a regulated stack, and increasingly it matters everywhere else — the AI transparency and provenance framing in NIST’s AI Risk Management Framework is going to become the default expectation faster than most teams are budgeting for.

Cleanup and ownership, or why I now write the shutdown script first

The last thing that will surprise a team shipping their first agentic pipeline is the debris.

A pipeline that runs unattended for a week will leak. It will leak draft Jira tickets whose parent stories were never approved. It will leak GitHub branches for test suites that were never merged. It will leak TestRail runs that started, produced two results and never got a summary. It will leak Confluence page comments the agent posted while asking itself a clarifying question. None of these are bugs. They are the natural output of an autonomous system that starts more work than it finishes.

I learned this by accident. About six weeks into the project I ran a query on Jira for tickets created by the automation user in the past thirty days. I was expecting maybe 20. It was 91. 68 of them were [DRAFT] in the title and had not been touched by any human. I closed them by hand one afternoon, and while I was doing it, I understood that the pipeline had a silent second job I had never designed for: garbage collection.

Now every pipeline I run has three things I write before I write the first agent. A shutdown script that closes any artifact the current run has orphaned. A nightly reconciliation pass that closes any artifact any prior run has orphaned. And a single named owner — a human, on the org chart, with a Slack handle — for every downstream system the pipeline can write into. When the pipeline creates a Jira ticket, the ticket has a real assignee. When the pipeline opens a pull request, a specific reviewer is on the hook. When the pipeline files a TestRail run, someone gets pinged if it goes stale. The pipeline is not allowed to touch a system that does not have a named owner. That rule alone would have saved me the ninety-one-ticket afternoon.

There is one anti-pattern here I want to name outright. Do not, under any circumstance, let the agent close its own artifacts. I tried it. The agent, tasked with cleanup, closed the wrong thirty tickets and then confidently wrote a summary saying it had closed the right ones. Cleanup is a human loop or a deterministic script. It is not a model call.

The pipeline works. It saves real time on the right kind of work. It also costs real time on a shape of work most teams don’t put in the estimate: Contract validators between agents, provenance stamping on every artifact, a shutdown script, a reconciliation pass, a human owner for every downstream system and an unshakable rule against the model doing its own cleanup. None of that is glamorous. None of it is what the demo shows. All of it is the runbook, and the runbook is what determines whether a pipeline is a lab experiment or something the on-call engineer trusts enough to sleep through. The teams that write the runbook first ship. The teams that write it after the first Sunday incident spend the next two quarters catching up.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

AI agents are being connected to real systems faster than most organizations are learning how to secure them. That should concern us.

The first wave of AI security discussion has been useful, but limited. The industry has learned the vocabulary: prompt injection, indirect prompt injection, tool misuse, data leakage, excessive agency, unsafe retrieval, and broken authorization boundaries. These terms are important because they give teams a way to talk about risk. 

But vocabulary is not containment.

The harder problem is what happens after a dangerous behavior is discovered. A team may adjust a prompt, restrict a tool, add a guardrail, or change the surrounding application logic. That may solve the immediate issue. What it does not automatically solve is the next release, the next model change, the next tool integration, or the next developer who unknowingly breaks the assumption behind the original fix.

This is where AI agent security still feels immature. In traditional software engineering, serious bugs become regression tests. The lesson is captured in code so the same failure cannot quietly return later. Security should work the same way. Agentic systems need a way to preserve discovered failures as repeatable checks.

That is the gap the OWASP Agent Security Regression Harness is trying to address. As a community-led open-source initiative within OWASP, this project aims to turn security insights into practical engineering work.

Agent security is becoming a systems problem

A chatbot can give a bad answer. An agent can take a bad action. That difference changes the security model.

Once an AI system can call tools, inspect repositories, query databases, open tickets, summarize internal documents, interact with APIs, or trigger workflow automation, the boundary is no longer just the model. The boundary includes permissions, tool design, application logic, data flow, logging, authorization, and the assumptions developers made when they connected everything together.

The risk is not limited to strange model behavior; the risk is system behavior. An agent that reads untrusted content and treats it as instruction is not merely confused—it has crossed a trust boundary. An agent that leaks private context through a tool call is not just producing a bad response; it is exposing data through an action path. These are the kinds of failures teams will face as agents move from prototypes into production.

The security industry has seen this pattern before. Cloud platforms and CI/CD pipelines increased leverage, making teams faster but making configuration errors more consequential. Agentic AI is another increase in leverage. That is why a one-time review is insufficient. Regression testing exists for exactly this kind of problem.

The missing workflow in agentic AI

Security teams do not need another reminder that AI agents can be manipulated. They need a workflow that turns manipulation into evidence. A hidden instruction inside a support ticket should not remain a warning; it should become a scenario that can be rerun. A tool call that leaks context should become a check with a clear failure condition.

The value lies not only in finding the first failure, but also in preserving the lesson. Production incidents become postmortems, serious bugs become tests, and security findings become backlog items. AI agent security should not be exempt from that discipline simply because the system includes a model.

The challenge is that agents are harder to test than traditional code. A brittle test that expects one exact sentence will fail in real-world conditions. Useful agent security tests must focus on outcomes. Did the agent cross a boundary? Did the agent call an unsafe tool? Did it disclose protected data? The OWASP Agent Security Regression Harness provides a standardized way to work on these questions in the open, focusing on practical, reproducible tests.

Why OWASP matters for AI

OWASP is valuable when it turns security problems into shared practice. The OWASP Top 10 did not eliminate web application vulnerabilities; its value was giving teams a common language and a practical reference point. AI agent security now needs the same kind of shared structure.

The field is moving quickly, and fast-moving fields tend to produce two unhelpful extremes: one side turns everything into hype, while the other turns everything into fear. A regression harness is a more useful answer because it is narrow and practical. It does not claim to solve every AI security problem, nor does it replace threat modeling or architecture review. It simply provides a necessary method for teams to prove that their controls hold after the system changes.

OWASP project stewardship

Open-source security projects need clear technical direction to turn a broad concern into something engineers can understand, run, and maintain. Under the leadership of OWASP Project Lead Mert Satilmaz, the OWASP Agent Security Regression Harnesshas moved past a theoretical idea into a functional tool. Satilmaz is a widely known leader in the AI security community, and this is reflected in the practical direction he has set for the project and the engineering skill involved.

The project benefits from a focus on release discipline, contributor workflows, and wide adapter coverage—supporting everything from the OpenAI Agents SDK to LangChain/LangGraph. By generating machine-readable results, it allows security teams to integrate these checks directly into CI pipelines. This approach treats agent security as a systems engineering problem rather than just a model behavior problem.

The method is the contribution

One OWASP project will not solve agent security by itself. That is not the point. The important part is the method the project represents.

AI security needs to become less dependent on warnings, one-off demonstrations, and claims that are difficult to verify. It needs more repeatable scenarios, clearer evidence, and better ways to test system behavior under security constraints. Teams should not be satisfied with saying a weakness was fixed. They should be able to prove the relevant control still holds after the system changes.

The best security work often looks boring from a distance: a harness, a test case, a clean project structure, and a workflow that lets another engineer reproduce the problem. AI agents will continue to become more capable and more connected to sensitive systems. Security teams need methods that are as practical as the technology is powerful. Regression testing is one of those methods, and adopting this workflow is an important step toward making secure AI a reality.

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 false values 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.

Microsoft has released MCP C# SDK v2.0, a major update of the company’s official C# SDK for Model Context Protocol (MCP) servers and clients.

Unveiled July 28, MCP C# SDK v2.0 implements the 2026-07-28 revision of the MCP specification, which Microsoft described as the protocol’s largest revision since its launch. The 2026-07-28 revision makes the MCP protocol stateless by default, standardizes the HTTP surface to allow ordinary HTTP infrastructure to route MCP traffic, and introduces Multi Round-Trip Requests (MRTR) to support interaction without requiring long-lived sessions.

MCP C# SDK 2.0 moves in lockstep with these changes, Microsoft said. The HTTP server transport now runs statelessly by default. Whereas version 1.x of the SDK configured stateful sessions out of the box, in version 2.0 HttpServerTransportOptions.Stateless defaults to true.

MCP C# SDK v2.0 also implements a small set of HTTP headers that the 2026-07-28 MCP revision standardizes. A tools/call now includes Mcp-Method: tools/call and Mcp-Name: get_order_status alongside the JSON-RPC body. With the 2026-07-28 revision, an MCP request becomes a single, self-describing HTTP POST. This means that ordinary HTTP infrastructure such as load balancers, proxies, gateways, and web application firewalls now can act on MCP traffic without deep packet inspection, Microsoft said.

And MCP C# SDK 2.0 adds support for MRTR on the server and on the client. MRTR addresses scenarios in which tools can’t answer in a single round trip, such as when a server wants to confirm with a user before taking a significant action. In previous versions of MCP, these interactions worked only over a live, stateful session. With MRTR, they work with no session at all, because all the continuity travels in the payload, Microsoft said.

With the 2026-07-28 spec compliance landing in MCP C# SDK 2.0, Microsoft said the SDK’s next focus is end-to-end authentication and authorization. The goal is to make secure MCP deployments as “turnkey” as the rest of the stack, building on the closer OAuth and OpenID Connect alignment the spec introduced, Microsoft said. 

Java Development Kit 27, an Oracle-driven, planned update to standard Java, is set to reach its initial release candidate (RC) stage on August 6. This update has features ranging from making the Garbage-First (G1) garbage collector the default collector and adding structured concurrency to simplify concurrent programming. JDK 27 is currently in rampdown phase 2, with the feature set now frozen.

Overall, there are nine features listed on what is described as a reference implementation of JDK 27. The first five features include making G1 the default garbage collector, post-quantum hybrid key exchange for TLS 1.3, lazy constants, structured concurrency, and primitive types in patterns, instanceof, and switch. The next four include compact object headers, JFR (JDK Flight Recorder) in-process data redaction, a vector API, and PEM (Privacy-Enhanced Mail) encodings for cryptographic objects.

The final release candidate stage for JDK 27 follows on August 20, with general availability scheduled for September 15. Early-access builds for JDK 27 can be found at jdk.java.net.

With JDK 27, G1 becomes the default garbage collector in all environments, rather than just in server environments. Goals are to ensure that the HotSpot JVM will always select G1 and that performance including throughput, latency, memory footprint, and startup time does not degrade significantly.

With post-quantum hybrid key exchange for TLS 1.3, the goal is to enhance the security of Java applications that require secure network communication by implementing hybrid key exchange algorithms. Such algorithms defend against future quantum computing attacks by combining a quantum-resistant algorithm with a traditional algorithm.

Lazy constants introduces an API for objects that hold unmodifiable data. Lazy constants are treated as true constants by the JVM, enabling the same performance optimizations that are enabled by declaring a field final. Compared to final fields, however, lazy constants offer greater flexibility in the timing of their initialization. This feature is in a third preview.

The goal of primitive types in patterns, instanceof, and switch is to enhance pattern matching by allowing primitive types in all pattern contexts, and to extend instanceof and switch to work with all primitive types. This feature is in a fifth preview.

Structured concurrency simplifies concurrent programming by introducing an API that treats groups of related tasks running in different threads as single units of work. Goals include streamlining error handling and cancellation, improving reliability, and enhancing observability. Structured concurrency is in its seventh preview.

JDK 27 makes compact object headers the default object header layout in the HotSpot JVM. Compact object headers reduce object headers from 96 bits down to 64 bits on 64-bit architectures, reducing heap size, improving deployment density, and increasing data locality.

JFR data in-process redaction allows users to redact command-line arguments and the initial values of environment variables and system properties in JFR recordings. JFR recording files may contain events that include sensitive data, such as secrets in command-line arguments, access tokens in environment variables, and passwords in system properties. This data is (optionally) redacted before it leaves the process, so that sensitive information does not leak.

The vector API introduces an API to express vector computations that reliably compile at run time to optimal vector instructions on supported CPUs, thus achieving better performance than equivalent scalar computations. This is an incubating API in its 12th incubation.

PEM encodings of cryptographic objects introduces an API for encoding objects that represent cryptographic keys, certificates, and certificate revocation lists in the PEM transport format, and for decoding from PEM back into objects. This is a preview API.

JDK 27 is a short-term feature release (non-LTS) that will receive six months of support from Oracle. Its predecessor, JDK 26, also a short-term release, became generally available on March 17.

I’m an old Borland guy. I started using Borland tools in the early 1990s, from Turbo Pascal through Delphi. I dabbled in Paradox. I even tried to stick with Borland Office. I wandered through the Inprise years, and the Kylix endeavor, and I was actually a Borland employee during the CodeGear/Embarcadero migrations. 

You could write a book about the rise and fall of Borland. Suffice it to say that things got dodgy when Borland strayed from its focus on developer tools, and they never really recovered.  

One of Borland’s missteps came with the open-sourcing of InterBase, its RDBMS. In the early 2000s, open-source software emerged from the academic shadows and began to commercialize. With the IPO of Red Hat, everyone was jumping on the Linux and open-source bandwagon. Borland made their move into this arena with InterBase. 

Two things soon happened. First, the Firebird project was created as a fork of the InterBase source. Second, Borland retreated from the open-source project and reincorporated InterBase as a closed-source product. One might mark this as the beginning of developers losing faith in Borland.

It was developers, then

And it always ends up being about the developers, right? I mean, who can forget a sweaty, maniacal Steve Ballmer jumping around onstage screaming “Developers, developers, developers”? For many years, Microsoft was notoriously anti-open-source, but even they eventually recognized the power of open-sourcing major tools like .NET and Visual Studio Code. 

But Microsoft didn’t do that out of the goodness of their heart — they clearly saw those tools as a means to bringing developers to their Azure cloud platform. When Amazon launched AWS, they clearly were sidestepping the IT procurement process, making it easy for developers to spin up VMs with just a credit card. Apple shipped the iPhone without an SDK, expecting developers to figure things out.  That didn’t last long, and they soon course-corrected.

Open source is great — but always remember that it offers benefits to companies beyond the software development process. Borland fumbled the ball with their open source efforts, but it soon became obvious how to leverage open source for corporate success. Or, as Stephen O’Grady argues in his book The New Kingmakers, developers are the ones who decide what technologies succeed. Companies quickly recognized that courting developers with open-source software and other free resources was the way to bring them into the fold. Because developers write all the software that makes a tool, platform, or application successful, it’s always a smart move to make developers happy.

It’s developers, now

AI hasn’t changed this equation. The latest incarnation can be seen from the company Nvidia. We think of Nvidia as a hardware company, cranking out GPUs as fast as they can. But GPUs don’t sell unless there is software that runs on them. Coding against a GPU in plain C++ was miserable, so Nvidia developed CUDA, a proprietary layer that made building for their hardware relatively easy. And the more CUDA is used, the more people depend on Nvidia hardware. This is not an accident. As Nader Khalil, Nvidia’s Director of Developer Technologies, told me, “You have to make the best hardware that you can, and you have to make the best software to utilize it. Software is the part of the stack that touches the user.”

Today, of course, developers are all about agentic coding, and Nvidia is eyeball deep in that world. As such, Nvidia provides a set of open-weight models called Nemotron that developers can use, inspect, and fine-tune for their own purposes. And of course Nemotron runs really well on top of CUDA. 

Nvidia, like Microsoft and Amazon, is doing this because they want to sell their products to more people. Nvidia can’t make enough GPUs for Anthropic and OpenAI to keep up with demand, but they also want to sell GPUs to us developers by enabling us to run our own models on our own computers. 

The open source movement began with pure hearts and noble ideals. But the reality of open source is that its nobility is easily melded with business needs. Open source software is really the bait — and developers are the real catch.

For a programming language that is prized for being convenient and easy, Python has some surprising barbs and sharp edges. Find out how a new pip flag can make it easier to work with project dependencies apart from the project itself. Get the skinny on why standalone Python programs are hard to assemble, and what you can do about it. See how Python’s new Installation Manager for Microsoft Windows lets multiple versions coexist on the same system. And find out what will be shipped when Python 3.15 debuts later this year.

Top picks for Python readers on InfoWorld

New pip flag fixes longstanding Python frustration
A longstanding gripe with Python’s pip package manager has a happy ending. The next version of pip will let you install a package’s requirements without installing the package itself.

Why it’s so hard to create stand-alone Python apps
Python’s best features, its dynamism and flexibility, have a downside: They make it tough to package Python apps as standalone programs. Not impossible, though; just … complicated.

The best new features in Python 3.15
If you haven’t grabbed the beta release of Python 3.15 yet, it’s ready when you are. Here’s a rundown of all the best bits you can start using right away.

Get started with the new Python Installation Manager
This all-in-one Python version management tool is now the recommended, default way to set up and manage Python versions on Microsoft Windows — including betas, release versions, and the special JIT and free-threaded builds, too.

More good reads and Python updates elsewhere

Ruff linter gets a massive upgrade in version 0.16
The speedy, Rust-powered linter and formatter for Python now supports over 400 rules by default, making for a more useful, zero-configuration, out-of-the-box linting experience.

What every Python developer should know about the CPython ABI
A massive, multilayered unpacking of that most intimidating of Python internals, the CPython application binary interface. Even if you never plan to write a CPython extension or contribute to the CPython project, the details laid out here are eye-opening.

Free-threaded Python: past, present, and future
At PyCon 2026, CPython core developer Thomas Wouters gave a talk about how Python came to support threads via the GIL, and how its developers went about removing the GIL over many years and multiple attempts. Excellent recap available at LWN.net.

PEP 837: Extensible JSON serialization
A newly introduced Python Enhancement Proposal (intended for Python 3.16) to make Python’s native JSON serialization more extensible, for instance to allow new types to automatically support serialization via a __json__ method.

Anthropic CEO Dario Amodei has argued that policymakers should keep lower-risk open-weight AI accessible while placing stricter safeguards around frontier systems, including mandatory testing and limits on China’s access to advanced computing and model capabilities.

In a post outlining Anthropic’s position, Amodei said broad restrictions, including bans on Chinese open-weight models used by US businesses, would not address his main national security concerns. Instead, he pointed to the possibility of authoritarian governments surpassing the US in advanced AI, as well as cyber, biological, and alignment risks posed by increasingly capable systems.

Amodei also called for action against industrial-scale model distillation, which he said allows Chinese developers to improve their models with less computing power than would be needed to train comparable systems from scratch.

The statement followed criticism of Anthropic for not signing an industry letter backed by Nvidia, Microsoft, Meta, IBM, Mistral, Hugging Face and other technology companies urging policymakers to avoid premature restrictions on open-weight models.

The letter said that open weights could broaden access to AI, intensify competition, and enable organizations to adapt and deploy models without relying on a single provider. Amodei agreed with parts of that case but disputed claims that openness inherently improves safety research or gives defenders an advantage over attackers.

He said regulation should be based on a model’s capabilities and risks rather than whether its weights are openly available. Under that approach, sufficiently capable open and closed models would undergo testing before release.

Conditional support

Analysts said Anthropic had moved closer to industry consensus by rejecting blanket bans, but its support remained more limited than the approach backed by many major technology companies.

Deepika Giri, head of research for AI, analytics, and data at IDC, said the Nvidia-backed letter presented open weights as strategic infrastructure that should remain broadly accessible, in contrast with Anthropic’s more restrictive position.

Amodei’s statement clarified that Anthropic supports open-weight models only under certain conditions, a stance that could also help the company preserve its competitive advantages as a proprietary model provider focused on compliance and tighter controls, according to Lian Jye Su, chief analyst at Omdia.

The statement was “a real olive branch” to supporters of open-weight models, according to Pareekh Jain, CEO of Pareekh Consulting. But he said the disagreement had shifted from whether such models should be released to where policymakers should draw the line.

“Anthropic still thinks that once a model gets powerful enough, releasing its weights publicly is riskier than keeping it locked behind an app, because you can never take it back or add safety fixes later,” Jain said.

Will the controls work?

Analysts differed over whether Anthropic’s proposed controls would achieve their aims without creating new barriers for smaller AI developers.

Jain said chip restrictions and measures against illicit model distillation would mainly affect model developers and infrastructure providers, rather than enterprises using models already on the market. Mandatory safety testing, however, could raise development costs and reduce the number of advanced open-weight models available.

“Testing is expensive and time-consuming, and so, giant, well-funded companies like Anthropic, Google and OpenAI can afford it,” Jain said. Smaller developers seeking to release cutting-edge open-weight models could struggle to meet the same requirements, he added.

The additional testing and screening could also restrict the number of open-weight models available to enterprises, according to Su. He said the requirements could weaken some of their principal benefits, including lower costs, reduced vendor dependence and community-led development.

Anand Joshi, managing director of market research firm JP Data, questioned whether limiting China’s access to advanced chips would materially slow its AI development, arguing that Chinese companies had shown they could build highly capable models with less computing power. He supported action against illicit distillation, however, saying safeguards were needed to prevent developers from reproducing the capabilities of other models without authorization.

The impact on most enterprise users could remain limited if less capable models were exempted, Jain said. Businesses deploying models that fall below the proposed testing threshold would probably face little additional cost.

How CIOs should choose

Giri said CIOs should assess models according to their capabilities rather than whether they are open, and should demand independent testing, clear licensing, model documentation and accountability for monitoring and incident response.

“Mandatory safety testing should be triggered by a model’s demonstrated capabilities, not its size or training cost,” Jain said, particularly when a system could significantly assist cyberattacks, biological misuse, or autonomous harmful actions.

Before deployment, CIOs should seek independent evaluations, detailed model documentation, security test results and information about the model’s software supply chain, he added. Charlie Dai, principal analyst at Forrester, said that assessment should include documented red-team results, model provenance, disclosures about training and fine-tuning, and evidence of independent testing against recognized safety benchmarks.

The article originally appeared on ComputerWorld.