For 15 years, public cloud providers have defined the industry for most enterprises: on-demand, automatically metered services delivered over the open internet that give developers immediate access to storage, databases, compute, application development platforms, and AI capabilities. That model remains dominant because it is simple, well-instrumented, and universally supported. Yet an adjacent reality has always existed. Large-scale, off-market capacity deals where technology companies with surplus GPUs, storage, and compute sold blocks of capacity in bulk to other firms under nondisclosure agreements were once common. Those were cloud transactions in substance, since you were using somebody else’s servers. However, they lacked the automation, metering, and governance that define public cloud services, and they operated entirely outside the frameworks enterprises rely on for budgeting, compliance, and accountability.

A shadow market becomes visible

These arrangements are now becoming more visible and more formalized. Some are even openly auctioned. Meta’s entrance into the cloud capacity space, essentially offering its excess compute infrastructure to outside buyers, represents the maturation of a market that has existed in back rooms for years. Large, multiyear capacity commitments are no longer whispered about during boardroom lunches. They are being announced, financed, and tracked by analysts. This shift is creating a distinct layer in the cloud landscape, one that sits between traditional hyperscalers and true private clouds, and one that enterprises can no longer afford to ignore.

The practical implication is that the cloud market you thought you understood now has a parallel track. When a large enterprise needs maximum GPU capacity for model training or inference, it has more options than a year ago, and those options come with genuinely different trade-offs. You can go to a hyperscaler and pay the published rate for metered GPU as a service, receiving a fully managed platform with all the tools, governance, and integration you need. Or you can reach out to a technology provider that happens to have idle or excess GPU capacity and negotiate a bulk deal at a fraction of the published rate. The first option provides predictability and depth of service. The second offers raw cost savings if you have the operational capability to handle less-managed infrastructure.

This bifurcation is muddying procurement decisions. The gap in pricing between bulk off-market capacity and public cloud offerings can be substantial. Some analysts cite differentials ranging from 10 to 100 times. But headline GPU rates are only part of the evaluation. Bulk deals tend to come with minimal metering, limited monitoring, and a do-it-yourself culture around incident response and optimization. You are, in effect, purchasing wholesale energy. It is robust and capable, but it requires your own wiring and maintenance. Organizations accustomed to the instrumentation and service-level agreements of hyperscalers may find such a different operational reality a bit jarring. Those with mature cloudops teams may find the economics compelling.

Who benefits and who adjusts

The hyperscale incumbents will not be displaced overnight. They offer the complete ecosystem, not just GPU frameworks but development tools, hundreds of managed services, identity, compliance, and integration layers that are genuinely difficult to replicate. However, they are now facing a market where customers with intensive computational needs can source raw GPU capacity from alternative suppliers, particularly for bursty or cost-sensitive workloads. This is not necessarily a threat to hyperscaler dominance, but it is a complication. The hyperscalers will likely respond through partnerships, capacity-coverage agreements, and possibly acquisitions of promising capacity players. Effectively, they will become customers of the same off-market ecosystem they once ignored.

The cloud market is adding a new axis of choice: managed breadth versus specialized efficiency. Enterprises will increasingly construct hybrid operating models, keeping steady-state, security-sensitive, and toolchain-dependent workloads on hyperscaler platforms while offloading cost-intensive training runs and elastic inference to bulk-capacity providers. This is not a binary choice. It is an expanding continuum of sourcing options that demands more sophisticated procurement and architecture planning.

How to take advantage

Know your actual workload cost before you negotiate. If your AI workloads are compute-intensive, model training-heavy, or require burst capacity at unpredictable intervals, the economics of bulk capacity deals can be compelling. Run a pilot that captures total cost of ownership, including data movement, integration effort, operational overhead, and potential downtime during self-managed troubleshooting before you assume bulk is simply cheaper. Compare fully loaded costs, not GPU-hour sticker prices.

Build portability into your AI stack from the start. Bulk-capacity providers often lack the governance, compliance tools, and model life-cycle management enterprises need. Mitigate this risk by standardizing on containerized inference runtimes, open model formats, and CI/CD pipelines capable of deploying across multiple targets. This type of discipline turns vendor diversity into negotiating leverage rather than operational liability. It also ensures you can shift workloads as capacity markets fluctuate.

Treat capacity sourcing as a strategic procurement function. Bulk cloud capacity is not a niche quirk. It is becoming a recognized market that rewards supply-chain thinking. Diversify your supplier base, negotiate multi-vendor commitments where possible, and develop a reserve strategy for critical workloads. Keep your hyperscaler relationship for reliability and breadth, but maintain at least one secondary capacity arrangement for cost-sensitive or elastic workloads. The enterprises that treat capacity as a variable asset, rather than a fixed infrastructure decision will be better positioned as this market continues to expand and formalize.

The cloud market is no longer a simple fork between public and private. A defined middle ground of negotiated bulk capacity is now attracting billions in investment and reshaping how AI infrastructure costs are allocated. Enterprises that understand this landscape and build flexible, portable architectures that can span it will capture more value from AI investments than those who default to the familiar hyperscaler menu alone.

When I talk to people about agents interacting with websites, the conversation almost always starts with perception: how does an agent “see” a page? Is it screenshots or the DOM or the accessibility tree? In my previous InfoWorld article, “Accessibility is the first-class interface for AI agents”, I argued that the accessibility tree is becoming an increasingly important interface between websites and AI agents. From there the conversation shifts to actuation, and to ways of making it less brittle, which let a site expose its own actions as callable tools instead of forcing an agent to guess at buttons and forms.

That conversation matters. But it leaves out a more consequential architectural question, one that determines who is accountable when an agent gets something wrong: where does the agent live?

There are three plausible homes for an agent that interacts with your business: on-site, in-browser and off-browser. Each one trades control for reach differently. Right now, much of the industry’s attention is focused on the two homes furthest from the business: browser extensions that co-browse alongside a user, and autonomous agents running in the cloud that talk to your APIs or drive a browser on their own.

I think that is the wrong place for most enterprises to start.

If you run a business with real compliance exposure, or a brand you cannot afford to have misrepresented, the pragmatic move is to build the agent that lives on your own site first and treat reach as a problem you solve later, on your own terms.

Reach without governance is a liability

The appeal of in-browser and off-browser agents is obvious. They promise discovery, scale and automation you do not have to build or maintain yourself. An off-browser agent can compare your prices against every competitor and keep working after your support team has gone home. A co-browsing extension can act inside a user’s already authenticated session without requiring any special integration on your side.

But an agent you do not control is still speaking for your business.

An off-browser agent talking to your APIs or scraping your DOM runs on a model you did not choose, follows guardrails you did not write and represents your brand in a conversation you cannot see. If it misquotes a price, misstates a policy or initiates a transaction that creates a customer dispute, the fact that the agent belonged to somebody else may not make the resulting problem disappear.

There is also a deeper security problem. Computer-use agents interact with untrusted content by design. Anthropic’s guidance for browser and computer-use agents notes that webpages and application interfaces can contain adversarial instructions and recommends scoped permissions, human confirmation for high-stakes actions, and monitoring of agent behavior. OWASP’s AI Agent Security Cheat Sheet goes further, identifying agent-specific risks including prompt injection, tool abuse and privilege escalation, data exfiltration and memory poisoning.

In-browser agents are a better deal, because a human is watching the same screen and can catch a mistake before it lands. But the model, the tone and the decision logic are still outside your hands. For  or any other regulated industry, that is not a risk to take lightly just to pursue reach you have not yet learned how to govern.

What you actually gain by building at home

An on-site agent is less glamorous than the idea of your product being discovered by roaming agents across the open web. But it is the only home where the business keeps full governance.

You choose the model. You define the guardrails. You decide the tone, the escalation paths and exactly what the agent is and is not allowed to promise a customer. Because the agent has direct access to your systems, it does not need to reverse-engineer your checkout flow as an outside agent would. It can be given your actual domain knowledge and your actual APIs.

That matters because enterprises have solved this problem before. They did not expose databases directly to the internet; they introduced APIs. APIs were not just about integration. They created contracts, authentication, auditing and policy enforcement. On-site agents represent a similar evolution. Rather than forcing an external agent to infer behavior from a user interface, a business can expose governed capabilities through tools with explicit contracts.

WebMCP is a promising step in that direction. It makes it easier for a site to publish actions an agent can invoke, instead of forcing the agent to guess at the page. The important shift is not that the agent can click a button. It is that every action becomes observable, policy-governed and replayable.

The Chrome team’s WebMCP Sports demo is a good preview of what this can look like done well: an on-site assistant calling the site’s own WebMCP tools, with every call visible in the chat log. That is not a black box you are hoping behaves. It is an auditable interaction, with named tools and defined contracts.

The three homes

The cleanest way to think about this is as a spectrum.

• On-site. The agent lives on your website. You ship it. You own the model, the tools, the tone, the policies and the telemetry. It has first-party access to your systems and your workflows. The trade-off is reach: it is coupled to your site, and it is not meant to carry the user’s journey across the web.
• In-browser. The agent lives inside the user’s browser session, usually as a co-browsing extension or a browser-integrated assistant. It benefits from the user’s logged-in state and can act with the user present. That gives it real reach and a strong human safety net. But the business does not control the model or the guardrails, and the agent can still misrepresent the brand.
• Off-browser. The agent runs elsewhere — in the cloud, on a server or on a user’s local machine and reaches your business by talking to APIs or driving a browser remotely. This is the widest-reach model, but also the least governed from the business’s point of view. It may compare competitors, cross workflows and act at scale, but you do not control the experience.

None of these homes is inherently bad. They solve different problems. But if your first priority is governance, accountability and brand integrity, on-site is the right starting point.

Start with the governed interface

For teams deciding where to put their first investment, three moves make the difference between a real interface and a chatbot glued to a homepage.

First, ship the on-site agent as the authoritative interface, not a fallback. It should have first-class access to your own APIs and domain knowledge — the same systems your support team and checkout flow already use — rather than being handed a scraped version of your own page.

Second, instrument every tool call it makes. If your agent calls a WebMCP tool to check inventory or apply a discount, log it the way you would log an API call from any other client. That log is your audit trail, your debugging tool and eventually your evidence when a regulator or customer asks what happened.

Third, design for human escalation from day one. Even a well-governed agent should not make every decision autonomously. Build explicit handoff paths to human operators for ambiguous or high-risk situations.

Taken together, those choices turn an on-site agent into a governed interface rather than a novelty feature. That distinction matters. The first is something an enterprise can safely operate; the second is something it will eventually have to defend.

When agents start talking to agents

There is another reason to build the on-site agent first: the three homes are unlikely to remain isolated.

Imagine that a user’s browser agent arrives at an airline website. It already knows the traveler’s preferences, calendar constraints, loyalty programs and perhaps their budget. The airline’s on-site agent knows something completely different: routes, seat availability, fare rules, upgrade eligibility and the airline’s operational policies.

Why should the visiting agent reverse-engineer all of that from a website?

A more natural architecture may be for the two agents to communicate.

This is no longer purely hypothetical. The Agent2Agent (A2A) protocol is explicitly designed to allow independent agents built by different vendors and frameworks to discover capabilities, exchange information, delegate work and coordinate tasks.

In that world, the user’s agent brings intent and user context. The site’s agent brings domain knowledge and governed execution.

And suddenly the on-site agent’s limited reach does not look quite so limiting. It does not need to travel across the web if other agents can come to it.

The incentive problem nobody is pricing in yet

There is a harder question underneath the technical one: who does the on-site agent actually work for?

A visiting agent, co-browsing or otherwise, is acting on the user’s behalf. An on-site agent, however well-built, is the business’s employee. And the moment the two negotiate a discount, an upgrade or a substitution, that exchange stops looking like a neutral handoff and starts looking like a sales conversation with an AI on each side of the table.

That tension is going to matter.

Businesses building on-site agents now should design their guardrails with that scrutiny in mind, rather than treating “the agent decided” as a shield. Control is worth having. It is also a responsibility. And building the agent that answers to you is the only way to exercise it.

