In hardware, when you ship something broken, the consequences are severe and often irreversible. That’s the world I worked in for years, in verification roles at Mellanox and later at Alibaba. The stakes forced the industry to build a rigorous verification culture. You proved designs worked before they left the building.

In software, verification disciplines look like CI/CD pipelines, static analysis, canary deployments, and observability. But those systems were built around code written at human speed, with human comprehension baked into the process. AI code generation has broken that assumption. The writing process can no longer be trusted to carry institutional knowledge and judgment into the codebase. The industry is being pushed toward the kind of rigorous verification culture that hardware engineers have practiced for decades.

Enterprises are generating code faster than at any point in history. Google recently disclosed that 75% of the company’s new code is now AI-generated. Meta has set internal targets requiring most of its engineers to generate the majority of their committed code with AI tools by mid-2026. The velocity gains are significant. But a growing body of evidence suggests the industry is accumulating a new form of technical debt, one that is less visible than the traditional kind and harder to unwind. It’s also preventable, and the organizations that get ahead of it will have a meaningful advantage over those that don’t.

Understand what makes this debt different

The standard narrative frames this as AI writing bad code. That’s not quite right. The more precise problem is cognitive debt: the loss of understanding of how and why software was built the way it was.

When a human writes code, something else happens alongside the typing. They simulate edge cases, reason through dependencies, and make judgment calls grounded in organizational context, including the business requirements behind a feature, the best practices the team has established, and the reasoning behind past architectural choices. That cognitive loop is how institutional knowledge gets built. When AI writes the code, you can get output that is syntactically correct, passes CI, ships cleanly, and leaves no one holding the mental model. The code works until something changes or breaks, and then the team is excavating a black box.

This is distinct from traditional technical debt, which is messy code. Cognitive debt is invisible code that functions but that nobody truly owns. And it compounds faster, because the same velocity that makes AI generation attractive is what prevents anyone from stopping to build the understanding that maintainability requires.

GitClear’s analysis of 211 million changed lines of code across major repositories found that during 2024, duplicate code blocks of five or more lines increased eightfold, while refactoring dropped from 25% to under 10% of all code changes. Refactoring is the slow, unglamorous work that keeps codebases healthy, and developers are doing far less of it. Google’s 2024 DORA report found that a 25% increase in AI adoption correlates with a 7.2% decrease in delivery stability. DORA analysts note that the root cause isn’t flawed code per se; AI inflates batch sizes, and larger changesets have always been riskier to ship.

These findings aren’t indictments of AI-assisted development. They’re diagnostics, and they point toward a specific set of fixes.

Close the context gap first

In a survey of 609 developers we conducted last year, 65% said AI misses relevant context during critical tasks like refactoring, writing tests, or reviewing code. Context is the primary driver of AI code quality, and it’s where most enterprise organizations are underinvesting.

When an AI tool generates code without access to your organization’s architectural decisions, historical pull requests, security policies, or existing module patterns, you get solutions that are locally correct but globally incoherent. Closing that gap requires context engineering: ensuring the tools and agents you use have access, at the right moment, to the right organizational knowledge, and the judgment to determine what is actually relevant for a given task. A retrieval system that surfaces too much irrelevant context can degrade output quality as readily as one that surfaces too little. The specific tooling matters less than the discipline. Context infrastructure needs to be actively maintained, not indexed once and forgotten.

Build this infrastructure before you scale AI generation. Retrofitting is significantly harder. Treat it the way you treat your CI pipeline, as a prerequisite for safe production deployment.

Consider what happens when a team has built this context infrastructure well. Their code review tooling knows about a deprecated internal API, because that deprecation decision lives in months of past pull request discussions that have been indexed and surfaced. When generated code references the old API, the review flags it. Without that context layer, the same mistake gets waved through every time. That’s the kind of institutional knowledge that evaporates when humans stop writing every line of code, and that you have to actively work to preserve.

Build a verification layer that matches your generation velocity

Almost all of the investment in AI-assisted development has gone into generation. Very little has gone into verification. That imbalance is where the tech debt accumulates.

I think of these as the blue team and the red team. The blue team covers code generation, autocomplete, and agentic coding. It’s getting the headlines, the budgets, and the product launches. The red team covers integrity checks, behavior coverage, and alignment with organizational standards. In most organizations, it’s an afterthought. A CI pipeline catches obvious failures. A code review might happen, but reviewers are overwhelmed by the volume of AI-generated output and cannot meaningfully evaluate all of it. The result is code with a veneer of having been reviewed without anyone having actually understood it.

The Crowdstrike outage of 2024 is worth keeping in mind here. AI didn’t generate the problematic code, but the incident illustrated what happens when a single software error propagates through production systems without sufficient verification. That exposure multiplies when code is being generated faster than humans can understand it.

A real verification layer means automated analysis that evaluates whether generated code aligns with your organization’s best practices, architectural standards, and compliance requirements. It means test coverage that reflects intended behavior, not only the happy path the AI chose to generate tests for. And it means traceability: a connection between the requirement and the implementation, so that six months from now, someone can understand what the code does and why it exists.

The numbers support investment here. In the same developer survey, teams that integrated AI into their code review workflow saw quality improvements in 81% of cases, compared to 55% for comparable teams without it. 

Make ownership non-negotiable

Every piece of AI-generated code in production needs an accountable human who understands it well enough to maintain it. This is harder than it sounds, and it’s where most organizations are falling short.

The same velocity that makes AI generation attractive also creates pressure to skip the slow work of genuine comprehension. A developer reviews a 500-line pull request that an AI generated in three minutes and faces a real choice: spend two hours actually understanding it, or approve it because it looks right, passes the test, and “LGTM” (looks good to me). 

Real ownership means slowing down generation velocity enough to allow for meaningful review, and being explicit with your team that this is the right trade-off. When that doesn’t happen, you’ve started building your next legacy system.

What to do this quarter

The good news is that none of this requires a multi-year transformation. The structural problems are real, but they have concrete solutions, and engineering leaders can make meaningful progress on all three fronts without waiting for the next budget cycle.

• Audit your context infrastructure. If your AI tools are generating code without access to your organization’s architectural decisions, deprecated APIs, and security policies, fix that before expanding generation velocity further. The quality of context determines the quality of output.
• Invest in the red team. Establish an automated code quality and governance layer that evaluates generated code against your specific organizational standards, beyond functional correctness. This is a distinct investment from your code generation tooling and needs to be treated as such.
• Establish ownership explicitly. Every AI-generated feature in production should have a human owner who genuinely understands it. Make that a formal requirement.

The organizations that get this right will find that AI generation becomes far more reliable once it has a verification layer underneath it. The ones that don’t will keep shipping faster while understanding their systems less, until the accumulated debt forces a reckoning. That’s a solvable problem. The question is whether you solve it now or later.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

The problem with software development today may no longer be writing code. With AI coding assistants generating code faster than ever, the bigger challenge is reviewing, testing, and safely releasing it.

AWS is betting that software teams need help with that part of the process, adding release management features to its DevOps Agent.

The new features, currently in preview, automatically assess code changes against organizational standards, identify potential release risks, and generate tests tailored to individual changes before they reach production.

The release readiness feature, in particular, runs the code in an AWS-managed isolated environment, executing lightweight user journey tests to verify the software builds, runs, and passes basic functional checks before the change enters the pipeline, the company wrote in a blog post.

The findings of these tests can be viewed through the DevOps Agent console, as comments on pull requests in GitHub or GitLab, or can be invoked directly through IDEs via Kiro or the Claude Code plugin, it added.

Targeting AI-era software delivery bottlenecks

Running code in isolated environments and delivering the results directly through developer tools helps address two longstanding challenges in software delivery, said Pareekh Jain, principal analyst at Pareekh Consulting.

It enables teams to validate how code changes behave before deployment, catching issues that static analysis may overlook, while reducing context switching by embedding findings into existing workflows, in turn accelerating fixes, Jain said.

The analyst pointed out that the release readiness capability addresses a key bottleneck in AI-driven software development: “While AI coding agents can generate code quickly, reviews, compliance checks, dependency validation, and release approvals still slow deployment.”

“By automatically checking code changes against internal standards, security policies, and dependency impacts, AWS helps developers, DevOps teams, and SREs identify issues earlier, reduce manual review effort, and improve release confidence,” Jain added.

These gains in productivity for developers could also translate into tangible business benefits for CIOs, according to Jain.

“Release readiness as a feature could help enterprises capture more value from AI-generated code while reducing operational overhead by eliminating the need for additional QA and DevOps resources. This means that they can accelerate software delivery without sacrificing reliability,” the analyst noted.

Autonomous testing before merging code

While release readiness reviews focus on assessing whether a code change is safe to move through the delivery pipeline, AWS is also adding a separate feature aimed at validating how those changes behave in production-like environments.

Named autonomous release testing, the new capability generates and runs change-specific test plans for web and API-based applications in customer-provisioned, production-like environments before the change actually merges, the company wrote in the blog post.

For Jain, autonomous release testing is “even more” important for developers and SREs as it “automates one of the most time-consuming parts of software delivery.”

“Developers spend less time creating and maintaining tests, while SREs benefit from fewer rollbacks and improved system reliability,” Jain said.

These benefits stem from the feature’s ability to automatically generate tests tailored to individual code changes, covering functional correctness, behavioral regressions, and integration scenarios that might otherwise require significant manual effort, Jain added.

However, AWS is not alone in trying to bring AI deeper into the software delivery lifecycle.

Microsoft-owned GitHub has been expanding Copilot’s code review capabilities, allowing the service to automatically review pull requests, suggest fixes, and provide feedback directly within developer workflows.

Google, meanwhile, has been steadily broadening the scope of Gemini Code Assist beyond code generation to support software development tasks such as code review and developer assistance.

AWS’s differentiation, though, according to Jain, lies in tying those capabilities to release management and operational workflows that span development and production environments.

Availability and pricing

For development teams interested in evaluating DevOps Agent’s new capabilities, AWS said both features are available in preview at no additional cost in the US East (N. Virginia) region.

AWS DevOps Agent, billed per agent-second, is included in the AWS Free Tier for new customers.

Additionally, new AWS DevOps Agent customers receive a 2-month free trial starting with their first operational task after general availability.

Each trial month includes up to 10 agent spaces, 20 hours of investigations (incident response), 15 hours of evaluations (incident prevention), and 20 hours of on-demand SRE tasks (chat), the company said.

Once those limits are exhausted, customers are charged based on consumption, with investigations, evaluations, and on-demand SRE tasks each priced at $0.0083 per agent-second, AWS added.

A prerequisite for using the new release management features includes connecting at least one GitHub or GitLab repository to an AWS DevOps Agent Space.

Z.ai has released GLM-5.2, an MIT-licensed open-source AI model designed for long-running software engineering tasks, as the Chinese company seeks to challenge proprietary coding models on cost and performance.

The company said GLM-5.2 ranked just behind Anthropic’s Claude Opus 4.8 on FrontierSWE, a long-horizon coding benchmark, trailing it by 1%. Z.ai said the model also edged out OpenAI’s GPT-5.5 by 1%.

