Thinking Machines Lab, the San Francisco startup founded by former OpenAI CTO Mira Murati, has released Inkling, its first general-purpose AI model. The launch adds another US-developed entrant to an open-weight market where Chinese developers produce several leading coding and reasoning models.

Inkling uses a mixture-of-experts architecture with 975 billion total parameters, of which 41 billion are active during processing. It supports a context window of up to 1 million tokens and was pretrained on 45 trillion tokens spanning text, images, audio, and video. Thinking Machines said it also trained the model for coding, tool use, and multimodal tasks.

The release follows the October 2025 launch of Tinker, Thinking Machines’ first product and an API-based platform for customizing AI models. Developers can fine-tune Inkling through the platform.

In a June 2026 assessment, AI model routing platform OpenRouter highlighted DeepSeek V4 Flash, GLM 5.2, MiniMax M3, and Nvidia Nemotron 3 Ultra as four notable open-weight models. Nemotron was the only US-developed model in the group.

Performance and developer access

Thinking Machines Lab’s benchmark table shows mixed results. Inkling scored 77.6% on SWE-Bench Verified, behind DeepSeek V4 Pro and GLM 5.2 but ahead of Nvidia Nemotron 3 Ultra. It also recorded 74.1% on MCP Atlas, 77.1% on BrowseComp with context management, and 79.8% on IFBench.

Thinking Machines said Inkling’s result used a bash-only harness, while the comparison figures were reported by the competing models’ developers.

The model includes a reasoning-effort setting that developers can adjust from 0.2 to 0.99. Thinking Machines said the setting allows users to balance performance against the number of generated tokens. In the company’s testing, Inkling matched Nemotron 3 Ultra’s Terminal Bench 2.1 score while generating about one-third as many tokens.

Developers can fine-tune Inkling through Tinker using context lengths of 64,000 or 256,000 tokens and test it through the Inkling Playground. The model is available through APIs from Together AI, Fireworks, Modal, Databricks, and Baseten. It is also supported by inference software, including SGLang, vLLM, TokenSpeed, llama.cpp, and Hugging Face Transformers.

Inkling’s full weights are available on Hugging Face as the original checkpoint and as a quantized NVFP4 checkpoint. Thinking Machines also previewed Inkling-Small, which has 276 billion total parameters and 12 billion active parameters. The company said it would release the smaller model’s full weights after completing testing.

Enterprise impact

Inkling’s differentiation lies in its open weights, multimodal capabilities, controllable reasoning, and integration with Tinker, rather than benchmark leadership, according to Biswajeet Mahapatra, principal analyst at Forrester.

“Enterprises are most likely to benefit in workloads where domain adaptation matters more than generic model performance, including knowledge-intensive copilots, multimodal customer service, document understanding, operational workflow automation, and agentic tasks that require organization-specific data, policies, and processes,” Mahapatra said.  

Inkling’s US origin could also influence adoption among Western enterprises, according to Pareekh Jain, CEO of Pareekh Consulting. He said many Western organizations face regulatory or procurement barriers when considering Chinese-developed AI models.

“Inkling gives those organizations a US-developed open-weight option that they can deploy on their own infrastructure,” Jain said.

However, the benefits will need to be weighed against the cost of deploying the full model.

Running Inkling on private infrastructure requires a GPU cluster with at least 2 TB of aggregated VRAM for the BF16 checkpoint, according to the model card. Thinking Machines lists configurations of eight Nvidia B300 GPUs or 16 H200 GPUs. A quantized NVFP4 checkpoint lowers the requirement to at least 600 GB and can run on four B300 GPUs or eight H200 GPUs.

“Because Inkling is a massive model with 975 billion total parameters, running the full model still requires significant GPU infrastructure, making closed-model APIs more economical for many organizations,” Jain said.

Jain said Inkling-Small may be a more feasible option for many enterprises because it could reduce infrastructure costs and latency while retaining useful performance across key workloads.

Safety and governance

Thinking Machines said it trained Inkling for calibration, instruction following, and resistance to censorship. The company said the model showed “strong patterns of censorship non-compliance” when evaluated by Cognition on its Propaganda and Censorship Eval.

Inkling scored 98.6% on StrongREJECT, which Thinking Machines described as a test of whether models refuse unambiguous harmful requests.

The model’s safety behavior should be retested after an enterprise customizes it, according to Jain. “Model fine-tuning can weaken safety filters, so companies should retest safety after customizing the model rather than assuming it stays safe,” Jain said.

He added that self-hosted and modified versions could diverge from Thinking Machines’ official model over time without receiving automatic updates.

“CIOs need to ensure every AI agent action is logged, auditable, and governed by human approval for high-risk tasks,” Jain said.

In many teams, dependency security still happens after the most important trust decision has already been made. A package is added, the lockfile changes, the feature moves forward, and only later does the pipeline ask whether the application should have trusted that code in the first place.

That workflow made sense when dependency security was mostly viewed as a compliance check. Run a scanner. Produce a report. Fail the build if the risk crosses a threshold. Let someone decide what to do next.

But the modern Node.js ecosystem has changed. The risk no longer begins in CI. It begins earlier, at the moment a developer decides to trust a package.

That is why the next phase of Node.js security cannot be limited to better pipeline enforcement. It has to move closer to the developer workflow, before dependencies become part of the application, before a pull request becomes someone else’s problem, and before a build log becomes the first moment anyone realizes that something important has changed.

Every install is a trust decision

The npm ecosystem is built on trust at an enormous scale. Every install is a trust decision. Every transitive dependency extends that decision to maintainers, packages, scripts, release pipelines, and infrastructure the application team may never inspect directly. This model gave JavaScript its incredible velocity. It also created one of its deepest security weaknesses.

Recent npm supply chain incidents show why this matters. In March 2026, malicious Axios versions were published to npm through a compromised maintainer account. Microsoft later described how those packages attempted to retrieve a second-stage payload during installation. In May 2026, TanStack published a postmortem explaining that 84 malicious versions across 42 npm packages were published through a legitimate release pipeline after an attacker abused GitHub Actions behavior and runner trust boundaries. Security researchers also reported broader Mini Shai-Hulud activity across the npm ecosystem in May, including hundreds of malicious package versions published in a short period.

Not every one of these incidents is a traditional CVE. Some are malicious package compromises. Some involve CI/CD credential theft. Some involve maintainer or pipeline compromise. But they all point to the same larger issue: dependency risk is now part of everyday software engineering, not something that can be pushed entirely to a downstream security process.

The problem is not the scanner. It is the handoff.

Ubiquitous dependency risk changes what developers need from security tooling.

The problem is not that teams lack scanners. Many organizations already run security checks in CI. The problem is that the output of those checks often arrives too late and speaks the wrong language for the person expected to act on it.

A pull request fails. A long vulnerability report appears. The report may be technically accurate. It may contain the right advisory IDs, affected versions, dependency paths, severity labels, and references. But the developer still has to comb through the output and reconstruct the actual engineering decision from the evidence provided.

That reconstruction is rarely simple. The developer has to understand which package introduced the issue, whether the vulnerable dependency is direct or transitive, whether the fix is actually within the application team’s control, and whether the recommended version is safe to adopt. They also have to determine whether the dependency is used in production or only during development, whether the update might break the application, and whether the fix belongs in the current pull request or requires separate engineering work.

That uncertainty is where security work often slows. The scanner has detected risk, but the developer has not been given a clear path from detection to decision.

Security needs to move closer to engineering judgment

This is not a criticism of scanning. Scanning is necessary. CI enforcement is necessary. Centralized security platforms are necessary. But they are not sufficient, because they often operate after the trust decision has already been made.

The real architectural question is this: where should dependency security live in the software development life cycle?

If it lives only in CI, it becomes an interruption. If it lives only in dashboards, it becomes someone else’s queue. If it lives only in periodic audits, it becomes a backlog. But if it lives at the moment a dependency is introduced, upgraded, or reviewed, it becomes part of engineering judgment.

That shift matters because modern JavaScript development is becoming faster than human review can comfortably handle. Developers no longer add dependencies only by reading documentation and choosing libraries manually. AI coding assistants can suggest packages, generate install commands, modify package files, and rewrite code around third-party APIs. Agentic development workflows can make dependency changes as part of broader automated refactors.

AI makes the trust boundary harder to see

That acceleration is useful. It also changes the risk model.

When a human developer adds one package, the team can review the decision. When a coding agent modifies several dependencies as part of a larger task, the trust boundary becomes harder to see. The package file changes, the lockfile changes, the application still runs, and the pull request may look like a normal feature update. But the real security question may be hidden inside the dependency graph.

This is where Node.js teams need a different mental model.

Dependency adoption should not be treated as a small implementation detail. It should be treated as an architectural decision with security consequences. A new package is not just code reuse. It is a new trust relationship.

That does not mean developers should stop using packages. The npm ecosystem exists because reuse works. Most teams cannot and should not build everything themselves. But convenience should not erase visibility. If a dependency becomes part of the application, the team should understand what was added, what changed in the lockfile, what risk comes with it, and what action is available if something is wrong.

Developers need confidence, not just reports

The same applies to remediation. Developers do not want a wall of vulnerability text. They want confidence. They want to know what action reduces risk, what version should be targeted, whether the change is safe, and whether the fix is actually under their control. A vulnerability report that leaves the developer uncertain may satisfy a process requirement, but it does not necessarily improve the speed or quality of remediation.

That is the gap many teams feel today. Security tools are often very good at saying, “There is a problem.” They are less consistent at helping the developer answer, “What should I do next?”

