AI Has Shifted the Competitive Frontier for Software Incumbents

Eric Vishria is dismissive of the idea that established software companies primarily need to fear customers “vibe-coding” their own substitutes. The deeper problem is that AI changes the basis on which those companies compete. Features, switching costs, operating plans, and sales assumptions that once created durable value may no longer do so.

For incumbents, the practical implication is more demanding than adding AI features to an existing roadmap. They need to reassess what actually makes their business defensible, what customers will pay for under new conditions, and which operating assumptions have become liabilities. A company can execute its pre-AI plan perfectly and still lose value because it is optimizing for a competitive frontier that has moved.

Databases are Vishria’s clearest example. Historically, their stickiness came partly from the work required to integrate and migrate them. Application developers built against a specific database interface; data accumulated over time; moving an application to another system became a difficult and expensive project. That friction helped support the high margins of businesses such as Oracle and SQL Server, as well as later database companies.

AI does not remove the need for databases. It changes the work behind the switching cost. Models such as Claude or Codex can write against database interfaces, which are unusually well specified. Agents also do not tire of repetitive translation work. A migration that once ranked among the most disruptive projects in enterprise software can become comparatively routine if a company is willing to allocate resources to it.

Cheaper experimentation should create more applications, each of which still needs a data system beneath it. But the criteria for a strong database business are changing: cost, the ability to scale from near-zero usage to a large workload, rapid provisioning and teardown, and portability matter more than the old protection afforded by an embedded interface.

That inversion applies to SaaS companies more generally. Vishria’s warning is not simply that they need to ship AI features. A company can faithfully execute a pre-AI strategy while preserving the wrong business model.

For much of the software era, management discipline meant setting a plan, executing aggressively, meeting or beating it, and compounding the result. That muscle memory becomes dangerous when AI changes what customers value, how quickly products can be rebuilt, and what new entrants can offer.

Vishria recalls an earlier blunt message to SaaS companies: adapt to AI or risk being valued at three times revenue. Many public SaaS companies trade above that level, but his comparison is with 2021, when similar businesses could trade around 30 times revenue. A company could grow fourfold and improve toward breakeven yet still be worth less if its valuation multiple declined by a factor of six.

The mistake is to treat AI as an after-hours project while the established business remains the daytime priority. Vishria cites Ann-Leigh Skates’s description of executives who ran their legacy businesses from 8 a.m. to 5 p.m. and tried to “do AI” in the evening. The required move is the inverse: reassess the legacy plan through new competitive conditions rather than attach AI to an unchanged plan.

That also affects leadership and go-to-market. Vishria has seen talented operators trained in the prior generation of software join scaling AI businesses and “completely flame out.” Their underlying ability is not necessarily the problem. The mismatch is between lessons developed on a relatively stable software substrate and companies whose products, costs, and demand patterns move with model capability.

A conventional software-sales model begins with quota capacity: set a target per representative, discount for attainment, assign territories, and build a forecast. That framework assumes the company must push demand through a sales organization. Some AI businesses, Vishria argues, are instead “selling magic”: they demonstrate a capability customers immediately want. In that situation, quota capacity still matters, but it may not be the first-order constraint. He has seen representatives sell $10 million, $20 million, or $30 million; Patrick O'Shaughnessy says he has recently seen $50 million.

The best salesperson in these companies is often the founder. The work is connecting a customer’s actual problem to what models can reliably do at that particular moment. Companies that retain old planning discipline without rebuilding that bridge can mistake orderly execution for progress.

Eric Vishria describes the AI-native advantage as a capacity to repeatedly discard recent work as models change. Bret Taylor’s term for this is “sandcastles.” Older software companies built castles: carefully engineered structures intended to stand for years. AI companies need to assume that a model release may wash away six months of product assumptions.

The relevant technical condition is what Vishria calls the “jagged edge” of AI capability. Models do not improve on a smooth, intuitive human learning curve. They may perform extremely well on one task, fail on a closely related one, and acquire a useful capability in the next release. Product builders need to know where those uneven boundaries sit, understand which customer workflows can accommodate them, and build around both strengths and failure modes.