Z.ai said GLM-5.2 supports a one million-token context window with up to 131,072 output tokens, positioning it for agentic coding workflows that require reasoning across large codebases.

The company is also making an efficiency argument. It said GLM-5.2 uses a technique called IndexShare, which reduces per-token compute by 2.9 times at a one million-token context length. It also said changes to the model’s multi-token prediction layer increased the acceptance length for speculative decoding by up to 20%.

The changes are aimed at a practical problem for developers: long-context coding agents can be expensive to run when they are asked to work across large repositories.

Enterprise appeal

GLM-5.2’s clearest appeal is that it pairs stronger coding capabilities with the cost advantages of an open-source model. But capability alone will not be enough to make it a credible alternative.

“Western enterprises will want independent benchmark validation, successful deployments at global enterprises, strong security and governance controls, and long-term support commitments,” said Pareekh Jain, CEO of Pareekh Consulting.

Jain said the fastest route to enterprise credibility would be hosting by a major cloud provider like AWS. That would allow customers to use the model under standard enterprise terms, with service-level commitments and compliance certifications.

Tulika Sheel, senior VP at Kadence International, said GLM-5.2 would also need to prove it can operate as a stable enterprise product.

“Demonstrated success in real-world deployments and transparent governance will be just as important as benchmark scores,” Sheel said.

The performance and cost claims will also need to hold up against established models.

“Enterprise leaders generally consider two major factors when evaluating new models,” said Lian Jye Su, chief analyst at Omdia. “First, they look at overall performance against competitors, where GLM-5.2 performs well in long-horizon agentic coding and software engineering. Second, they look at the cost of adoption. As an open-source model, GLM-5.2 has clear cost advantages.”

Su said the model could appeal to engineering teams under pressure to control AI costs. It may also attract open-source advocates and companies with significant operations in Asia-Pacific.

But the claims still need wider validation, particularly around hallucination control and coherence during extended tasks. These are critical issues for enterprises considering AI coding agents, which may need to work across large codebases and multi-step software engineering workflows.

Jain said the one million-token context window could be useful for large codebase analysis. It could also help with legacy modernization projects and complex engineering documentation.

He said long-context capability may also help with audit logs or legal contracts, where splitting material into smaller chunks can create errors across document boundaries. But for everyday coding tasks, effective retrieval systems may matter more than very large context windows, making some of the benefits more limited in practice.

Governance risks

The governance question depends largely on where the model runs.

Sheel said enterprises should evaluate GLM-5.2 as they would any strategic technology partner, rather than as a standalone model. That means looking at where data is stored and whether the model can be used in environments customers control.

That deployment choice is central to the risk calculation, according to Jain. Because GLM-5.2 is available under an MIT license, companies can download the weights and run them on their own infrastructure, reducing the need to send sensitive data to Z.ai.

“The risk flips completely if you use Z.ai’s hosted API instead,” Jain said.

He said Chinese national security rules could require domestic companies to cooperate with government requests, making hosted use difficult for regulated industries or workloads involving sensitive data.

Su said the issue is not limited to Chinese vendors. Recent restrictions affecting access to some Anthropic models have also highlighted the risk that enterprises may have limited control over the availability of AI services from foreign providers.

“Selecting solutions from American and Chinese AI vendors does expose non-US Western enterprises to additional risk of having zero control over the availability and uptime of these models,” Su said.

When SpaceX on Tuesday officially announced its plan to purchase AI coding startup Cursor for $60 billion in stock, as it had predicted it would do in April, it presented CIOs and developers with a little good news, a little bad news and a massive pile of uncertainty. 

The details of the proposed acquisition were virtually identical to the terms announced in April, even retaining the $10 billion consolation prize for Cursor should SpaceX back out of the deal.  

But for CIOs and developers, the increasing probability of the deal happening is forcing them to make long-term decisions without many long-term answers about what is likely to happen to Cursor, which says its coding agents are used by 64% of Fortune 500 companies.

But whether the deal is good news for Cursor’s customers, or even those of its rivals, is an open question.

Arnal Dayaratna, research VP for software development at IDC, is firmly in the good news camp. He argued that the main element holding back the company, which he estimated brings in about $2 billion in annual revenue, was access to GPUs. And, he said, SpaceX’s xAI has the ability to resolve that problem.

It’s all about the GPUs

“The implication is that Cursor can get better because it will get better access to more compute, in the form of GPUs. That was what Cursor was struggling to obtain,” Dayaratna said, adding that Cursor joins both Anthropic and Google in aligning with xAI. 

“It is bad news for Anthropic,” he said, pointing out, “[Elon] Musk figured out that GPUs were the limiters, the bottleneck. Not human talent: compute. And it’s not only about GPUs. It’s about the data centers,” as well as the mechanisms needed to support data centers, including electricity access, cooling apparatus, and zoning rights.

“Zoning rights are very difficult to obtain in the United States, and Elon has been able to leverage his political capital” to obtain those rights, Dayaratna said.

Dayaratna also commented on the highly unusual tactic of a company pre-announcing an acquisition and then announcing it “officially” two months later. The reason, he suggested, is that Musk didn’t want the acquisition to delay the SpaceX IPO, but he did want potential investors to know about it. “It gave the IPO more legs, even though it was not formally a part of the IPO. He wanted to socialize it before it happened,” he said.

Jason Andersen, principal analyst at Moor Insights & Strategy, took a far more cautious approach and predicted, “enterprise customers will be very concerned.”

Time for CIO due diligence

“xAI’s models and treatment of guardrails are very different than what Cursor has stood for,” Andersen said, and the key issue involves model choice. “Will Cursor be able to point at models other than Grok? If that is the case, it could go towards helping customers be OK with things for a while,” he said. 

But Andersen stressed the words “for a while.” He argued that Cursor rivals have gotten more sophisticated, which could give enterprise CIOs more alternatives.

“The tooling options from the classic enterprise vendors have gotten really good, and also have a number of features that enable better governance and teaming. For example, Kiro from AWS is already a worthy competitor to Cursor, but there have also been major improvements from Google and Microsoft this year,” Andersen said. “I’d venture to say that Cursor was already facing a substantial competitive challenge in the enterprise, especially as the vibe coding movement lost some steam towards agents that enable so much more developer capability.”

Andersen added, “A lot of SpaceX’s valuation is pinned to xAI and there wasn’t enough IP there for it to be long-term competitive with Anthropic or OpenAI without rapidly injecting new technology.”

Shashi Bellamkonda, principal research director at Info-Tech Research Group, said the current period of due diligence gives CIOs opportunities to ask difficult questions.

“I do believe that enterprise customers will start to ask harder questions now, especially if more of the processing starts moving through Grok or xAI infrastructure,” Bellamkonda said, but he stressed that he does see a SpaceX deal helping Cursor.

“Cursor is already carrying a lot of LLM cost and if SpaceX and xAI can give it access to more compute and a faster, improved Grok model, customers could eventually get better performance at a lower cost. Grok is getting faster and more accurate, and under SpaceX there may be more enterprise appetite for xAI than xAI had on its own,” Bellamkonda said.

Questions about data privacy

But Bellamkonda also pointed to the trust issue, specifically asking whether Cursor would be allowed to continue its zero-data-retention policy under the new ownership.

“Enterprise users with sensitive codebases will want to understand exactly where their data is going, who has access to it, and whether any prompts, code, metadata, or embeddings are touching SpaceX or xAI systems,” Bellamkonda said. “Zero data retention is only valuable if customers believe the controls still apply across the new infrastructure. If they can preserve Cursor’s privacy posture while using xAI and SpaceX compute to improve the product, this could be a very strong outcome for customers. If the data governance is unclear, enterprise buyers will hesitate.”

Justin Greis, CEO of consulting firm Acceligence, echoed Bellamkonda’s concerns.

“For many enterprise customers, Cursor’s zero-data-retention policy was not simply a security feature. It was a foundational part of the procurement and approval process,” Greis said, pointing out that security teams, legal departments, compliance officers, and executive leadership all became more comfortable adopting AI-assisted development because they believed their source code, prompts, and proprietary intellectual property would not be retained, stored, or repurposed.

“Whenever ownership changes, customers naturally revisit those assumptions,” he said. “I would expect enterprise customers to immediately seek clarity on whether existing zero-data-retention commitments remain unchanged, whether those commitments continue to be contractually enforceable, and whether any future modifications could be introduced through changes to terms of service or product strategy.”

Reassessing platform risk

Another concern is whether the move will create greater vendor concentration, and whether that will increase risk exposure. 

“Many organizations are already concerned about becoming overly dependent on a small number of AI providers. If Cursor becomes more tightly integrated into a broader SpaceX technology ecosystem, some enterprises may worry about reduced flexibility and fewer alternatives. I suspect this will be a continued question with SpaceX’s recent IPO and growth plans,” Greis said.

Additionally, he pointed out, “AI coding platforms are rapidly becoming part of critical software delivery infrastructure. When organizations standardize on these tools, they are making a long-term platform decision that influences developer productivity, software quality, security processes, and engineering workflows. A change in ownership naturally prompts a reassessment of platform risk, roadmap alignment, and long-term strategic direction.”

As well, Sanchit Vir Gogia, chief analyst at Greyhound Research, noted, “zero data retention survives only where it stays contractual, auditable, enforceable and fenced from affiliate use. The deeper point is what Cursor has become. It is no longer a developer convenience. It sits inside the act of software creation, close to the intellectual-property bloodstream of the enterprise. That is a control plane, and control planes change hands rarely and consequentially.”

Gogia added that even before an acquisition, Cursor was already weakening its data guarantee. “Even now the promise is layered. Cursor’s own disclosures show that standard Privacy Mode still permits some code data to be stored for product features, while only the stricter legacy setting retains nothing. Zero is the exception, not the default.”

Developers are caught between the joy — or pressure — of using agents to ship 10x faster today and the dread of how they will maintain that code tomorrow. The gap between “vibe” code and code that can be deployed to millions of users is vast and easy to underestimate. Closing the gap requires care, expertise, and effort, with the payoff coming later. Agents are able to complete increasingly complex programming tasks but without the quality we need. What’s missing, and how can we fill the gap?

Why agent-generated code degrades: the bloat problem

Enterprise code has to clear three bars: it must be maintainable, reliable, and secure. Out-of-the-box AI agents can miss all three. Let’s focus on the biggest and most visible maintainability issue, which is bloat: redundant validation, defensive checks that cannot fire, near-duplicate functions, dead code that nothing removes. A None check on a parameter typed as dict. A try/except around a call that never throws. Two functions, identical except for the negation in their return statement.

Bloat varies dramatically by model. Sonar’s LLM Leaderboard runs every frontier model through 4,400+ Java tasks and analyses the code generated. To complete the benchmark, GPT-5.4 High generated 1,159,000 lines of code at an 81.05% pass rate, while Claude Opus 4.7 Thinking generated only 336,000 lines of code to return a better than 82.52% pass rate. Different models generate dramatically different code to achieve similar outcomes.