This is the broader problem I have been exploring through CVE Lite CLI, now an OWASP project. The point is not that one command-line tool solves Node.js security. It does not. The larger idea is that dependency security has to move closer to the developer’s moment of decision. A useful developer-side security workflow should not merely report that risk exists. It should help the engineer understand whether the issue is in their control, what change is available, and whether the fix actually reduces risk.

The future is decision support, not just detection

That distinction is important. The future of Node.js security is not just more detection. It is better decision support.

Security teams still need policy. Enterprises still need dashboards. CI still needs gates. But developers need something more immediate: a way to reason about dependency risk while the code is still fresh in their mind. That is where the ecosystem has to evolve.

We already accept that testing belongs close to development. We accept that linting belongs close to development. We accept that formatting, type checking, and build validation belong close to development. Dependency security should follow the same path. It should not be treated as a mysterious report that appears at the end of the process. It should become part of the normal rhythm of engineering work.

Before adding a package, developers should understand what trust relationship is being introduced. Before accepting an AI-generated dependency change, they should inspect what entered the graph. Before merging a pull request, teams should understand whether a vulnerability is direct, transitive, fixable, or blocked by another package. And before treating a CI failure as noise, organizations should ask whether the workflow is giving developers enough information to act confidently.

Node.js security will be won, or lost, before CI runs

The Node.js ecosystem will not become safer by slowing down all development. That is unrealistic. It will become safer when security work is placed where developers can actually use it.

The next generation of Node.js security will be won or lost before CI runs.

It will be won when dependency decisions are still small enough to understand, fresh enough to review, and close enough to the developer for action to feel natural.

That is the shift teams need to make now. Not from insecure to secure in one step, but from late detection to earlier judgment. From vulnerability reports to engineering decisions. From trusting packages by habit to understanding trust as part of software design.

A year ago, most enterprise AI systems generated recommendations. Today, AI systems are approving transactions, routing shipments, updating records, interacting with customers, and triggering downstream software actions with little or no human involvement.

For CIOs, that shift changes the central governance question. The challenge is no longer simply whether an AI model is accurate. It is whether the organization can explain, audit, and defend the decisions the system makes.

When an AI assistant suggests a meeting time or summarizes a document, mistakes are inconvenient. When an autonomous AI system issues a refund, reprices a product, modifies a customer record, or initiates a financial transaction, mistakes carry operational, legal, and reputational consequences.

When those consequences arrive, “the model decided” is not an acceptable explanation.

This is the accountability gap emerging at the center of enterprise AI adoption. Organizations are deploying increasingly autonomous systems while relying on technology that often provides little visibility into how decisions are made. The result is a growing mismatch between the level of authority organizations grant AI and their ability to understand or justify its actions.

Black-box AI may have been acceptable when AI primarily generated predictions. It becomes far more problematic when AI begins taking actions on behalf of the business.

The lesson software already learned

Fortunately, the technology industry has faced a similar challenge before.

As enterprise software systems became more distributed and complex, troubleshooting failures became increasingly difficult. Engineers could no longer rely on intuition to understand what happened when something broke. The solution was observability: the practice of instrumenting systems so their internal state could be understood through logs, metrics, traces, and monitoring.

The goal was not to predict every possible failure in advance. It was to create enough visibility that teams could reconstruct what happened after the fact and identify the root cause.

Enterprise AI now requires a similar discipline.

But AI observability must go beyond traditional software observability. It is not enough to know what action occurred. Organizations also need visibility into why the system believed that action was appropriate.

An auditable AI system should be able to answer questions such as:

• What information did the system rely on?
• Which tools or data sources did it access?
• What alternatives did it consider?
• What verification steps were performed?
• How confident was it in its conclusion?
• What events led to the final action?

These questions are rapidly becoming essential operational requirements rather than technical nice-to-haves.

Why visibility matters more as AI gains autonomy

As AI systems become more autonomous, failures become harder to detect and diagnose.

A human reviewing a single AI-generated recommendation can often spot obvious mistakes. A network of AI agents coordinating multiple tasks across business processes presents a different challenge. Decisions can build upon one another. A flawed assumption early in a workflow can propagate through subsequent actions, creating confident but incorrect outcomes.

The challenge is rarely identifying that something went wrong. Eventually, an error surfaces through a customer complaint, a failed transaction, an audit finding, or an operational disruption.

The challenge is determining why it happened.

Which information influenced the decision? Which tools were consulted? Which safeguards worked as intended? Which ones failed?

Without visibility into the reasoning process, troubleshooting autonomous AI workflows can become significantly more difficult than debugging traditional software systems.

For CIOs responsible for enterprise reliability, compliance, and governance, that lack of visibility creates unacceptable operational risk.

Moving toward glass-box AI

The answer is not to slow AI adoption. The answer is to make AI systems observable.

Increasingly, organizations are seeking AI systems that behave more like a glass box than a black box. The objective is not to expose every parameter inside a neural network. Rather, it is to provide a clear, auditable record of how decisions were reached and why actions were taken.

The most promising approaches share two common characteristics.

The first is verification. Instead of treating a single model’s output as ground truth, systems incorporate independent validation steps before actions are executed. Multiple agents, external checks, business rules, or verification workflows help identify errors before they become operational incidents.

The second is explainability. Effective systems maintain a decision trail that captures inputs, intermediate reasoning steps, tool usage, verification activities, and outputs in a form that human reviewers can understand.

Together, these capabilities create something that has long been expected of human decision-makers but is often missing from AI systems: the ability to show your work.

The regulatory and business reality

The push toward AI observability is not being driven solely by technologists.

Regulators increasingly expect organizations to demonstrate oversight of automated decision-making systems. Emerging AI governance frameworks place growing emphasis on transparency, traceability, accountability, and human oversight.

Customers are moving in the same direction. Whether the decision involves pricing, service, eligibility, or support, people increasingly want the ability to understand and challenge outcomes that affect them.

The result is a convergence of operational, regulatory, and market pressures around a single requirement: organizations must be able to explain what their AI systems are doing.

Three questions every CIO should ask

Before deploying autonomous AI systems, technology leaders should be able to answer three basic questions:

1. Can we reconstruct the complete decision path that led to an action?
2. Can we verify critical outputs before actions are executed?
3. Can a human auditor understand why the decision occurred?

If the answer to any of those questions is no, the organization may be granting more authority to AI than it can responsibly govern.

Accountability will become a competitive advantage

The organizations that succeed with autonomous AI will not necessarily be those that automate the most processes or deploy the largest models. They will be the organizations that combine automation with accountability.

Black-box systems made sense when AI primarily generated predictions. As AI increasingly acts on behalf of businesses, customers, and employees, visibility becomes essential.

The future of enterprise AI will belong not to systems that merely act, but to systems whose actions can be examined, understood, and trusted.

—

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.

Preview 6 of Microsoft’s .NET 11 software development platform is now available, with improvements across the runtime, libraries, frameworks, and C# and F# programming languages.

Announced July 14, .NET 11 Preview 6 can be downloaded from dotnet.microsoft.com. The full, general production release is expected in November. The first preview was unveiled February 10.

Runtime-async, the .NET runtime’s built-in implementation of async/await, keeps getting faster in Preview 6, building on the suspension improvements from Preview 5. Async continuations can now opt out of ExecutionContext capture and restore. And the JIT now compiles a dedicated runtime-async version of a synchronous, task-returning method rather than delegating to it through a thunk. The JIT turns the method’s tail calls into runtime-async calls and awaits the task that would otherwise have been returned, so the async path no longer pays for an extra layer of indirection, Microsoft said.

In library improvements, System.Text.Json can now serialize and deserialize the new C# union types. The serializer recognizes a union through the new JsonTypeInfoKind.Union contract type, reads and writes the active case, and supports the reflection-based serializer and the source generator. The new JsonUnionAttribute, JsonUnionCaseInfo, and type-classifier APIs enable customization of how cases are discovered and named.

In C# improvements, extension members now include indexers, so developers can add this[...] access to a type from an extension block. This rounds out the extension members feature introduced in .NET 10, which already supported extension methods and properties. An extension indexer is declared like an instance indexer inside an extension block.

Other highlights in .NET 11 Preview 6:

• Math.BigMul(long, long, out long) is now significantly faster on x64. The JIT generates a single MUL r/m64 instruction when both operands are 64-bit values and the caller requests the high half of the result. Previously the JIT emitted a helper call. The change eliminates the call overhead and makes code that multiplies large numbers tighter.
• Minimal API validation in ASP.NET Core now supports asynchronous validators end-to-end.
• For F#, the compiler emits better sequence points for several common debugging scenarios. Breakpoints and stepping are improved for call arguments that need stack-empty debug points, for expressions and comprehensions, simple literal bindings, and if or match conditions.
• For .NET MAUI, .NET 11 Preview 6 advances the cross-platform CollectionView and Shell architecture, removes the legacy Xamarin.Forms compatibility package, and brings the Apple workloads onto stable Xcode 26.6.
• Also for .NET MAUI, HybridWebView JavaScript interop is reworked to use a source generator instead of reflection, so it no longer produces trim or AOT (ahead of time) compiler warnings and works correctly in fully trimmed and Native AOT apps.
• Projects that use Microsoft.TypeScript.MSBuild in Razor Class Libraries now properly integrate TypeScript compilation outputs with ASP.NET Core Static Web Assets.

OpenAI’s recent update to its Codex CLI has introduced a new protocol that appears to shift more orchestration decisions from user-defined configuration to the runtime, prompting developers to request greater visibility into the instructions exchanged between AI agents.

In a detailed GitHub merged request, users stated that the Multi-Agent V2 protocol-infused architecture of the CLI no longer exposes the instructions passed between parent and sub-agents, making it difficult to inspect how work is delegated across the system.