The first agent should be the one you can govern

The history of enterprise software suggests a familiar pattern. Organizations adopt new interaction models by first bringing them under their own governance. Internal systems become APIs. APIs become platforms. Platforms become ecosystems.

AI agents will likely follow the same path.

That is why I think the first agent your business builds should not be the one that can reach the entire web. It should be the one whose behavior you can understand, measure and improve. Once that foundation exists, expanding outward becomes an architectural choice instead of a leap of faith.

Reach is tempting. But for regulated and brand-sensitive businesses, control has to come first.

Every AI feature you’re building is based on a price that isn’t real. Current AI services are heavily subsidized as model providers seek to expand their market share, and subsidies inevitably end. Just think back to the early days of Lyft and Uber, when a single ride often cost less than taking public transit. As the costs associated with building on cheap AI infrastructure slowly start to reflect reality, the architecture decisions you made to get to market quickly may be the ones hemming you in.

This isn’t unique to AI. IT leaders have always had to weigh speed-to-value against the cost of dependency. What’s different now is how fast those dependencies are being built, and how little visibility most teams have into them.

Across IT, scalability is contingent on portability. And architecting with portability in mind is the best way to minimize lock-in as AI pricing models evolve, giving you leverage in future contract negotiations, and a fighting chance of switching platforms if the costs of one vendor get too high.

The challenge is that AI providers are incentivized to make leaving as painful as possible, which they achieve through deep integrations and proprietary features. You can control some of this through architectural decisions. Other parts are structural dependencies you should at least be aware of going in.

Swapping platforms will never be painless, but it’s less painful than being locked in when your vendor decides it’s time to recoup its losses, as every AI provider eventually will.

The part you control

The foundation for portability is the abstraction layer, an internal service your applications call instead of hitting Claude, GPT, or Gemini directly. It uses a request format defined by you, and translates that to whatever the vendor behind it expects. If you need to change vendors later, it’s closer to a configuration change than a code rewrite.

You don’t need to build this from scratch; open-source gateways like LiteLLM or Portkey already handle the routing and interface. Scoped to what you actually need, it’s a small project that one or two engineers can complete in a few weeks.

From there, audit the parts of your codebase that call a vendor’s API directly and route them through your proxy layer one at a time (have fun with that). Skip the features you’re not using yet, like fine-tuning or batch APIs, and focus on the 80% case. Think: text in, text out, and maybe tool calls.

The parts you don’t control

The API call is the easy part to abstract. Other dependencies may be tougher to account for given the pressure to deploy quickly, but you should at least be aware of them.

Prompts get tuned to a specific model’s characteristics, and those instructions won’t necessarily make sense to another model. If you do switch vendors, expect to re-tune each prompt. Fine-tuning a model will box you in, unless you use an open-weight model that you operate internally.

Vectors generated by one provider’s model won’t be compatible with another’s, so switching means re-embedding your knowledge base. Tool calling and structured output conventions differ by vendor, so code written around one model’s schema will need rewriting for another. Caching and batching mechanics carry their own vendor-specific rules and cost implications that don’t map across providers.

In short, code portability is cheap. Behavioral portability is the real cost, and no gateway tool solves that for you.

Build with your eyes open

Most teams don’t realize how locked into a model they’re becoming until they’re forced to move, which is the worst time to find out. How many parts of your codebase import a vendor SDK directly, versus calling a shared internal function?

If you want a real answer instead of a guess, pick one workflow that isn’t business-critical and try porting it to a different vendor. See what breaks and how long it takes to fix. That will uncover your dependencies better than a checklist.

The bottom line is that you should treat AI providers like any other infrastructure vendor where concentration risk matters. Hold AI providers to the same standard you would apply to any IT or technology vendor. There will likely always be some level of dependency, but you should know where the hooks are and choose them deliberately. That way, you’re prepared when AI price hikes inevitably arrive.

—

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.

Frontend teams have become pretty good at monitoring what happens after an application reaches production. We track JavaScript errors, API failures, latency and Core Web Vitals. When something changes after a release, these signals help us determine whether the application is healthy.

But there is one gap I think frontend teams often overlook. An application can look completely healthy in those dashboards while an important workflow is unusable for someone navigating with a keyboard or assistive technology.

Imagine a checkout flow where a recent UI change makes the final button unreachable by keyboard. The page still loads. The API responds successfully. There are no new JavaScript exceptions, and performance metrics look normal. Every traditional signal says the application is working, yet some users can no longer complete the purchase.

That is why I have started thinking about accessibility as more than a compliance or pre-release testing concern. If an accessibility regression prevents someone from completing a critical workflow, that is also a production reliability problem.

Where traditional frontend observability falls short

Most frontend observability focuses on technical health. We want to know whether pages load quickly, requests succeed and deployments introduce errors. These are useful signals, but they mainly tell us whether the software is functioning as the system expects.

Accessibility failures are different because they often do not produce obvious technical errors. Removing an accessible name from an icon button will not necessarily throw a JavaScript exception. Replacing a semantic button with a clickable div might leave mouse interaction working normally. A focus-management regression inside a modal can make the interface extremely difficult to navigate while having no effect on page performance.

This creates a blind spot. Our monitoring can tell us that the button rendered and that clicking it successfully triggered an API request. It may not tell us that a keyboard user cannot reach that same button.

Automated accessibility checks in CI are an important first line of defense, and I use them as an early guardrail. But I would not treat a passing CI check as proof that the production experience is accessible. Production applications contain changing data, feature flags, third-party scripts and combinations of components that may not be represented in isolated tests.

Automated tools also have limits. They can identify many structural problems, but they cannot detect every accessibility or WCAG conformance failure. CI should therefore be an important checkpoint, not the end of accessibility verification.

Monitor accessible journeys, not just healthy pages

One way I think frontend teams can close this gap is by applying the same idea behind synthetic monitoring to accessibility.

Instead of checking only whether a page loads, we can test whether important user journeys remain usable. Can someone navigate the primary controls using only a keyboard? When a dialog opens, does focus move somewhere sensible? Can a form be completed without relying on a mouse? Do important controls still expose useful names and roles?

Consider the checkout example again. Traditional synthetic monitoring might verify that the page loads, products appear and the checkout API responds. An accessibility-aware journey could go further by navigating through the same flow with keyboard interactions and verifying that focus reaches the controls required to complete the purchase.

I would not try to automate every accessibility requirement this way. The goal is to identify a small number of critical workflows and ask a simple question: Can a user still complete the task?

For applications with a design system, I would extend the same thinking to shared components. A regression in a button, dialog, form field or navigation component can spread across many screens at once. Testing keyboard behavior, semantics, accessible names and focus expectations at the component level can catch problems closer to their source instead of discovering the same regression page by page.

This creates two useful layers of protection. Design-system checks help protect the building blocks, while synthetic journeys help verify that those building blocks still work together in real application flows.

Make accessibility part of release health

Frontend teams already look at signals after deployment to decide whether a release is healthy. We watch error rates, latency, failed requests and performance changes. I think accessibility signals can become part of that same conversation.

That does not mean creating another huge dashboard or turning every automated accessibility warning into a production incident. The useful approach is to focus on impact.

If a release introduces a minor issue in secondary content, the team may address it through the normal development process. If the same release prevents keyboard users from completing checkout, submitting a form or navigating a primary workflow, that deserves a different level of attention.

This is where accessibility-aware release health becomes valuable. Teams can define a small set of expectations around critical journeys and shared components, then watch for regressions just as they would watch other frontend reliability signals.

The need for this approach is becoming harder to ignore. The 2026 WebAIM Million analysis found an average of 56.1 detected accessibility errors per home page, a 10.1% increase from 2025. It also found that the average home page contained 1,437 elements, a 22.5% increase in a single year. As interfaces become larger and more dynamic, relying only on occasional accessibility audits becomes increasingly difficult to scale.

If users can’t complete the workflow, the system isn’t healthy

Frontend observability has given us increasingly sophisticated ways to understand what applications are doing in production. But our definition of application health should not stop at whether JavaScript executed, APIs responded or pages rendered quickly.

A system can pass every one of those checks and still fail the person trying to use it.

Accessibility testing during development remains essential, but production-oriented signals can help close the gap. Synthetic user journeys can tell us whether critical interactions still work. Design-system regression tests can protect shared components. Accessibility-aware release checks can help teams recognize when a deployment has affected a critical workflow.

For me, the principle is simple. If users cannot complete an important task because of an accessibility regression, I do not think we should describe the application as healthy just because the traditional dashboards are green.

That is not only an accessibility problem. It is a frontend reliability failure.

Databricks on Wednesday introduced Adaptive Instructed-Retriever, a new retrieval model designed to improve enterprise AI search by taking additional steps for complex queries while stopping early on simpler ones in order to help its customers balance answer quality, latency, and cost.

The new model builds on research behind Databricks’ earlier Instructed-Retriever-1 but takes a different approach to handling complex queries.

While Instructed-Retriever-1 uses parallel, single-step search and incorporates enterprise data schemas and custom instructions to improve retrieval, Adaptive Instructed-Retriever can combine parallel retrieval with sequential, multi-step search when additional evidence gathering is needed.

That distinction matters because applying multi-step search to every query can increase latency and the computational resources required for retrieval, while limiting every query to a single search step can hurt results for complex, multi-hop questions.

Adaptive Instructed-Retriever, the company said, is designed to take additional steps only when they are likely to improve retrieval quality, allowing it to return earlier on simpler requests.

To achieve that capability, Databricks trained the model using synthetic enterprise retrieval environments and an agentic data synthesis process, reusing training data from Instructed-Retriever-1 while adding synthetic multi-hop questions designed to benefit from multiple search steps.

It then used online reinforcement learning to train the model to weigh the potential improvement in retrieval quality against the cost of additional search steps, rewarding high-performing search trajectories while penalizing steps that did not produce corresponding gains.

That training approach, the company said, can produce multiple versions, or checkpoints, of the model with different quality-latency trade-offs, allowing one trained with a lower penalty for additional search steps to spend more time improving results and another with a higher penalty to limit search steps and reduce latency.

For customer enterprises deploying the model in production, these versions or checkpoints would allow retrieval performance to be matched more closely to the requirements of different applications rather than applying the same search strategy across all workloads, it added.

Adaptive retrieval could help control AI search costs

That flexibility could become increasingly valuable as enterprises move AI agents and other applications into production, where improving answer quality often requires additional inference, compute and retrieval resources that can raise the cost of running them at scale, analysts say.

“Repeated searches can improve answers to complex questions but add latency and compute costs, while a single search can be faster and cheaper but fall short on harder queries. The ability to determine when additional search is worthwhile could therefore help enterprises avoid spending resources without improving answer quality,” said Ashish Chaturvedi, executive research leader at HFS Research.

For CIOs, that ability to limit unnecessary search could eventually offer greater predictability over compute consumption and costs.

“The problem with agentic AI at scale is that consumption is hard to forecast, agents searching and re-searching create compounding, unpredictable cost and latency, and finance teams hate these variable bills. Knowing your agents will search within a defined ceiling, and that you can set that ceiling per workload, is what makes agentic search safe to run at scale rather than a runaway meter,” Chaturvedi noted.

The economics could become even more compelling, Chaturvedi added, if the specialized model can deliver the claimed retrieval quality of larger general-purpose models with lower latency.

Adaptive Instructed-Retriever, according to Databricks, matched or exceeded the retrieval quality of Claude Sonnet 5, GPT-5.6 Luna and DeepSeek-V4-Flash in its internal evaluations while completing requests in 5.8 seconds, or more than twice as fast as those models.

That difference could matter economically because retrieval is a high-frequency operation for data agents, Chaturvedi said, potentially allowing enterprises to avoid applying the cost and latency of larger models to every retrieval request.

Developers could shed some retrieval orchestration

There are advantages for developers too, especially in terms of reducing orchestration-level work.