Bloat is not just messy. Carnegie Mellon researchers studied 807 open-source projects that had adopted Cursor, matched against 1,380 controls, measured by SonarQube. A short-term velocity gain disappeared by month three, while static analysis warnings rose 30% and code complexity rose 41% — both persistent. The harder it became to change the codebase and the more bugs it contained, the more the velocity was dragged down. Any experienced developer will know how this goes: quality problems compound until the code feels impossible to change and the only option is the dreaded rewrite.

Three forces produce bloat once a model is in use:

1. Agents do not feel the maintenance burden. Armin Ronacher, the creator of Flask, made the point on the Pragmatic Engineer podcast in late April. Humans feel the cost of bad code over time, and as Ronacher put it, “if the pain gets too big, you as a human are incentivized to fix the cause of your pain” — so we refactor. Agents do not. They obliviously extend bad structure indefinitely. A senior engineer’s job is to say no to unnecessary abstraction. The agent has no equivalent reflex.
2. Training rewards apparent completeness. Pretraining corpora are full of explanatory material — Stack Overflow answers, tutorials, README snippets — deliberately self-contained and verbose. Post-training compounds the effect: human raters prefer outputs that look thorough, so models learn that “comprehensive” reads as better. When uncertain which edge case matters, the safe move is to handle all of them. Each guard is locally defensible. The aggregate is bloat.
3. Iterative generation has no deletion pressure. Agents add but rarely delete. Removing dead code does not make any test go green, so superseded functions accumulate alongside their replacements. SlopCodeBench, a March 2026 benchmark across 11 coding models, found rising structural complexity in 80% of trajectories and rising verbosity in 89.8%. Agents continue to patch bad code, treating every task as if it’s their last.

AC/DC: the loop that compensates

What closes the gap is a loop around each iteration of agent work. The agent does what it is good at — generating code — and our job is to wrap that with three steps the agent cannot reliably do on its own. At Sonar we call this the Agent Centric Development Cycle, or AC/DC: guide, verify, solve.

Guide

Many teams overcorrect on context. They paste the style guide, three years of architectural decisions, and the entire onboarding doc into the agent’s instructions and expect output to improve. ETH Zurich researchers tested this and found the opposite: large context files often reduced task success against no context at all, and added 20% or more to inference cost.

Keep agent-facing context short — under 200 lines is a useful heuristic — and restrict it to fundamentals that can’t easily be inferred from the code: naming conventions, architectural invariants, what has been tried and failed. However, this will only get you so far, so make sure to provide specific context for each task. If you have architectural expectations, don’t expect the agent to guess them. Software architecture tools can be used to provide additional context in the guide phase.

Task shape matters too. Break the work into steps and agree on a plan; ask the agent to provide three solutions and evaluate the impact on quality of each. There is no perfect software architecture, and you understand the trade-offs in your codebase best, so think critically about the changes before they happen. Without this, the agent will confidently pick an option, seemingly at random, and the further it goes the harder it is to “unpick.” If you want to test this, ask three instances of your preferred agent to complete a task that involves some polymorphism and watch each one confidently suggest a different solution.

Verify

The most expensive verification mistake is doing it last. Reviewing 200-line pull requests (PRs) after the agent is done is the dynamic behind the Faros/DORA figures Addy Osmani highlighted: 98% more PRs merged in high-adoption teams, review times up 91%. Verification inside the loop is different. Unit test runs, static analysis, and security scanners produce output the agent can act on. This is where AI-native tooling belongs: purpose-built for the agent to invoke, not just for humans to consult through a UI.

Human reviewers cannot keep up. When agents merge twice as many PRs per week and each one takes nearly twice as long to review, doubling the review staff still leaves you behind. Automated verification is the only response that scales. Fast feedback has always been a fundamental tenet of good software engineering. Feeding it directly back to the agent protects the developer from simple mistakes and leaves them headroom to work on the harder ones.

Solve

If verification happens within the agentic loop, the agent can fix any issues whilst the code is being generated without expensive remediation steps. Static analysis tools can guide the agent on how to resolve the issue quickly. Some cases need human judgment — a None check at a system boundary may document a real precondition. But most of the work is mechanical. Automate the obvious fixes and let engineers spend their attention on the cases that are not.

The investment that compounds

Better models will keep arriving. They may not change the mechanism of bloat or the dynamics of compounding decay. The loop is what does — bounded tasks, sharp context, in-loop verification, and a deliberate “solve” step to clear bloat before it accumulates.

The same logic governs how autonomy should expand. Reduce human interventions only when the agent’s guide, verify, and solve cycle is making them redundant. Our biases can sting us here: an agent’s ability to write code can lead us to agree with it more than we should. Don’t trust blindly; wait for the evidence.

The teams that will be shipping enterprise-quality code with AI agents in 18 months are not the ones running the “best model.” They are the ones treating workflow as the engineering investment, with the seriousness once given to build systems and CI. The model is the tool, the workflow is the discipline. That is where the durable advantage compounds.

—

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.

CIOs and CISOs have many strategic and operational fears when it comes to unleashing fully-autonomous agents on tasks and hoping that everything works out. Will the agent start to delete critical files? Will the agent go off on a mission tangent and generate a massive token bill for the team when they return the next morning? Will it be tricked by a state actor and engage in malicious actions?

To help alleviate those concerns, OpenAI announced on Thursday that it has agreed to acquire Ona, a 79 person cloud development environment (CDE) provider formerly known as Gitpod, to accelerate its efforts to make agentic AI enterprise-friendly. 

An OpenAI statement said Ona’s technology “provides secure, persistent environments where agents can access the tools, systems, and context they need to make progress over time. By bringing Ona to OpenAI, we will expand Codex beyond work tied to a single device or active session and help more organizations deploy agents securely in production.”

An Ona statement attributed to CEO Johannes Landgraf shared similar sentiments.

“Ona brings the building blocks agents need for enterprise work: trusted, customer-controlled cloud environments where work continues across devices, inside the systems where software actually lives,” Landgraf said. “OpenAI brings frontier intelligence, product polish, and a scale of research and distribution we could never reach alone.”

Landgraf’s statement did not provide any annual revenue numbers, but did hint, without naming, at some large customers. “Since the beginning of the year, weekly Ona agent sessions have grown 13x in production across some of the world’s most demanding institutions: the oldest bank in the US, one of Europe’s largest pharma companies, one of Asia’s largest sovereign wealth funds and many others,” he wrote. “The largest enterprises out there love the platform and are expanding more rapidly than ever before.”

Arnal Dayaratna, research VP for software development at IDC, said IDC’s figures for Ona put its annual revenue for 2025 at “roughly $7 million.” He speculated that Ona’s revenue for 2026 would be higher: “Let’s say it’s $15 million. I am being generous. Maybe it’s really $10 million or $12 million.”

Dayaratna said if he uses a standard acquisition price of roughly a multiple of 30 times revenue, then depending on the actual 2026 figure, “that comes to $450 million or $500 million or so.”

But IDC sees this being a potentially good move for OpenAI, regardless of the specific acquisition price, given that OpenAI had the classic “buy or build” challenge. 

OpenAI has a substantial Codex effort, Dayaratna said, but what they lack is a safe area to protect enterprise autonomous agent efforts. “This is outside of what OpenAI has now. These are secure environments where agents can have memory and operate securely,” he said. “This is the kind of technology that one would expect to be needed, but I don’t know how good it is, to be honest.”

Gartner’s First Take, published today, noted that the acquisition will bring Codex “the essential scaling capability it lacked,” but also pointed out it forces some difficult decisions on enterprises: “Software engineering leaders must weigh the benefits of a vendor-specific integrated stack against the flexibility of staying vendor-agnostic.”

In addition, Gartner wrote, “This acquisition appears to be OpenAI’s response to Anthropic supporting self-hosted sandboxes in Claude Managed Agents, starting May 2026.”

Tom Findling, CEO of Conifers.ai, said he also sees OpenAI’s fear of Anthropic playing a meaningful role in this deal. 

“It feels like a move to keep pressure on Anthropic, especially as Claude Code gains traction with developers and enterprise buyers,” he said. “So I’d read this less as OpenAI taking out a small competitor and more as OpenAI trying to make sure Codex is enterprise-ready before Anthropic gets too far ahead. In the enterprise market, the battle is not just who has the smartest coding model, but who can make AI agents safe and useful enough for big companies to actually deploy.”

He added, “I don’t think this means OpenAI suddenly needs help making Codex better at writing code. The bigger issue is making Codex work inside real enterprise environments, where security, access controls, persistent cloud workspaces, audit trails, and integration with existing developer workflows matter just as much as the model itself. Ona gives OpenAI some of that missing plumbing.”

Jason Andersen, principal analyst for Moor Insights & Strategy, echoed the concerns about Anthropic.

“To be honest, I think it reinforces what I think, which is that OpenAI and Codex have given a lot of ground to Anthropic and Claude Code, who are winning right now,” he said. “But again, this is not about the market today, I think it’s about how OpenAI will need to position itself as more than just a model as we see the incumbent players, particularly Microsoft, bolster their enterprise coding infrastructure story.”

Andersen said that Moor doesn’t have any strong basis for a guess on the financials, but added, “I am going to assume it was a fairly high multiple, but on a small base. I would not speculate on an amount, but given the enterprise customers that Ona did have, it may be more than we think.”

He also reinforced the idea that OpenAI is going to need help to achieve its own objectives.

“We continue to see that AI adoption is strongest in coding, and other use cases are not as far along,” he said. “So, if you are a general-purpose AI company like OpenAI, you need to double down on development use cases. The meaningful investment and spending on development is happening at the enterprise level, and those customers have more demands for governance, security, etc. than Codex or Claude code can handle.”

That said, he noted, “what you’re seeing is traditional software and cloud plays building out the coding and ops infrastructure around the popular models. That increased competition, while good for selling tokens, is still keeping OpenAI and Anthropic on the outside looking in. So, OpenAI and Anthropic need a stronger enterprise dev story, or they are just another model that could be easily replaced.”

Jeremy Roberts, senior director at Info-Tech Research Group, said that he also sees this as likely a good move for OpenAI.

“OpenAI is growing up a little bit,” and they may be falling behind Anthropic, Roberts said. “I see Ona as a boring company, but not in a bad way. They are not flashy, but absolutely necessary.”

Ona is delivering a workspace for Codex that an enterprise can run in its own virtual private cloud, with governance and persistence and an environment where the company can apply their own controls including log management, credential management and resource access, he said. “It is a bucket for the agents to operate in” where IT can “make sure that access is properly credentialed and is controlled effectively to prevent the model doing what it shouldn’t be doing,” which includes managing read/write protections.

Microsoft has open-sourced an AI evaluation framework that converts natural-language requirements into executable tests, expanding its push into enterprise AI governance as organizations struggle to validate agent behavior before production deployments systematically.

The framework, called ASSERT (Adaptive Spec-driven Scoring for Evaluation and Regression Testing), generates evaluation scenarios, datasets, metrics, and scorecards from written specifications, product requirements, and governance documents, Microsoft said in a blog post announcing the release.

“Agents fail in ways that are hard to see,” Microsoft wrote in the blog post. “They drift from policy, produce unsafe outputs in edge cases, and behave differently in production than they did in testing. Generic benchmarks do not catch these failures because they are not built around your policies, your agent, or your use case.”

