Amazon CEO: Merely Adding AI to Legacy Products May Not Secure the Future

In a conversation with a16z's Ben Horowitz and Erik Torenberg, Amazon CEO Andy Jassy shared the story of a weekend prototype: on a Thursday, the team finalized a concept for a consumer-facing Agent; four or five employees collaborated over the weekend, and by Sunday, they had produced what he described as an approximately 80% deliverable working prototype. An Agent is an AI assistant capable of invoking tools and executing tasks sequentially; here, 80% reflects his estimate of prototype progress. This case illustrated two key judgments from the interview: AI will transform how teams organize, and it will change the kinds of products enterprises must build.

On one side stands Amazon's projected total company-wide capital expenditure of approximately $220 billion for the year; on the other lies an adjustment in team size and working methods. Jassy expects that the hyperspecialized division of labor—where an employee was responsible solely for pricing—will be challenged, and companies will rely more heavily on small teams that leverage AI tools to drive projects cross-functionally.

Organizational Reinvention: Moving from Over-Specialization Back to Small Cross-Functional Teams

Twenty-nine years ago, when Andy Jassy joined Amazon as an assistant product manager, he was responsible for roughly five products at once. But as the company expanded and its product portfolio grew heavier, large corporations broadly adopted much finer divisions of labor: a product manager often oversaw only the pricing component of a single product. Many have come to view such extreme specialization as the default path to scaling a business, but Jassy argues this assumption does not hold—and demands thorough reconsideration as AI becomes pervasive.

This operational acceleration shares an underlying logic with the genesis of AWS (Amazon Web Services). Years ago, Amazon discovered that internal product teams were spending 70% to 80% of their time repeatedly building foundational infrastructure—compute, storage, and databases—leaving only 20% to develop truly differentiated product features. By turning foundational capabilities like compute and storage into shared cloud services, teams were freed from repetitive toil. In Jassy's view, large models are driving a similar shift: he sees models advancing work across diverse functions like coding, customer service, analysis, and research to roughly the 80% mark, allowing humans to pick up the task from a significantly higher starting point. Consequently, small team members can transcend previous functional boundaries and collaborate to deliver a complete initiative.

Inside Amazon, this shift is illustrated by two concrete cases:

In foundational engineering, Bedrock is the service enabling customers to access models, while inference refers to a trained model processing new inputs to produce results, supported by an inference engine. The Bedrock team had 6 engineers rewrite the inference engine in 76 days; according to an estimate shared in the interview, the same task might previously have required approximately 40 people over a year. In application exploration, when a consumer-facing Agent concept was agreed upon on a Thursday, 4 to 5 people collaborated over the weekend to build what Jassy considered an approximately 80% deliverable working prototype by Sunday. This percentage reflects prototype progress, highlighting how a small team equipped with cross-functional tools can validate a concept in a dramatically compressed timeframe.

This willingness to revisit established operational patterns was also visible in Amazon's earlier overhaul of its fulfillment network. That was an adjustment to the logistics network itself: during the pandemic, driven by urgent demand from customers and sellers, Amazon prioritized rapid expansion, doubling the size of a fulfillment network built over 25 years within just 18 months, and rapidly erecting a last-mile delivery system rivaling legacy carriers, even though many components remained unoptimized at the time. That rapid expansion inevitably brought cost and efficiency pressures. The team confronted the inefficiencies head-on using real metrics and candid discussions, subsequently restructuring the national US network into a regionalized model. By placing inventory closer to customers and shortening transit distances, Amazon managed both to cut costs and accelerate delivery.

Confronting shifts in technology and the external environment, organizational structures and staffing levels face corresponding adjustments. Looking at future job changes, Jassy expects that because substantial portions of coding, customer support, and analysis can be driven by Agents, fewer people will be required in existing individual roles compared to the past practice of adding headcount linearly with business scale. At the same time, the evolution of fields like AI, robotics, and space will spawn a wave of new roles—both known and yet to be discovered. He stopped short of drawing a definitive conclusion on net societal employment gains or losses, but emphasized that companies internally will rely more on smaller, cross-functionally collaborative teams to explore new business.

The urgency for large enterprises to accelerate this organizational restructuring is further intensified by speed pressure from startups. Jassy observed that many emerging companies today are agent-native or AI-native from inception, and mature incumbents must find ways to match that pace of building. In his view, among large corporations with extensive operations and loyal customer bases, some will inevitably move slowly—and those that move slowly will be far more vulnerable to challenges from startups.

Capital Expenditure of ~$220 Billion: The Cash Cycle of Data Centers and Servers