Sierra is his application-layer example. The company began in customer service and has extended into longer-running agents through Horizon. It may look like an application company from the outside, but its work depends on experimentation close to the models: building agents, developing harnesses, and learning which tasks are dependable and which are not.

Sierra’s role, in Vishria’s framing, is to act as an enterprise customer’s “AI sherpa.” It spans model capabilities and the workflows, constraints, and expectations of a large customer. A company that understands only the technology may fail to deploy it usefully; one that understands only the enterprise problem may build around capabilities that have already changed.

That is why he thinks the traditional division between product management and engineering fits AI work poorly. In the older model, product managers translated customer needs into requirements and engineers determined the implementation. With AI, people making product decisions need to understand customer problems and the technical boundary at the same time.

The useful distinctions are less about job title than about three capabilities: understanding customer problems, having taste, and being curious about the jagged edge of model performance. An engineer, designer, or product manager who combines all three can be effective. Someone who lacks the technical curiosity to understand where models work and fail will struggle to specify an AI product from a distance.

Cursor is the example Vishria uses for this continual reorientation. He points to its movement from an integrated development environment to tab autocomplete to agentic work. The important pattern is not a particular feature but the company’s willingness to change what it is optimizing for as model capability changes.

Fireworks supplies the infrastructure counterpart. It serves open-source models on Nvidia hardware, much as cloud providers, neo-clouds, Baseten, and Together do. From outside, such a business can appear to be a commodity or a pass-through reseller. Vishria’s observation is that the operational differences can be substantial.

He describes Fireworks as roughly five times faster than a cloud provider on the same open-source model and Nvidia hardware, with an additional multiple-X throughput advantage that users may not see directly but that matters to the company’s economics. The company, in his telling, can pay cloud-provider margins and still make money.

Serving models with two-trillion-, three-trillion-, or four-trillion-parameter scales is hard enough to create differentiation even when visible inputs are shared. Operational excellence—how efficiently a company runs the model, not merely which hardware it buys—can be a moat. The same stack description can conceal sharply different speed, throughput, and cost structures.

Eric Vishria grounds his case against zero-sum thinking in cloud computing. When Amazon launched S3 and EC2 in 2006, he recalls, many sophisticated investors treated AWS as a commodity business without durable margins. By 2014, the fear had reversed: AWS would consume not only infrastructure but enterprise applications, using Amazon’s cost structure to underprice the rest of software.

That did not happen. AWS became the largest provider, but Azure and Google Cloud grew into major businesses. Snowflake competed with Amazon Redshift while running on Amazon; Vishria describes that as “out-Amazoning Amazon on Amazon.” Confluent, Elastic, MongoDB, Databricks, and Datadog became important businesses in markets where Amazon had offerings or could have competed.

Vishria characterizes the major cloud providers as roughly a 40–30–20 split, while also pointing to Cloudflare as another large cloud business outside those three. There was “tons and tons of roadkill.” But the market was large enough that one provider could not scale quickly enough to absorb every valuable layer of it.

He thinks AI may rhyme with that pattern, but at much greater speed. The claim that one model lab will “do everything” understates the infrastructure required to scale intelligence: energy, power, data-center capacity, chips, memory, algorithms, and deployment systems. Vishria expects an oligopoly of major winners, alongside smaller businesses that could still reach $100 billion in value.

That view also informs Benchmark’s internal debate about where AI value accrues. Vishria sees opportunities in foundation models, cloud-service providers, neo-clouds, inference platforms, specialized chips, edge inference, and large data-center models. Several layers can sustain major businesses at once.

“Everything works” does not mean every company works. Most companies in each layer will fail. The implication is more demanding, not less: differentiation must be real enough to survive in a large market with intense competition.

Enterprise demand is part of the case for market breadth. Blue-chip companies are not yet using AI in the way AI-native startups do, but Vishria sees a much different posture from the early cloud era. Large enterprises are experimenting, spending, discussing the technology internally, and trying to determine what it means for their businesses. They see AI as both a larger opportunity and a larger threat than cloud was at a comparable point.

