Open-Weight Models Could Capture Most Enterprise AI Workloads

? arvind-krishna puts a rough midpoint of 2030 on the arrival of a quantum computer capable of breaking today’s cryptography. The date is uncertain; the consequence, in his view, is not. Data encrypted now can be stolen and stored until it becomes possible to decrypt. That makes the transition to post-quantum cryptography a present-day infrastructure problem, not a task to begin when a working machine appears.

Krishna said DARPA’s Quantum Benchmarking Initiative began with a few hundred companies and had narrowed to roughly 13. The central question is which teams can build a quantum computer that works, with estimates ranging from 2028 to 2033. Today’s machines, he said, remain error-prone and difficult to scale. He expects the first important milestone to be a credible demonstration of error correction on a running machine—not a simulation—with independent evaluation of the claims. He predicted some progress by 2027.

The next marker is whether machines can scale their gate computations. Krishna put current machines at roughly 10,000 such computations and suggested that adding an order of magnitude each year could bring them to 10 million by 2029. That would not mean a general-purpose machine at full scale, but, he said, it could be enough to produce surprising results.

“Logical qubit” is one way to describe the effective capacity after error correction, though Krishna said he did not love the term. A machine with 10,000 physical qubits might, for example, have only 200 logical qubits once errors are accounted for. The distinction matters because raw qubit counts can make a machine sound more capable than it is.

Krishna also qualified what it means to call post-quantum cryptography “quantum proof.” Its security, he said, rests on theoretical understanding of what quantum computers could do, much as confidence in today’s cryptography rests on complexity theory and assumptions rather than a theorem proving that it cannot be broken.

Nikesh Arora argued that organizations cannot wait for a precise arrival date. Cryptographic keys are embedded throughout IT systems, and replacing infrastructure takes time. He said companies can begin using post-quantum-ready keys to wrap traffic as an interim measure, but warned that a 2029 or 2030 deadline would already be late. In his view, the practical choice is to start moving now rather than expect to replace large amounts of infrastructure in a single year.

The panel also tested whether AI might crack encryption before quantum hardware does. Krishna distinguished between discovering a new quantum algorithm and getting its advantage from classical hardware. AI might help discover or prove an algorithm, he said, but classical computers do not operate like quantum computers; running a quantum algorithm on classical hardware would not deliver the quantum speedup. David Friedberg raised a different possibility: AI could find a classical route through number theory, such as a better way to predict prime distributions. Krishna said that could happen, but the practical question would be how long it took to break a key. A method that required ten years per key would not pose the same immediate threat.

For enterprise AI, Arora’s starting point is to let employees experiment with the best available models before optimizing for cost. Many workers have only recently begun using AI, he said, and imposing constraints too early could slow adoption and make it harder for teams to understand where the technology helps. But experimentation does not imply that every production task should run on a frontier model.

Arora framed model selection as a question of matching intelligence to the task and its cost. His example was endpoint security: the company inspects large amounts of traffic at an annual cost of roughly $20 to $25 per endpoint, using machine learning that runs on the endpoint itself. Sending that traffic through a large model and paying per token would be economically impractical. For routine tasks, he said, a smaller, compressed, task-specific model can be trained toward very high accuracy. In a breach, the calculation changes: the business cost may be enormous, so a company may justify frontier models and agent swarms to reason through the attack.

That distinction also shapes Arora’s preference for open-weight models in many enterprise settings. A company can adapt one using its own data, manage the model weights, and retain more auditability and control. Frontier systems remain useful for tasks where their additional capability is worth the price, but they are not necessary for every workflow.

Krishna agreed, emphasizing three forces pushing enterprises toward open weights: lower costs, protection of intellectual property, and geopolitics. He said an open-weight model could be run on a company’s own GPUs for roughly $1 to $2 per million tokens after a week of engineering work, compared with around $20 for a prior-generation model and as much as $50 for a frontier offering. If the cheaper system can do 95% of the work, he argued, the economics are hard to ignore.

He also warned that sending a model’s chain of thought to an outside provider could expose company IP if that reasoning is captured and logged. Organizations that want to run models themselves cannot simply choose a closed frontier model if it is not available for that purpose. Krishna noted that the strongest open-weight models at the time were Chinese, but said he saw little danger in running them in a company’s own sandbox; using them through a cloud service was a different matter. He expected Western open-weight models with comparable capabilities to emerge over the next year or two, and estimated the gap at no more than six to twelve months.

Krishna predicted that 75% to 90% of token use could eventually go to open-weight models, while acknowledging a gap between that destination and current developer behavior: developers tend to choose the most expensive model if it is the easiest option.

The gap is partly a deployment problem. Krishna said using a powerful model during experimentation may help teams prove a use case quickly; moving production workloads to cheaper systems is a different decision. Arora’s examples point to the same rule from the operational side: frontier capability is most valuable when the cost of failure is high, while routine tasks call for a model whose cost and performance fit the job.

The cybersecurity discussion turned on an asymmetry: an attacker needs one vulnerability; a defender must find and patch them all. Arora said models can identify weaknesses in code, but they also produce false positives. He described Mythos as hallucinating about 30% of the time in one setting, and estimated that when companies investigated the vulnerabilities surfaced by such models, roughly 60% to 80% proved real. Even a useful discovery still needs to be tested and understood before a company can act on it.