Running parallel to organizational adjustments is a dramatic acceleration in infrastructure construction. Amazon projected its capital expenditures for the year to reach approximately $220 billion. The core context underpinning this decision is the extraordinary pace of business expansion: in the interview, Jassy pointed out that three years into the launch of early AWS, the annualized run rate (an extrapolation of annual revenue based on the current run rate at that time, rather than three-year cumulative revenue) was roughly $60 million; in contrast, during the first three years of generative AI, the annualized run rate of AWS's internal AI business alone exceeded $25 billion, demonstrating that current demand is expanding at a tempo far outstripping the early cloud era.

Addressing concerns over the impact of capital expenditures on free cash flow, Jassy explained the investment and recovery cadence—the cash cycle—for two distinct classes of AWS assets:

First are data center land, physical shells, and electrical power infrastructure. This portion requires capital commitments approximately two years in advance before servers can be installed and revenue can be generated. These assets have an estimated useful life of about 30 years and represent upfront sunk capital; however, a long asset life does not automatically guarantee 30 years of steady cash returns. Because data center construction requires concentrated upfront cash disbursements, building facilities at massive scale simultaneously during a high-growth phase creates heavy early cash outflows while revenue collection lags, visibly depressing free cash flow in the initial phase.

Second are servers, accelerator chips, and networking hardware. Lead times for procuring this equipment are comparatively short—typically just a few months—allowing the company to commit capital based on clearer signals of customer demand. Hardware investments achieve breakeven in roughly 3 years on average, with a useful life of about 5 to 6 years; he also mentioned that most of the relevant deals being executed at the time carried roughly five-year terms. If subsequent demand falls short of expectations, the company can cushion future spending by slowing or curtailing server purchases. However, because upfront data center construction costs are already committed, ongoing power, maintenance expenses, and facility utilization will continue to affect overall cash flow.

Furthermore, the large-scale construction of data centers has sparked debates across communities and public policy. Jassy noted that modern digital services across finance, healthcare, and e-commerce already fundamentally rest on data centers; he likened current AI compute infrastructure to the national highway and bridge construction of the 1950s, arguing that slowing down construction would risk falling behind other nations competitively. Addressing external concerns over resource consumption, he compared the total water consumption of the golf industry with all of Amazon's data centers, noting the latter consumes far less; he also pointed out that backup generators run only during rare maintenance windows. On grid load, he argued that the electric grid itself requires investment and modernization, and as capacity expands, electricity rates in certain regions may stabilize over the long run. At the same time, he emphasized that data centers generate substantial local tax revenue (such as approximately $3 billion in taxes for St. Joseph County, Indiana), and Amazon has committed $1 billion over the next five years to surrounding communities through its Built Together program—underscoring that growth must be balanced through public-private partnerships rather than treating expansion as an entitlement simply because demand is strong.

Barbell Demand and Resource Allocation: Trade-offs Between Long-Term Customers and Compute Battles

Even with massive capital expenditures, compute supply remains tight. According to Jassy, among large blocks of compute capacity, available capacity for the current year is essentially sold out, the following year is largely spoken for, and even a considerable portion of the year after that is locked up; nonetheless, AWS continually reserves a proportion of on-demand capacity in services like Bedrock and EC2, so not every resource is booked solid. He also anticipates that supply constraints on critical components will not be eliminated overnight and could persist for several years.

In the current market, Jassy observed a 'barbell' distribution in compute demand—heavily concentrated at the two ends, while the middle remains largely untapped:

Actual AI usage today is clustered at the two ends of the barbell: on one end are frontier AI labs consuming staggering amounts of compute, alongside a handful of breakout applications like ChatGPT and Claude Code; on the other end are concrete enterprise use cases deployed to cut costs and boost efficiency, such as customer support automation, fraud detection, and workflow automation. A single enterprise might employ AI in customer support while many of its other business applications continue to operate as before. What Jassy terms the middle of the barbell consists of the countless existing applications that keep enterprises running day to day: some already invoke models, but the overwhelming majority have yet to broadly integrate inference. In Jassy's view, while current usage is heavily polarized at both extremes, this vast cohort of everyday production systems in the middle represents the single largest volume of potential future growth. He believes this adoption will expand year by year; over a five-to-seven-year horizon, a significant number—perhaps even the majority—of existing enterprise applications could broadly utilize inference.

This supply-and-demand dynamic also forces real trade-offs in resource allocation. Amid constrained memory supplies, vendors must decide how to allocate between High Bandwidth Memory (HBM) for AI accelerators and standard DRAM for general-purpose core servers. In the interview, the hosts posed a hypothetical question: facing frontier labs willing to pay steep premiums for power and chips, would cloud providers be tempted to buy back or squeeze existing customers' standard compute allocations to resell at higher prices?