“Multi-agent v2 currently routes agent instructions through normal tool arguments and inter-agent context. That means the parent model can emit plaintext task text, Codex can persist it in history/rollouts, and the recipient can receive it as ordinary assistant-message JSON,” the request read.

“This changes the v2 path so agent instructions stay encrypted between model calls: Responses encrypts the message argument returned by the model, Codex forwards only that ciphertext, and Responses decrypts it internally for the recipient model,” it added.

Other users, commenting on the thread, also said that the lack of visibility into agent instructions can be attributed to the recently introduced Multi-Agent V2 protocol, with one user stating that reverting to the previous version of the CLI restored visibility, but only as a temporary workaround.

Separately, Ignat Remizov, CTO at payment service Zolvat, filed a GitHub feature request to offer what can be described as a permanent fix after stating that OpenAI may have introduced the change in efforts to harden security.

“A possible shape is to keep the encrypted message field for model delivery, but add a separate non-encrypted audit field for the readable task text. The audit field should be persisted in rollout/history/trace metadata so users and maintainers can inspect what was delegated without needing to decrypt model-delivery ciphertext,” Zolvat wrote.

Enterprise governance concerns are likely to emerge

While an OpenAI contributor said the protocol remains under development and declined further changes to the request, analysts warned that the issue would create debugging, governance, and operational challenges for development teams and their enterprises if the issue persists or becomes a long-term characteristic of multi-agent systems.

“Hidden agent instructions reduce observability in multi-agent systems. Developers can no longer see whether failures stemmed from incorrect task delegation, poor orchestration, or model reasoning, making debugging, prompt optimization, and root-cause analysis significantly harder. Agent instruction traces are becoming as essential as application logs in modern software,” said Pareekh Jain, principal analyst at Pareekh Consulting.

For CIOs, Jain pointed out, opaque agent interactions create governance challenges.

“Without visibility into how agents delegated and executed tasks, it becomes harder to audit decisions, investigate incidents, demonstrate compliance, and build trust in AI systems. Enterprises will increasingly expect secure but auditable agent communication rather than completely hidden orchestration,” Jain said.

“Any big enterprise, especially in regulated industries such as banks and hospitals, needs to be able to prove what their AI systems did and why, especially if something goes wrong. If a sub-agent does something bad, like touching private data, the company needs to show here’s exactly what it was told to do. If that record doesn’t exist, it is a serious problem for trust and legal accountability, not just an annoyance,” Jain added.

Further, the analyst pointed out that issues around the visibility of agent operations could even slow production deployments of mission-critical AI.

“Enterprises, just like we are seeing with developers on GitHub, are likely to demand stronger observability, audit trails, and governance before trusting autonomous multi-agent systems. It is nearly as important as model performance,” Jain added.

An email sent to OpenAI enquiring about planned changes to the protocol went unanswered.

These days, application developers can take their pick from a vast menu of architectural solutions. We can choose from the well-understood to the experimental, and from blended solutions in between. Several powerful middle-ground technologies that emerged during the cloud revolution have really come of age. Here we’ll take a look at putting together three of the most impressive: GitHub, Vercel, and Firestore.

Each of these is an important tool in its own right that can be used to attack specific problems. In combination, they not only meet the needs of several important application scenarios, but they have a superpower—the ability to dramatically shorten the distance between development and deployment.

There is nothing quite as gratifying as putting your hands on just the right mix of tools for a given need.

A ‘no-ops’ stack built for speed

If your primary goal is sheer development velocity, you would be hard-pressed to top this architecture. This “no-ops” stack collapses the distance between your local IDE and a globally distributed production environment. You are essentially trading the overhead of managing VMs and load balancers for the sheer speed of committing code and watching it deploy automatically.

While each component is highly flexible, adopting them requires a specific, event-driven mindset. There are a few finicky bits to manage, mostly around routing environment variables securely and designing around stateless back-end functions. But the constraints are obvious and well-documented.

Before we look more closely, let’s quickly identify the kinds of apps that are a perfect fit here, along with those that are workable and those that really merit a different approach.

• The sweet spot (deploy and go): AI-mediated applications, asynchronous game back ends, and real-time collaborative B2B dashboards. This architecture perfectly absorbs the unpredictable latency of LLM APIs and instantly syncs state across multiple clients without requiring you to build custom WebSocket infrastructure.
• The middle ground (workable, with trade-offs): Headless e-commerce, moderate IoT telemetry, and apps requiring scheduled batch processing. You will encounter friction if your catalog relies on deeply relational SQL constraints, or if your background reporting jobs take longer than a few minutes and hit serverless execution limits.
• The danger zone (look elsewhere): High-frequency trading, fast-paced action multiplayer games, heavy data ETL pipelines, and core financial ledgers. Serverless architectures cannot natively hold open the persistent WebSockets required for twitch-reflex data, and heavy compute tasks will abruptly time out.

We should mention that these categories are not mutually exclusive. Many enterprise applications, such as a full-scale e-commerce platform, straddle these lines. You might use Vercel and Firestore to build a lightning-fast, reactive storefront that handles ephemeral user state like shopping carts, while simultaneously “stitching in” a managed SQL database like Supabase or PlanetScale. This hybrid approach allows you to maintain the relational integrity required for back-office inventory and financial ledgers and pair it with the front-end velocity this stack provides.

GitHub: the bedrock

I don’t need to introduce you to GitHub. It is a central element of the development landscape. I still remember CVS and SVN with a certain nostalgia, but the enhancements of Git speak for themselves. When combined with the orchestration powers of GitHub, it is no wonder that virtually the whole industry has adopted this type of platform.

Git plus GitHub gives you an enormous amount of power already, in terms of how you can organize and automate your projects. But there is a next-level experience in combining GitHub and Vercel. For JavaScript-based projects, you can take simple GitHub pushes and turn them into instantly deployed clients and serverless functions. It is one of the cleanest and least fiddly ways to move from raw code on your local machine to a globally deployed, full-stack architecture.

Vercel: the nexus

Vercel is more than just a deployment host. It is a control plane that ties this high-velocity, no-ops architecture together. Alongside GitHub and Firestore, Vercel’s deeper strength is its ability to act as an orchestration layer between your reactive front end and external stateful services.

Vercel has a great amount of facility in fine-tuning what branches go to what environment and helpful features like instant rollback. You can just log into Vercel’s dashboard for your project and see the history of deployments and any errors and logs. It’s a simple menu choice to roll back to a historical version or compare one version against another.

When you “stitch in” third-party services (such as a managed SQL database like Supabase or a payment processor like Stripe), Vercel’s serverless functions become the lightweight interface, and Vercel’s the adapters handle the communication. You offload the integration logic (the service layer) to Vercel’s global Edge Network, keeping your UI and back end clean, responsive, and decoupled. 

In short, Vercel allows you to get the speed of the “no-ops” development life cycle without sacrificing the complex transactional integrity required for some applications like enterprise inventory systems.

Firestore: the datastore

Firestore is an extremely lightweight, NoSQL, cloud datastore. It has a great deal of add-on power, but its core value proposition is that it accepts virtually any data you stuff into it and it provides event-driven subscriptions to data changes.

These two capabilities together make Firestore about as straightforward a solution to a managed back end as you can imagine. You subscribe to collections or even fields and then you simply stick “unstructured” data (read: JSON with variable fields) in and the client waits for the changes it is interested in.

This is so streamlined that one can just point the browser (or native mobile app) directly at Firestore and listen for events. Which immediately raises the question of identity, for auth and for data visibility, but hold on—Firestore’s third superpower is that it has an authentication module that actually works. What I mean is, it is actually pretty simple and yet confidently secures your app.

Sometimes auth solutions seem either too simple (and yet opaque) or too mired in the nitty gritty. Firestore auth will let you do some basic configuration and start using a reasonable auth almost immediately. 

Not to belabor the point, but having a realistic and attainable auth solution elevates your stack to a production grade—one that can handle many real-world applications. Firestore auth plays nicely with other important APIs, like Stripe. Typically, auth is a major feature that feels like off-roading in a Honda Civic, but Firestore’s approach to auth, added to this particular stack, feels like a normal speed bump. It’s just another component you plug in, rather than a tentacled alien you weave into the your code.

The limits of the velocity stack

This architecture combines components that are optimized for flexibility. That same character also introduces distinct limitations. Understanding these is essential before committing production workloads.

The serverless life cycle

Serverless functions are spun up to handle requests. They close out soon afterward and lose any state. For that reason, they cannot natively hold open persistent WebSockets. If your system requires continuous, sub-millisecond, bidirectional streams—like a real-time multiplayer action game or a high-frequency trading dashboard—pure serverless will fight you all the way. You are forced to introduce a third-party managed WebSocket service to route messages back to your stateless endpoints via HTTP webhooks.

The execution time ceiling

Vercel (like all serverless platforms) enforces strict timeouts on operations. While enterprise tiers might grant you up to 15 minutes, standard functions often time out after 10 to 60 seconds. Long-running tasks like video transcoding, database scripts, or orchestrating multi-step AI agent workflows, which might take 20 minutes to resolve, will run up against these limits. Heavy-lifting tasks must be offloaded to a dedicated, long-running service like Google Cloud Run, or broken into smaller, asynchronous chunks via message queues.

The cold start reality

While the industry has made massive strides in minimizing initialization times—particularly with lightweight edge networks—traditional Node.js-based serverless functions still experience cold starts. If a function has not been invoked recently, or if traffic spikes require a new instance to spin up concurrently, the first request will take a noticeable latency hit as the container provisions and the code loads.

API instead of RAM