That imbalance changes how defenders should use the tools. Arora said companies cannot assume that AI-generated patches are safe without testing them. Krishna agreed that agent-written code can outperform previous human-written code when agents also run evaluations and fix discovered flaws before release. But those evaluations only catch the flaws the process knows how to look for. Fully verifying arbitrary software correctness, he said, remains computationally difficult.

Krishna described three defensive advantages: collaboration, cost symmetry, and technological superiority. Companies can pool vulnerability information through trusted parties, patch a shared weakness once, and distribute the fix rather than having each organization independently repeat the work. The analogy is existing cybersecurity practice: an attack technique discovered in one place can inform protections deployed to many customers.

The broader strategic aim is to make defense less expensive relative to attack and to build enough technological advantage that attackers face higher costs. Krishna said agents already write about half the code at his company, and that it is better than earlier code in part because agents can evaluate and repair what they find. But he did not claim that this makes software error-free. The unresolved constraint is whether the system can identify every relevant defect, especially when inputs are unrestricted.

David Sacks asked whether the prospect of strategic competition makes AI development effectively unavoidable: if rival countries keep building, should others slow down, or prioritize defensive and economic capacity? Arora said development is proceeding at a frenetic pace and that he does not expect anyone to stop. He also argued that public discussion has overemphasized AI’s risks at the expense of its benefits.

Neither Arora nor Krishna treated competition as an excuse to disclaim responsibility. Arora said a company that builds and releases a system cannot simply say it does not know how to control it. Krishna added that the company still wrote the product, even if an agent produced some of the code. Arora’s position was that commercial firms accepting economic value have responsibilities for what they put into the market.

Krishna said attempts to slow digital technology in one jurisdiction may simply leave room for others to advance. Regulation and data-center restrictions are also shaped by politics, he argued, alongside concerns about long-term economic advantage. He did not expect all 50 U.S. states to ban data centers, but said it was possible that 30 might; the remaining 20, he suggested, could benefit from the resulting investment. His point was not that political constraints are imaginary, but that they will be uneven and can shift with elections.

The panel’s discussion of global access also separated affordability from capacity. Arora thought it should be possible to make models cheap enough for businesses to use, but identified compute supply as a more immediate source of unequal access. A company may have the resources and motivation to innovate yet still struggle to secure compute, especially outside the main centers of supply.

Krishna framed the wider economic question as a recurring contest between labor and capital. He argued that societies and companies willing to invest heavily in capital have tended to prevail in earlier cycles of technological change. He distinguished protecting workers’ opportunities from preserving every existing job: in his view, resisting displacement as a principle could leave countries behind, while accepting it may create different work.

The case for vertical integration began with IBM’s mainframe, which Krishna said has lasted 65 years in part because IBM controlled much of the system. In the 1960s, that meant going from sand and wafers through fabrication, chips, software, and the surrounding hardware. The company no longer makes its own fabrication plants, he said, but still designs chips and keeps much of the engineering and software in-house. The strategic question is where control protects important IP and value, and where a component has become a commodity that is better bought from others.

Arora pointed to Nvidia as a contemporary version of the integrated-stack strategy. A company that controls multiple layers can decide where to let prices fall and where to preserve profit. If competition erodes the returns in one layer, value can shift elsewhere in the stack. That control also gives a company leverage over the ecosystem around it.

For AI applications, Arora expects the stack to extend from software and reasoning through memory and context to the final action. He argued that these pieces will become harder to separate as models demand more memory and context. An agent trained on a user’s history, connected services, and APIs becomes harder to move to a rival system because the context and accumulated memory do not transfer easily. In that sense, the application layer itself can become vertically integrated: the customer is not merely choosing a model but relying on a system that holds the task history and carries it through to an outcome.

This is why Arora sees “open versus closed” as more than a question of model weights. It may become a contest between stacks. He predicted that consumer AI would also become a fight for distribution, with major model companies competing to control the user relationship and applications becoming more like interfaces to broader systems.

Arora sees consolidation in cybersecurity as a way to reduce the burden on customers. He said organizations should not have to buy dozens of products and then integrate them themselves. His analogy was enterprise CRM: at Fidelity, his first employer, he recalled 23 separate systems that collectively performed functions now associated with CRM. Over time, that fragmented landscape consolidated into platforms such as Salesforce, Microsoft Dynamics, or Oracle. In cybersecurity, he expects companies to combine strong products and make their data work together so customers do not have to do the stitching.

The broader software market may face a similar shift. Arora said it is increasingly difficult to know the long-term value of software products when AI can alter what customers expect them to do. He expects significant disruption in SaaS over the next few years, as firms apply AI to workflows they already know could work differently.

Krishna put the potential scale in enterprise terms: a typical organization may use 500 to 5,000 software vendors. Companies could replace many narrow applications with smaller AI capabilities and rely more heavily on a handful of platforms, he argued. Consolidation could reduce distribution costs as the value of individual software products falls.

But Krishna drew a boundary around what AI-generated software can easily replace. Interaction-heavy applications may be more exposed; systems that must deliver extreme reliability, such as database lookups in retail banking or closing financial books, are harder to substitute. A replacement may need to run in parallel as a digital twin for years before an organization can safely switch over, Chamath Palihapitiya observed. Krishna agreed that in such cases the transition may not offer an obvious cost advantage.

The result is not a single forecast of software’s disappearance. It is a split between products whose value lies in interaction and adaptable workflows, and systems whose value depends on dependable execution. Consolidation may reach far across enterprise software, but the pace and scope will depend on how much reliability each task requires.