In response, Jassy framed Amazon's decision around the logic of long-term customer success. In fields like financial services and healthcare, many established enterprises have relied on AWS to power mission-critical operations for years. Squeezing standard capacity expansions for longtime customers just to capture short-term premiums would erode hard-earned trust. He recalled that during the pandemic, AWS proactively helped customers optimize cloud architectures and trim spending; even though this reduced Amazon's cloud revenue in the short term, helping customers succeed over the long run ultimately fueled cloud growth. Therefore, Amazon's strategy is to aggressively expand supply, ensuring mission-critical production systems run uninterrupted while supporting AI business growth—all while keeping supply expansion economically sustainable.

In-House Silicon Evolution and the Inference Cost Threshold

For the massive volume of mainstream enterprise applications in the middle of the barbell to steadily adopt inference, Jassy believes success hinges both on internal organizational capabilities—such as model fine-tuning, post-training, and prioritization—and on inference costs. Although inference expenses have dropped over recent years, in his view, costs remain roughly an order of magnitude too high for universal adoption—meaning they must decrease to approximately one-tenth of current levels. If an enterprise rewrites applications running on general-purpose CPUs to be powered by AI accelerators, high compute costs demand that the refactoring deliver significantly greater incremental business returns. Lowering inference costs is essential to lowering the threshold for enterprises to overhaul their operations.

This demand for price-performance drove the three-stage evolution of Amazon's proprietary silicon:

1. Dedicated Network Interface Cards (NICs) to Offload Overhead: When Amazon acquired chipmaker Annapurna Labs, the original intent was to solve an earlier challenge: virtualization, networking, storage, and security consumed too much server overhead. By co-developing specialized NICs to offload these foundational components, the goal was to free up as close to 100% of server resources as possible exclusively for customer compute.
2. General-Purpose CPU Graviton: In general-purpose compute, dominant market vendors lacked strong incentives to dramatically improve price-performance. The Annapurna team subsequently built the Graviton CPU. According to Jassy, Graviton delivers roughly a 40% price-performance improvement over comparable x86 processors, and 99% of AWS's top 1,000 EC2 customers have now adopted it broadly.
3. AI Accelerator Trainium: Facing an accelerator market dominated by a single supplier, Amazon assembled a team to develop Trainium, a chip dedicated to training and inference. As Jassy described, it delivers approximately a 30% to 40% price-performance advantage over comparable processors.

Progress in proprietary silicon has also complemented partnerships with leading AI labs. Amazon's investments in Anthropic and OpenAI weighed the strength of their engineering teams, the caliber of their models, their robust commercial growth, and long-term business synergies. Operationally, Anthropic integrated its models into Bedrock and builds on Trainium; for OpenAI, both parties worked to bring its models to Bedrock while collaborating on a stateful runtime environment, and like Anthropic, OpenAI made multi-year, multi-gigawatt compute commitments to Trainium. In Jassy's view, because Agents must maintain context and execution progress across complex tasks, stateful runtime environments represent a critical requirement for building future Agents.

Urgent Real-World Risks: Cybersecurity and Code Response Speed

Compared to the distant risks dominating public discourse—such as rogue botnets running amok or malicious intent injected into robots, which Jassy acknowledges are possible future risks requiring industry and public sector collaboration—he emphasized that the more immediate and underestimated near-term threat lies in cybersecurity. Large language models can identify countless system vulnerabilities that human engineers previously overlooked, dramatically accelerating the efficiency of vulnerability discovery.

What severely compresses the defender's window is the acceleration of attack methods. AWS's technical documentation on Continuum points out that attackers leveraging frontier models can write functional exploit code within minutes of a vulnerability disclosure. In contrast, current enterprise security workflows follow an extensive chain from vulnerability identification and triage to patch development, testing, and deployment; even if a patch is developed rapidly, complex system dependencies still delay rollout. Facing this operational imbalance, Jassy argues that future systems must achieve minute-level responses to security threats.

This expectation imposes new demands on software architecture: enterprises will need to rewrite or adjust code to make it agentically capable, allowing Agents to assist in updating code snippets within strictly defined guardrails and boundaries. Concurrently, combining large models with automation helps defenders expand the scope of penetration testing (simulated attacks to discover latent vulnerabilities), probing blind spots that human teams previously lacked the bandwidth to reach. To support this defensive loop, AWS launched the Continuum security service, which currently validates vulnerabilities and generates patches or pull requests while requiring human review and approval for remediation; the official team cited automated remediation within predefined constraints as a future roadmap direction once sufficient confidence is built. Navigating this balance in production—achieving minute-level response times while ensuring automated changes remain rigorously controlled—remains an ongoing engineering challenge for enterprises.