Traditionally, developers handling complex, multi-hop questions often have to design the control flow for multiple search rounds themselves, including deciding when to refine a query, search again, or stop, but Adaptive Instructed-Retriever’s learned search policy shifts those decisions into the model, potentially reducing the amount of bespoke retrieval orchestration developers need to build and maintain, Chaturvedi said.

That, in turn, could make sophisticated retrieval capabilities more accessible to teams that lack the resources, expertise, and time to build a search agent from scratch, echoed Stephanie Walter, practice leader of AI stack at HyperFRAME Research.

More flexibility brings new trade-offs

However, there are trade-offs that developers should consider, analysts pointed out.

While the model’s checkpoints can help prevent individual queries from consuming an unpredictable amount of compute, teams will still need to test and monitor different settings to determine which one of these delivers the best balance of cost, latency and retrieval quality for each application or use case, Walter said.

That, in turn, adds another layer of performance and cost optimizations developers need to manage, Chaturvedi echoed.

More so because being able to choose the right model checkpoint means working through real business questions and documenting where answers are coming from in your database or other knowledge bases, said Mike Leone, principal analyst at Moor Strategy and Insights.

“Very few enterprise development teams have built such a curated list. In practice, that means most teams are likely to simply select a setting once and leave it unchanged,” Leone added.

Even with the right checkpoint in place, however, Adaptive Instructed-Retriever does not address every challenge that can affect retrieval quality. Teams would still need to prepare and organize their data, enforce permissions, evaluate retrieval quality, and verify final answers, Walter said.

Echoing Walter, Leone added that a smarter search policy cannot compensate for poorly structured underlying data or a lack of agreement over what key terms mean, meaning it could still retrieve the wrong answer even if it does so more efficiently.

There are also caveats that CIOs should take note of.

Adaptive Instructed-Retriever’s performance and quality claims, Chaturvedi said, are based on Databricks’ own benchmarks against competitors selected by itself, meaning that these claims will need to be tested against an enterprise’s actual workloads rather than accepted at face value.

Even if those results hold up, however, CIOs will still need to decide whether the potential gains in retrieval performance, latency, and cost justify adding a specialized model to their AI stack.

Rather, using a larger general-purpose model for both retrieval and reasoning could offer a simpler alternative by reducing the number of models enterprises need to deploy and manage, Chaturvedi said. The economic case for Adaptive Instructed-Retriever for CIOs, therefore, will depend on whether its claimed performance holds up on real enterprise workloads and whether the potential savings outweigh the additional complexity of using a specialized model, Chaturvedi added.

We spent the last decade building entire finops departments just to decipher what the cloud bill was saying. Just when we figured out how to stop leaving idle compute instances running, generative AI introduced an infinitely more opaque, faster-moving layer of spend.

AI bill shock has spread like a slow moving hurricane across the industry. Aside from the spike in large language model (LLM) costs, the deeper architectural problem is attribution: where exactly is the money going, and exactly what value is it delivering to the business?

When API calls are wrapped in layers of automated agents and prompt templates, your application becomes a black box that consumes capital to spawn tokens. If a features engine is burning thousands of dollars a month just to have an LLM output pleasantries or process low-value data, that isn’t innovation, it’s an uncovered manhole, a gaping liability. Architectural maturity means treating tokens like any other constrained resource.

Fortunately, there are a few good levers we can pull to control AI spend. Here are the five key tools for taming the beast.

Model routing

Don’t use a nail gun if a thumbtack will suffice.

The most powerful models like the latest Claude Opus are some of the most sophisticated software systems ever built. They are capable of handling extremely complex and subtle use cases. They are also voracious beasts when it comes to compute (and therefore dollar) consumption. They are often overkill.

We naturally start with the most powerful model we have when prototyping and sketching out APIs and requirements. That’s because we are in the “get it working” mode and we don’t want to be tangling with model limitations. But for production, it is absolutely essential to dial in on what is the least powerful model we can use.

Sometimes we can address this by tuning the model choice and discovering what will work manually. But in larger enterprise architectures, we can move to a conditional routing layer. Frameworks like RouteLLM or Semantic Router can dynamically direct simple classification, basic text parsing, and user intent detection to fast and cheap utility models like GPT-4o mini or Claude 3 Haiku.

You can also use advanced AI gateways for routing and spend allocation. At the infrastructure level, wrapping this logic in a dedicated AI API gateway (such as Kong, Cloudflare AI Gateway, or Portkey) gives you the ultimate control. A mature gateway allows you to implement “cascade routing” to automatically fall back to a cheaper or open-source model if your primary LLM hits rate limits or latency spikes. More importantly, an AI API gateway centralizes your telemetry, stripping away the black box so you can enforce hard token budgets per tenant or per microservice. You are essentially building a load balancer for cognitive tasks.

Of course, AI gateways also introduce complexity and cost themselves, so these factors must be balanced into the equation. But the bottom line is, there is a right-sized model for your project. You can save a bundle by routing requests to a good-enough, Goldilocks model.

A side note: Another trend in model routing is “repatriation of compute.” That entails running models (often open-source models) on local hardware, instead of renting generative AI endpoints on the cloud.  This implies all the trade-offs and benefits of other on-prem options.

Semantic caching

In conventional web apps, caching is a solved problem. You put Redis in front of your database, map an exact query to a cached payload, and you’re done. But LLMs break traditional caching because human language is infinitely variable. “How do I reset my password?” and “I forgot my login info” are entirely different strings, but communicate identical intents.

If you rely on overly precise matching, your hit rate will be effectively zero, and you will pay the full token price for every phrasing permutation.

Enter semantic caching. It’s like regex for meaning. Instead of hashing the raw text string, you run the incoming prompt through a fast embedding model and do a similarity search against previously answered prompts. You define a confidence threshold (say, 0.92), and if it is met, you serve the cached response (bypassing the LLM and its cost entirely).

The architectural effect is twofold. First, a semantic cache hit reduces your inference cost for that query to exactly zero. Second, it drops response latency from seconds to milliseconds. You can implement this using purpose-built frameworks like GPTCache, or, if you prefer a leaner infrastructure, by using pgvector inside your existing PostgreSQL database to store and match the embeddings.

However, just like dynamic routing, semantic caching demands a rigorous architectural calculus. You are trading generation costs for embeddings and lookup costs. To check the cache, you still have to tokenize the prompt, call a cheap model (like text-embedding-3-small), and execute a vector search.

You also introduce the very real danger of semantic flattening. Tuning the similarity threshold is a delicate art. Set it too low, and your application starts serving general, recycled answers to nuanced user questions. For open-ended, creative, generative AI applications, semantic caching is practically useless. But for retrieval-augmented generation (RAG) implementations, customer support bots, and internal knowledge bases where users ask the same 20 questions a thousand different ways, it is the most effective cost-reduction lever you can pull.

Prompt caching

Whereas semantic caching stores the response to a given intent, prompt caching stores the data needed to contextualize the question. When the user enters a prompt, it is sent to the generative AI endpoint. But instead of your application having to repeatedly gather and send the massive contextual info needed to frame the prompt—from a RAG pipeline, a database, or other source—that information is already pre-loaded in the context cache. The model simply applies the new question to the cached data, slashing both your latency and your input costs.

The core idea behind prompt caching is that the AI engine itself retains the relevant contextual data for incoming prompts. Tokens cached this way get a massive discount (50% to 90%) compared to raw input tokens. But the details of how it is handled vary between providers.

For OpenAI, prompt caching is automatic, but requires attention to how your app uses the endpoints in order to leverage them. OpenAI enforces a 1,024-token minimum threshold. More importantly, it requires an exact, byte-for-byte prefix match starting from token zero. If you inject a dynamic variable (like a timestamp or a user ID) at the very top of your system instructions, you instantly invalidate the cache and pay full price for every token that follows.

Some other providers, like Anthropic Claude and Google Gemini, use explicit caching. You must deliberately engineer the cache into your architecture, either by hitting a dedicated API endpoint to upload the static document (the context data) with a defined time to live, or by injecting strict cache control breakpoints into your JSON payload. Explicit caching often requires paying a “write premium” up front, but it gives you the control to guarantee your heavy RAG data stays alive in memory for hours rather than minutes.

Prompt discipline

Just because a model can consume gargantuan amounts of tokens, doesn’t mean it should.

With models now capable of ingesting one million to two million tokens in a single prompt, there is a temptation to brute-force use cases into submission by dumping the entire PDF, the entire codebase, or the last three years of logs into the payload and let the LLM sort it out.

This is a finops blunder. You are paying for every single token you send. Furthermore, from an engineering standpoint, stuffing the context window runs into the very real “muddy middle” problem (aka “context rot”), where the model loses resolution into the middle of the content. As the payload grows, performance and accuracy suffer.

The cure is a strict RAG diet. Naive RAG implementations might pull the top 20 results from a vector database and blindly concatenate them into the prompt. Architectural maturity requires a more ruthless filtering process before those tokens ever reach the expensive LLM.

This is where reranking becomes key. Reranking takes the compiled prompt context and makes sure it is efficiently structured before it hits the LLM. Instead of sending raw search results directly to your primary model, you introduce a tiny, highly-efficient cross-encoder (like Cohere Rerank or an open-source BGE model). You cast a wide net in your cheap vector database to fetch 50 potential matches, then pass them to the reranker to score their actual relevance against the user’s specific prompt. The reranker ruthlessly trims the fat, allowing you to pass only the top three or four hyper-relevant chunks to the expensive frontier model.

You are trading a massive, expensive LLM context payload for a tiny, cheap reranking step. The architectural math here is almost always a resounding win. While a cross-encoder might add 100 milliseconds of latency to the pipeline, it routinely slashes prompt token counts by 80% or more, while simultaneously increasing the accuracy of the final generation. In the generative AI spend playbook, giving your LLM less to read is one of the highest-leverage moves you can make.

Response constraints

By default, LLMs are polite, conversational, and verbose. If you ask an API for data, it desperately wants to start with “Certainly! Here is the JSON you requested,” and end with “Please let me know if you need anything else!”

In a web interface, this is charming. In an application’s API architecture, it is a leak in the finops hull. Generation tokens (output) are almost universally priced 3x to 5x higher than prompt tokens (input). Every pleasantry is burning your most expensive commodity.