In a traditional server environment, you can store transient data in global RAM, allowing subsequent requests to access shared context instantly. In the serverless model, every request might hit a fresh container. Therefore, all shared context must be externalized. Although Firestore serves brilliantly as the state manager, relying on a database for high-frequency, sub-millisecond, ephemeral caching introduces network latency and per-operation costs. That said, using a shared RAM state on a server is non-trivial also, unless you are using a single app server and VM (because high-availability or fail-over requirements will lessen the RAM win on a traditional server).

Tuning for velocity and control

Every architectural decision is a trade-off. There are no cost-free choices. By adopting the GitHub, Vercel, and Firestore stack, you are explicitly maximizing feature velocity over fine-grained control.

You lose the ability to tweak the underlying operating system, hold open persistent sockets, or run hour-long back-end scripts. In exchange, you gain an architecture that scales from zero to global distribution instantly, requires virtually no devops maintenance, and perfectly absorbs the asynchronous, event-driven realities of modern application development.

For the right application—whether it is a fast-moving prototype or an enterprise AI copilot—this stack doesn’t just save time; it fundamentally changes how quickly a small team (or a single person) can impact the market. You stop worrying about build chains, load balancers, and server patches, and you focus on the central mission: shipping features.

On the first day of Software Engineering 101, you learned about the SDLC — the software development life cycle. You learned that there is a whole lot more to producing quality software than writing some code and deploying it to production. We’ve studied the SDLC every which way, and we know where and how time is spent within it.

The coding is the most interesting part of the SDLC. It is one of a number of steps in the process, but it’s the part that takes up the biggest chunk of the SDLC schedule.

Agentic coding has changed all of that. I wrote earlier this year about the impacts upstream of coding when writing code is no longer the bottleneck. Here I want to think about the impacts for developers downstream — what we can expect to happen after the code gets written — when agents write the code.

Downstream from coding

Even before agentic coding, we developers spent far more time reading and maintaining code than we spent writing it. Maintaining the code and supporting the product has always been the major lifetime cost of the project as a whole. Now that the bottleneck has moved away from the coding process, we will look for ways to apply AI agents downstream of writing code. So, just as agentic AI has made writing code trivial, we can expect it to improve the remaining 60% to 70% of our job as well.

Maintenance of code can be a real challenge. We are all familiar with how it often goes. We get a vague customer report of a problem along with a copious log, and we have to dive in and make sense of a very complex situation. The application has hundreds of settings and options, making the potential code paths practically infinite. Maybe we have a copy of the customer’s database with their precise settings, or maybe we just know they have one specific setting inside the problem feature set. Maybe we can reproduce the problem. Maybe we can’t. It’s almost always vague and confusing.

Here’s where agents can really shine. Normally, a huge log is a problem. What mere mortal can sift through the thousands of entries that our powerful logging tools can produce? No human, but Claude Code will happily gobble up all of that data and quickly zero in on the problem. And by quickly, I mean frequently in a matter of minutes or seconds. 

The next choke point

Or as Spiros Xanthos, the CEO of Resolve AI — producer of a tool specifically designed for applying agents to production problems — says, “The real opportunity is purpose-built AI that can carry more of the cognitive load of production… If we get that right, developers spend less time manually piecing together what happened and more time building and improving the systems they own.”

I’ll venture to say that dealing with production problems is more challenging than writing code, both for humans and agents. But agents have huge contexts and infinite patience, and we humans do not. Code is a bounded system, and agents can train on an enormous body of data illustrating a vast array of coding techniques. Production? As Xanthos put it to me, it’s effectively unbounded, enormously varying, and a living, breathing system different for every product and every company. 

We should always focus on the tightest bottleneck, and then move on to the next one. We’ve solved the coding choke point, and now we need to turn our attention to the next one — fixing production issues. That’s a non-trivial part of a developer’s job, and we shouldn’t be surprised that AI agents can do it better than we can.

The first time I heard someone say their AI now wrote 80% of their tests, I asked the obvious question. Eighty percent of what?

After 20 years building and leading test automation for consumer-scale platforms, my honest answer turned out to be eighty percent of the typing, not eighty percent of the engineering. The remaining twenty was where the work still lived. Budgeting for two percent of leftover effort was the mistake. When the real number was closer to thirty, that gap was the difference between a pipeline that shipped and one that quietly built up a queue of half-trusted features nobody could rely on.

This piece is about that gap. As an independent research project on LLM-augmented testing methodology, I built a six-stage agentic pipeline that takes a design in Figma and produces running tests in WebDriverIO, connected end to end over the Model Context Protocol. It works. It has been useful. And the parts that broke surprised me, because they were not the parts the hype cycle tells you to worry about.

How I wired a six-stage pipeline over one protocol

The pipeline runs six stages in sequence, each owned by a different agent, with every handoff crossing MCP.

Six-stage agentic test pipeline: design capture → requirements writer → ticket opener → code generator → test-case writer → automation generator. Each stage carries an MCP handoff and a provenance stamp.

The end-to-end trace links a pull request back to a Jira ticket, a requirements section and a Figma frame. Each artifact is stamped with the agent that produced it, the model it used and the inputs it was given.

MCP is the boring middle that makes any of this work. The cliché is that MCP is “USB-C for AI”: one open protocol, any tool. Like most analogies, it is about eighty percent right. The part that matters is the eighty: I do not have to write a custom adapter for every system the agent talks to. One MCP server per tool and every agent talks to all of them the same way.

Typed handoffs between agents are my own architecture, layered on top of MCP rather than provided by it. Each agent writes a typed artifact the next agent reads. Each handoff is logged with provenance. When something went wrong six stages in, I could replay the chain. Without that discipline, a multi-agent pipeline is a debugger’s worst day. You know the test plan is wrong. You cannot tell whether the mistake came from the Figma read, the requirements interpretation or the ticket scaffolding. With it, I could point at exactly which stage went sideways and which inputs it was looking at when it did. The pattern lives in a public MIT-licensed reference implementation for any reader who wants to run it.

The sixteen-minute number is the marketing number. I ran the full chain end to end in about sixteen minutes on a synthetic net-new screen, Figma in, automation suite out. That repeated across my runs; it is not a demo trick. But sixteen minutes is the part of the story most fun to tell and least useful to learn from. It is what gets quoted in the all-hands. The hours that come after, when a human reviews each handoff, are where the work actually lives.

What actually broke in production-style runs

The failures that stalled my pipeline were rarely the ones I expected.

I expected hallucinated APIs. I got them: the agent confidently called endpoint names that sounded right but did not exist. I expected sparse-spec-in, sparse-spec-out, where a Figma frame with no annotations produced a requirements doc with vague acceptance criteria, every time. I expected locator drift, the common UI-automation failure mode where a renamed component silently breaks an entire test suite. There is solid outside writing on non-determinism in tests covering this whole family of failure modes, and the agent inherited every one.

What I did not expect, and what kept the pipeline down longer than any of the above, was the plumbing.

The model backend timed out under load. It lost credentials silently and started returning empty strings, which the agent then read as confidence. A duplicate consumer on a shared long-poll API endpoint produced an HTTP 409 conflict that broke delivery without throwing anything visible. One unguarded exception inside one agent aborted a whole shared scheduler run and took the other agents in the registry down with it. The single worst incident cost me three hours to find. An environment variable had silently rotated overnight; every agent in the fleet was returning structurally valid but semantically empty requirements docs; the downstream stages were dutifully generating tests against nothing.

None of those are model bugs. They are infrastructure. The agent literature, which is what I went looking through when I started this work, mostly does not talk about them.

The fix was not better prompts. It was circuit-breaker-style review checkpoints between stages and what I now call the four-guard discipline: four small guards I consider non-negotiable on any unattended agentic pipeline. The bulkhead pattern from microservices is the most consequential. An unhandled exception inside one agent can no longer abort the shared run; the offending agent fails fast with a structured error and the others keep going. Paired with that, a pure-data fallback ensures a model timeout produces a deterministic output explicitly marked as degraded mode, rather than an empty string the next stage will misread as confidence. A single-owner lease sits on every shared external endpoint, the cure for the duplicate-consumer incident that ate one of my Sunday afternoons. The cheapest guard was the last to arrive: a one-line synthetic canary every agent has to produce a known correct response to before any real work begins, so a credentials rotation or silent backend failure trips an alert before downstream stages have generated artifacts against garbage.

None of these guards is novel. They are textbook stability patterns at a new boundary: the seam between the LLM agent and the rest of the system, which most of the existing agent literature still treats as a solved problem.

The 20% you don’t see, and when not to do this

Here is the part the demo videos leave out. Even when the pipeline works, the human time per stage does not go to zero.

Human review time per ticket across five pipeline stages: code review 60-180 min, automation review and flaky-fix loop 30-90 min, ticket architecture and sequencing 30-60 min, test data and environment 15-30 min, requirements review 20-30 min. Net: the human still spends 20-30% of the original effort, almost all of it reviewing rather than creating.

Net of all that, the human still spends twenty to thirty percent of the original effort, almost all of it reviewing rather than creating. The pipeline saves seventy to eighty percent, not ninety-eight. The trap is budgeting for the two percent you do not save.

When does this kind of pipeline make sense? In my experience, when the Figma is richly annotated and acceptance criteria are clear up front; when there is review capacity to absorb the work the pipeline shifts onto humans; when the stack is well represented in the training data; and when the feature is net-new rather than a deep edit of legacy code. When does it not? When the design lives on a whiteboard. When the integration touches old code with hidden contracts. When the path is regulated or safety-critical. When there is no senior reviewer who can hold the line. When the work is exploratory and writing the spec is the actual point of the exercise.