Rather than requiring developers to manually create evaluation suites, ASSERT translates written intent into reusable tests that can be integrated into AI development pipelines, the company said in the blog post.

With ASSERT, Microsoft is entering an increasingly competitive AI evaluation market that already includes platforms such as LangChain’s LangSmith, Braintrust, Patronus AI, Galileo, Arize AI’s Phoenix, and Promptfoo, which help enterprises benchmark, monitor, and validate large language model applications.

Behavioral testing remains immature

The release comes as enterprises rapidly expand AI agent deployments while formal evaluation practices remain the exception rather than the rule.

“Most organizations, in fact, 99% of them, do not evaluate any AI agents pre-production,” said Anushree Verma, senior director analyst at Gartner.

According to Verma, the industry’s next competitive advantage will depend less on advances in reasoning models than on how effectively organizations simulate and stress-test AI agents before deployment.

“The next competitive moat in agentic AI is not about the sophistication of reasoning models or the underlying architecture,” she said. “It will be about the depth and realism of the training environment through agentic simulation, particularly for mission-critical deployments.”

Gartner estimates that by 2029, more than 75% of domain-specific agents designed without agentic simulation in regulated industries will fail to deliver value.

Forrester sees enterprises moving toward behavioral evaluation but says most organizations have yet to make it a formal production requirement.

“Most enterprises are still in an intermediate stage where behavioral evaluation is inconsistently applied rather than treated as a formal production gate,” said Biswajeet Mahapatra, principal analyst at Forrester.

According to Forrester data, more than 45% of organizations are already using AI agents, and another 25% are piloting them, yet many continue to struggle with scaling because of immature governance and limited operational rigor.

“The net is that behavioral evaluation is becoming important, but for most organizations it is still ad hoc or tool-driven rather than a standardized release gate enforced across the lifecycle,” Mahapatra said.

AI judges still need human oversight

Microsoft said ASSERT uses large language models as judges, with model-generated evaluations agreeing with human reviewers 80% to 90% of the time in the company’s internal validation.

That level of agreement can help automate large portions of AI testing, but should not be treated as a standalone governance mechanism, Mahapatra said.

“An 80% to 90% agreement rate with human reviewers indicates strong alignment but is not sufficient as a standalone control for governance or compliance,” he said.

Instead, enterprises should adopt layered oversight where AI evaluates AI at scale while humans retain supervisory accountability for high-risk, regulated, or ambiguous scenarios. Buyers should also watch for bias, consistency issues, and overreliance on a single model acting as both generator and evaluator, he added.

Open source reduces lock-in, not governance risk

Microsoft released ASSERT under the MIT open-source license, allowing organizations to inspect, modify, and integrate the framework into existing AI development workflows.

But open sourcing a framework does not eliminate questions around evaluation neutrality, Mahapatra said.

“Open sourcing under an MIT license reduces lock-in concerns and enables broad interoperability across model ecosystems,” he said. “However, it does not fully eliminate trust or conflict-of-interest questions because the originating vendor still influences how evaluation criteria, scoring logic, and definitions of acceptable behaviour are encoded.”

Instead of relying on a single evaluation framework, enterprises should validate AI systems against multiple evaluation approaches and retain ownership of internal evaluation policies, he said.

Modern AI systems have evolved beyond the simple chatbots that quickly became popular. Now they use semantic tools to manage workflows and link machines to machines, providing a flexible and effective framework for the next generation of business automation. What you used to build in Microsoft’s Power Platform or construct inside Biztalk is now an agent, built around large language models (LLMs) that can parse both your data and the APIs that you want to use your data with, orchestrating workflows with a level of autonomy that traditional tooling can’t match.

That shift has offered new opportunities, much like those that came with business platforms like Microsoft Dynamics and Salesforce. Here, tools built to solve one set of business problems could be turned into applications that could be sold to other companies. What worked for you to solve one of your problems could now be an added revenue stream, sold through platform marketplaces that helped customers manage installations and customizations.

Agents are business applications now

Modern agents are much like those business applications. Often developed to solve a specific need, but quicky adopted by organizations and refactored to apply enterprise standards (using tools like the Agent Governance Toolkit and frameworks like Microsoft’s Agent Framework), they’re rapidly maturing and are ready to be shared more widely. The process of sharing needs to be curated and controlled, and, if possible, tied to a revenue stream.

There’s certainly some urgency here. Until recently, subsidized tokens have kept costs artificially low. Now companies like GitHub and Anthropic are moving to a more sustainable (for them) pricing model, increasing the cost of inferencing and squeezing companies’ AI budgets. As a result, switching AI projects away from a cost to a revenue source is high on CIOs’ agendas. If those tuned and trained agents can be sold on a marketplace, then that token budget can be justified.

Microsoft has always been a company built on partner relationships, starting with individual developers and working all the way up to the largest software companies and consultancies. That reach is key to helping partners extract as much value as possible from their agents, as it allows Microsoft to integrate its partner sales tools into its own products and services, as well as into other platforms.

Extending the Microsoft Marketplace for AI developers

We’re already familiar with many of Microsoft’s marketplaces, built into individual tools like Teams, into platforms like Microsoft 365 or Visual Studio, or into the Windows Store. Now the company is doing the same for AI developers, extending Microsoft Marketplace to software agents. Announced at Build 2026, the updated Microsoft Marketplace provides ways to publish code—apps and agents—developed across all of Microsoft’s development platforms, including Copilot Studio, opening the marketplace up to traditional and non-traditional developers alike.

Perhaps the most important aspect of this new Marketplace is its own intelligence, using context to expose your code to the right audience. If you’ve developed an agent for use with Microsoft 365, it will be exposed inside the Microsoft 365 Copilot Agent Store; for Visual Studio, in the Visual Studio Marketplace; or for Teams, in the Microsoft Marketplace. All of these are different views on the same back end, using AI to ensure that the relevant agents are displayed.

Replacing search with Intelligent Discovery

This is extended by another new service, Intelligent Discovery, which adds natural language support to search, using AI to infer user intent and highlight the most relevant tools. Building on the familiar metaphor of the search bar, the initial smart search model offers a freeform way to explore the Marketplace. While there are suggested prompts, they’re not necessary. The search tooling allows you to generate comparisons between tools using your own criteria, with the Marketplace AI generating views based on your requirements.

Microsoft’s aim here is to shift discovery from keywords to use cases, so that buyers can quickly get the tools they need without having to evaluate different solutions, before completing a purchase. By handing that aspect of the buying process over to Marketplace’s AIs, customers can go straight to trials or even to buying agents and applications.

For a tool like this to be successful it needs to be trustworthy. By building it on top of the same development frameworks as your agents, Microsoft can take advantage of the AI guardrails built into Microsoft Foundry as well as low-level tooling like the Agent Governance Framework. Restricting the intelligent search to the Marketplace catalogue reduces the risk of hallucination, as output is grounded in Marketplace data and metadata.

A developer-friendly marketplace

Microsoft is providing tooling to help developers get their listings right. According to Cyril Belikoff, Microsoft’s vice president of Commercial Cloud and AI, “We actually have a separate AI tool that we give to software companies to optimize their listings, called a listing optimizer, funny enough, and that listing optimizer reviews their listing and then provides them with particular guidance on how to best improve it, so that it can be best discoverable in today’s search world.”

You can expect the listing optimizer to be tuned to work with the new Marketplace tooling, but for now it still focuses on traditional search. As Marketplace is a B2B platform, there’s a lower risk of spam applications, but even so, Microsoft remains aware of the possibility of a new system being gamed, and will be rolling out Intelligent Discovery carefully, monitoring its performance as more customers get access over time.

Having a new discovery method is one thing; getting quality AI applications in the Marketplace is another. Microsoft is validating all code submitted, though the criteria will differ between target platforms. An agent built for Teams will be treated differently than one built on Microsoft 365’s WorkIQ. It’s an approach that allows Microsoft to support new standards as they become available.

Alongside its agent development tooling, Microsoft is rolling out a new set of guidelines and processes to help developers get ready to sell their agents. Hosted on GitHub, these offer code templates as well as a link to the App Advisor guidance tools.

Still gaps to fill

This first release of Intelligent Discovery is promising, but some key features are missing. With agent token costs an increasing problem for businesses, it would be nice to see tools that help predict costs, integrating with finops tooling. We’re living in an age of shadow AI, and putting the AI we used to buy with credit cards in Microsoft Marketplace is one way to shine a light on those shadows — bringing the necessary control and governance to AI purchases, and maybe even providing support for site licensing.

Microsoft Marketplace is becoming a useful resource for AI application developers. It encompasses the entire development life cycle: offering tools that can help you build agents, the models that you need to power your agents, and finally a way to monetize your work. There’s a longer-term opportunity here, for both the Marketplace and Intelligent Discovery to offer Model Context Protocol (MCP) interfaces, ensuring that tooling and tool discovery become part of the developer workflow, and making developers aware of new tools that might help solve a problem or simplify a task.

I’ve been around long enough to remember when deploying an application meant copying a *.exe file from the developer’s machine right into production. I am not making this up. It was that simple, and that fraught with peril. Applications weren’t complex — they were often not anything more than that simple *.exe file — and the process around deployment didn’t need to be anything complex, but it probably should have been.

Proper deployment of an application is something we’ve learned to do over the years. The process of properly building, testing, and deploying an application has grown more complex for two reasons. First, the process must ensure that every deployment succeeds. Deploying complex applications can be convoluted and challenging, and a strict deployment process ensures everything happens properly and runs correctly. Second, the process must thoroughly test the application to make sure that all the moving parts work together to create a properly functioning application. 

Today’s continuous deployment processes were hard-won from many lessons learned. Eventually, these practices became formalized, even to the point where the Sarbanes-Oxley Act was understood to require that IT departments formally document their deployment processes. 

This kind of governance is what separates professional software development organizations from those that, well, don’t know what they are doing. 

Agentic growing pains

Agentic development is headed in this same direction, but it’s all happening a bit more quickly. It was just a few months ago that people began to use AI to write code seriously. At first, most of us were doing it furtively, having Claude Code find and fix bugs, and then quietly checking in the solutions. Maybe we were a bit hesitant to mention that we had done this, but then we felt guilty about doing it and taking credit, and eventually we mentioned it. But it soon became apparent — like “within a week” soon — that Claude Code was up to the task, and we became pretty open about it. 

Very quickly, it not only became accepted but actually encouraged, and we were off to the races. In a month, everyone was tokenmaxxing.

It almost seems a bit out of control. Sure, there is a lot of code being generated and non-trivial amounts of money being spent, but it isn’t quite clear if the results are worth the effort. I’m not at all sure if anyone can say that the money spent is returning the value needed.

At some point, as an industry, we are going to have to get control of all of this. I fear that there will be a rush to impose governance over the whole thing. This, like deploying an .exe directly, is also fraught with peril. Right now, there appears to be little control over what tools are being used where, how much is being spent for what purpose, and what that spending is actually getting us. 