He thinks many enterprises need help crossing from experimentation to deployment. Companies that can be an “AI sherpa”—understanding both an enterprise workflow and the model capabilities relevant to it—can create value in that transition.

The limiting factor may not be interest. Vishria worries more about energy. He frames models as systems that translate compute into intelligence. If demand for intelligence continues to rise, demand for compute should rise with it. Compute, in turn, requires energy.

He says China is bringing on roughly 10 times as much energy as the United States in the following year. If energy becomes the binding input, less available energy means less intelligence, fewer tokens, or more expensive tokens. Higher token prices would constrain usage through ordinary supply and demand. In Vishria’s account, power availability is not peripheral infrastructure policy; it may set the economics and attainable scale of AI deployment.

He does not argue for a narrow bet on one energy source. He mentions solar, nuclear, gas, gas turbines, rare earths, and other supply-chain inputs, arguing for development across all of them. The strategic priority is expanding the energy capacity that makes compute possible.

Eric Vishria uses Cerebras, robotics, and radiology to make a common point: a compelling technical possibility does not become commercial value automatically. Hardware must survive manufacturing reality. Robotics needs a data pipeline that does not yet exist at internet scale. Healthcare has reimbursement, liability, workflow, and data constraints that model performance alone cannot dissolve.

Vishria invested in Cerebras in 2016, when the company consisted of five founders and a deck. Its proposition was simple enough to be legible: GPUs were far better than CPUs for deep learning, but they were not necessarily the optimal hardware architecture for the workload.

He reduced the opportunity to three levers: increase the number of cores, improve communication between cores, and bring memory closer to compute. Cerebras pursued all three with a wafer-scale chip, described at the time as having roughly 450,000 cores and about 20 gigabytes of on-chip SRAM.

AI, in his account, created a workload that GPU parallelism did not fully solve. Neural-network layers made it partly communication-bound: data needs to move effectively among cores, not merely be processed by a large number of them.

The architecture was conceptually straightforward. Making it work was not. A logical block diagram can represent much of the path in software; in hardware, Vishria says, it may represent only 2%. Semiconductor systems must survive physics, manufacturing, packaging, compilers, kernels, and a broad vendor supply chain. Cerebras received its first parts around 2019 and had a first working system around 2020, after repeated stages of bring-up.

Simulations provide a performance roofline: the best theoretical result a system could achieve. Reality takes performance away from that ceiling. Vishria says a system may begin at roughly 10% of its simulated maximum, then require years of work on software, compilers, and kernels to get closer to it.

Cerebras at one point was “melting,” he says, despite having raised hundreds of millions of dollars. The experience has not made him less interested in ambitious hardware efforts, but it has made the difficulty vivid. Conventional objections to such projects are usually right, he says—perhaps 19 times out of 20, or even 99 times out of 100. The venture question is whether there is a credible path for an unusually hard project to go right.

He still expects AI to create specialized compute winners, as prior computing generations produced large companies around CPUs, graphics, networking, and mobile. He also sees a possible new CPU category: LLMs generate code that runs on CPUs, while existing CPU designs carry constraints accumulated over earlier eras. But the payoff for an investor is inseparable from the execution burden. Hardware companies do not control their full stack; supply chains, manufacturing partners, memory availability, and geopolitics can determine outcomes.

Robotics has a different bottleneck. Repetitive tasks in controlled environments are already widely addressed. The harder challenge is dexterous work in unconstrained physical settings: handling arbitrary objects, adapting to variation, and acting reliably outside a carefully designed production line.

Large language models could be bootstrapped on internet-scale human knowledge. Robotics has no comparable corpus of embodied activity. Companies are using video, simulation, and teleoperation to fill that gap. Vishria thinks the promising route begins with high-value data, not simply a large volume of demonstrations: build a useful base model, then use smaller amounts of post-training and reinforcement-learning data to extend it to new tasks.

