As long-time technology investors, we’ve seen the lines between applications and infrastructure blur faster than at any point since the cloud era. Our Battery General Partner Dharmesh Thakker recently traced this shift in his LinkedIn post. The upshot: The cloud-computing era was venture investors’ golden age, and the winning bet was the “fat middle”–think databases, observability and security tools sitting between business applications and the raw infrastructure below them. The SaaS and data-infra layer sat comfortably above chips and compute that someone else—namely the hyperscalers—worried about. But today, with AI applications now tightly coupled to the data centers, chips and infrastructure running them, infra choices have become critical to drive margins and, ultimately, build a durable company.

The companies winning in AI right now don’t sit neatly on one side of that line; instead, they own the full stack, from dirt to tokens.

Let’s take Cursor as an example. Cursor started out as an AI-powered autocomplete tool, powered entirely by third-party foundation models—primarily OpenAI’s GPT-4 and Anthropic’s Opus. But it didn’t stay a code-completion plugin for long. It evolved into a fully agentic IDE (integrated development environment) and along the way began developing Composer, its own custom, specialized model that’s trained on how engineers actually work inside Cursor.

In doing so, Cursor became a fully vertically integrated AI company—data, model and harness—working together as one system. With SpaceX’s acquisition, it now adds compute for both training and inference. And tomorrow, if Elon decides to buy or build a chip, Cursor would become the first company outside of Google to own the entire stack, from chips to tokens.

Cursor’s path may end up as the reference architecture for winning agentic AI application companies. To pressure-test that thesis, we recently brought together VPs of engineering from top AI application companies and paired them with leaders on the AI infrastructure side (semiconductors, inference and model builders), over good wine and food. The topics of discussion: How are these once separate worlds converging, and what does it take to be a successful engineer in the era of AI?

Three shifts surfaced over the course of the evening’s conversation.

1. The full-stack AI thesis is now a real debate, not just a slogan.

For a decade, the SaaS era has taught us that infrastructure and applications could thrive as separate layers. The provocative question on the table: does AI break that? One camp argued that building an enduring AI company requires owning the entire chain: model, inference, and workflow, because that’s the only place durable advantage lives.

The journey to get there looks something like this. Start on frontier closed-source models from Anthropic or OpenAI to move fast and find product-market fit. Once you’re there, shift to open-source and open-weight models like GLM, Kimi and run your own inference for cost and control. The catch is that this migration is harder than it sounds: Prompt engineering is deeply model-specific, so switching models tends to break things in non-obvious ways. The teams that do this well treat model performance as a discipline, building deep evals and benchmarks so they can swap a model and measure whether quality holds. As one infrastructure leader at the dinner shared, his model performance team behaves like quantitative traders, hunting for “alpha” in kernel and matrix-multiplication optimization. One architectural change alone once made a customer’s inference several times cheaper overnight—proof that small inefficiencies, exploited at scale, generate real savings.

The counter-view held that SaaS-style layering still works, and not every application-software company needs to become a chip-aware model shop to succeed. What’s clear is that the answer is no longer obvious. The divide between senior engineering leaders is itself a signal that the old assumption—build on top of someone else’s model—is now in question.

2. Inference engineering is becoming a new muscle for every AI company.

Inference used to be something you outsourced to a model provider; increasingly, it’s a skill you build in-house. As more companies adopt open-source models and run their own inference, the know-how to do it efficiently is quickly becoming a core part of every platform org. The reason is simple economics: How well you serve a model directly determines your gross margin, so squeezing more out of every token becomes a first-class engineering problem rather than an afterthought.

A second, related theme: Training and inference are fundamentally different jobs, and require  different hardware to maximize token efficiency. Training is a massive, one-time push to teach a model; inference is the steady, latency-sensitive work of answering requests at scale. The clusters built for one tend to be poorly suited to the other. We’re already seeing the first signs of this split. Google recently divided its newest chip generation into two distinct designs, one tuned for training and one for inference. Expect more of that specialization as the agent era makes the mismatch too expensive to ignore.

3. Tokenomics and the second-order effects of coding agents

The economics of AI-native development are no longer rounding errors. One company at the table is spending roughly $1,000 per engineer per month on coding agents and expects to easily triple that with more capable models like Fable. Across a ~200-engineer org, that pencils out to $5–7M a year in token spend. This is a massive cost driver—one that is growing exponentially as agents take on more of the work.

This is pushing engineering teams to build their own internal systems to manage and optimize token spend. Most notably, LLM gateways that sit between engineers and the underlying models, routing each request to the most cost-effective model for the task and caching aggressively to avoid paying twice for the same work. Coinbase* is a good example. By defaulting engineers to cheaper open-weight models like GLM 5.2 or Kimi 2.7 through an internal gateway and layering in smart routing and caching, it cut its AI bill nearly in half even as token usage kept climbing. The broader signal is that cost management is becoming a first-class metric for engineering teams, sitting right alongside latency and reliability.

The next frontier: engineers who speak both languages

As the stack collapses into integrated systems, the most valuable engineers won’t be the ones who only build applications or only optimize infrastructure. They’ll be the ones fluent in both, who understand fine-tuning, distillation, and inference economics as readily as UX and workflow design, and who know when owning a layer creates real advantage versus when it’s effort better spent elsewhere.

This is quietly reshaping how the best companies organize. Roles are increasingly scoped not by which layer of the stack you own, but by the outcome you’re accountable for. It’s the organizational equivalent of the shift from per-seat to outcome-based pricing: Value gets measured by what’s delivered, not by where you sit in the stack. Teams still scoping roles layer by layer are leaving outsized leverage on the table.

Nowhere is this clearer than in how hiring profiles are evolving. The model-performance team barely existed eighteen months ago; today it’s one of the most sought-after functions in AI, and the profiles filling it would have looked out of place a year ago. Many are quant traders and HFT engineers, prized for their latency obsession, cost-per-cycle instinct and eval-and-backtest discipline that map almost perfectly onto serving models efficiently. Others come from a quantitative-science background, fluent in large-scale data, signal extraction, and constrained optimization, exactly the toolkit for squeezing more out of inference, fine-tuning, context and workflow orchestration, and even voice latency.

The trillion-dollar question of whether apps and infra ultimately merge or stay separate is still open. But the engineers preparing for the merged world are the ones we’d bet on.