Teams I have seen succeed with agentic pipelines budget for the rework explicitly, staff the review queue and treat the saved hours as capacity for harder problems rather than headcount they can release. Teams I have seen struggle did the opposite: declared victory at the demo and quietly accumulated a backlog of half-trusted features the next quarter had to clean up.

The right unit of measurement is not how much the pipeline generates. It is how much of what it generates a human still has to touch before you would ship it. Call it the 80/20 rework rule: measure the rework, not the generation. The teams that get the rework number right are the ones whose AI investments compound. The teams that stop counting at the headline percentage are the ones that own the cleanup six months later.

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

Red Hat OpenShift 4.22, an update to the company’s hybrid cloud application platform, is now generally available. The release focuses on cutting cloud infrastructure costs, simplifying operations of virtualized workloads, and securing sensitive data.

Announced July 14, Red Hat OpenShift 4.22 continues to harden the platform foundation to meet growing security standards, helping reduce the manual effort of compliance and risk mitigation, Red Hat said. The introduction of a minimal Red Hat Universal Base Image (UBI) strips away non-essential packages to reduce the overall attack surface. With Red Hat OpenShift sandboxed containers 1.12, OpenShift 4.22 makes support for confidential containers on bare metal generally available.

The OpenShift 4.22 release also introduces confidential AI as a technology preview. With confidential AI, organizations can isolate and run highly sensitive workloads and proprietary AI algorithms inside a cryptographically isolated slice of memory and CPU, providing data privacy even during runtime execution, according to Red Hat.

OpenShift 4.22 also brings new Red Hat OpenShift Virtualization capabilities. A new Ethernet virtual private network integration with user-defined networks allows teams to connect containerized and virtualized workloads to external infrastructure. Volume groups now can be used to execute multi-volume snapshots for VMs, providing a crash-consistent backup mechanism that simplifies disaster recovery. And the introduction of two-node OpenShift with fencing provides a highly resilient and resource-efficient option for constrained edge environments, Red Hat said.

In addition, OpenShift 4.22 offers new platform capabilities designed to optimize resource usage and lower operational overhead. The Red Hat build of Karpenter, an open source auto-scaler that right-sizes compute instances for Kubernetes clusters, is now generally available for Red Hat OpenShift Service on AWS with hosted control planes. And customers running Red Hat OpenShift Service on AWS with hosted control planes now can integrate AWS EC2 Spot Instances for fault-tolerant workloads to save on costs.

Finally, Red Hat OpenShift 4.22 introduces the JobSet operator to streamline large-scale distributed training runs and LLM fine-tuning. This framework coordinates multiple related jobs as a single unit, maximizing the use of expensive GPU compute.

Port has rolled out Port AI Builder, a vibe coding platform designed for software development and platform engineering teams.

Announced July 14, Port AI Builder lets teams create and run agentic workflows in natural language, with built-in human-in-the-loop review and approval. The platform lets organizations apply AI agents across the SDLC (software development life cycle), drawing on domain skills spanning site reliability engineering, devops, architecture, security, AI governance, data modeling, and UX, while maintaining governance and visibility, the company said. Port AI Builder is available through free and paid subscriptions.

Port AI Builder works on top of Port’s Agentic SDLC Platform, which provides the context lake, workflow orchestration, agent management, and governance that enterprises need to operationalize AI SDLC, according to the company. The new AI Builder lets teams build production-grade workflows in minutes, for use cases such as autonomous resolution, AI cost management, and engineering performance tracking, without losing control, Port said.

When an HTTP request is too long or complex to be encoded in its URI using GET, developers have long resorted to using the POST method as a workaround. However, this can create issues; while GET requests are defined as safe and idempotent, POST does not necessarily share those characteristics.

To combat the problem, the Internet Engineering Task Force (IETF) has published a proposed standard HTTP request method, QUERY (RFC 10008), which bridges the two functions, taking the best of each.

A safe method is defined as one which is “essentially” read-only, where “the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource. Likewise, reasonable use of a safe method is not expected to cause any harm, loss of property, or unusual burden on the origin server,” the IETF standards document states. And when a request is idempotent, no matter how many times it is retried, the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request.

POST requests do not always fulfill those criteria. But QUERY requests do. The input to the QUERY operation is, like POST, passed as the content of the request, rather than as part of the request URI as it is with GET. Unlike POST, QUERY allows functions such as caching and automatic retries to operate, precisely because it is safe and idempotent.

Read-only in disguise

“RFC 10008 matters because it gives the web’s favorite workaround a protocol identity,” said Sanchit Vir Gogia, chief analyst at Greyhound Research. “Developers have disguised read-only questions as POST commands for two decades; QUERY carries the question in the request body while declaring it safe to retry and cache. The significance is machine-readable intent; retry engines, caches, and autonomous agents act on what a method declares, not on what documentation intends. Under automation, semantics become policy.”

“GET works while a request fits comfortably in a URI, and stops working the moment a developer needs deep filters, long identifier sets or an entire query document,” Gogia explained. “URIs also attract exposure through histories, bookmarks, and access logs, and encoding every input combination into the address quietly turns each permutation into a distinct resource.”

“POST solves the size problem and withholds the promise,” Gogia said. “Its generic semantics admit creation, mutation, and side effect, so no cache, retry engine, or gateway is entitled to assume that a given POST is repeatable or reusable.”

But while QUERY answers the long-running POST-for-search problem, the new method comes with some gotchas. As software engineer Rickvian Aldi noted in a blog post, “The cautious version is: it answers the semantics, not all the deployment work. Front-end code still needs stable query keys. Servers still need validation and cache-control headers. Infrastructure still needs to allow the new method.”

New standards take time

And that will take time; standards are often slow to be adopted. And before QUERY can be widely used, other standards such as the HTML forms standard need updating. That exercise is already in progress by groups such as the Web Hypertext Application Technology Working Group.

“Publishing an RFC as a Proposed Standard doesn’t mean the whole ecosystem supports it the next day,” said open source developer Daniele Teti in a blog post. “It’s the first rung of the IETF standards track: the specification is stable and ready for implementation, but it takes time for browsers, servers, proxies, CDNs, and client libraries to actually adopt it.” No major browsers support QUERY as yet, although, on the server side, Node.js and Go support the method.

Gogia pointed out that the authors of RFC 10008, engineers at Cloudflare, Akamai, and greenbytes, recognize this.

“The retreat route is designed into the standard itself,” Gogia said. “The Location bridge exists so that a QUERY can collapse back into a GET the moment it meets infrastructure that never learned, and the document says as much when it notes that clients can switch to GET for subsequent requests to simplify processing. Read that way, the equivalent resource is less a philosophical concession than a contingency plan, and it is the feature most likely to carry the method through its awkward years.”

Oracle on Tuesday expanded its AI Agent Studio for Fusion Applications with new pro-code development tools, including a CLI-based capability called AI Studio Skill, allowing developers to build agentic applications using familiar environments such as VS Code, Codex, and Claude Code.

The AI Studio Skill is the CLI that provides the Fusion-specific context and tooling that AI coding assistants need to build Fusion-native applications. It provides access to the project structure, APIs, templates, validation, packaging, and deployment workflows required for Fusion Agentic Applications, Natalia Rachelson, SVP of product for Fusion Applications at Oracle, told InfoWorld.

“Think of it as Oracle’s development harness for popular AI coding assistants. Developers can use models like Codex or Claude Code to generate code, while the AI Studio Skill connects those models to Oracle AI Agent Studio and the Fusion runtime,” Rachelson said.

Familiar tools and workflows to simplify development

The access to familiar IDEs and harnesses, according to analysts, will make it easier for developers to build and maintain agentic applications for business workflows.

“The AI Studio Skill provides developers a way to build Fusion agents like a new software function versus configuring them like application extensions,” said Scott Bickley, advisory fellow at Info-Tech Research Group.

“Enterprise developers expect source control, code review, repeatable deployments, testing or debugging, and integration into their existing toolchains. Connecting the various IDEs and code assist products will make it easier to build, validate, and maintain agentic applications using already familiar tools and processes. This ostensibly will result in agents that are easier to maintain, govern, and align with enterprise development practices,” Bickley added.

For Robert Kramer, managing partner at KramerERP, the move is likely to drive more adoption of the Studio itself: “Oracle is meeting developers where they already work and making Fusion a more attractive place to build agentic applications.”

Native runtime could aid governance in production deployments

However, the CLI and IDE integrations, for Bickley, extend beyond developer productivity into tackling the governance and execution challenges that often prevent AI prototypes from reaching production.

“One of the most painful barriers to production AI is that many prototypes are built outside the enterprise systems where identity, permissions, workflow approvals, and overall system governance are already built in,” Bickley said.

In contrast, the integrations will allow enterprises to run agentic applications from inside Oracle’s platform, leveraging existing business context, identity, approvals, and governance rather than recreating those capabilities through external orchestration layers when moving them into production, Bickley added.

That shift, the analyst further added, will prove beneficial for CIOs because it will accelerate business outcomes while operating within a trusted environment.

Governance, observability, and lifecycle management matter more to CIOs after agentic applications move into production, Kramer echoed.

Governance gains come with strategic trade-offs

The approach of building and running agentic applications natively inside Oracle Fusion, though, is not without trade-offs, analysts cautioned.

CIOs should pay close attention to vendor lock-in as more business processes become agentic, Bickley pointed out.

“In the case of Oracle Fusion, ensure the ATLAS framework provides an accurate validation layer at a low cost of overhead. Consider the levers that Oracle may avail itself of contractually or commercially in the future,” Bickley said.

“ROI should be modeled against a progressive monetization schema as AI agents operate upon a consumption-based infrastructure.  As such, ensure provisions limiting cost overlays and uplifts are agreed upon prior to locking in,” Bickley added.