Sunday Robotics, a Benchmark investment, is pursuing that approach through vertical integration of robot, model, and data collection. Vishria says the company uses gloves designed to map directly to its robot hands, allowing teleoperated demonstrations to transfer more effectively into training data. The intended loop is high-quality data, pretraining, a capable base model, and iterative post-training that produces new behavior.

A later visit made that loop more concrete to him. The original demonstration involved a “totally janky cardboard glove thing” in a Stanford basement. Later, he saw roughly a dozen robots folding arbitrary laundry in an office-building basement. What persuaded him was not a polished demonstration but the evaluation loop: people removed the clothes, measured whether they had been folded properly, and established a rigorous baseline.

Laundry is useful because it is arbitrary, dexterous, and not time-sensitive. If folding takes longer than a person would take, that may still be acceptable. Yet Vishria treats the task as secondary. The commercial and technical payoff depends on whether a company can build a training flywheel that makes capabilities multiply across tasks.

Radiology supplies the institutional version of the same constraint. Vishria recounts Jeff Hinton’s 2016 argument that training radiologists should stop because AI would become better at reading medical images. He does not reject the technical premise. Models may be able to outperform people on particular image-reading tasks, and Benchmark has invested in NewLantern, which is working in the area.

But the full work of a radiologist is broader than a narrowly trained model’s task. There is no single comprehensive training dataset containing the full range of cases a radiologist handles. A company can become strong at chest CTs or another defined category, while a radiologist may interpret X-rays, CTs, MRIs, and scans across many parts of the body in a single day.

Healthcare also reimburses doctors for readouts and allocates liability for errors and missed findings. Those payment structures, legal responsibilities, and clinical workflows remain part of the adoption problem. Vishria expects AI to help radiologists improve throughput first, with AI and clinicians dividing and checking parts of the work. The system may gradually allow AI to read more scans, but that transition could take a long time.

Meanwhile, lower imaging costs may increase the number of images created. The near-term result, he argues, may be a need for more radiologists rather than fewer. Data quality and institutional integration govern adoption speed; model capability alone does not determine the labor-market outcome.

Eric Vishria describes himself as an investor second and a partner first. An opportunity can be “investment grade”—a business likely to work and make money—without meeting his standard for investment. He wants mutual chemistry with founders: a relationship in which both sides learn, challenge one another, and improve the company’s decisions.

One test is whether he could honestly persuade someone he cares about to join the business and explain why it could become that person’s life’s work. Another is what Patrick O'Shaughnessy calls the “green button test”: if the founder calls at 9 p.m. on a Saturday, will he answer? Vishria says the answer is generally obvious.

He also asks whether success would matter. Some companies can be well run but should not raise venture capital, he says, because they do not create enough equity value even if they are right. The question is not only whether a business can succeed. It is whether anyone will care at the scale required for a consequential outcome.

Benchmark’s move into growth investing follows the same emphasis on exceptional outcomes. Historically, Vishria says, early-stage investing and high cash-on-cash multiples were nearly synonymous. Limited partners invested in venture capital not to outperform an index by a few percentage points, but for the chance to earn extraordinary multiples.

As company outcomes and markets have grown, he believes some high-multiple opportunities now exist beyond the earliest stage. Benchmark’s intention is not broad exposure or a departure from high-conviction investing. It is to pursue rare companies where the potential outcome remains unusually large, even if the entry price is higher than a traditional venture round.

He acknowledges that Benchmark may be late to that opportunity. The decisive issue was building a team able to evaluate later-stage companies differently. The firm had seen situations where it had the right intuition but did not act because an opportunity sat outside its established box.

Large outcomes cannot be fully modeled at the beginning. Timing and external conditions matter, particularly in hardware, where companies do not control their full supply chain or the geopolitical conditions around it. Vishria’s preferred analogy is golf: practice gets the ball close to the pin; a hole-in-one is luck. The way to improve the odds of luck is to create more close shots.

In venture, that means working with unusually capable people on opportunities whose eventual scale is not bounded in advance. Vishria has made 18 investments over 12 years, a small number by design. High conviction and high commitment are not substitutes for luck, but they are his way of increasing the number of situations in which luck can matter.