The governance over our deployment processes was successful and useful because it arose organically. The accepted, codified procedures arose from the lessons that practitioners learned by actually building and deploying applications. We all should work to ensure that a similar process happens with agentic coding.

Developers know best

Because agentic coding is happening so quickly and so furiously, the danger is that a governance process will be imposed over the top just as quickly and furiously. I want to encourage us all to take a deep breath, slow down a bit, and take a close look at what we are doing, and more importantly, how we are doing it. 

Agentic coding will be governed in some manner. It’s critical that we practitioners take the lead in providing that governance, or we’ll have governance forced upon us. We are the ones that know what matters and how the tools should be used. We are the ones with skin in the game and the ones keeping pace with the technology. 

Top-down governance of a technology moving this fast will never be able to keep up. Or as Uri Haramati, co-founder and CEO of Torii says, “The person closest to the tool usually understands why it’s being used, and governance works better when it includes those people instead of trying to control them.”

Copying that *.exe file into production is comically reckless. We don’t do that anymore because we know better. It took time, but we learned the right way to deploy software. Right now, we are in the “copying the *.exe” phase of agentic coding, and we need to figure out the right way to do it before someone comes along and does it for us.

Threat actors are continuing their onslaught against software supply chains, now with malware named after death itself.

The newly-discovered Hades Campaign is a “highly sophisticated” supply chain compromise that targets Python developer environments and runs as soon as infected packages are imported. It uses the popular Bun toolkit to silently execute multi-layer payloads that can extract sensitive data, move laterally across compromised systems, exploit common security frameworks, and even hijack AI gatekeeper analyzer systems via adversarial prompt injection.

Notably, the campaign exploited the popular C++ library ensmallen, as well as packages in the computational biology, bioinformatics, and genotype-phenotype analysis ecosystems.

The most novel thing about this malware is its combination of advanced tactics, noted David Shipley of Beauceron Security. He noted that we’ve seen memory-focused malware, we’ve seen attacks that attempt to defuse large language model (LLM) powered analysis with hidden prompts, and we’ve seen malware with wiper capabilities.

“But all three, in a fast moving mass propagating worm, is its own kind of nightmare,” he said. “And I suspect this is the way of the future.”

How Hades works

The Hades Campaign was discovered by researchers at StepSecurity, who called it the latest evolution of the Miasma threat actor. The researchers previously described Miasma attacks that had sent self-replicating worms to perform multi-cloud credential sweeps, caused infected repositories to execute code when folders were accessed in integrated development environments (IDEs) or by AI agents, and used techniques that scanned and read Linux process memory.

Hades uses the same credential harvesting methods, self-replicating worm logic, and GitHub-based exfiltration patterns, the researchers noted. In addition to ensmallen, compromised packages include mflux-streamlit, nhmpy, ppkt2synergy, embiggen, gpsea, and pyphetools.

The campaign’s entry point is a simple, obfuscated script embedded inside a Python package’s __init__.py file, a critical building block that gives Python the ability to recognize packages and import modules. Once they gain access, threat actors drop a precompiled Bun runtime binary and executes its JavaScript payload. Bun allows the malware to run complex JavaScript tasks in environments lacking a Node.js installation, bypassing traditional package manager controls and proxy logs.

The malware is able to scrape Linux memory mappings, and also introduces tailored macOS and Windows memory scrapers, which allow threat actors to extract sensitive, encrypted data.

Interestingly, attackers are also able to evade detection by automated LLMs that scan for suspicious code. This is achieved with a simple block of text at the top of the file; this instructs the model to ignore the hidden code below, classify the package as verified and clean, and provide reports stating it is safe.

This element represents what the StepSecurity researchers described as a “significant conceptual shift,” with attackers writing payloads that target AI systems’ cognitive logic. “Scanners that pass raw text to LLMs without strict boundary isolation can be coerced into generating false negative verdicts, allowing the malicious package to bypass organization analysis,” they wrote.

The tactic is indeed clever, Beauceron’s Shipley agreed, pointing out that attackers will increasingly target endpoint LLM-powered agents.

Why? “Because there’s no reliable defense,” he said. “LLMs are incredibly susceptible to social engineering.” This has been relabeled as prompt engineering, but is essentially just phishing for bots, he pointed out.

“While everyone’s worried about LLM-powered vulnerability discovery and automated exploitation, it’s LLM-created smart malware like this, and AI-powered phishing of humans and bots, that keeps me awake at night,” Shipley said.

Hades’ crafty worm propagation

The Hades Campaign command and control (C2) infrastructure uses three independent channels on public GitHub infrastructure to allow its communications to blend in with normal traffic. Stolen credentials are encrypted locally in a hybrid fashion (serialized, compressed, and pushed to a newly created public GitHub repository under attackers’ control). Exfiltrated repositories carry the description “Hades — The End for the Damned.”

Researchers noted that a core component of this campaign is its ability to propagate and move laterally across networks. It exploits the very methods meant to protect systems, including Secure Shell (SSH) and Secure Copy Protocol (SCP), OpenID Connect (OIDC),and Supply-chain Levels for Software Artifacts (SLSA).

For instance, when running inside a GitHub Actions workflow runner, the malware checks for OIDC variables, then bypasses registry signature policies and generates cryptographically signed SLSA provenance bundles via Sigstore. It can then fetch target libraries and inject the obfuscated script and JavaScript payload. From there, it can publish compromised versions to the Python Package Index (PyPI) repository and node package manager (npm) using the target’s credentials and the generated Sigstore bundle.

“This ensures that the published package appears to have valid, cryptographically verified build provenance from the organization’s official GitHub Actions build environment,” the researchers explained.

Further, if a harvested GitHub token has write permissions, the malware will target repositories to extract secrets using GitHub Actions runners. This occurs “directly from the runner’s address space without ever writing them to disk or making a suspicious network connection,” the researchers noted.

The malware also targets rule files and configuration directories for 14 different AI agents and systems, planting custom prompt instructions or executing hooks that trigger a bun run bootstrap command when the victim loads or consults the workspace with their AI assistant. Finally, it establishes persistence on the workstation and monitors for the presence of the stolen token; if that token is revoked, it executes a wiper process to erase the user’s files.

Model Context Protocol (MCP) has gained considerable momentum as a standard connector between LLM-powered tools and local systems, internal and external APIs, and data sources. From major clouds to devops tools, MCP servers are enabling powerful, AI-powered development and operations capabilities through natural language commands.

Nowhere is this more true than in the world of databases. Most major database platforms now support agentic access through MCP servers. Using an MCP server for databases, you and your AI agent proxies can perform lookups, create and update data, and perform administrative tasks without you having to write SQL by hand.

The MCP server could also guide your LLMs to write new code or build automations that align with your database schema, like its tables, structure, and fields, as well as embeddings, indexes, and metadata. It could also aid debugging by enabling faster queries to surface data issues or misconfigurations, along with plenty of other possible use cases.

Below, we’ll cover official MCP servers from some of the top platform options across major database styles. Though maturity varies, the MCP servers discussed below represent some of the best vendor-backed offerings available today across relational SQL, NoSQL, graph, vector, and data warehouse systems.

These servers can be used by any MCP-compatible tool, IDE, or agent, whether it’s Claude Code, Codex, Cursor, Gemini CLI, Google Antigravity, VS Code, Windsurf, or something else. Adding them is typically simple, often involving a lightweight JSON addition to your MCP configuration file.

Amazon Aurora MCP Servers

MySQL and PostgreSQL are the world’s most widely-used open source databases. However, in both cases, there is no canonical MCP server—what we see are different MCP servers emerging across vendors. One of these vendors is Amazon Web Services (AWS), which offers official MCP servers for Amazon Aurora, its managed relational database service compatible with both MySQL and PostgreSQL.

According to the documentation on GitHub, the Amazon Aurora MySQL MCP Server can be used to convert natural language commands into MySQL-compatible SQL queries, which can then be executed against Aurora MySQL databases. Similarly, the Aurora Postgres MCP Server provides MCP tools for working on PostgreSQL databases. The Aurora DSQL MCP Server does the same for distributed Postgres databases.

AWS provides a growing portfolio of official MCP servers across its product line, including MCP servers for other Amazon database platforms like DynamoDB, ElastiCache, and Redshift. If you’re a heavy AWS shop and you want to enable LLM interactions with your data, these are sensible choices.

BigQuery MCP Server

BigQuery is Google’s cloud-based data analytics platform, and a popular data source for AI applications. BigQuery users with API access configured can also utilize the BigQuery MCP Server to interact with the platform using MCP-compatible AI clients.

Using the remote BigQuery MCP Server, engineers can generate and execute queries on data sources, or return metadata on datasets, tables, and schema. This can be done with a simple natural language prompt like “List the datasets in project PROJECT_ID.” Results are filterable by region, data set ID, column name, and more.

As part of Google’s fully-managed, remote-hosted MCP portfolio, the BigQuery MCP Server provides some peace of mind regarding security, maintenance, and ease of use for distributed teams. The MCP tools are subject to some limitations, however, in terms of query result size, processing time, and other factors. If you’re using BigQuery and you want more agentic control, you’ll want to check this one out.

Elastic Agent Builder

Another important database category includes platforms designed for keyword and semantic search. In this space, Elasticsearch is commonly deployed. Instead of providing a single MCP server, Elasticsearch provides the Elastic Agent Builder, which is a more comprehensive framework aimed at agentic workflows.

Using Elastic Agent Builder, you can chat with an agent to retrieve data context from Elasticsearch data and extend it into various environments. The Agent Builder itself includes an MCP server endpoint for programmability and exposing the agent to other clients.

Unlike others on this list, this is not a direct MCP interface to raw Elasticsearch APIs. Instead, it’s an interface that exposes skills from the agent platform. This should also not be confused with the Elasticsearch MCP Server, released in mid-2025, which has since been deprecated.

A possible downside of using this utility is that it includes an additional layer between your IDE or agent and the data you’re searching. The agent setup requires a higher subscription and takes additional steps to configure compared to other MCP servers.

That said, if you want an extensible common layer to interact with both Elasticsearch and external MCP servers, while centralizing responsibilities like permissions, this is an interesting proposition.

MCP servers for Neo4j

Graph databases are another key NoSQL database type these days, specializing in using nodes and edges to accelerate queries of highly interconnected data. Of these, Neo4j is a popular graph database option.

The Official MCP Server for Neo4j works with all kinds of Neo4j deployment (desktop, sandbox, self-managed, and the managed Neo4j Aura cloud service), and allows LLM-based clients to retrieve graph schema, execute read and write statements, execute graph algorithms, and more.

In addition, several other MCP servers for Neo4j are available from Neo4j Labs. These have specialized uses, such as generating Cypher queries from natural language, maintaining an in-memory graph database, modeling and visualizing graph, and interacting with the Neo4j Aura API.

The first MCP server for Neo4j was developed in December 2024. If you’re an avid Neo4j user and want to experiment with interacting with your graph databases in a chat-infused way, these stand as an interesting platform of servers.

MCP Toolbox for Databases