Core Business Reinvention: Rethinking Everything from Alexa to Legacy Franchises

During the interview, the participants categorized enterprise AI adoption into three tiers: the first is using AI to trim baseline costs across legal, finance, and customer service; the second is building novel, unprecedented products from scratch; the third is systematically redesigning established, successful products.

In Jassy's view, when confronting generational technological shifts, companies that view AI merely as a tool for incremental improvements may well fail to preserve a leading product experience three to five years down the road. Teams must break out of their existing frameworks and ask a foundational question: "If we were building this from scratch today with all the new AI capabilities available, what product experience would we design?" Take the voice assistant Alexa: its original "brain" architecture was pioneering, but with the advent of generative AI, the experiences modern technology can power are fundamentally different. He believes Alexa's "brain" must be reinvented to deliver a competitive experience over the long term.

Amazon's technical overview of Alexa+ illustrates this with a specific task: a user asks it to book lunch at a favorite restaurant and notify a friend of the plan. Fulfilling this request requires invoking a reservation service first, followed by a messaging service to notify the contact; a model generating a conversational reply has not actually booked the table or sent the text. To solve this, Amazon rebuilt its architecture for orchestrating external services, enabling models to string together multiple service calls. The system must also verify information, route requests to the right model, and manage latency so these actions execute accurately and promptly. This illustrates what "replacing the brain" entails: when the user tasks an application is expected to fulfill fundamentally change, the underlying systems executing them must be redesigned accordingly.

Such reinvention routinely encounters dual inertia: on one hand, engineers develop deep affection for systems they built by hand and hold operational doctrines honed by past experience, naturally clinging to practices proven to work in the past; on the other hand, many existing customers develop attachments to familiar workflows. Jassy pointed out that driving fundamental transformation requires that the new technology, product experience, and business justification be overwhelmingly compelling. Even then, managing the transition remains an arduous change-management challenge—much like the earlier push migrating traditional IT from on-premises data centers to the cloud, requiring a shift in both mindset and ingrained habits.

In Jassy's view, this rethinking is not confined to voice assistants. Across mature businesses such as retail e-commerce, Prime Video, Fire TV, and Prime Music, Amazon is pushing teams to imagine what a clean-slate rebuild would look like. While these businesses may not face the immediate urgency of voice interfaces today, he worries that incumbents content with local, incremental adjustments to legacy products may struggle to sustain a superior experience three to five years from now.

Reimagining from scratch does not dictate an all-or-nothing replacement on day one, nor will teams get everything right on the first try. In execution, enterprises can pursue flexible paths: they can incubate standalone new applications first, or gradually blend iteratively validated elements into the core experience, transforming the overarching user journey progressively over the coming years.

Leverage Points for the Next Generation and Management Criteria for Multi-Track Growth

Advising the younger generation on navigating AI, Jassy suggested embracing rather than avoiding the tools—actively learning them, using them frequently in daily life, and daring to tackle tasks outside their comfort zones. He noted that neither of his two children are software developers, yet both actively learned to build applications with AI and integrated them into daily work. Using business school case studies as an example, where reading cases, extracting charts, and synthesizing takeaways historically consumed vast amounts of time, AI now allows individuals to complete that initial information gathering and organization far more rapidly.

Yet he cautioned that tools cannot replace critical thinking and synthesis. While models help individuals reach an elevated starting point much faster, assembling disparate pieces into a cohesive business strategy, product logic, or actionable roadmap still relies heavily on human judgment, creativity, and experimentation.

On the question of how large corporations manage multiple sprawling business lines simultaneously—a frequent source of external skepticism regarding whether Amazon is stretched too thin—Jassy argued it boils down to organizational structure and commitment. In pursuing diverse ventures like AI, robotics, low-Earth orbit satellite communications (Amazon Leo), autonomous driving (Zoox), and healthcare, Amazon favors a decentralized, dedicated structure: assigning discrete teams with dedicated leadership and focused builders, avoiding burdening the same managers with disparate businesses. Deciding whether to enter a new domain hinges on several criteria: whether the experience could move the needle if scaled, whether the team holds a differentiated perspective, whether customer needs in that space remain poorly served, and whether the company possesses the conviction for sustained, long-term investment.

Jassy also emphasized that focusing exclusively on a core business and cultivating it deeply is equally a highly successful strategy. For enterprises choosing a multi-track approach, the key to navigating technological shifts lies in maintaining steady growth in the core business while proactively leaning into secular trends with the right teams and long-term stamina to solve unmet customer needs.

Smaller teams can explore new ideas from an elevated starting point, while mature products must rethink the fundamental tasks they perform for customers. These two shifts define Jassy's core assessment of how companies must operate in the AI era.