These considerations, the analyst further added, are becoming increasingly relevant because most enterprise software vendors, including the likes of SAP and ServiceNow, are introducing offerings and features to become the runtime and orchestration layer for enterprise AI.

Earlier in May, SAP expanded its AI strategy with the Autonomous Enterprise vision, introducing a unified Business AI Platform, Joule Studio 2.0, and AI Agent Hub to let enterprises build, govern, and run AI agents within a managed runtime.

In June, ServiceNow expanded its AI transformation by adding new features to its Context Engine and AI Control Tower, in order to better embed governance, enterprise context, and observability into AI workflows across enterprise systems.

During the same month, Salesforce, via its Informatica acquisition, added features to tie AI agents more closely to trusted enterprise data and operational workflows.

For developers and enterprises willing to try out the new CLI-based experience, it can be accessed from within the Studio without any additional cost, Oracle said.

The company is also adding a public GitHub repository that it said will provide templates, starter projects, sample applications, reusable assets, and reference architectures to help developers build and validate agentic applications faster.

For decades, software engineering has been plagued by “productivity theater.” Every few years, the industry aligns around a new vanity metric — usually one that latches onto whatever technology happens to be in vogue at the time. For a discipline rooted in creativity and problem-solving, this is a poor way to demonstrate progress. Yet, we find ourselves in this position once again. The pattern is often the same: reach for something we can easily count, and in doing so, lose sight of what we are actually trying to achieve.

Quantity over quality: the wrong measurement, every time

I recall when I was coming up as a software engineer in the 1990s, a small number of companies took up the practice of paying their engineers by each line of code. This may have been productivity theater at its worst, leading to negative incentives, inefficient processes, and just generally bad engineering. Developers were rewarded for writing far more code than the problems they were facing required — classic “quantity over quality” — and the result was bloated, brittle codebases that were all but impossible to maintain. The goal — to create reliable software that solved real user problems — got buried under the incentive to produce.

Then in the 2000s, the rise of Agile brought us story points, an abstract way to estimate task complexity, effort, and risk relative to other work. Rather than answering “How long will this take?,” story points were meant to answer, “How big is this compared to what we’ve done before?” This approach sounds good in theory, but in practice, some development teams learned to game the system by inflating estimates, over-engineering solutions to look productive, and losing sight of whether the work they produced actually created value. Once again, the metric became the goal, and the actual goal — delivering outcomes that mattered to the business — became secondary.

Every one of these metrics failed for the same reason: they measured effort instead of value.

Quantity in the age of AI

Today, “tokenmaxxing,” a trend in which developers and teams optimize for consuming as many AI model tokens as possible, treats raw consumption as an equivalent for output. As I see it, this is the latest flawed productivity metric to make its way into the world of software engineering. Tokenmaxxing is nothing more than another vanity metric, and is just as useless as using “lines of code” or inflated “story points” as a benchmark.

Tokenmaxxing is the result of a few different behaviors, including:

• Prompt flooding: stuffing massive codebases, documentation, and context into every prompt, burning tokens on context the model doesn’t actually need.
• Agent swarms: running multiple AI agents in parallel to maximize code output, regardless of whether the work is coordinated or coherent.
• Background loops: keeping AI sessions or agents running continuously in the background, racking up token spend without clear ownership of what is being produced — or why.

Now, it is no secret that AI is reshaping how software is developed, and these behaviors are the result of that reshaping. Providing AI with codebases, running multiple agents at once, and even relying on coding assistants for help all have their uses. But when we lose control of the changes we are making and why we are making them, we find ourselves facing a new version of the same old problem: measuring engineering productivity with the wrong metrics.

A more useful question to ask isn’t, “How many tokens did we spend?” but rather, “What problem did we actually solve, and for whom?”

Spending resources without goals

Yes, AI is giving software engineers the ability to do more with less, to move quickly, and to experiment in ways that were previously out of reach. But leaning on AI to perform productivity, rather than deliver it, is a trap that will cost us in code quality, team capability, and business credibility.

As a CTO, I am all for experimenting with AI. I want to use it to make our programs better, stronger, and future-proof. What I don’t want is for it to drive us toward excess while leaving us with little to show for it.

The test I keep coming back to is simple: does this AI-generated output help us ship something that matters? Does it reduce friction for a user, close a gap in a workflow, or improve reliability for a customer? If the answer isn’t clear, then we are spending resources — both human and computational — without a defined goal. And that is not engineering. That is activity.

Spec-driven development: where value gets defined

It is time to adopt newer approaches like spec-driven development, a method where engineers write detailed specifications first and AI generates code against them. Rather than relying on prompt flooding and agent swarms and hoping AI produces the best result, we need to shift toward defining requirements, reviewing AI-generated output, and orchestrating systems with intent.

But spec-driven development is more than a methodology. It is the place where engineering intent and business value get defined together. The spec is where you answer, “Why does this matter, and what problem are we solving?” before a single token gets spent.

Software engineers have long taken pride in writing elegant code, and I would hate to see AI cheapen that pride rather than elevate it. In an AI-first world, the craft shouldn’t disappear; it should simply move upstream. The spec is where elegance lives now, and it deserves the same attention to detail we once reserved for the code itself.

At its core, software engineering is about defining, analyzing, and resolving technical challenges. If we are willingly giving all of that up to AI, we will lose the integrity of our discipline and the ability to prove our value. Using the maximum number of tokens to produce code isn’t impressive. Using a well-crafted, intentional prompt to solve a specific problem? That’s the work worth celebrating.

Stop performing productivity and start delivering it

We are at an inflection point. Many organizations are defaulting to activity-based metrics, measuring how much AI is being used rather than whether it is improving delivery, product quality, or business outcomes.

The question worth asking is not, “How much AI did we use this sprint?” It is “What value did we deliver for our users, our team, or our business?” Was it the ability to resolve a critical bug more quickly? Reduced cycle time on a high-value feature? A customer workflow that now takes minutes instead of hours? Those are outcomes. Those are the things worth measuring.

AI can help us deliver meaningful outcomes faster, but only if we use it with the same rigor and intent we expect from every other engineering or business decision. Don’t let it become another form of productivity theater. The most successful engineering organizations in the age of AI won’t be the ones that consumed the most tokens, they’ll be the organizations that never lost sight of why they were building in the first place.

—

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.

Visual Studio Code 1.128, the most recent edition of Microsoft’s code editor, adds support for multi-chat agent sessions using Anthropic Claude agents.

Introduced July 8, VS Code 1.28 can be downloaded for Windows, Linux, or Mac from code.visualstudio.com.

With VS Code 1.28, multi-chat agent sessions now support using Anthropic Claude agents. With multiple chats, a session can contain related chats, allowing users to compare approaches, branch from an earlier turn, and run work in parallel. Users can add chats, fork a chat from an existing turn, switch between peer chats, and send turns concurrently. Each chat keeps its own history, title, and model selection, and restores with the parent session after restart, Microsoft said.

VS Code 1.28 also makes Copilot Vision generally available. With Copilot Vision, VS Code users can attach images and PDFs by pasting them into chat, dragging and dropping them, or using the context menu. Images also may be read by the agent via a tool call, Microsoft said.

Also in VS Code 1.28:

• Quick chats allow users to ask a question in the Agents window without opening a workspace first.
• VS Code can contribute OS-level keyboard shortcuts that take effect even if VS Code is not in focus. Users can add systemWide to a keybinding definition in keybindings.json to make it OS-level.
• Developers can configure a location for browser tabs to open via a new setting, workbench.browser.newTabPlacement. The setting provides three options: to open browser tabs in the active editor group, in a dedicated group to the side, or in a dedicated auxiliary window.
• VS Code can contribute OS-level keyboard shortcuts. These shortcuts take effect even if VS Code is not in focus.
• Administrators can configure where GitHub Copilot sends OpenTelemetry (OTel) data, allowing organizations to enforce telemetry flows to an approved collector without each developer setting OTEL_* environment variables. The managed configuration applies to both the Copilot Chat extension and the agent host process.

OpenClaw’s announcement that it has become a nonprofit foundation is generating IT excitement because of the potential for governance and development consistency that the popular platform has thus far lacked. Still, some worry about the risks created by the move. 

“Our ambition is for OpenClaw to be the Switzerland of AI. Neutral ground where every model and every lab can plug into the technology and collaborate on standards in the era of agents,” OpenClaw said in a post. “That work is already underway in Foundation-convened councils on agent identity, agent profiles, evals, and enterprise deployment.”

The statement, co-authored by OpenClaw creator Peter Steinberger, pointed out, “the great open source projects of our time — Linux, Apache, Mozilla — endure because a neutral steward stands behind them. That is the role we are taking on to keep OpenClaw MIT licensed, open, and independent so that everyone building on it can trust it will be here for the long term.”

But it reassured users that the original OpenClaw leadership is still in charge.

“Peter built this thing and Peter keeps making the calls, especially the technical ones. Since joining OpenAI earlier this year, he has continued to steward OpenClaw as an open and independent project, and OpenAI has made a commitment to keep it that way,” the post said. “The foundation is here to serve: good governance, stable funding, and paying the people who keep the claws alive.”

However, some analysts and consultants were skeptical about how much true independence Steinberger would have, given his salaried role with OpenAI. 

Neutrality claim in question

“The Switzerland of AI neutrality claim collapses under its own announcement,” said Noah Kenney, principal consultant at Digital 520. “OpenAI runs a team [at OpenAI] called Claw Labs that Peter leads and OpenAI is a major donor to OpenClaw. The ‘neutral steward’s’ chief technical decision maker is employed by one of the competing labs it is supposed to be neutral with.” To OpenAI, he said, OpenClaw is closer to a tax-exempt nonprofit subsidiary than it is to a neutral ‘Switzerland of AI.’