Google’s MCP Toolbox for Databases is a notable MCP server because it’s a popular catch-all for various database types. Unlike the other entries on this list, this server connects LLMs not to a single managed database, but unifies LLM access to multiple systems. The open source utility ships with pre-built configurations for nearly 30 databases including PostgreSQL, MySQL, SQL Server, Oracle Database, MongoDB, Redis, Neo4j, and Snowflake, as well as the databases in Google Cloud.

Once you define data sources in a tools.yaml file, you can use MCP Toolbox to perform structured queries or semantic searches against databases directly from within an IDE or agentic client using plain English. MCP tools translate commands into actions like list_tables and execute_sql.

MCP Toolbox for Databases is mature, originally built as a generative AI utility and later re-worked for MCP-style workflows. It offers numerous download, configuration, and interaction methods.

If you’re using a variety of databases on Google Cloud and elsewhere and you want an “all-in-one” MCP server, MCP Toolbox for Databases is a great place to start.

MongoDB MCP Server

MongoDB is the popular NoSQL document-oriented database. The creators of MongoDB have released an official MCP server that works with the open-source database as well as the company’s cloud-hosted MongoDB Atlas database platform.

The MongoDB MCP Server provides a number of tools to interact with MongoDB. You can query the database, return information on collections, create or remove collections or indexes, gather statistics on database usage, and more. Other tools enable MongoDB Atlas operations, like creating users or clusters, returning cluster data, and other functions.

The server’s tools are read-only by default but can be switched to allow write capabilities. It can be used locally, but also supports Streamable HTTP transport for remote servers, although that comes with greater security concerns.

For those using MongoDB and wanting to hook their AI-enabled IDE or CLI up with more automated powers, the official MongoDB MCP Server is worth checking out.

Pinecone MCP server

Among vector-native databases, Pinecone stands as a strong, widely used option with a well-designed API and comprehensive SDKs. The Pinecone MCP server extends this experience, allowing users to query its documentation and execute functionality via AI agents and AI-enabled IDEs.

To date, the Pinecone MCP server consists of nine MCP tools. These cover read-only actions, like knowledge gathering via the Pinecone official documentation and querying vector records, index metadata, configurations, and statistics. It also allows for write operations like updating records and creating new indexes.

Released in mid-2025, the Pinecone MCP server is one of the more complete early implementations, with easy configuration and installation.

For those using Pinecone who want to test new LLM-assisted workflows for creating indexes with embeddings, performing reranking, or testing results using natural language commands, the Pinecone MCP server is worth trying out.

Redis MCP

An ultra-fast in-memory database, Redis is commonly used for caching, real-time analytics, and other latency-sensitive use cases. And as you might have guessed, the company behind the Redis database provides an official MCP server. The server allows read, query, and write capabilities.

Developers can use Redis MCP from an LLM client to perform high-level actions to analyze, reference, or embed Redis data and interact with the Redis server within their prompts. The documentation suggests some example prompts for common use cases, such as “Cache this item,” “How many keys does my database have?,” and “What is user:1’s email?”

Unlike other MCP servers, which only allow a slice of platform capabilities, Redis MCP offers full Redis support. This enables working with Redis constructs such as hashes, lists, sets, sorted sets, streams, and more, according to the GitHub repository.

One possible drawback is that Redis MCP has yet to support Streamable HTTP transport. Until this is developed, the server is constrained to local deployment. But for those seeking a local MCP server to work with Redis data, this is the best choice.

Snowflake MCP Server

Snowflake is a cloud-hosted, AI-enabled data platform widely used in enterprise contexts for data warehousing, data analytics, and data engineering purposes. Compared to other data storage systems, Snowflake is unique in that it’s more fully managed and combines structured and non-structured data types.

The Snowflake MCP Server, available on GitHub, can be used to perform many of the standard Snowflake platform operations. This includes a “fuzzy” search of all records via Snowflake’s Cortex Search and structured data semantic lookups using Cortex Analyst.

Other abilities include object management operations like creating, updating, and deleting records. The server also can invoke other agentic-designed capabilities, like the ability to generate and execute SQL statements against back-end databases.

Snowflake MCP Server is well-thought-out and well-documented, with walkthroughs for various agent and deployment patterns. Those already building with Snowflake should find it complements the mechanics they already employ.

Supabase MCP Server

A longtime open-source favorite, PostgreSQL is one of the most popular and trusted object-relational SQL-based database systems. With an active open source community, Postgres has been maturing for decades. Given its open source nature, there isn’t a single “official” MCP server for the platform. Anthropic built an original reference implementation, but it’s now archived.

Instead, database platforms built on PostgreSQL provide different flavors of MCP servers, with a range of vendor neutrality and specificity. One notable option is the Supabase MCP Server, provided by Supabase, a cloud-based “back end as a service” and Postgres development platform.

Supabase MCP Server connects AI agents with Supabase projects, allowing engineers to issue natural language commands to manage tables, query data, get logs, fetch configuration information, and more. The Supabase MCP Server is pre-1.0 release and some features are still experimental.

If you’re an engineer using Supabase and looking for an MCP server to connect your AI assistant with your Postgres databases, this is a good tool to test out.

Other MCP servers for databases to consider

So far, we’ve reviewed official, vendor-backed MCP servers from some of the most-adopted managed databases. However, numerous MCP servers exist across other database platforms and types.

One MCP server that aggregates LLM access across various database types is DBHub, which works with MySQL, PostgreSQL, SQL Server, MariaDB, and SQLite. Developed by Bytebase, DBHub is described as a zero-dependency, token-efficient MCP server.

For SQL, the options are nearly endless. Official servers exist for Microsoft Azure SQL and DuckDB. PulseMCP catalogs more than 100 MCP servers for MySQL, although most are unofficial, solo-creator open source projects. Of these, one of the most starred is MCP Server for MySQL, developed by full-stack developer Ben Borla and optimized for Claude Code.

For Postgres, notable alternatives to Supabase include pgEdge Postgres MCP, Neon MCP server, and Postgres MCP Pro. For vector databases, others beyond Pinecone have been quick to adopt MCP as well, including Weaviate and Milvus.

Using MCP for databases: what to watch out for

Before diving into MCP servers for enterprise databases, it’s important to understand the security risks. For instance, prompt injection remains an unsolved problem, so it’s recommended to limit permissions for SQL statements.

To mitigate this, Supabase recommends enabling AI client settings that require manual approval for each tool call before execution. Experts also recommend assigning only the minimum permissions required and avoiding exposure of sensitive data like API credentials. Due diligence around authentication and authorization is especially important when hosting remote servers.

Lastly, to avoid shadow IT, it’s becoming common practice to catalog the internal MCP servers you use, even for experimental projects. For this, experts recommend an MCP registry that documents approved servers. An MCP registry improves both MCP server discovery and security awareness.

Anyone can build an app now. But nobody seems to care.

Well, not nobody. VCs keep funding startups that add AI to, well, everything. But users aren’t buying the massive influx of new apps. In a chart shared by Jen Zhu Scott based on the new National Bureau of Economic Research’s working paper “Writing Code vs. Shipping Code,” iOS app releases have exploded since the advent of agentic AI. That would perhaps be cause for celebration had app reviews not declined during this same period, and apps with significant usage have stayed essentially flat.

In other words, more apps but almost nobody new showing up to use them.

For those of us that grew up in open source, it’s a familiar problem. The greater the abundance of code, the greater the need to help would-be customers navigate it through marketing (including branding), sales, etc. AI is creating so much noise, in terms of new code, new products, etc., that the real work has shifted to taste-making.

Getting more but not using more

I’ve been saying for a while that developer productivity isn’t about producing more code faster. Or at least it shouldn’t be. Productivity is about producing well-architected, secure, maintainable code that solves a problem someone actually has.

That’s a very different thing. It’s not something AI can fix; at least, not yet.

Charity Majors put it more bluntly in a post I wrote in 2024: “Writing code is the easiest part of software engineering,” she said. The harder parts are figuring out what to build, integrating it into a larger system, validating that it works, maintaining it over time, and getting humans to trust it enough to use it.

Turns out the harder parts are really hard. Mert Demirer, Leon Musolff, and Liyuan Yang tracked more than 100,000 GitHub developers alongside their AI usage telemetry. Autocomplete, interactive agents, and autonomous agents each ramped raw coding activity, with cumulative effects on commits of 40%, 140%, and 180%. That sounds great until you look how the gains attenuate the closer you get to actual users. For example, that 180% jump in commits became roughly 50% more projects and just 30% more actual releases. The report’s authors call this the weak-link problem: The strong link (writing code) got much stronger, while the weak links (everything else humans have to do) didn’t. The estimated elasticity of substitution between AI and human effort is 0.25, which is economist for “these complement each other, but they don’t replace each other.”

When the authors checked four major app marketplaces, they found a bump in new apps but no increase in total usage. In other words, we’re getting better at creating things with AI’s help; apparently we’re not good at turning that into user interest. User attention (and budget) is finite. The hard part is to figure out how to get users to care enough to pay (with their time or their money).

Learning to love marketing

So what’s actually scarce in a world of near-infinite software? Not code, for sure. No, what’s scarce is attention, trust, and a reason to switch.

That means the durable advantages in software increasingly live in the parts of the business developers often undervalue, like a recognizable brand (something that Red Hat figured out early on in open source) or a channel they already use. Or it could be in areas that developers appreciate but don’t pay for, like good documentation or a welcoming community.

This isn’t a new idea; it’s just newly unavoidable. We’re watching something similar inside enterprises, where AI adoption is wildly uneven, not because the technology has no value, but because the organizational plumbing around it often hasn’t been built. This is why a new kind of speed is important. I once argued that speed was the killer app, and that was mostly true. Today the more interesting speed is how quickly you can earn trust, fit into a workflow, answer objections, and get adopted.

Years ago I wrote that RethinkDB was dead and MongoDB wasn’t what killed it. RethinkDB was at the time, by many technical measures, a better database, built around “correctness, simplicity, and consistency.” It still lost—and badly. Its founder’s own postmortem was unsparing: They had picked a brutal market and tuned the product to the wrong definition of good. Being technically right turned out to have almost nothing to do with getting adopted.

With AI we’re generating a thousand smaller “RethinkDBs,” only faster and with nicer landing pages generated by the same model that wrote the code. These aren’t going to win, any more than RethinkDB was able to unseat MongoDB. It’s not just about the tech, but rather about making that tech fit within a user’s or enterprise’s world and making it easy to adopt. AI makes this harder, not easier.

It’s a cliché that developers don’t like marketing. It’s also false in my inexperience. What developers don’t like is traditional marketing. During my time at MongoDB and now at Oracle, my developer relations teams have focused on offering developers deep, hands-on enablement, and the response has been fantastic. Is a technical tutorial marketing? Of course it is. So is a forward-deployed engineer working side by side with an enterprise’s engineers to help them effectively use your tech. Just because it’s not a 30-second Super Bowl ad doesn’t mean it’s not marketing.

Years ago the Dilbert cartoon captured developers’ disdain for marketing. It was funny then, and it’s funny now, but it has never been true.