Taming LLM responses requires strict API-level enforcement. First, max_tokens must be treated as a hard circuit breaker to prevent runaway generation loops, not as a formatting tool. (Relying on max_tokens to shorten answers often just results in truncated, unparseable JSON.) Second, use stop sequences (stop_words). If your model only needs to output a SQL query, setting a stop sequence for the markdown closing tag (“`) or the word “Explanation:” forces the model to sever the connection the moment the computational work is done.

Modern APIs also offer structured outputs (or strict JSON mode), which forces the model to adhere to a rigid schema you define. By combining this with zero-tolerance system prompts (“Output ONLY valid JSON. Omit all conversational text and pleasantries. Failure to do so will break the system”) you force the LLM to behave like a traditional API endpoint rather than a chatbot.

The architectural balance here is to avoid degrading the model’s reasoning ability by strictly limiting its input. LLMs do not have internal working memory, they “think” by iterating on token output. If you force a model to solve a complex logic problem and output a single boolean true or false without giving it space to reason first, its accuracy will plummet. The finops goal isn’t really to force minimal words; it is to ensure that every expensive output token is performing actual computational work (like chain of thought reasoning).

For more on how to manage AI back ends, take a look at this article.

How to effectively consume generative AI to satisfy user needs is the first battle. The second is keeping the finances from undermining that hard work. The five keys discussed here should give you all the power you need to make sure the engineering and the cost controls are working together.

I guess I’m a Go developer now.

My first programming language was BASIC. My seventh-grade math teacher, Mr. Schulte, taught BASIC to us on Fridays. He gave us programming assignments for homework during the week. Some of us loved it so much we stayed after school to play games and create extra programs, including our own crude, text-based adventure games. I remember hearing a story about a crazy new language called Pascal that didn’t have line numbers. How in the world would that work?

Years later I became a Pascal programmer — an ardent one. So ardent, in fact, that I would argue for hours with Visual Basic developers on CompuServe, AOL, and Usenet, telling them how Turbo Pascal, and then Delphi, was clearly a superior language. I was completely self-taught — if you count all the help that others gave me as teaching myself. I wrote shareware, became pretty competent, and eventually started helping others. 

People would tell me I should branch out and learn other languages — C++ or C#. But I wanted to be a master of one instead of a jack of all trades. Besides, we were all Windows developers and there was no better tool for writing Windows applications than Delphi. It became a point of pride for me, and I would stick up for Delphi and its company Borland no matter what. It got so bad that my friends would tease me, calling me “Baghdad Nick” after the famously optimistic Iraqi foreign minister during the Iraq War. 

Delphi by day

Looking back, I was foolish. I did become a pretty good Object Pascal programmer, but I would have benefited from learning JavaScript or a functional language. I did eventually learn TypeScript and a bit of C#. (I guess I was following Anders Hejlsberg around…) 

But if you were to ask me to this day what kind of code I write, I’d say I’m a Delphi developer. Indeed, that is my day job. I understand Delphi deeply, knowing all the nuances and insider tricks to making the language my own.

But over the course of a day or two, I’m now a Go developer, too. 

If coding all day isn’t enough, I have taken on a side project for a friend. I’ve been writing Delphi code for him for a while, but now he wants to shift gears. He has asked me to build a cross-platform application for his company written in Go and Wails Version 3. Now, I’m no Go expert. In fact, I only have a passing familiarity with the language. I can decipher what is going on, but I’m far from understanding the intricacies of what makes Go tick.

But that doesn’t really matter anymore, does it?

Claude bootcamp

I asked Claude to give me a tutorial on Go and Wails. It did a great job, quickly bringing me up to speed on the basics. (How cool is it that you can so easily turn a struct into a JSON object?) I described what I wanted, and asked for recommendations for libraries. The project uses Go for the “back end” and React on the “front end.” (I use the quotes because those “ends” are actually all built into a single binary.) 

In about an hour I came to understand the architecture and got a basic application up and running. I told Claude what I wanted, and it obliged. I described the basic data structures and objects needed, and Claude wrote them quite elegantly. I didn’t actually write a line of code, but there the project was, in all its glory. Go, TypeScript, and HTML. 

Claude managed the Git repository and even created a nice little CI/CD pipeline for me, building binaries for Mac, Linux, and Windows, all in one step.   

I went from being basically ignorant of the Go language to having a moderately sophisticated application in a day.

The thing is, I’m still not that good at Go. Not that good at all. But I’m a Go programmer nonetheless. Maybe next weekend I’ll become a Python programmer.

Nvidia CEO Jensen Huang argues it’s the “most illogical thing in the world” to believe AI will kill SaaS, and says the markets “got it wrong” in sending SaaS stocks tumbling. Why “illogical”? Because, as analyst Benedict Evans stresses, the fact that everyone can now easily spin up code actually doesn’t solve any SaaS problems, because creating code and tools is the easy part: “The hard part is knowing that you need a tool for this in the first place and then knowing what the tool should do.”

If that’s true, then what Shopify is doing with Sidekick is potentially revolutionary by embracing and extending the traditional SaaS model.

In December, Shopify introduced custom app generation through Sidekick. A merchant (Shopify customer) describes a tool, and Sidekick writes the code, using Shopify’s interface components and connecting to its Admin API. It’s a cool option and has been very popular. Shopify says merchants created almost 4,000 custom apps in the first three weeks following the release.

This isn’t surprising: Shopify is delivering the customization customers have long wanted from enterprise SaaS while ensuring they still enjoy the comfort of ongoing support and platform stability.

I suspect we’ll see more enterprise SaaS like this, despite silly predictions that AI would kill SaaS. Cheaper code gives customers a way to fix the things they dislike about an application without replacing everything they do like. For a vendor willing to accommodate that, AI could make its product considerably more useful and, hence, much “stickier.”

The feature that never ships

Cloudflare’s Jeremy Morrell discusses this in an excellent essay on extensible software. “In the past year, your users have suddenly acquired the ability to speak code into existence,” he writes, allowing for “markets of one.” His argument is that software should let customers put that ability to work, building additions around an established core.

Morrell has a commercial interest here, which he discloses: He works at Cloudflare and thinks its infrastructure is well suited to running those additions. He’s not wrong. But it’s the general opportunity to match customizability with stability that matters so much.

There are really (really) good reasons why vendors haven’t allowed customizability of their core products. Enterprise software companies limit deep customization to prevent high maintenance costs, security risks, and broken system updates. Oh, and to prevent their products from becoming convoluted bloatware. No matter how much you may want feature X, that feature would likely be irrelevant to almost everyone else, so adding it would complicate the product for the majority. No one wants that.

Customers have long paid consultants to customize software or they’ve hired developers to do it themselves (all while taking care not to violate their vendor licenses). Morrell points to Salesforce, which has spent years letting businesses build their own logic into its platform. In other words, AI didn’t invent extensibility. No, AI just makes it incredibly cheap. There’s a meaningful opportunity here for customers who can describe the change they need but have never been able to get it built. Some will save money on software or customizations they previously bought, while others will finally get software that nobody could profitably sell them.

Following the money

This change, however welcome for enterprises, won’t be comfortable for developers selling a narrow reporting tool or a small workflow improvement. Their customers may decide that an LLM-generated extension is good enough. An AI-built customization needn’t match every feature of the commercial product. It only has to do the job that the customer was paying for.

The platform underneath that extension has a different calculation. Every useful tool built against its data and APIs gives the customer another reason to stay. AI can make an individual feature less valuable to sell while making the product that hosts it more valuable to own. (Yet another reason to tsk-tsk foolish eulogies for SaaS companies.)

Ultimately, this should benefit anyone who both knows the business and can build more efficiently for that business. Benedict Evans makes this point in his newsletter, arguing that cheaper coding doesn’t solve the problem of discovering what software ought to do or persuading an organization to use it. A useful idea that spans several departments still needs those departments to agree. Even excellent code can’t sign off on a new way of running accounts payable.

Evans also describes how improvised tools eventually become important enough to need formal ownership and support. Anyone betting that companies will happily maintain everything they can generate should spend some time with the person who inherited the last departmental spreadsheet. Silicon Valley folks with little knowledge of real-world enterprises might think enterprises will vibe code all their software now, but they won’t. That’s not how software works because it’s not how people work.

This cuts both ways for established software vendors. Customers may continue to need their expertise while becoming less willing to accept a product’s limitations. A vendor that makes customization easy can benefit from that impatience, while one that blocks it has given the customer a new reason to investigate alternatives. The difficult decisions will come when customization interferes with what the vendor already sells.

I wrote in 2022 about Microsoft’s complicated relationship with open source, and how a company’s broad commitment to openness can collide with a division’s revenue targets. The same tension applies here. A CEO can be excited about letting customers build anything. The executive responsible for selling the premium reporting package may be less enthusiastic. Resolving that disagreement will determine what customers actually get to build, however capable the AI becomes.

Getting comfortable

Customers have their own calculations to make. An application shaped around the way your company works can be wonderful, but it can also be a pain to leave.

There are limits to what Shopify’s generated apps can do today. They are admin tools, not storefront or checkout extensions. Shopify also tells merchants to test them before installation because they can change customer-facing data. A generated app can be wrong, and running it inside a familiar product doesn’t relieve the merchant of checking its work.

Shopify lets merchants inspect and edit the generated code and restore an earlier version. That’s useful, but code written for Shopify’s Admin API still depends on Shopify. Having the source doesn’t give you another company ready to run it unchanged.

AI might eventually make moving those extensions easier, too. But recreating a screen is one thing; reproducing the behavior it relies on throughout a business is a considerably bigger undertaking. That includes the assumptions about records and transactions that the custom code gets to take for granted while it runs on the original platform.

None of this makes customization a bad deal. Customers can gain more control over their daily work while, somewhat ironically, becoming more dependent on a supplier. For SaaS vendors, that’s a good commercial reason to let customers finish the bits their developers will never get around to building, even when it costs them an add-on sale (and potentially some support headaches, depending on how they’re architected for extensibility). The customer is doing work that makes the underlying product more valuable.

AI, in short, has the potential to make SaaS dramatically more valuable, not extinct.

Cloud computing has always been about survival. When you’re building systems at scale, you need to think about resource planning, capacity, and adaptability when demand spikes. The survivalist mindset in cloud architecture is about building systems that can weather unexpected storms, whether that’s sudden traffic spikes or the need to scale AI inference across a global user base. During the past decade, serverless computing has been the go-to architecture for this kind of resilience, abstracting away the underlying infrastructure so you can focus on the application itself. Now, AI has arrived in that serverless world, and it’s changing how we think about deploying intelligence at scale.

The concept is straightforward enough. Instead of provisioning GPU instances, managing model deployments, and sizing your inference infrastructure, you call an API, send your data, and get back a response. The provider handles the rest; the model runs somewhere in their cloud, scales automatically, and you pay per token or per request. Services like Amazon Bedrock, Azure OpenAI Service, and Google Cloud Vertex AI have made this the norm rather than the exception. You get access to foundation models from Anthropic, OpenAI, Meta, and Google through managed APIs that abstract away everything from hardware selection to auto-scaling logic. It’s elegant in its simplicity, and for many use cases, it’s exactly what you need.

The scalability advantage

The benefits of this approach are substantial, and they’re worth examining carefully. The most obvious is that you don’t have to spend time sizing infrastructure. Sizing AI infrastructure is notoriously difficult. GPU instances are expensive, and getting the right number to handle your peak load without overprovisioning during quiet periods requires expertise most organizations lack. Serverless AI offloads that problem entirely. You describe what you need, the service provisions it behind the scenes, and you are billed for what you use. The system scales up when you need it and scales back down when you don’t. There’s no idle capacity, no waiting for instances to spin up, no late-night calls to your infrastructure team when a model needs to handle a sudden traffic surge.

If done correctly, this can be a godsend for applications that consistently scale up and down. Retail is the canonical example. During the holiday season, a retailer might see AI-powered recommendation engines handle 10 times their normal load. In January, that demand drops dramatically. A serverless approach means you’re not paying for GPU infrastructure sitting idle during the slow months. The same logic applies to seasonal businesses, event-driven applications, or any workload with unpredictable traffic patterns. You get elasticity without complexity.

The hidden costs of pay-per-use

The drawbacks need to be considered as well, and this is where many architects get into trouble. Since you don’t have direct control over scaling and descaling processes and storage resources, the cost is going to go up and down as your infrastructure needs vary. In many cases with highly variable scaling systems, this can be a benefit. We’re not overprovisioning or underprovisioning, and we’re not dealing with the impact of idle services and overpaying for infrastructure that we never use. The bills move with your actual usage, which sounds ideal until you realize that usage-based billing doesn’t always mean lower costs.

If your AI applications use a static number of resources over time, serverless services will typically cost you more. When you’re running inference at a steady rate around the clock, you’re often better off provisioning dedicated infrastructure and negotiating a fixed rate. The per-token pricing that makes serverless attractive for variable workloads becomes a premium you pay for flexibility you don’t actually need. More importantly, you’re never going to really leverage the benefits of serverless technology, because the infrastructure used in these AI processes will be relatively static over long periods. The cold starts, the scaling latency, the lack of control over instance types—none of those downsides are ever offset because you never use the upsides.

Fit architecture to use case

This is a horses-for-courses situation, and you need to think carefully about whether you want to leverage this technology. Even though serverless has been around for quite a long time in the cloud world, I’m not sure most enterprise architects and AI architects fully grasp how to deploy serverless-based AI. The technology is new enough that the patterns are still forming, and cloud providers’ documentation generally emphasizes ease of use without adequately covering scenarios where it falls short. The result is organizations defaulting to serverless AI for every use case, driven by the same “serverless is always better” thinking that plagued early cloud adoption.

Serverless AI is an architectural option like anything else. You need to be very careful with it, matching the right business problems to the technology. Variable, unpredictable workloads with strong seasonal patterns are ideal candidates. Static, steady-state inference workloads are probably not. The decision should be rooted in understanding your traffic patterns, cost constraints, and operational requirements, not from assuming that serverless is inherently better than provisioning your own infrastructure. The survivalist’s thinking applies here as it does everywhere in cloud architecture: The best tool is the one that fits the job, not the one that sounds the most exciting.

A year and a half ago I sat in a conference in Silicon Valley and watched an AI agent write production-quality code in real time. I knew our engineering model was going to change, and within a few weeks my team was past the question of whether to adopt AI. The real debate was how far we were willing to go in redesigning how we build legal software around it.

Since then, output per engineer across our R&D organization has roughly tripled. We ship nearly twice as many releases per quarter, deployments have grown from 82 to more than 155, and customer reported defects are down 65% per million lines of code across the last 18 months. We track all of this with DORA metrics, cycle time, pull requests merged per developer, and lines changed per developer against a fixed baseline, and the improvement holds up on every measure.

Getting there had less to do with the tools than with how the organization works. Every CTO I talk to is running some kind of AI coding pilot and seeing decent results: faster prototyping, better test coverage, quicker first drafts. Almost none of them have changed the development life cycle itself, and that is where the real gains were for us.

We spent the past 18 months rebuilding our product development life cycle around AI. Requirements, development, testing, security, deployment, and governance all changed, some beyond recognition. We got plenty wrong along the way, and a few of the lessons would have saved us months if someone had handed them to me at the start.

The biggest gains came from removing handoffs

We assumed most of the productivity gain would come from AI writing code faster. It didn’t. The biggest gains came from getting rid of the handoffs between stages.

In the old model, a feature passed through at least four handoffs on its way out the door: product to development, development to QA, QA to security, and security to deployment operations. Each of those queues cost us time and context. A feature could be code complete in a day and then sit for two weeks waiting on teams that each had their own backlog and their own priorities.

So, we restructured. A team now carries a feature end to end, and AI agents handle the rote work at each stage. A feature that used to take 15 days to go from spec to a working pull request now takes about four hours.

If you take one thing from this article, measure the total time from idea to deployment rather than lines of code generated, and go find where the work sits idle. That is where the gains are hiding.

Governance accelerated adoption

Most engineering organizations add governance after the innovation has proven itself. We flipped that order. We build software for lawyers, where a wrong answer on high-stakes work can cost a client dearly, so moving fast and cleaning up later was never on the table.

Before we scaled past the first pilot teams, we set standards for code review, security scanning, and quality on anything AI produced. Confidence scoring lets routine approvals pass through automatically while anything below threshold goes to a human. Security and quality gates run inside the pipeline itself rather than as a checkpoint at the end.

What we didn’t expect was how much this sped up adoption. Engineers trusted the system, so nobody had to wonder whether code from an agent would pass review, introduce a vulnerability, or get them blamed when the model got something wrong. Eighteen months ago, about 3% of our pull requests had any AI assistance. Today it’s 68%, every engineer in the organization uses AI, and vulnerability density has fallen 76% over the same period. Governance came first and adoption followed, which is the opposite of the sequence most people assume.

Pick your tools and get good at them

A better model or agent ships almost every week, and early on we burned real energy evaluating them. At some point we stopped and standardized on a small set of coding agents.

Going deep paid off more than staying current. We learned the strengths and failure modes of our coding agents and tuned our workflows around how they actually behave, which matters more than whatever the next release promises. Teams that chase every new model spend all their time evaluating, and every switch resets the muscle memory and the trust they built with the last tool. They end up with a lot of pilots and not much change.

Automate the entire life cycle

The obvious place to point AI coding tools is at the coding. Some of our biggest wins came from the edges of the life cycle.

We built or deployed dedicated agents for every stage: requirements, sprint planning, code generation, test authorship, security scanning, deployment, and site reliability. Each one owns a single job and gets measured on a single outcome. What makes it work is a centralized knowledge repository that product and engineering maintain together, a curated and structured knowledge base with retrieval-augmented generation on top. Every agent pulls product context, domain rules, and prior decisions from that same source of truth, so what comes out of one stage is clean input for the next. Without it we would have a set of fast agents that lose the thread at every handoff.

Requirements definition was the most dramatic early win. It used to take weeks. We built an agent that grills a raw product idea the way a tough stakeholder would, pushing on gaps until the spec is ready for development, and that phase now finishes in an afternoon.

Testing moved even faster as quality engineers shifted their focus to optimizing and improving the agents that build tests. AI now generates 99% of our new tests, up from 47% a year ago, with more than 39,000 AI-developed tests in the suite, a number we could never have staffed our way to. Each test is generated directly against the code change it covers and checked against the functional requirements defined in the product requirements document, so growth in volume doesn’t come at the cost of traceability. Engineers spend their time reviewing, refining, and hardening what the system produces rather than writing first drafts, and that shift, from authoring tests to curating and strengthening them, is a big part of why quality improved while we sped up.

We started with one area of the product development life cycle, got it right, then expanded. I would recommend that sequence to anyone. The key is to develop a model that can be expanded to the rest of the phases after experimenting on what works rather than trying to roll it out to every area and having to rebuild the framework later.  

Design for the velocity you’re about to create

We set a public and very specific goal: double R&D productivity in 12 months. It was uncomfortable, and there were stretches where I wasn’t sure we would make it. But a number that aggressive forced everyone to accept that incremental improvement wasn’t going to get us there, and we had to take apart old ways of working while the technology underneath was still maturing. We hit the goal inside the year, and output has kept climbing ever since.

What I underestimated was how fast the bottleneck would move downstream. Once engineering sped up, the constraint moved to go to market. Every release still needs documentation, enablement content, briefings for customer success, and customers who are ready for what’s coming, and for a while we were shipping faster than any of that could keep up. We now treat go to market as its own automated phase of the life cycle, with the same agent-driven approach we applied to code and testing, and a simple rule that nothing ships until the rest of the organization can support it. If I were starting over, I would build that capacity from day one instead of finding out about it the hard way.

The real transformation is organizational

The tools matter, but everyone can buy the same tools. What we actually did over these 18 months was redesign the system around AI: the way work flows between teams, the governance that lets people trust the output, the small set of tools we committed to, and a target aggressive enough to force all of it. Any one of those alone would have produced another interesting pilot. Together they produced a different engineering organization.

None of this is finished. The models keep improving and the life cycle will keep changing with them. The organizational groundwork is what lets us absorb each improvement as it arrives, and for any technology leader still stuck at the pilot stage, that groundwork is where I would start.

—

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.

For a growing number of organizations, AI has become not only a key component of the software development process, but the centerpiece.

These enterprises have shifted toward an AI-first development strategy, where artificial intelligence is integrated into all phases of the software development life cycle, rather than being a feature to use selectively during the process.

In most cases, this means a move toward agentic workflows, with developers acting as architects responsible for overseeing AI agents. But in a larger sense, AI-first development is a transformation of how developers explore and understand code, with a focus on designing and producing more and more applications with AI in mind.

Why AI-first development?

For what is surely a rising number of software development teams and organizations, the AI-first approach is becoming more necessary than optional.

“AI-first development matters because the alternative is increasingly untenable,” says Mona Rajhans, senior software engineering manager at cybersecurity products provider Palo Alto Networks, who leads a 14-person AI engineering team. Simply put, development teams that use AI to build applications can accomplish far more in less time.

By the same token, it is increasingly important to design applications with AI components and agentic users in mind. “Bolting AI onto an existing architecture after the fact is like adding a second floor to a house with no load-bearing walls,” Rajhans says. “It works until it doesn’t, and when it breaks it breaks badly.”

One of the biggest advantages of AI-first development is the speed with which teams can complete projects and get products into development. This includes identifying and addressing issues much earlier than would be otherwise possible.

“Work that used to stall in the backlog for quarters, like platform migrations and updating aging libraries, now clears in days,” says Collin Hogue-Spears, senior director, DTE, at application security software company Black Duck Software. “Defects surface at design time rather than in production, where a catch costs a code review instead of an incident.”

When you apply AI from the onset of your software project, “you’ll typically learn about issues with your concept in hours rather than weeks,” says Bob Hutchins, CEO at consulting and advisory firm Human Voice Media. “I developed full production applications where the first working prototype was completed prior to the kickoff meeting for a traditional shop.”

AI-first development also helps to keep unnecessary costs down. “Retro-fitting AI into projects is often costly and difficult,” Hutchins says. “Project designs that include AI from day one result in cleaner data flow patterns, much clearer permission schemes, and user interface elements that understand how agents will interact with these systems.”

Implementing a chatbot to an existing application produces a chatbot, Hutchins says. “Designing for AI provides an entirely new type of product,” he says.

Perhaps most important, using AI-first development causes teams to improve their documentation and overall clarity in their thought processes, Hutchins says. “Since an AI cannot read minds, teams which follow this approach will provide better documentation specifications, because the specification itself will serve as the actual instruction set.”

How to succeed at AI-first development

Not all development teams are ready for this sea change in the development process. Many struggle to adopt AI-first development for any number of reasons. Maybe they have underlying engineering systems that rely on undocumented knowledge, implicit rules, or manual oversight. Or they don’t have the right quality assurance, security, and testing processes and skills in place.

AI requires precise context in order to function correctly, and teams that rely on undocumented legacy codebases and obscure architectures might find that AI generates inaccurate information that ends up requiring significant rework by humans.

By following a few good practices, developers and teams can prepare for an AI-first environment and excel at this new paradigm for development.

Add new skills and roles

One of the most important steps is to add new skill sets and roles that fit into the AI-first strategy, even if that means uncomfortable changes for some. Without the needed skills in place, nothing else in the AI-first approach will work well.

“The scarce ability is no longer writing code, but reading it quickly and assessing it accurately,” Hogue-Spears says. “The strongest developers will work as architects: they frame the problem, direct the agent, and verify the result. That is how one engineer safely oversees the work of several.”

Organizations need to focus staffing on the senior architecture roles and cut or redesign the entry-level junior coding roles, says William Flaiz, founder of CleanSmartLabs, a provider of data cleansing products.

“Tools like Claude Code can write good clean code fast so that is no longer the bottleneck,” Flaiz says. “The judgment and experience of what to build, how to architect it, and what is going to break comes from the judgment of senior architects. Skip this and you will ship product fast, but it will break under user load.”

Consider training programs to ease the transition

Much of AI-first is relatively new for a lot of organizations, and many developers and managers will need to learn what it means to be architects in this new world.

The architect role “is changing in a way most organizations have not caught up to yet,” Rajhans says. “The job is less about writing code and more about designing the boundaries, where the agent acts, where the human decides, and what happens when the agent is wrong. That last question is the one most teams skip until it is too late.”

Development teams also need to shift the developer role to an orchestrator role for agentic development, Flaiz says. Training will be needed in a lot of cases.

“They have enough product context and user understanding to where agents hand off, conflict, and which agent wins when in conflict,” Flaiz says. “This is not a programmer role in the traditional sense, but a new role that is a good transition for junior and entry-level developers.”

In addition, Flaiz recommends integrating user experience expertise into the development process, “not as a starting point only or as a gate check at the end,” he says. “AI can write requirements, specs, and assist with architecture, but it doesn’t understand your users. It doesn’t know the habits of how real users interact with software. That comes from watching [user experience] tests, analyzing behavior, and being human.”

Shift toward agentic workflows

A key part of AI-first development is shifting toward agentic workflows, where autonomous agents deploy reasoning, planning, and external tools to achieve complex goals. This is the scenario in which developers will act as architects who oversee AI agents as they work to solve problems and build applications.

“The fundamental transition here is from typing—writing code—to specifying what you want done,” Hutchins says. “People who thrive within agentic workflows are individuals who can clearly define systems, think through potential [uncommon scenarios], and assess others’ work objectively.”

While keying in code might seem to matter at times, the skills required for agentic workflows “represent true architecture and editorial judgment,” Hutchins says. “As such, senior engineers’ values increase rather than decrease.”

With the new workflows, “developers will spend less time writing every line of code manually and more time defining goals, considering product constraints, iterating through architecture, designing intuitive user interfaces, envisioning data flows, and calculating expected outcomes,” says Bob Brauer, founder and CEO of Interzoid, a consultancy and provider of data enrichment and structured intelligence services.

“AI tools and agents can then help generate code, test plans, documentation, deployment scripts, and monitor ongoing maintenance requirements,” Brauer says.

Create new testing and review processes

Another good practice is to create a new review process prior to building agent pipelines. “AI will generate ‘plausible’ garbage without hesitation,” Hutchins says. “Organizations that are currently suffering damage due to [poor] generation are the same ones that grew their generation capabilities faster than their ability to verify generated output. We have already seen consultants return client monies paid for fake citations. This represents a process failure, not a technology failure.”

Reviews need to be ongoing. “Design for the human checkpoint,” Hutchins says. “For every workflow the questions should be ‘where does a person with judgment need to review before we send this?’ If you cannot answer this question for your current workflow, then you are not implementing AI-first development. You are simply allowing unsupervised delegation.”

As for testing, “developers have to get comfortable with non-determinism,” Rajhans says. “AI-first systems do not behave the same way twice. Testing, observability, and failure handling all have to be redesigned from scratch around that reality. Teams that treat AI outputs like function returns get burned fast.”

Start small and proceed with caution

Despite the urgency among many business leaders to move aggressively toward AI, a somewhat cautious approach might be best for both near-term and long-term goals.

“Begin small and track everything,” Hutchins says. “Allow developers access to approved tools and clearly defined guidelines, then determine where [and] when AI reduces developer time verses when AI generates additional rework.”

AI-first development will become increasingly critical as competition intensifies and software teams face growing pressure to deliver faster, more sophisticated, and easier-to-use applications, Brauer says.

“By leveraging AI across requirements gathering, architecture/design, coding, testing, deployment, and ongoing maintenance, development teams can significantly increase their effectiveness and create greater organizational value,” Brauer says. “Organizations that embrace AI-first development will be better positioned to deliver higher-quality software faster and gain a meaningful competitive advantage.”

Microsoft has released Visual Studio Code 1.136, an update to the popular programming editor that previews an Agent Merge feature and introduces two experimental features for agentic coding.

VS Code 1.136 was released September 2 and can be downloaded from code.visualstudio.com.

Agent Merge, a preview feature, helps take a pull request across the finish line, Microsoft said. Agent Merge asks an agent to address review feedback, fix failed checks and merge conflicts, and rerun workflows until the pull request is ready to merge. To use Agent Merge, turn on the setting chat.agentMerge.enabled. Then you can enable Agent Merge for a session by running “Enable Agent Merge for Active Session” from the Agents window or selecting the “Agent Merge” button in the title bar.

VS Code 1.136 also introduces multi-root workspaces, an experimental feature that allows developers to work with GitHub Copilot and Claude agents across multiple project folders in the editor window chat view. Agent hooks remain scoped to a single workspace folder, Microsoft said. If hooks are detected in multiple folders, VS Code prompts the user to select the primary folder from which to load them.

Another experimental feature in VS Code 1.136 is chat backgrounds in the Agents window. This allows users to personalize the Agents window with a theme-aware pattern of built-in VS Code icons or an image of their own. Also new for chat are enterprise controls for dictation data. The new controls allow administrators to manage the dictation model and language-model transcript cleanup through enterprise policies. Microsoft said it was possible to require on-device transcription and disable language-model cleanup, so dictation remains available while preventing dictation data from being sent to cloud transcription or a Copilot model.

Nvidia has released a free tool that will enable users to build an AI inferencing cluster from disparate PCs on the same network, accessible from a single interface.

Released as a beta, Nvidia Personal AI router (PAIR) connects devices running Windows, macOS or Linux to process AI inferencing workloads privately.

While the system is aimed primarily at home users, it could find favour with enterprises looking to put idle desktop compute capacity to use.

PAIR works with DGX Spark desktop supercomputers, PCs containing RTX GPUs, and some MacOS devices. The systems in the cluster run tasks in parallel, but PAIR does not turn them into a virtual GPU, Nvidia said.

The beta version of Nvidia PAIR is available for download now.

This article first appeared on Network World.

OpenAI launched GPT-6 Astra on Thursday, disclosing that the new flagship model has crossed the “Critical” threshold for cybersecurity risk under its Preparedness Framework, a classification the company said triggers additional deployment restrictions.

“GPT‑6 Astra is rolling out today to a limited set of organizations and over the coming days will become available to all ChatGPT Plus, Pro, Business, and Enterprise users, as well as through the OpenAI API and AWS,” OpenAI said in a statement.

Enterprise administrators must manually enable Astra for their workspace, since access is off by default at launch, according to the company.

Developers can access Astra in the API as gpt-6-astra or through Amazon Bedrock, OpenAI said, priced at $10 per million input tokens and $50 per million output tokens. Pro, Business, and Enterprise users also get a variant called Astra Pro, and the company said Astra supports Zero Data Retention for eligible API customers.

Company claims perfect score on exploit benchmark

OpenAI said it tested Astra without production safeguards on ExploitBench, and that the model scored 100%, up from 78.5% for predecessor GPT-5.6 Sol. On ExploitGym, a broader exploit-development benchmark, the company said Astra reached a 42.4% success rate against 30.3% for Sol, while using fewer output tokens.

“Its ability to identify and develop zero-day exploits can help defenders find and patch weaknesses, but it also creates a need for stronger safeguards,” OpenAI said in the blog post.

Recommended for you

OpenAI also tested Astra on vulnerabilities disclosed in the three months before launch, to check whether it could find flaws on its own rather than recalling old exploits from training data. The model found two new zero-day vulnerabilities during that test, OpenAI said, and it is now disclosing both to the software makers involved.

Sanchit Vir Gogia, chief analyst at Greyhound Research, said the Critical label is a disclosure event rather than a capability event.

“Astra’s capability did not change between 10 August, when OpenAI said Critical capability could not be ruled out, and September 1, when it said the threshold was met,” Gogia noted. “The testing changed. The model did not.”

That inverts the obvious enterprise response, he said.

“Astra is now the only frontier model whose cyber capability an enterprise actually knows, because it is the only one measured against a published threshold, while every unlabelled model already sitting behind enterprise credentials has never been measured that way and will not be until its vendor chooses to measure it,” Gogia pointed out. “Those models are not safer.”

OpenAI said the public version of Astra will refuse advanced offensive tasks such as generating proof-of-concept exploits, though it plans to loosen those restrictions for vetted defenders through a program called OpenAI Daybreak in the coming weeks.

The launch follows OpenAI’s rollout of GPT-5.6 Sol, which the company said scored 73.5% on ExploitBench at launch, and comes months after Anthropic’s Fable and Mythos models were briefly pulled from export markets over similar concerns.

Governance shifts from the model to the harness around it

Gogia said the bigger shift is that reasoning now translates into state change, since a wrong chatbot answer is an information problem while a wrong agent action inside a customer-record system is an operating event.

“The governance unit therefore moves off the model,” he said, arguing the relevant question is no longer which model is approved, but how much damage a given identity can do before a control intervenes.

Amit Kumar Jena, head of AI development at Kanerika said the visibility problem is concrete: when an agent acts through a user interface, systems of record log the action as a person, so an agent that updates 400 ERP rows shows up as a service account making 400 updates, with no record of which instruction or model version produced them.

“You lose granularity inside the exact system a regulator or auditor will ask to see,” Jena added.

OpenAI said it built a new evaluation, informed by an incident involving Hugging Face, to test whether a model given an impossible task would exceed its authorized scope.

“Compared to GPT‑5.6 Sol, which without production safeguards went beyond the authorized target 48% of the time, GPT‑6 Astra did this in 0% of cases,” the statement added.

Gogia said the more uncomfortable finding is that Astra behaves better and watches worse: OpenAI reports decreased chain-of-thought monitorability against Sol, with Astra less likely to reveal incriminating reasoning, and its monitoring covers OpenAI’s own external deployment but nothing published extends that telemetry to customers. “OpenAI being able to monitor Astra does not mean an enterprise can audit Astra,” Gogia said.

The article originally appeared on CSO.

The consulting firms told us this would be different. They arrived with slick slide decks, expensive vendor packages, and promises to revolutionize how we do business. Their message was clear: Digital transformation was no longer optional; it was existential. Companies that failed to adapt would be left behind and crushed by more agile competitors with cloud-native architecture and data-driven strategies.

That was back in 2020, when Boston Consulting Group released research showing that 70% of digital transformations failed to meet their objectives. The consulting industry rushed to publish its frameworks, maturity models, and proprietary methodologies. Enterprise IT organizations spent millions on these programs, hoping to finally bridge the gap between technological capability and business value.

Several years on, I can say that little has changed. If anything, the issue has worsened.

The damage that was done

Most digital transformations didn’t just fail to deliver ROI; they actively damaged the organizations that undertook them. Technical debt accumulated as companies deployed monolithic cloud platforms that were neither modular nor scalable. Business misalignment became endemic as transformations focused on technology for its own sake rather than on solving actual business problems. Organizations found themselves locked into expensive vendor relationships that failed to deliver on their promises.

I’ve spoken with dozens of enterprise CIOs and CTOs over the past several years, and the stories are remarkably consistent. Transformations that were supposed to take six months stretched to two years. Budgets estimated at a few million exploded to six, eight, even twelve times the original projection. The consulting firms had excellent PowerPoint skills, but when it came to implementation, the results were consistently disappointing.

The damage wasn’t just financial. Organizations lost confidence in their IT capabilities. Talented people left because they were tired of being managed by consultants who couldn’t code their way out of a paper bag. Business stakeholders grew cynical about technology initiatives, having been burned too often by projects that promised transformation but delivered chaos.

Why the consulting models failed

Let’s be direct about what happened. The consulting industry discovered that digital transformation was highly profitable. They could sell their methodologies, vendor partnerships, and “best practices” frameworks, and charge premium fees for implementation support. The problem was that these frameworks were largely one-size-fits-all approaches disguised as bespoke solutions.

A major global bank doesn’t have the same requirements as a regional healthcare provider, yet both were sold the same transformation playbook. The consulting firms had invested too heavily in their methodologies to admit that the real answer might be to start with business requirements and work backward toward technology. Instead, they assembled prepackaged solutions optimized for vendor partnerships rather than clients’ actual needs.

The talent problem was equally severe. The consulting firms could certainly talk about digital transformation; they had excellent slides and compelling narratives. But when it came to implementation, the skill gaps were glaring. These organizations assembled solutions by following playbooks rather than understanding how the technology components actually fit together. The result was systems that were overengineered, overprovisioned, and ultimately underperforming.

Cloud computing was supposed to be the great enabler, but many organizations misunderstood and misapplied it. Organizations lifted and shifted their existing problems along with their existing architecture. Monolithic applications running on expensive virtual machines became the new normal, with organizations paying cloud costs that far exceeded their on-premises expenses, yet achieving none of the scalability benefits the cloud was supposed to deliver.

What we still need to learn

As we grapple with the next wave of technology transformation—this time centered on artificial intelligence—the lessons from digital transformation failures should be front and center. The first and most important lesson is brutally simple: Focus on business needs first. I know this sounds obvious, but I guarantee you that every failed digital transformation project lost sight of its core business requirements. They built technology for technology’s sake without understanding the problems they were trying to solve.

Too many transformations focused on individual business units rather than enterprisewide strategies. The result was a collection of systems that couldn’t work together cohesively. Isolated solutions felt like progress but actually made integration harder and created new dependencies that hadn’t existed before.

Organizations also need to invest in serious training for their people. I’m not talking about sending IT staff to vendor certification programs that teach them to pass tests on proprietary platforms. I mean fundamental architectural education that helps people understand how to assemble technology effectively.

We face a massive shortage of AI, cloud, and security architects, as well as other technical leaders who can design solutions that work. Rather than addressing this gap, organizations are placing unqualified people in these roles and hoping for the best. It’s past time to invest in education.

The case for simplicity

Here’s something that also should be obvious but clearly isn’t: You can solve the same business problem with $1 million or $20 million, depending on the sophistication of the IT organization building the solution. Both designs will work reasonably well, but one solution costs 20 times more because it is overbuilt and overengineered.

Organizations are adding AI to everything under the sun, even when simpler solutions would work just as well. They’re overprovisioning cloud resources because they lack the architectural discipline to rightsize their infrastructure. They’re building systems designed for scale they’ll never reach, complexity they don’t need, and features no one requested.

The path forward requires a minimalist approach. Build systems that are good enough for their intended purpose. Focus on requirements rather than capabilities. Resist the temptation to adopt every new technology just because it’s available.

Digital transformation didn’t fail because the technology was flawed. It failed because we forgot that technology exists to serve the business, not the other way around. To succeed with AI, we need to remember that fundamental truth. And remember the consulting industry’s tendency to sell us expensive solutions to problems we don’t have.

Meta won’t judge employees by how much they use AI when it comes to annual performance reviews, despite early efforts to drive AI adoption focusing on so-called token maxing.

The company has told employees that it “will not use AI adoption dashboards or token counts to evaluate impact,” according to  a report by The Information.

The announcement came in an internal memo from executives Maher Saba and Santosh Janardhan, which said that instead of measuring AI usage, “managers should look at output quality, velocity, problem complexity and scope taken on.”

This marks a culture change for Meta, where engineers had previously competed to consume the most AI tokens, displaying their scores on a leaderboard. Meta then discovered that its employees were being diverted from regular work because they were using AI to carry out additional tasks to boost their scores.

Amazon had similar results when it implemented a leaderboard to track AI use; it also found that some employees were trying to game the system by using AI to complete unnecessary tasks, and it has now deleted it.

The company, however, does also monitor employees’ use of AI for training purposes, in a program introduced in April, but this is information was not used to measure employee performance.

Meta had already started to look askance at the concept of using AI metrics as a tool to assess employees. Earlier this year, Chief Technology Officer Andrew Bosworth told employees in a memo that “nobody should be using AI tools just for the sake of using them,” adding that “token usage alone is not a measure of impact of any kind.”

Hot on the heels of the Rust 1.98.0 release, the Rust team has published Rust 1.98.1, an update that fixes a miscompilation in vtable generation.

Rust 1.98.1 was announced September 3.

A Rust issue opened August 21 (and now closed) noted that Rust 1.98 emits a zero method entry in a compiler-generated vtable, resulting in a segmentation fault and a crash. According to the Rust 1.98.1 release notes:

In Rust 1.98.0, in some circumstances, rustc would incorrectly generate a trait object vtable with a null pointer where a function pointer should be. This leads to undefined behavior in the emitted code. In some cases this may “just” cause segfaults due to the null pointer being loaded, but it is possible for it to be justification for arbitrary effects.

This bug is fixed in Rust 1.98.1. The Rust 1.98.0 release brought algebraic methods for addition, subtraction, multiplication, division, and remainder to floating-point types, allowing optimizations on these operations using algebraic properties of real number.

Users of a previous version of Rust installed via rustup can install Rust 1.98.1 by running the command rustup update stable. The Rust team asks developers who would like to help test future releases to consider using the beta (rustup default beta) and nightly (rustup default nightly) channels and to please report any bugs.

When Nvidia said Thursday that it plans to pay $13 billion to acquire Hugging Face, the question arose of whether the open AI platform would remain open when it becomes a unit of Nvidia. And the current lack of a single viable open alternative that does everything Hugging Face does for enterprises adds further complications for CIOs.

Rumors of the pending deal have been circulating for at least a week. 

In its announcement, Nvidia said, “Hugging Face will remain an open platform for the entire AI ecosystem. Developers will choose the models they want, the frameworks they want, the clouds and inference service providers they want and the computing platforms they want. Nvidia compute will not be required to build on or deploy through Hugging Face.”

It added that Hugging Face will continue to support open source and open weight models from every model builder, and “continue to support multi-cloud and multi-accelerator development and deployment, so builders can use the hardware and infrastructure that best fit their work.”

Hugging Face CEO Clément Delangue took to his X account to also reassure customers, noting, “open-source AI is at an inflection point” and pointing out that, for the business to scale, it needs “more compute, more support, more collaboration and more visibility. That’s why we went to talk to [Nvidia CEO] Jensen [Huang], who offered to do exactly that with us.”

Preserving the Hugging Face team

Nvidia is also attempting to retain some of the Hugging Face workforce. As part of the deal, according to Nvidia’s 8-K filing, the purchase price is $11.9 billion, with “approximately $1 billion” earmarked for “an equity-based retention program” for Hugging Face employees who agree to join Nvidia. It has yet to be announced how many members of the Hugging Face workforce, estimated to be almost 750, will be offered roles at Nvidia.

But despite the reassurances from Nvidia about maintaining the open nature of Hugging Face, analysts and consultants suggested that the truth may not be known until months, or even a year, after the acquisition finalizes sometime next year; the transaction is expected to close “in the first half of 2027.”

Cause for optimism

Enterprise CIOs can only wait and see what Nvidia will ultimately do. 

But in the meantime, there is cause for optimism, given the history of recent open source acquisitions, said Jason Andersen, principal analyst at Moor Insights & Strategy. 

“There is always a ‘sky is falling’ narrative” with these transactions, Andersen said, but in recent years, open source acquisitions have often turned out quite well.

“What happened to Red Hat after IBM bought it? Things got better,” Andersen said. “The same can be said for GitHub after Microsoft bought it. Or Google’s acquisition of Gemma. There are just too many examples of it going the right way.”

Justin Greis, CEO of consulting firm Acceligence, also sees this acquisition as potentially good news for enterprise CIOs. 

“If Nvidia turned [Hugging Face] into a walled garden or an obvious funnel toward Nvidia hardware, it could undermine the community and network effects it just paid nearly $13 billion to acquire,” he pointed out. “Nvidia is being unusually explicit that Hugging Face will remain model-, framework-, cloud- and accelerator-agnostic, including saying that Nvidia compute will not be required.” 

And, he added, Nvidia could indeed make Hugging Face even more enterprise friendly. 

“Nvidia itself points to the opportunity to improve Hugging Face’s reliability, safety, model evaluation, inference, and deployment capabilities. That is potentially a very big deal,” Greis said, noting that enterprises don’t simply need access to more models, they need confidence that those models can operate within complex environments with governance, security, performance, resilience, and lifecycle management around them.

Those needs make the combination compelling, he said: “Nvidia has the engineering depth, infrastructure expertise and ecosystem reach to significantly raise that bar. Hugging Face has been enormously successful as a developer and open-model platform. Nvidia now has the opportunity to help make it much more enterprise-grade: a place where companies can discover models, datasets, and AI components, but also increasingly evaluate, test, secure, operationalize, and deploy them with the level of confidence and rigor expected inside a large enterprise.”

Avoid a single dependency

Still, said Shashi Bellamkonda, a principal research director at Info-Tech Research Group, there are various practical steps that CIOs can and should soon take to preserve what they have already created within Hugging Face.

“This should be a clarion call for CIOs to treat Hugging Face and open source models as part of their enterprise supply chain, and if a production system depends on an artifact hosted on Hugging Face, keep a verified copy in a second registry, whether that is GitLab, Amazon S3, or an internal artifact store,” he said. “Enterprises should also consider the source for open models and develop a fallback plan such as the model developer’s own repository or another hub, because Hugging Face is the dominant platform today, but no enterprise should depend on one company’s availability, governance, or roadmap.”

Bellamkonda also pointed out that, by owning Hugging Face, Nvidia would gain valuable visibility into which models are gaining traction, how developers are deploying them, and which hardware ecosystems they run on. It would then “hold a powerful position in the distribution of new open models, so that combination of infrastructure ownership, market intelligence, and hardware influence should factor into CIO planning,” he said.

Mike Wilkes, enterprise CISO at Aikido Security, added that one of the factors that makes a CIO’s 2027 contingency planning in the face of Hugging Face’s new ownership difficult is that there are not that many large open source companies that could directly replace Hugging Face for an enterprise.

“No true replacement exists for Hugging Face at its scale, but there are ways to avoid making it a single point of dependency,” he said. “Azure AI Foundry is probably the closest enterprise alternative regarding model breadth, now advertising more than 11,000 models and supporting models from OpenAI, Anthropic, Meta, Mistral and others. AWS SageMaker JumpStart is another option, as enterprises can create private curated model hubs with their own governance controls. Google’s Model Garden is a third viable choice and supports both managed and self-deployed open models inside the customer’s own cloud environment.”

But adopting any of those alternatives means a move from an independent Hugging Face to Microsoft, Amazon, or Google, “so they change the concentration risk rather than eliminating it,” Wilkes noted. “The best enterprise strategy is not to search for another Hugging Face, but to separate model discovery from model custody. We can continue using Hugging Face to discover and evaluate models while mirroring approved models into an internal repository or registry under our control.”

Risk of increasing AI control by Nvidia

IDC’s Ashish Nadkarni, a group VP, said CIOs must also remember that the Nvidia move could give it various levers to even further tighten its control over global AI developments. 

“Hugging Face is like GitHub for AI. It is the default front door for open AI innovation: it’s where data scientists, machine learning engineers, and developers discover pretrained models, fine-tune them, and push them into production, or find open datasets to train their own models,” he said. “Owning that front door gives Nvidia a major position in the mindshare of today’s AI development personas.”

Consultant Brian Levine, executive director of FormerGov, also advised CIOs to stay alert. He predicted that Nvidia will exert greater control over Hugging Face efforts, but it will happen so gradually that it might not be noticed.

“The risk isn’t a dramatic reverse course. It’s a slow drift, where the Nvidia-optimized path quietly becomes the easy path, and everything else becomes the friction path,” he said. “Stop treating Hugging Face as a vendor-neutral utility and start treating it as a strategically-owned platform. That doesn’t mean leave. It means keep your options real and tested, not theoretical.”

Unanswered questions

And, from an enterprise CIO’s perspective, there’s another worry.

“Nvidia’s openness commitment is precise where it is cheap, and silent where it is expensive,” said Sanchit Vir Gogia, chief analyst at Greyhound Research. “The release promises that Nvidia compute will not be required, that multi-cloud and multi-accelerator support continues, and that developers choose their own models, each of which is a commitment about availability rather than about terms. Nothing in it addresses ranking, search placement, or default routing, and those are what decide which models a developer ever sees. Nobody has to be banned for the field to tilt. Gravity is enough and gravity is the part the pledge does not mention.”

Meta is upgrading its Muse Spark family with a new model aimed at long-horizon coding tasks and agentic software development while keeping its standard API pricing unchanged, giving development teams access to improved capabilities without paying more per token.

The new Muse Spark 1.3 model claims to complete coding tasks using about 25% fewer tokens and 20% fewer tool calls than its predecessor, potentially giving development teams more efficient AI-assisted coding at the same per-token price, the company wrote in a blog post.

The efficiency gains come from Muse Spark 1.3 taking fewer turns when they aren’t needed and producing less verbose responses, while improving its ability to sustain longer-running tasks by generating its own context, correcting gaps in its plan, following complex instructions, managing multiple workflows and recognizing its limitations, it added.

Productivity and cost benefits

For developers, the combination of improved capabilities and unchanged pricing could boost productivity while encouraging teams to use AI for a broader range of coding tasks, said Pareekh Jain, principal analyst at Pareekh Consulting.

“Since it is better at understanding complex prompts and following instructions, developers can get better results with fewer retries and potentially use less AI for the same tasks, while also making it easier to extend the model to a broader range of coding and software development workloads with reduced human supervision due to its improved reliability,” Jain said.

These workloads could include understanding large codebases, debugging, changing multiple files, using developer tools, and testing code, Jain added.

That, in turn, could potentially reduce inference costs related to AI-assisted software development for CIOs.

“CIOs potentially get more work for the same token price if Muse Spark 1.3 completes tasks with fewer tokens, tool calls and retries,” Jain further said.

Lower cost per task may not translate into lower overall AI spending

However, that reduction in inference costs may not translate into lower overall AI spending.

Primarily because, most enterprise teams will use the more capable model for longer running and more complex tasks, offsetting the reduction in inference costs, said Abhishek Satapathy, principal analyst at Avasant.

That scenario is more likely as enterprises tend to increase their use of a resource when efficiency improvements make it cheaper to consume, a dynamic reflected in the Jevons Paradox, Jain said.

Enterprises should therefore look at the cost of successfully completing a task rather than the model’s per-token price, Jain added.

Efficiency claims remain disputed

Meta’s benchmarks of the new model, which were conducted internally, also come with caveats when viewed against independent evaluations.

While Meta claims that Muse Spark 1.3 uses fewer tokens than its predecessor, independent evaluations have produced different results, raising questions about how consistently those efficiency gains will translate across workloads.

Artificial Analysis, an AI benchmarking platform, found that Muse Spark 1.3 generated about 100 million tokens while completing its Intelligence Index evaluation, compared with a 71 million-token median across the models it evaluated.

While these results do not directly replicate Meta’s internal coding evaluation, which measures token use on specific coding tasks, they highlight how model efficiency can vary significantly depending on the workload and evaluation method, said Manoj Chandra Jha, principal analyst at Nord-IQ Research.

“The differing results reinforce the need for enterprises to test the model against their own workloads before budgeting for expected efficiency gains,” Jha added.

Eesel AI, an AI productivity platform, also cautioned users against Meta’s claims about Muse Spark 1.3’s performance.

“Meta’s scorecard compares 1.3’s max mode (still gated behind safety testing at launch) against 1.2’s xhigh mode, so part of the jump is a reasoning-tier change, not a clean generational leap,” it wrote in a blog post.

That makes it harder for enterprises to determine how much of the reported performance gain comes from improvements in 1.3 itself and how much comes from the higher reasoning configuration used in Meta’s comparison, Jha said.

Redditors have also expressed skepticism over Meta’s benchmarks, terming it “classic benchmaxxing”, the practice of optimizing a model or workload to score high on a benchmark rather than a real-world use case.

However, analysts remained optimistic about the new model’s value and its adoption.

“This is Meta playing the value card as the new model undercuts Anthropic and OpenAI’s flagship pricing by 4-to-6x, while still producing results that are competitive with more expensive models,” said Jha.

That should potentially position it as a “strong” alternative for enterprises running complex software development workloads at scale, echoed Satapathy.

Entrusting mission-critical workloads in the cloud puts a lot of pressure on IT operations to build resilience into data infrastructure they don’t even own — to make sure that when an incident happens elsewhere, the lights stay on at home. Fortunately, savvy CIOs are learning they can architect their systems for resilience and high availability to keep mission-critical cloud workloads running when disaster strikes.

When designing for resilient, highly available cloud workloads it is critical to understand the details of your cloud provider’s service level agreement (SLA) and recognize that providers operate on a shared responsibility model. That means there are many things the provider is responsible for, but the workloads you’ve got running on their infrastructure are not among them. With that in mind, we’ll need to focus on three core goals essential to building and maintaining highly available, resilient cloud workloads:

1. Identify and eliminate single points of failure
2. Close or mitigate conditions leading to recovery gaps, and
3. Overcome operational complexity.

Remember, everything fails

Designing for application-level resilience and high availability is predicated on recognizing that everything fails. That’s not pessimism, but realism, and embracing this fact gives you a leg up in architecting resilient IT. Hardware breaks down, disasters occur, mistakes are made, software incompatibilities are common, and limits are exceeded that result in loss of service. There are four categories of failure that need to be taken into consideration when designing for resilience and high availability:

1. Single point of failure: As the term suggests, this describes a non-redundant device, route, or point of connectivity that results in zero fault tolerance in the event of an incident involving that choke point.
2. Excessive load: Exceeding the throughput or memory limits of a device or service can result in latency, service degradation, or failure affecting service level agreements (SLA) and service level objectives (SLO).
3. Misconfigurations and bugs: Perhaps the most common source of failure, these breakdowns often occur during installation, maintenance, and patching leading to the incorrect execution of code.
4. Shared fate: This type of failure is like non-redundant connectivity. When you rely on third-party services and there is an incident beyond your control affecting a partner, it can result in downtime or service degradation.

Having identified the primary challenges to maintaining service uptime and continuity, let’s explore an approach to achieving resilience through high availability, disaster recovery, and the process of continuous improvement.

Working toward continuous improvement

High availability is often thought of as measured by “X Nines,” representing the percentage of time a service is operational over the course of a specified time frame, usually a year. Six nines of availability, for example, means that a service can be expected to run 99.9999% of the time, or 8759.99 hours out of 8760 in a year. That sounds good until a disaster happens. Then we shift to disaster recovery, or the ability to restore a service and its associated data quickly and correctly when things go wrong. Disaster recovery is often measured and evaluated by a recovery point objective (RPO), which is the maximum acceptable amount of data loss, and a recovery time objective (RTO), which is the maximum acceptable amount of time a service can be down.

By learning from our mistakes, incidents, and the ongoing process of testing, observing, and evaluating IT operations, we apply new information in the goal of continuous improvement to get peak performance out of our investments in IT. But because we’re addressing resilience and high availability in the context of workloads operating in the cloud, we should understand the shared responsibility model that most cloud service providers use. Details may differ from provider to provider, but the shared responsibility model of cloud services is your vendor’s statement of responsibility for maintaining its infrastructure and ability to deliver storage and compute capacity in a region and availability zone where you have a need. In return, you accept responsibility for the configuration, maintenance, availability and operation of the workloads you choose to run on your vendor’s cloud.

A cloud service provider will typically operate and maintain physical infrastructure in different areas around the world, with multiple availability zones in each area. Each availability zone will have one or more data centers with its own power, cooling, and other operational support. Data centers are typically located far enough from each other to minimize the chance that a natural or regional disaster will affect multiple data centers, but close enough that they can operate as a single, logical data center — thereby maximizing bandwidth and throughput, while minimizing latency. This is redundancy at scale that eliminates a single point of data center failure.

Designing for application high availability and disaster recovery

To build out or retrofit your infrastructure for application-level resilience and high availability, there are four things you must have: clustering, data replication, failover, and disaster recovery. Let’s look at each and how to architect for them.

Clustering

Clustering is the practice of connecting like and complementary systems to improve availability and reliability. Think of it as putting into practice the maxim “the whole is greater than the sum of its parts.” Traditionally, clustering was achieved using hardware, specifically storage area networks (SAN), to connect and support systems in a physical data center. However, in the cloud age, hardware-based clustering has proven to be expensive and inflexible. Software-based SANless clustering with products such as SIOS LifeKeeper delivers all the benefits of the traditional approach while also working better in cloud and hybrid environments.

SANless clusters enable the configuration of nodes based on the organization’s operational priorities and work easily for enterprises running geographically distributed data centers or cloud availability zones. Because SIOS LifeKeeper supports single-site, multi-site, cloud, or mixed environments, and affords real-time access to operational data during incidents requiring failover, it is ideal when mission-critical workloads are distributed across multiple providers. LifeKeeper clusters create redundancy and eliminate single points of failure, both of which are necessary for achieving high availability. For enterprises operating hybrid or multi-cloud infrastructure, this enables you to shift to secondary resources should your primary service experience an outage.

Data replication

IT operations and your mission-critical applications rely on data, so it’s vital to keep data in sync between nodes in real time, whether synchronously or asynchronously, depending on the application. When working to achieve high availability, it’s important to monitor the health of infrastructure elements and the applications you’re running. This ensures that downtime affecting the application and any downstream dependencies is detected so that failover and recovery to a standby node can occur automatically. When everything is in sync and data replication is happening, this ensures complete readiness; there’s no need to rebuild a database or for any manual operations. And with SANless clusters using SIOS DataKeeper, this will happen across availability zones, regions, and to or from on-premises, cloud, or multi-cloud resources in hybrid environments.

What’s important here is that the software you use for SANless clustering be application aware. That’s SIOS LifeKeeper. Because high availability and resilience mean not just failing over to standby infrastructure resources, but for properly failing over mission-critical workloads (think SQL Server, SAP, Postgres, or industry-specific applications like Meditech), the software needs to understand how those applications work so that they can recover and restart cleanly. Otherwise, when failover occurs, there’s a good chance that workload is not going to be available, or it could be out of sync. When your software is application-aware, failover and recovery is fast and predictable with no API dependencies or last-minute provisioning.

Failover

With SIOS SANless application-aware clustering and replication in place, you can automate real-time failover and achieve the goal of high availability and resilience. Because we’ve chosen a software-based approach, failover occurs in the data plane, so there’s no need to spin up a new instance following an incident. Everything is already running, in sync, and ready. Furthermore, failover is immediate and it’s predictable. That is what you need when dealing with mission-critical workloads. Consider that many of the mission-critical applications you use were not designed to operate in the cloud, so even if your infrastructure is resilient, the application itself represents a single point of failure. Without replication, application monitoring, and real-time failover automation, you risk loss of revenue, security degradation, or worse.

Depending on the size of your enterprise and the industry in which it operates, an hour of downtime can cost $1 million or more, and 90% of organizations report costs of at least $300,000 per hour. Beyond that simple loss of revenue are soft costs associated with reputation damage, lost productivity, missed transactions, and more. Revenue protection is only part of the equation; it is about protecting the business.

Disaster recovery

Any design for high availability and resilience must also take into consideration the risk of a non-IT disaster that disrupts operations. Natural disasters like fires, earthquakes, and floods, or disasters caused by humans like the accidental severing of a trunkline or an act of sabotage conspire to bring operations to a sudden halt. Clustering, replication, and failover all play into disaster recovery, but there are additional considerations that must be addressed. For disaster recovery (DR), you’re going to want geographic distance between your primary site and your DR site to minimize the risk that a regional event doesn’t affect both. That means you’re going to want asynchronous (or near real-time) data replication.

Asynchronous replication is typically only a second or less behind synchronous replication, so it is de facto real-time, but that delay allows you to replicate across higher-latency networks and across longer distances. And because replication is happening continuously, even if you have a local failover between node one and node two, replication to the DR node doesn’t stop. Instead, when node two comes online it becomes the source of the mirror replicating to the DR site and back to node one once it is restored.

Patching and planned maintenance

Beyond the simplicity and cost advantages that come from taking a software-based approach to designing your cloud and hybrid infrastructure for high availability there is another big benefit. You are also better prepared to respond to the increased pressure on rapid implementation of software updates and security patches. No one wants to be the person responsible for taking too long to patch for a vulnerability, but every time you touch a system, you’re introducing the risk of error. That risk is greater when dealing with the cloud where you have less control over the underlying infrastructure, more abstraction, and a lot more moving parts.

In short, patches can break things as well as fix them. They have thus become a significant contributing factor as a cause of downtime. With SANless clusters you’re able to minimize that risk by enabling rolling updates, meaning you can patch a secondary server, verify that the patch didn’t break anything, and then patch the original server where the primary application is still running. If something does break on the secondary server, the primary is unaffected and you can quickly recover to the previous state while you figure out what went wrong. This simplifies the process of executing ad hoc patches and performing planned maintenance, mitigating the associated risks.

An investment in cloud and hybrid infrastructure and services doesn’t have to put IT operations at the mercy of a third party. With the right approach, you can design for high availability and resilience and keep your mission-critical workloads running in the cloud even when things outside of your control go wrong.

—

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.