He pointed out that, in addition, Microsoft is shipping the enterprise version of OpenClaw, and Nvidia is shipping the hardware bundle. “This is being called the Switzerland of AI, but Switzerland does not have its central bank run by France,” he observed.

Kenney said that what the new OpenClaw has actually built is “a shared dependency that several competitors fund, staff, and steer, wrapped in a nonprofit structure. Enterprise IT should understand that structure, because treating OpenClaw as neutral is a mistake,” adding that CIOs need to look at this development devoid of the emotional component. 

“There is a strategic irony here that CIOs should sit with,” Kenney said. “If OpenClaw succeeds at becoming the universal agent substrate, then every model plugs into the same identity layer, the same profiles, and the same deployment plumbing. The thing every vendor is racing to own becomes a commodity that nobody owns.” He pointed out that, in the short term, that is genuinely good news for buyers because it means less lock-in and more portability.

“But,” he said, “when the connective tissue is free and natural, the only labs that benefit are the ones with the best models and the deepest distribution. Commoditize the layer below you and you compete on the layer where you are already strongest. The foundation is not a charity. It is the biggest players agreeing to stop fighting over the plumbing so they can fight over the water, and the enterprise is the one paying the water bill either way.”

Good news, bad news

Jason Andersen, principal analyst at Moor Insights & Strategy, liked the potential consistency that could emerge from the structural change, given the complexity of agent development today. 

“We are seeing a lot of OpenClaw variants hit the market, such as those from Nvidia as well as competing products from cloud and SaaS vendors. A common base helps solidify the common parts,” Andersen noted. “That said, a common challenge is the sustainability of these open source foundations over time. In addition to releasing code, these foundations need funding to evolve and grow. And that funding needs to come from continued momentum to incentivize existing members to increase investment and recruit new members to join.”

Andersen stressed that IT buyers need to keep an eye on the roadmap for any OpenClaw variant they choose to deploy, “as that will directly impact the foundation, and the momentum of the foundation and common base. If the common base loses momentum, it can lead to forks, or just a loss of innovation. When that happens, members tend to back away, which puts customers in limbo.”

But not everyone sees the promised structure as entirely good for IT.

Ishraq Khan, CEO at coding productivity tool vendor Kodezi, said, “most CIOs do not want to bet their future entirely on a single model vendor. They want Claude for some workloads, GPT for others, open models for sensitive environments, and potentially internally fine-tuned systems for specific use cases. The problem is that every vendor currently brings its own identity system, tool interfaces, permissions model, and operational assumptions. That fragmentation does not scale.”

He said, “the risk if standards fail is straightforward: every vendor builds its own closed ecosystem, enterprises become locked into individual stacks, and security becomes dramatically harder. The opportunity if OpenClaw succeeds is equally significant: enterprises get portable agents, common identity standards, interoperable tooling, and a healthier competitive market around models rather than ecosystems.”

Will it remain a nonprofit?

However, said Justin Greis, CEO of consulting firm Acceligence, one of the key details that IT executives will want to keep in mind is that OpenAI also began as a nonprofit, but it was quickly seen as not adhering to nonprofit objectives. 

“OpenAI’s transition from a nonprofit research organization into a more complex structure highlighted the challenge of maintaining mission alignment while scaling technology, capital, partnerships, and commercial operations,” Greis said. “OpenClaw has the opportunity to address some of those governance questions earlier by establishing clear principles around neutrality, transparency, and decision-making before the ecosystem becomes even larger and more valuable.”

He noted, “we have seen this pattern before with technologies like Linux and Kubernetes. The strongest open ecosystems succeeded because they created trusted foundations that enterprises could build upon. The technology was important, but the governance model that underpinned it was equally critical.”

Risks are ‘squarely in IT’s lap’

Consultant Brian Levine, executive director of FormerGov, echoed Greis’ concerns. 

“CIOs shouldn’t assume that this nonprofit will always be a nonprofit, or confuse being a nonprofit with actually being neutral or unbiased,” he said. “The risks are squarely in IT’s lap: autonomous agents ‘with their own identity’ acting on a user’s behalf blow straight through traditional IAM assumptions. Issues, such as agent identity, auditability, secret handling. Identity boundaries have not yet been reliably solved. Until they are, enterprises should treat OpenClaw agents like privileged service accounts, not like a browser plugin.”

Independent cybersecurity and risk advisor Steven Eric Fisher pointed to another IT exposure that might come from this OpenClaw transition: Cost.

“OpenClaw currently has a very high token burn rate in usage, which presents a significant cost consideration for large-scale enterprise adoption,” he said. “The skills marketplace introduces a new supply chain threat that enterprises will need to manage. Threat management, and specifically handling external marketplace elements, can be highly challenging for open-source operations. Ultimately, at scale, enterprise adoption could become a difficult balancing act between managing high operational costs and securing an expanded security surface.”

This article originally appeared on Computerworld.

Microsoft has released TypeScript 7.0, a native port of the company’s strongly typed version of the JavaScript language based on the Go programming language.

With this new codebase, TypeScript 7.0 brings native code speed, shared memory multithreading, and a number of new optimizations that typically yield speedups between 8x and 12x on full builds, Microsoft said in a July 8 announcement. This port of TypeScript to native code was done as faithfully as possible, writing new code while maintaining the structure and logic of the original codebase to keep results consistent and compatible between the two compilers, according to Microsoft. 

TypeScript 7.0 is available via npm:

npm install -D typescript

To help with the TypeScript 6.0 to TypeScript 7.0 transition process, Microsoft has published a new compatibility package, @typescript/typescript6. This package provides an executable named tsc6, so that if needed, a developer can install TypeScript 7.0 (which ships its own tsc binary) side-by-side with TypeScript 6.0 without naming conflicts. The new package also re-exports the TypeScript 6.0 API, so that a developer can use tsc for TypeScript 7, while other tooling can continue to rely on TypeScript 6.0.

TypeScript 7.0 is a major milestone in the TypeScript project, Microsoft said. This port has been the primary focus for Microsoft’s team for more than a year. With TypeScript 7.0 now out, the team will return to new feature work, ergonomic improvements, more performance wins, and implementing a new API for the broader ecosystem. Microsoft expects a fairly similar timeline to releases prior to TypeScript 7.0, with new versions published every three to four months.

TypeScript 7.0 was announced as a release candidate on June 18.

GitHub Copilot has introduced an interactive canvas that makes it easier to follow, review, and steer the actions of the upgrade agent as it modernizes .NET applications.

The GitHub Copilot upgrade agent assesses the application, generates a structured upgrade plan, creates implementation tasks, and executes the work, according to a July 9 bulletin from Microsoft. Now developers can follow that workflow in the GitHub Copilot app through an interactive upgrade canvas. The upgrade canvas provides a live view of the modernization workflow as it unfolds, Microsoft said.

This agent upgrade agent starts by assessing the .NET application and identifying what needs to change:

• What version of .NET is this application targeting?
• Which NuGet packages need to be updated?
• Are there breaking API changes?
• Which projects can be upgraded independently?
• What should happen first?

From this point, the agent generates a structured upgrade plan and breaks the work into actionable implementation tasks. While the GitHub Copilot app provides the interactive upgrade canvas, GitHub Copilot upgrade also is available in the following tools:

• Visual Studio – Built directly into Visual Studio. Right-click a solution or project in Solution Explorer and select Modernize to start a .NET upgrade.
• Visual Studio Code – Install the GitHub Copilot upgrade extension, select the Upgrade agent from the agent picker dropdown menu, and prompt the agent to modernize your .NET application.
• GitHub Copilot CLI – Install the GitHub Copilot upgrade plugin to assess, plan, and execute .NET upgrades directly from the terminal.

Developers can get started with GitHub Copilot and the GitHub Copilot upgrade agent by visiting the GitHub Copilot upgrade marketplace.

Microsoft has been pushing hard to make Visual Studio Code a major way to consume its AI services, mostly in the form of GitHub Copilot. GitHub Copilot’s deep integration with VS Code brings many conveniences — inline autocomplete, for instance — but it’s frustrating for those, like me, who would rather use another model provider, or even a locally hosted LLM, for those functions.

Visual Studio Code 1.122 introduced a new feature, “Use BYOK [Bring Your Own Key] without a GitHub sign-in,” that allows you to “use chat, tools, and MCP servers in air-gapped or restricted environments where GitHub sign-in isn’t possible.” More importantly, it “enables fully offline workflows with local models like Ollama.”

In other words, you can now use locally hosted LLMs for chat, tools, and Model Context Protocol servers inside Visual Studio Code. The one thing you still can’t do is use a local LLM for inline and next-edit suggestions — at least, not without additional tooling.

Choosing a model for BYOK mode

If you want to use a local LLM with VS Code’s bring-your-own-model system, the first thing you need is a way to host the model. VS Code lacks a model-hosting mechanism of its own, although it’s conceivable that a VS Code extension may offer something like that in the future. That said, hosting models is complicated enough that a dedicated app is really needed for the job.

One easy way to host models is via a product like LM Studio, a convenient GUI for standing up, serving, and managing LLMs on one’s own hardware. The model host does not have to be the same system you run VS Code on, either. It can be on a server box you control, or on a cloud instance.

The choice of model is also important. Many models are powerful but won’t run well on commodity hardware because they’re simply too big. A good rule of thumb is to choose a model that fits into existing VRAM, along with the memory needed for a sizable token context (the more, the better). Also, the model should be suited to coding and development work. Some models in this vein that fit comfortably into 8GB VRAM include:

• Gemma4 (effective 2 billion parameters version)
• Qwen3.5 9B
• Codestral 22B v.0.1 (proprietary license)

Setting up BYOK mode in VS Code

Once you have a model up and running, you can integrate it with Visual Studio Code. If you’ve disabled VS Code’s AI features, you will need to turn them on. Make sure the setting chat.disableAIFeatures is turned off. You can find it in Settings | Chat | Miscellaneous.

Third-party language models are managed through Visual Studio Code’s language model list. Press Ctrl-Shift-P and type Manage Language Models to open the list of existing language models.

First you will see a list of the built-in models, which are all externally hosted. To add a new model, select Add Models at the top right and select Custom Endpoint.

You’ll then get a series of prompts:

• Group Name: This is “Custom Endpoint” by default, but you can choose any name you want. The name is strictly for organizing the model list and doesn’t affect things like model recognition or connectivity.
• API Key: If you’ve configured LM Studio to use an API key for serving models, provide it here. If you’re hosting the model locally and you haven’t explicitly set up API keys, you can leave this blank.
• API Type: The options here are Chat Completions, Responses, and Messages. Most of the time you’ll want to use Responses, as it’s the most general-purpose option of the three.

Once you finish providing those answers, you’ll be dropped into a modal editor for a JSON file that holds the details about the endpoint you’re configuring.

You’ll need to provide a few more details by typing them into the labeled fields:

• id: A text field that uniquely identifies this particular entry. The choice of ID is pretty much arbitrary; if you’re using only a single model, the ID could be the model name.
• name: The name of the model that is used to identify it on the model server. In LM Studio, you can get this name by clicking on My Models in the main interface, then selecting the three-dot icon for the model in question and clicking Copy Default Identifier. For Qwen 2.5, for instance, name might be something like qwen2.5-coder-7b-instruct.
• url: The URL to the server’s endpoint. On LM Studio, this defaults to something like http://127.0.0.1:1234/v1. The /v1 at the end is important because that endpoint is used for autodiscovery of models and their capabilities.

The other fields generally don’t need editing. Most models have tool calling functionality. If you know for a fact that the model you’re using doesn’t have vision support, then set vision to false.

Once you have these fields filled in, you can close the modal editor to save the changes. If you reload the Manage Language Models page, you’ll now see your new endpoint:

You should now be able to launch the chat window and use the defined model for conversation and utilities:

One current, and major, limitation of Visual Studio Code’s BYOK functionality is that it only works for chat and utility tasks. It doesn’t allow you to use a local model for inline suggestions or code completions. The only way to take advantage of local models for expanded functionality with VS Code is to use a third-party tool like Continue.

It isn’t clear if Microsoft will eventually lift this restriction. GitHub Copilot integration in VS Code is a large part of how Copilot as a service reaches its target audience. For the time being, you can certainly use third-party and local models for a significant part of your AI-assisted development work in VS Code, and you can close the functionality gap with additional tooling.

Unless you’ve been living under an old woodpile in your backyard, you have certainly seen how agentic coding is rocking the software development world. Things are happening fast and furious, and keeping up is practically a full-time job. 

The latest area that is catching the attention of developers is how agentic coding is affecting the open source community. The open source movement has been defending the rights of folks to use, change, and contribute to software for many years. And of course, agentic coding is starting to become part of that process.

On the one hand, maintainers of open source projects rightfully are frustrated as they become overwhelmed with pull requests of dubious quality and usefulness being submitted by coding agents. On the other hand, as David Heinemeier Hansson notes, maintainers are starting to get a little snooty about accepting AI-written code, viewing it as somehow not worthy of being included. Some organizations have explicitly banned AI-generated submissions.

I get that they don’t want AI slop overwhelming their input queues. But I think it is a huge mistake to ban AI-written code outright.

Whose code?

Before I dig deeper into that notion, it’s important to look at another issue that arises from all of this: Who actually owns the code that AI writes? 

Copyright requires that a human produce the thing being copyrighted. If you prompt Claude Code with “Write me a CMS system” and then Claude writes you a CMS system that you check into a public GitHub repository unchanged, it’s not quite clear if that code is protected by copyright. However, if you prompt Claude Code with a specification and guidelines and then you work with Claude to refine the initial result, reviewing the code and making changes as part of an iterative process, then it could be argued that a human did produce that code. But it is not at all clear-cut legally. (Please note that I am not a lawyer.)

The current thinking is that the result of accepting verbatim the output of a simple prompt is not copyrightable, and that no one actually owns the code — an interesting notion in and of itself. 

But then the ethical question comes into play. If I find a bug in an open source project, I ask GitHub Copilot to fix it, and Copilot writes a clever and effective fix, then who cares who owns the code? Should a maintainer of the project reject such a pull request just because it was AI-generated? That seems silly to me, yet it is happening today. 

Our code

There is, too, the issue of license compliance for AI-generated code. As a general rule, LLMs generate code rather than copying it. They don’t copy and paste code directly from repositories. However, there have been cases where AI-produced code has resembled open source code so closely that the claim could be made that it is a copy. If this happens with GPL code, it could be a violation of the license to use it without the receiving code base being “infected.” Open source maintainers naturally should be concerned about this happening.

In the end, an open source maintainer should care about the quality and license compliance of submissions, not how those submissions were derived. Gatekeeping based on the source of code doesn’t seem like a good path towards project success. Good code is good code, no matter where it comes from.

Agentic coding is here, and the open source community needs to realize — and embrace — that inevitability.

OpenAI has launched a program with cybersecurity firm Trail of Bits to use AI to find and fix vulnerabilities in widely used open-source software, as enterprises face growing risks from flaws buried deep in their software supply chains.

The initiative, called Patch the Planet, uses AI-assisted vulnerability research alongside human review to help turn security findings into tested fixes that can be disclosed through existing project channels.

Initial participants include Python, Go, cURL, Sigstore, NATS Server, aiohttp, freenginx, pyca/cryptography, and python.org. These projects support software development, networking, cryptography, and supply chain infrastructure used across a wide range of enterprise applications and services.

OpenAI said each engagement will begin with consultation with maintainers to identify where security support is most needed. Researchers will then investigate potential vulnerabilities, validate meaningful issues, develop or refine patches, support testing, and coordinate disclosure through the project’s existing channels.

Participating security researchers will use the company’s models and Codex Security to analyze code and help move fixes toward release. Trail of Bits engineers will review findings before they are sent to maintainers, a step meant to filter out false positives and duplicate reports before they add to the workload of open-source projects.

The company is also working with HackerOne and Calif to support vulnerability triage, coordinated disclosure, and additional discovery work as the program expands.

OpenAI said work under the program has already identified “hundreds of security issues and merged dozens of patches, with many more still undergoing coordinated disclosure.”

The work has also produced tools for fuzzing, historical CVE analysis, and differential testing, along with systems to filter inaccurate findings before patches are generated, OpenAI added.

The focus on open-source security follows incidents such as Log4Shell and the XZ Utils backdoor, which showed how quickly a flaw in a shared component can move through enterprise software.

Analysts said Patch the Planet changes the risk equation only if enterprises treat AI-assisted vulnerability research as an input to a broader software supply chain risk program, not as a substitute for one.

“The key shift is speed: AI-assisted research can help find, validate, patch, test, and document issues faster, while human reviewers reduce false positives before maintainers are burdened,” said Biswajeet Mahapatra, principal analyst at Forrester. “But the dependency on scarce expertise does not go away; it moves to triage, exploitability judgment, patch safety, disclosure timing, and production rollout.”

Guardrails before deployment

CISOs should put governance controls in place before using AI-assisted vulnerability research in enterprise security pipelines, to ensure unverified findings do not overwhelm engineering teams, said Devashri Datta, an open-source cybersecurity architect.

“CISOs should demand a Safety Relevance Layer in their risk modeling, a structured framework that requires every AI-generated finding to pass automated verification, including dynamic proof-of-concept validation and strong false-positive filtering, before it reaches a human analyst,” Datta said.

Those controls should also cover disclosure, particularly when AI tools identify flaws in third-party open-source components that the enterprise does not control, Datta said. Organizations need predefined escalation paths, notification timelines, and role assignments that take effect once a confirmed issue is found in an external dependency.

“Ad hoc disclosure in an AI-accelerated environment isn’t just a process gap; it’s a liability,” Datta said. “Trusting AI in the production pipeline requires verifiable auditability: organizations must be able to trace why the AI flagged a line of code, how it validated the exploit, and how it determined that the patch would not break downstream production systems.”

Continuous exposure reduction

AI-assisted vulnerability research could force enterprises to move away from periodic patching cycles and toward more continuous risk assessment, analysts said. If variant analysis and differential testing can be compressed from weeks to days, security teams may need faster ways to decide which findings matter most in their own environments.

That shift also means enterprises can no longer rely only on generic CVSS scores to prioritize remediation, Datta said. Findings will need to be assessed against the affected system, its business role, runtime exposure and the likelihood that a flaw can be exploited.

“We have to move toward context-aware, safety-critical prioritization,” Datta said. “Enterprise SBOM and VEX programs must evolve from passive compliance spreadsheets into live, machine-readable data feeds. For AI-assisted pipelines specifically, that means extending the VEX model to cover AI-introduced risk surfaces.”

Mahapatra said vulnerability management programs will also need to become more closely tied to software ownership, supplier response, and business impact.

“Security teams should move from periodic vulnerability handling to continuous exposure reduction,” Mahapatra said.

That means SBOMs should be treated as live inventories tied to runtime exposure and supplier response, rather than static compliance documents. Patch decisions should also account for asset criticality, exploitability, compensating controls, and business impact.

The article originally appeared on CSO.