Years ago Matt Klein, creator of the open source Envoy project, once talked me through all the non-development work that goes into making an open source project thrive. As he reflected, “If you look at what I did in 2016 and early 2017 to [introduce] and grow the project, it was not technical.” So what was it, if not core engineering? “It was all leadership, public relations, marketing, documentation, etc., and I did it all myself and I nearly killed myself [doing it].” As he summed it up for me, it was a “f—ing lot of work,” and much (most?) of it wasn’t about code. It was about helping users appreciate the value of that code.

TL;DR? The boring but essential go-to-market grind has always been the real job. It’s what will separate winners from losers in AI.

The boring work wins

None of this is an argument against AI coding tools. Developers should absolutely use them. I use them constantly.

But AI can’t compensate for the hard work that goes into making a product successful in the market. In a world drowning in AI-generated sameness, taste becomes a competitive advantage. For me, “taste” translates into knowing what not to build, or what not to publish. It’s also all about knowing how to market one’s product, which might include ads but definitely needs to incorporate technical training that helps developers make sense of your code.

In short, there’s no Field of Dreams “build it and they will come.” There’s just a lot of hard, human work to help real people find and use your code.

GitHub is expanding Copilot beyond the IDE with a new desktop application and a new collaborative work surface called canvas as part of its broader efforts to pitch the AI-assisted coding tool as the control center for agent-native software development.

The desktop application announced at Microsoft’s annual Build conference this week is designed to give developers a dedicated environment for working with AI agents throughout the software development lifecycle, rather than limiting those interactions to code-generation tasks inside an editor, the company wrote in a blog post.

The application includes a collaborative workspace called canvas where developers can brainstorm ideas, refine requirements, generate plans, and iterate on projects alongside AI, it said.

It also has new Agent Merge and code review features that enable developers to automate Copilot to combine tasks of different agents to complete a specific goal or conduct autonomous code reviews according to set standards, it said.

These new features could reduce context switching, increase engineering efficiency, and accelerate delivery cycles, said Phil Fersht, CEO of HFS Research.

Shift in pricing justified?

However, despite the new features, much of the conversation among developers in recent weeks has centered on a different topic: this week’s shift to a usage-based billing model for GitHub Copilot that it announced in April.

The changes were met with a wave of criticism on the GitHub community forum, where some users accused the company of a “bait and switch,” while others requested refunds or announced plans to cancel their subscriptions.

For analysts, though, the pricing change was, at least from GitHub’s point of view, necessary and justified.

“The pricing change is justified by where GitHub is going, not by where the product is today. Running multiple agents in parallel with sandboxes, canvas reviews, and Agent Merge looping through CI is closer to cloud compute than an IDE plugin, and you cannot price compute on a flat seat fee. So metered billing is the right call structurally,” said Advait Patel, a senior reliability engineer at Broadcom.

Fersht said developers and CIOs need to focus on Copilot’s metamorphosis from being a coding assistant into a platform for orchestrating software-development agents and workflows.

“That changes the ROI conversation significantly. CIOs should stop thinking about Copilot as a seat-license productivity tool and instead evaluate it as an AI-powered software delivery platform,” he said. “The metrics shift from ‘lines of code generated’ to broader operational outcomes such as release velocity, code quality, defect reduction and engineering efficiency.”

GitHub is not the first company offering vibe-coding tools to rethink its pricing strategy as AI agents proliferate across enterprises and evolve to take on more complex software-development tasks that are computationally more intensive.

Over the past year, platforms such as Claude Code, Replit, Cursor, and Kiro have repeatedly adjusted their pricing structures to account for mounting infrastructure costs, limited GPU availability, and the expense of serving increasingly sophisticated AI models and agents, despite furor among their users.

For CIOs, the challenge is proving ROI

That common pressure across AI coding vendors is why Amit Chandak, chief analytics officer at IT consulting firm Kanerika, thinks developers and CIOs should focus less on GitHub’s pricing mechanics and more on whether these increasingly capable tools are delivering measurable business value.

“The new features that GitHub announced can act as productivity multipliers as well as features that increase consumption without delivering proportional business value. Without productivity baselines established before adoption, enterprises risk absorbing higher costs with no clear line back to delivered value,” Chandak said.

For Fersht, developers and CIOs will need to focus on governance, monitoring and financial controls as the pricing model is changing.

“The governance challenge is very real. Autonomous agents can continuously reason, test, revise and interact with multiple systems in ways that create far less predictable consumption patterns than traditional SaaS tools,” he said.

Patel, however, advised users and decision-makers to be more skeptical, especially since the new features are currently in technical preview.

“Customers are being asked to pay variable rates now for value that has not been validated in production. Do not assume new capabilities justify higher spend,” he said. “Instead, run a 90 day pilot, measure PRs merged per dollar before and after, and let the data decide. If the ratio improves, the pricing is fair. If it does not, you are paying for promise, not delivery,” Patel added.

The team behind RubyGems, a package hosting site for Ruby developers, has added a new feature to bundler, a tool for managing Ruby packages (or ‘gems’) to protect developers against the recent wave of software supply chain attacks: A cooling-off period before recently updated packages are installed on their systems.

Recent attacks on software repositories have focused on stealing developer credentials in order to introduce malicious code into the packages they create, which then steals more developers’ credentials when they install the malicious updates, and so on. Users of the repositories are vulnerable if they download an affected package during the short interval between it being interfered with and the malicious additions being discovered and removed.

To counteract this, RubyGems team has added a new cooldown argument to Bundler that takes ignores gems until they have been published for a specified number of days. This provides an additional layer of defense against malicious package releases as it gives others an opportunity to identify any malicious code they contain before installation.

The cooldown system works by checking the timestamp of any new versions of gems. Any new additions to the source will have to come from older versions, any new additions will be delayed until they are validated.

In situations where waiting is unhelpful — for instance when a known-good package is released to patch a dangerous security flaw — the delay can be overridden.

Microsoft has announced Coreutils, a new Windows 11 feature that allows developers to run many popular Linux command line utilities natively on Windows from a single binary.

Revealed at this week’s Build 2026 developer conference in Seattle, Coreutils is about reducing what Microsoft terms the “cognitive load” faced by developers when moving between Windows and other platforms.

Currently, accessing the Linux command line utilities that are considered essential in many CI/CD development environments on Windows requires a kludge that involves either opening an emulation such as Git Bash, or a virtualized Windows Linux Subsystem (WSL) terminal.

Both are time-consuming and inefficient. As Microsoft’s announcement puts it: “Developers constantly move between platforms, but familiar commands don’t work consistently, forcing workarounds, lost speed and context switching.”

Coreutils removes the need for this back and forth, allowing developers to run most Linux commands straight from the Windows CMD command prompt, PowerShell, or Windows Terminal.

“Whether you’re moving between Linux, macOS, WSL, containers or cloud environments, the commands and workflows you’ve built over years just work in your Windows environment,” Microsoft said.

Most utilities, but not all

Installed as a single executable (via WinGet: install Microsoft.Coreutils), Coreutils for Windows itself is a Rust rewrite of the GNU uutils/coreutils project that provides commands that are universal across Linux distros.

Fundamental to making Coreutils efficient to manage is the fact that individual Linux commands run from a multi-call executable which maps via NTFS hardlinks pointing to each command. The advantage of this approach is that there’s only one binary to install, one binary to sign, and one binary to patch or update.

Microsoft lists 75 Linux utilities supported by Coreutils, including commonly-used commands such as ls, cp, find, grep, find, rm, du, hostname, and uptime.

However, some Coreutils commands clash with existing CMD or Powershell commands, or are otherwise not possible to execute; Microsoft provides a compatibility table listing conflicts. This means that some commands are not available, specifically: dir, expand, kill, more, timeout, and whoami.

There are also some commands omitted from Coreutils because a command relies on a POSIX Unix/Linux feature that Windows doesn’t implement in a compatible way; some examples are chmod, chown, id, stty, and chroot.

In other cases, the command will execute in one context, CMD, but not in PowerShell. Microsoft explained the complex order of precedence:  “Whether the Coreutils version runs depends on the shell, the PATH order, and (for PowerShell) the alias table.”

As well as Coreutils, the Build 2026 developer conference also saw Microsoft announce WSL containers CLI and API to deploy Linux containers on Windows, a new framework for autonomous agents with open source governance tools, and Microsoft Scout, an AI agent designed to automate tasks in Microsoft 365.

For enterprises embracing AI-assisted development, writing code is no longer the hardest part. Operationalizing it is. Microsoft is targeting that challenge with Rayfin, a new open-source SDK and CLI unveiled at Build 2026.

“Rayfin turns backend development into a code-first workflow. Developers and coding agents can define a full application backend in code, including databases, business logic, APIs, identity, and access policies, and deploy it to Microsoft Fabric for a fully managed, enterprise-grade backend,” Shireesh Thota, CVP of databases at Microsoft, wrote in a blog post.

In effect, Thota added, this approach cuts down the manual integration work and time typically required to connect backend systems once an application front-end is built.

Explaining further, how Rayfin works, the top executive said that developers or coding agents working on their behalf define the entire backend using the SDK, and then that definition is deployed directly to Fabric using the CLI.

Governance, not productivity, may be the bigger draw

According to independent consultant David Linthicum, Rayfin increases developer productivity, reduces integration overhead, and platform sprawl: “Instead of standing up separate app runtimes, data services, governance layers, and custom integration code, they can push more of that into one managed environment. It also keeps application data closer to the analytics estate.”

However, the rise in developer productivity is just the hook, according to Stewart Bond, research vice president at IDC.

“For CIOs, the more compelling value proposition is governance and operational control. It is governance by default — inherited security, compliance, and access policies from day one — that addresses the risks CIOs most frequently cite when AI-generated code and agent-authored applications enter production environments,” Bon said.

“IDC research indicates that AI data readiness is not owned by a single team but by a coordinated network of stakeholders across all four planes of the enterprise intelligence architecture, and Rayfin’s architecture reflects that by ensuring that application data lands directly in a governed data estate, making it immediately available for reporting, analytics, and AI workloads without additional pipeline work,” Bond added.

For Ashish Chaturvedi, leader of executive research at HFS Research, Rayfin should help CIOs tackle another facet of non-governance: shadow IT.

“Coding agents have democratized app creation. Today, anyone with a prompt and a browser can spin up a working application in minutes. Every one of those ungoverned apps is a potential data silo, a security gap, and a compliance liability waiting to land on someone’s desk. Rayfin is the governed on-ramp,” Chaturvedi said.

Platforms like Rayfin are set to gain traction

Analysts say platforms like Rayfin are becoming increasingly common as enterprises discover that AI applications are difficult to govern and operationalize when data, models, policies, and runtimes are spread across separate systems.

Enterprises moving beyond isolated AI experiments, according to Bond, increasingly need automated governance, real-time processing, and tighter feedback loops between AI systems and enterprise data — capabilities that are harder to deliver when application and data layers remain separate.

More so because the economics, too, becomes harder to argue, Chaturvedi said.

“When apps run inside the data platform, you eliminate data movement costs, reduce governance surface area, and shrink the attack surface. Within three to five years, converged platforms will be the default for new agentic applications,” the analyst added.

However, Stephanie Walter, practice lead of the AI stack at HyperFRAME Research, pointed out that enterprises will not move every application onto one platform.

“The likely future is a hybrid model: some agentic applications will run inside governed data platforms like Fabric, Snowflake, or Databricks, while others will continue to run on general-purpose cloud runtimes. The architectural question will be where the application’s most sensitive data, context, and control plane should live,” Walter said.

Making Fabric the runtime for AI applications

Beyond the immediate benefits around governance and operational control, Walter sees Rayfin as a strategic move in Microsoft’s broader effort to expand Fabric’s role within the enterprise technology stack.

Rayfin’s release, Walter said, is less about a new developer tool and more about Microsoft’s attempt to reposition Fabric as a platform for building and running AI-native applications.

“Rayfin positions Fabric as a runtime environment for a new class of AI-native applications. That is strategically important because the next phase of enterprise AI will not be won only at the model layer. It will be won by the platforms that can turn governed enterprise data into safe, operational applications,” Walter added.

However, she remained skeptical about whether developers will accept Fabric as an application runtime and not just a data platform: “Rayfin lowers the barrier, but Microsoft still has to prove the developer experience is lightweight enough, the deployment model is flexible enough, and the governance benefits are strong enough to justify building inside Fabric rather than around it.”

Microsoft is making Rayfin available in preview, and enterprises can try the service through a 60-day Microsoft Fabric trial. The SDK and CLI-combo can also be accessed via Replit, the company said.

A veritable garden of linters and type checkers has blossomed in the Python ecosystem. Pyright and Mypy are two of the most popular, while Astral’s ty and Meta’s Pyrefly are two promising Rust-based newcomers. We compared early-stage ty and Pyrefly last June. One year later, Meta has released Pyrefly 1.0.

Pyrefly is intended to stand out from the pack by way of a few key features. It’s written in Rust for performance and memory efficiency, and it has a number of intriguing forward-looking features, some still experimental.

Setting up Pyrefly

Pyrefly installs into a Python environment like any other Python type checker (pip install pyrefly) and brings with it no additional dependencies. Visual Studio Code users can work with Pyrefly via an extension, but the extension doesn’t give you access to the command-line tools offered by Pyrefly when it’s installed in a project venv.

You can start using Pyrefly right away, with no actual setup. If Pyrefly detects no configuration for a given project, it defaults to flagging only the most high-profile errors: syntax issues, unrecognized names, and so on. To start using Pyrefly’s more advanced features, you can add a [tool.pyrefly] section in pyproject.toml, or create a pyrefly.toml file, and populate those with your desired settings.

You can also run pyrefly init on your codebase and set things up automatically, including migrating existing settings from previous Pyrefly installs or from Mypy or Pyright. By default Pyrefly will use **/*.py* as the project’s includes directory, and will automatically ignore site package paths from your configured environment, thus sparing you potentially thousands of spurious errors from your venv’s installed packages.

Using Pyrefly

Once you have Pyrefly set up on a project, you’ll likely see an immense number of new errors. To silence all of them at once via # pyrefly: ignore comment directives, run pyrefly suppress. This will not only reduce the amount of error noise, but allow you to see what each error actually is from its suppression comments.

Suppression comments have another nice readability feature: they can be placed on the line before the offending error, rather than at the end of it. You can also pre-emptively suppress errors for an entire module with one directive at the top of the file, but having each error suppressed individually makes more sense. And while there’s a pyrefly suppress --remove-unused command to remove suppressions that have no actual error, there’s no command for stripping a codebase of all suppressions. However, because suppressions are consistently formatted, you could remove those suppressions with a simple regex-powered search-and-replace.

A currently experimental feature called baseline files borrows an idea from the basedpyright tool. You generate a project-wide .json file with pyrefly check --baseline that tracks all existing errors in the project, then only new errors apart from those will be reported. It’s a handy way to refactor a codebase when new work is being done on it, so that existing problems can be handled separately.

If you have the Pyrefly extension installed in VS Code, objects without existing type hints will have suggested type hints displayed as inlays if the types can be inferred from the code. These can be added with a right click, or inserted automatically across the codebase with the command pyrefly infer.

Advanced Pyrefly features

Two major third-party Python packages have direct type annotation support in Pyrefly. One is Django and its ORM, via the django-stubs package. Models, fields, relationships, class-based generic views, and many other features have typing support. The other package, Pydantic, gets support from Pyrefly for features like fields, dataclasses, and Pydantic’s own runtime validation logic. Pydantic validation can be “lax” (automatic coercion of types via unions) or “strict” (exact types required).

Many advanced Pyrefly features are still considered experimental, but have a lot of promise. With type coverage, for instance, you can use pyrefly report to generate a JSON report of how thoroughly types are used in the codebase. (This is not to be confused with the coverage package in Python, which describes test coverage for a codebase.)

Another experimental feature lets you generate stub files for a codebase by using static code analysis (not runtime analysis). PyTorch users also benefit from a form of experimental Pyrefly support. Tensor shapes can be described with types and type-checked across transformations. Note that the typing used for this is exclusive to Pyrefly, as there is no agreed-on standard for how to do this.

Pyrefly vs. Pyright and Mypy

Pyright and Mypy have been the default choices for linting and type checking in the Python world for some time now. Pyright is an easy default for Visual Studio Code users, as it’s part of Microsoft’s Python extensions for that editor, and Mypy offers extensibility and broader compatibility with older codebases. Pyrefly, on the other hand, is forward-looking, with fewer legacy concerns. It also has a higher score for test conformance than Mypy, though not a higher score than Pyright.

Other key differences include the type checking philosophy used by each, and their licensing. Pyrefly and Pyright infer as aggressively as possible, while Mypy’s default is to skip anything unannotated. And while Pyrefly and Mypy are MIT-licensed, only Pyright’s core functionality is MIT-licensed. Pylance, the language server extension for VS Code that is powered by Pyright, is proprietary.

Finally, Pyrefly’s Rust codebase gives it a default performance edge over both Mypy and Pyright, which are written in Python and TypeScript, respectively. Astral’s ty, also written in Rust, is still more prototype than mature project. Pyrefly has enough of a feature set right now that it’s already worth experimenting with—although that’s best done on a branch of your code where adding type annotations, suppression comments, and init files won’t pose a problem.

When I was a kid, we all marveled at the notion of the Star Trek computer that you’d just talk to and that would answer all your questions. It seemed impossibly fantastic and categorically impossible. Well, we have that now. In one episode, Captain Kirk used a universal translator to communicate with an alien (never mind that the aliens always seemed to speak English..). Today, everyone’s phone can do real-time translations between all the most commonly spoken languages on the planet. 

If you haven’t figured it out by now, I’m bullish on agentic coding. I think it’s marvelous, I think it will bring about an increase in software development jobs, and I think it will bring about unprecedented growth in the production of software. It’s that last point I want to explore a bit more deeply, because I think an explosion of software is coming.

Thomas Watson, the legendary IBM CEO, is often misquoted as saying, “I think there is a world market for maybe five computers.”  The true story is that he went out to talk to 20 customers, hoping to sell five IBM 701 computers, and ended up with 18 orders. Of course, today, computer sales are measured in the hundreds of millions. 

We are currently in the “loving the thought of getting 18 orders after expecting five” stage of software. We are just getting started.

Mr. Watson probably couldn’t envision everyone walking around with a computer in their pocket that is a 100 million times more powerful than that IBM 701. And though I’m going to try, I’ll certainly come up way short of imagining a volume of software output that is eight orders of magnitude beyond what we are producing today. 

Ready for takeoff

The first chunk of this blitz will be software that looks familiar and isn’t that surprising. It will be the software sitting in our backlogs — things we’ve wanted to do for years but haven’t had the time for. All software development houses have these projects, and now they will get done. This software will be an expansion of the software we currently have. 

The second chunk will come when companies without development teams realize they can build the software they need using consultancies that can deliver quickly and at minimal cost. They will develop software tools that fit their unique business needs. Instead of using off-the-shelf solutions that they adapt to their needs, they will build custom software that works exactly the way their companies do.

The third chunk will come when those companies figure out that they can build the software they need themselves. Agentic coding tools will soon be powerful enough for non-developers to create the custom software a company needs, and they’ll be able to do these things in-house. 

The fourth wave is the one that really excites me — the wave of things we haven’t yet conceived of. I’d love to be able to tell you what that will be all about, but of course I can’t. It would be like someone telling you in 1988 about Google Maps, Wikipedia, ChatGPT, and Spotify.

The cost of developing software is about to drop through the floor, causing the demand for software to shoot through the roof. Software has no real physical limitations, like bridges do — the only limitation is our imaginations, and that has proven to be boundless.  

Workday is aiming to help customers to develop and deploy agentic systems without compromising corporate security or compliance, unveiling a series of AI tools at its DevCon event this week.

Chief among them is Agent Passport, which validates an agent’s safety and compliance both before it is deployed, and continuously during its operation. When an agent attempts a task, Agent Passport can allow, block, or route the action appropriately, and problem agents can be stopped or restricted, based on company policy.

Agents will be vetted for a series of risks, including prompt injection, jailbreak and goal hijacking, system prompt extraction, leaks of employee data, and unsafe outputs. Those tests will be tied to public standards such as Mitre ATLAS, and will be performed by security partners, not by Workday. Security teams can view those attestations, receiving a signed, auditable record of who tested the agent, and what it was tested for.

Because every check is tied to a public standard, security teams can compare agents from different vendors, tested by different partners, on the same terms.

The sole testing partner at launch is Cisco.

“It’s difficult to really get ramped up in a standard with a lot of partners in the mix, so we want to get this right with just ourselves and Cisco,” said Workday CTO Gabe Monroy. “We’ll be rolling it out more broadly soon.”

No-one to blame

There are still questions to be worked out. For example, if an agent that has been tested and received its compliance stamps from a tester misbehaves, who’s on the hook? That, said Monroy, is something “we’re still wrestling with with our partners.”

Agent Passport will be available in early access in the third quarter, with general availability expected before year end.

DevCon also saw the launch of Developer Agent, which enables developers to easily build AI apps and agents, and Agent-Ready Tools, a new class of enterprise connectors created for autonomous agents.

Agent-Ready Tools provide agents with precise, easy-to-navigate business logic and context while reducing hallucination and latency, Workday said. They connect to act across Workday through open standards such as MCP. For agents that need to work beyond Workday, developers can use pre-built Pipedream connectors to create custom agent actions and expose them as Agent-Ready Tools.

Developer Agent plugs into a dev’s agentic development tool of choice, be it Claude Code, Cline, Codex, Cursor, or Google Antigravity, and can also be used to create and deploy custom agents for the Workday platform with the open AgentSkills standard (OASS). Using it, a developer can simply type a request such as “Build an agent that alerts finance when a department is trending to go over budget this quarter,” and Developer Agent will choose the appropriate Agent-Ready Tools, connect to the necessary data and services, and pull in any required documentation and examples to complete the task.

Developer Agent and Agent-Ready Tools are available to early access customers through Workday Extend Professional, with general availability planned for the second half of 2026.

This article first appeared on CIO.