There is great anxiety and uncertainty about AI replacing jobs. How can we move past vague warnings and bombastic predictions and bring data to bear on this question? One good way is to look at the profession where AI capabilities are furthest along and adoption has been exceptionally rapid: software engineering.

In this essay, we argue that there is enough evidence to reject the narrative that once AI capabilities reach a certain threshold, it will cause mass layoffs. Given that this is true even in a sector with very few regulatory barriers, most other professions are likely to be even more cushioned.

We also have a good understanding of why this is the case. We can think of many kinds of knowledge work, including software development, as a “decide-execute-deliver sandwich”. AI compresses the “execute” layer — the middle of the sandwich — but the other two layers resist automation in a way that will not be overcome by capability improvements alone.

We conclude on a note of cautious optimism about the future trajectory of demand for software engineering. This essay is the first in a series, and the next one will look at reasons why individual software engineers’ careers might be rocky even if overall demand is healthy. The series is based on the published literature in economics and software engineering, our own evaluations and observations of AI agents, and many software engineers’ reflection on the present and future of AI impacts on their profession, gleaned both from published writings and our interactions with the community.

The stories of AI-driven mass layoffs in software seem to be classic “AI washing”

Consider three stories that made the headlines and how they contrasted with reality:

• In February, fintech company Block (maker of Cash App, Square, Afterpay, and other such apps) announced layoffs of 4,000 employees because, according to founder Jack Dorsey, AI is “enabling a new way of working” with “smaller and flatter teams”, specifically citing late-2025 improvements in model capabilities.
  
  But subsequent reporting revealed a radically different picture. After growing headcount more than threefold during the pandemic, the company was under massive financial pressure. A data scientist on the Cash App team, Naoko Takeda posted that Block “shoved AI down everyone’s throats” yet she saw “very limited gains in productivity.” She refused a 75% retention raise and quit. Other employees interviewed had a sharply different understanding of what AI was capable of at Block and whether Dorsey had a competent understanding of the issues.
  
  As Aaron Levie has pointed out, CEOs are uniquely prone to delusions about AI’s usefulness because they can build quick prototypes but can’t see the 90% of work it takes to turn it into a finished product. Dorsey’s public statements about AI seem to fit exactly this pattern.
  

• In April, Snap laid off about 1,000 people, with CEO Evan Spiegel primarily citing AI as the reason in his layoff memo. He also said that AI generated 65% of new code. In reality, the layoffs followed a campaign by an activist investor demanding cost cuts. (Snap has posted a net loss every full year since its 2017 IPO and shares were down over 30% in 2026). Tellingly, the nature of the cuts, such as 150 jobs spanning various roles in the augmented reality division, don’t correlate with the cuts we would expect to see if they were driven by AI (i.e. programming and other “AI-exposed” jobs across the board, not concentrated in any unit).
  

• In May, Intuit announced 3,000 cuts, alongside deals with Anthropic and OpenAI. The press connected the two, framing the layoffs as AI-driven restructuring. For once, the CEO actually pushed back on this easy narrative, saying that “none of it had to do with AI” and that the cuts targeted “coordination-heavy roles” and too many management layers.

We did not cherry-pick these examples. In every story about AI-driven software engineering layoffs that we examined, the same narrative violation emerged. It turns out that “AI washing” of job cuts is an economy-wide phenomenon, evidenced by many surveys:

• 59% of U.S. hiring managers admitted they emphasize AI when explaining hiring freezes or layoffs because it plays better with stakeholders than citing financial constraints.

• Forrester principal analyst J. P. Gownder says of companies preparing supposedly AI-driven layoffs: “When we ask if they have a mature, vetted AI app ready to fill in those jobs, nine out of 10 times, the answer is no—and they haven’t even started.”

• In a HBR survey of over 1,000 global executives, 21% had made large headcount reductions “in anticipation of” AI, with another 39% having made low or moderate anticipatory headcount reductions. In contrast, only 2% had already made large reductions in headcount related to actual AI implementation. The 10x gap suggests that executives, like everyone else, are highly prone to succumbing to the misleading narratives about AI replacing jobs.

Another interesting data point comes from the WARN Act, which requires certain disclosures of plant closings and mass layoffs affecting over 100 workers. In March 2025, New York became the first U.S. state to add an AI disclosure checkbox to WARN Act filings. In the full first year, more than 160 companies filed WARN notices. Not a single one checked the AI box.1 We reached out to the NY Department of Labor who confirmed that as of late May, only one company, Nespresso, checked the box.2 If these filings are accurate, only 46 out of about 25,000 laid off workers in New York State in the relevant period, or about two-tenths of a percent, were affected by AI.

Even more damning for the AI-driven-mass-layoffs narrative: layoffs are the wrong signal of AI’s potential productivity benefits in the first place! The research is clear that the effect operates through “slower hiring rather than increased separations”. Firing existing workers results in the loss of precisely the tacit knowledge and organizational capital that allows workers to operate AI effectively. Besides, it is expensive in terms of severance, damage to morale, and rehiring risk. Given these costs, it is largely unnecessary given that natural turnover achieves the same result in a few years.

So what does the data tell us when we look beyond layoffs to overall employment trends? An important paper from Federal Reserve economists compiles the evidence in the U.S. context. Software engineer employment is still growing, but they find that it is growing slower post-ChatGPT compared to a no-AI counterfactual, by about 3 percentage points per year. One important limitation of this study is that the methodology can’t capture self-employment, so it is possible that some of the slowdown in growth is being absorbed by entrepreneurship instead. We do have evidence from other studies that AI makes entrepreneurship easier. So the real picture is probably even healthier than the Federal Reserve study suggests.3

Finally, it is worth acknowledging two kinds of indirectly-AI-driven job losses in software engineering that are real, but different from AI replacing software engineers. First, AI sometimes decimates demand for the product, in cases like Chegg (homework help) or Stack Overflow (technical help), both of which have laid off workers. AI doesn’t directly do the job that these workers did, but rather obviates the need for it. The historical parallel is strong: Among the 270 jobs in the 1950 U.S. census, only one job was automated away — elevator operator. But many others were rendered obsolete by new technology, like the job of telegraph operator.

Another credible AI-driven layoffs story is among companies that sell AI, rather than buy it. So when companies like IBM or SAP announce layoffs because of AI, a more accurate framing is “we reallocated headcount from legacy functions to our fastest-growing product line.” That’s ordinary corporate restructuring around a revenue opportunity, not technology displacing workers.

Why coding agents haven’t led to labor displacement: the decide-execute-deliver sandwich

Many tech leaders, like the Snap CEO above, report the percentage of code written by AI alongside reports of layoffs or predictions of future job losses. This feeds into the simplistic mental model that once AI writes all the code, there is no need for coders. Fortunately, this mental model is wrong. This AI-written-code metric is almost completely disconnected from what matters for labor displacement. Here’s why.

Writing code isn’t, and never was, the bottleneck. For example, a 2019 paper summarized existing studies with the conclusion that “developers spend surprisingly little time with coding, 9% to 61% depending on the study”. This finding was consistent with the paper’s own data from 6,000 developers at Microsoft. As coding agents began to be taken up, there was an explosion of blog posts in late 2025 pointing out that writing code isn’t the bottleneck, as developers realized that using agents to write most of the code led to little impact on overall productivity [1, 2, 3, 4, 5, 6, 7, 8].

If writing code isn’t the bottleneck, what is? The task-breakdown surveys point at things like meetings or debugging. This just leads to more questions: what are developers doing in those meetings and why can’t it be done by AI? Won’t debugging get automated as capabilities improve? To understand the real bottlenecks, we have to get qualitative, and dig into software engineers’ own understanding of what it is they do that resists automation.

When we did this analysis, it revealed three things as the real bottlenecks (1) deciding and specifying what to build, (2) verifying and being accountable for what is delivered, and (3) the deep human understanding — of the codebase, the business, and the environment — required to carry out both of these.

In other words, software engineers’ work consists of a “decide-execute-deliver” sandwich (with understanding being a prerequisite for all three). AI has compressed the middle of the sandwich, but has left the two ends largely unchanged. As long as software development teams are in charge of decision making and accountable for what they deliver, engineers still need to spend time building up a deep understanding of the system. These are the three bottlenecks.

Figure: Software development consists of three layers: (1) Decision making — problem framing, specification, planning (2) execution — design and implementation (3) delivery — testing, verification, integration, maintenance, etc. Note that these are conceptual layers, not temporal phases. It is common to switch back and forth in the course of a project.

Evidence for the sandwich model of AI’s productivity effects comes from a recent paper on “Writing Code vs. Shipping Code”. Across 100,000 developers on GitHub, the researchers found that AI agents led to an eight-fold increase in the number of lines of code written, consistent with the idea that AI almost completely compresses the Execute layer of the sandwich. But this led to only 30% more releases, strongly suggesting that human bottlenecks (the Decide and Deliver layers) remain in place.4

Can the sandwich be further compressed? We don’t think so. At one end of the pipeline, development teams need to decide what to build. One of the most important lessons junior software engineers learn is that requirements specification (the profession’s lingo for this layer) takes surprisingly long, and if it is compressed, it leads to much more pain down the line. This layer is hard to automate because it requires thinking about user needs, market signals, organizational priorities, and in some cases regulatory constraints.

As AI capabilities improve, the kinds of decisions that can be delegated to AI increase over time. But this does not make the “decide” layer thinner — once a decision can be delegated to AI, it is no longer a source of competitive advantage, and the value of human decision-making migrates upward. Software increases in complexity over time, so there is no ceiling to this process.

At the other end of the sandwich, human teams need to be accountable for what they deliver. It is possible that some day in the future teams will ship mission-critical code without fully testing and understanding it, but today’s AI is so unreliable that such haphazard practices would represent an existential threat to software teams and their customers.

Even if the technical barriers go away in the future, we don’t have to cede control to AI. A central insight of AI as Normal Technology is that we can collectively choose to keep humans accountable through shared norms, law, and policy. This is a much more resilient way to control the speed of AI impacts and improve safety than trying to slow the development of technical capabilities. These speed barriers are already largely in place due to liability laws and sector-specific regulation, but can be further strengthened. (For a longer version of this argument, see the original essay.)

In this vision, as more and more of the execution layer gets delegated to AI, the software engineer’s role in the future becomes analogous to that of a crane operator. AI agents will do most of the cognitive heavy lifting; supervising the agent and keeping it in control becomes most of the human’s job.

Some commentators argue that a future with humans staying in control is unlikely because it is too costly to pay people to do so. There have already been a few viral stories of poorly-supervised coding agents deleting production databases or causing other types of damage. But we view these as “man bites dog” stories rather than an emerging norm. They go viral precisely because they represent such irresponsible and unusual behavior that they have shock value, and serve as regular reminders and learning moments helping the community guard itself against over-reliance on AI. As the aphorism goes, “if it’s in the news, don’t worry about it”. Still, being able to detect whether there is an uptick in poorly-supervised use of AI for high-stakes tasks — across the economy, not just in software engineering — remains one of the most critical data gaps we have today.

By the way, the sandwich getting squished is a new trend and it is not uniquely due to AI. Over two decades ago, the Bureau of Labor Statistics started tracking programming separately from software engineering. Roughly speaking, programmers are responsible only for execution while software engineers manage a bigger part of the sandwich. Not only has programming been shrinking, it is also pays much less because it is seen as grunt work. AI merely accelerates this long-existing trend, further devaluing purely technical skills.

This pattern — where humans remain heavily involved at both ends of the decide-execute-deliver sandwich, even as AI increasingly automates the middle layer, seems to be broadly applicable to most knowledge work, though it is farthest along in software. After all, complex decision making and accountability are common to most fields. A lack of recognition of this phenomenon has led to many overconfident claims about imminent job losses, such predictions about AI replacing radiologists.

Vibe coding is not agentic engineering

One reason for confusion about the extent to which software engineering is changing is the sloppy use of the term “vibe coding” to refer to a wide spectrum of practices, the ends of which are conceptually distinct and more dissimilar than similar.

In true vibe coding the user simply tells the agent what to do, doesn’t supervise it when it’s running, doesn’t review the code — might not even have the skills to do so — and doesn’t evaluate the output, beyond perhaps noticing when things are visibly broken.

This is in contrast to how most software engineers are actually using agents — as a tool, with the human remaining in control and accountable for the output. Fortunately, the term agentic engineering is gaining currency as a descriptor of this practice.

As agentic engineering has become the norm, engineers are discovering that supervising coding agents is surprisingly time consuming. For example, Simon Willison, a prominent developer and chronicler of the AI transition, has noted how he is mentally exhausted by 11am from supervising agents. This is consistent with our experience as well.

More quantitative evidence comes from SWE-chat, a dataset of coding agent interactions from open-source developers who opted into a logging tool. The study found that only 44% of agent-produced code survives into user commits, that vibe-coded commits introduce vulnerabilities at nine times the human-only rate, and that the most common user intent is understanding existing code, not generating new code (19% vs 13%). The self-selected nature of the dataset means that we can’t draw strong conclusions based on this study alone, but it does reinforce many other lines of evidence that vibe-coding and agentic engineering patterns are quite different.

To re-iterate, these are not two distinct categories. They are two ends of a spectrum, and there is a blurry middle. Not every project is either a throwaway or mission-critical. Not every workflow fits precisely in the left column or the right column of the table. But the key implication for the jobs question remains solid — companies can’t ship production software by hiring unqualified vibe coders instead of software engineers.

What does the future hold?

AI boosters might claim that mass layoffs are coming; they just haven’t happened yet because human-level software engineering abilities are very recent (or haven’t been achieved yet). But if the sandwich model is correct, these predictions won’t come true. AI has already largely compressed the middle of the sandwich (and the compression actually started decades ago). So even making the execution layer instant and perfect will only be a small change from the status quo. The reasons why the other two layers have resisted AI is not because of capability limitations.

In fact, not only are software engineering jobs not going away due to AI, there might even be an increase in demand for software engineers. When software (or anything else) gets cheaper to create due to technological productivity improvements, people will buy a lot more software (in econ jargon, software is highly “price elastic”). And as we have argued, AI doesn’t replace software engineers (the “elasticity of substitution” is low), so the demand for more software results in a derived demand for more software engineers. A loosely related but flashier economics term, “Jevons’ paradox”, is often thrown around in the AI discourse to describe this concept.

Historically, this has been the pattern — programmer employment in the U.S. has grown from near-zero around 1950 to millions today. This is sharply different from occupations such as agriculture in which labor demand was famously decimated due to mechanization and automation. The difference is that the amount of calories people consume is relatively fixed — even a 25% increase led to the obesity epidemic — whereas the amount of software produced has grown a millionfold. Modern cars have something like a hundred million lines of code running on their various on-board computers.

If there is a ceiling to the demand for code, we are nowhere near it. Virtually all cognitive work benefits from software. As AI makes coding cheaper, people are creating all kinds of one-off utilities — whether for work or personal use — that it never made sense to create until now.

To be clear, while we think there will be a lot more software in the future, and likely more software engineers, this doesn’t mean big tech companies will get even bigger. The majority of software engineers today already work in-house in non-software firms, and that share might grow in the future. Then there’s the idea of “AI rollups”, which refers to venture capital or private equity firms buying “Main street” businesses — dentistry practices, accounting firms, and whatnot — and rebuild them from the ground up to be “AI-native” by embedding software engineers or AI engineers into those businesses. Of course, it might end up being nothing more than hype. It’s too early to tell.

Some people predict that demand for software engineering skills will fall because of democratization. They acknowledge that there will be more software produced than ever before, and also that more human time will be spent producing software than ever before, but that this work will be done by people who are not software engineers. The idea is that AI will democratize software engineering to the extent that legal software, for instance, can be more easily created by those with training in law than in software engineering.

Maybe. But we’ll bet against it. In our view, this falls into the same trap of conflating vibe coding with agentic engineering, and the execution layer with the the whole decide-execute-deliver sandwich. In fact, when we look at the history of programming, there have always been claims that we are at the threshold of democratization — old languages such as FORTRAN, COBOL, and SQL were all accompanied by such prominent hopes at the time of their introduction. It never happened. The barrier isn’t actually learning the syntax. It’s having enough skilled judgment to make good decisions while maintaining accountability.

Ultimately the distinction may be semantic. It seems clear that the amount of time people spend on getting computers to do new things will increase over time. This might take the form of building software, or managing complex workflows using agents, or something else. It will require a mix of software skills, AI skills, and domain expertise. Whether it is today’s software engineers who will best adapt to fill these new roles remains to be seen.

That last point about the need for adaptation sets up the next essay in this series. The fact that aggregate labor demand in software is likely to remain strong doesn’t mean that most individual workers won’t be affected. We will argue that AI will create massive structural shifts in how software is produced, which will have big impacts on which software engineers stand to gain or lose — based on the types of firms they work in, their geography, their seniority, the pace at which they can adapt.

Further reading

Deena Mousa points out the superficiality of broad, economy-wide analyses of AI impacts based on metrics like “AI exposure”, and instead calls for “careful, occupation-specific work”. We hope that this series of essays will play a role in establishing a nuanced understanding of AI’s transformation of software engineering. We’ve previous coauthored, with Justin Curl, a paper analyzing AI in legal services that seriously engages with regulatory and other bottlenecks that make that occupation unique. We plan to do more occupation-specific deep dives in the future.

In a remarkable essay called No Silver Bullet 40 years ago, Fred Brooks distinguished between the “essential complexity” and “accidental complexity” of software. He argued that some of the complexity of software is accidental, arising from limitations of present technology such as the clunkiness of programming languages, and can be alleviated over time as tooling improves. But some of it is essential, because specifying the correct behavior of software is itself hard. He presents a forceful articulation of why the “decide” layer of the sandwich is thick and resists automation. Interestingly, hopes of boosting programmer productivity through AI were already prominent back then! Brooks argues that because AI or any other technology only reduces accidental complexity, it won’t result in an order-of-magnitude productivity improvement. (Brooks is the author of The Mythical Man Month, an essay collection that is almost certainly the best known and most influential writing on software engineering of all time. No Silver Bullet later became part of the collection.)

We are grateful to Felix Chen for feedback on a draft.

This story appeared in The Logoff, a daily newsletter that helps you stay informed about the Trump administration without letting political news take over your life. Subscribe here.

Welcome to The Logoff: You’re paying for Donald Trump’s ballroom. And it’s getting even more expensive.

What’s happening? This is far from the first time The Logoff has written about the ballroom Trump is currently building on the site of the demolished East Wing of the White House — but bear with me. 

On Tuesday, the Washington Post reported new details about the structure’s cost and funding, including an estimated price tag of $600 million. Of that, more than half will reportedly be taxpayer dollars — not, as Trump has previously promised, money raised entirely from private donors.

The new price tag is also (another) significant leap in cost. When Trump first announced plans for a ballroom, he said it would cost $200 million — then $300 million, then $400 million. Now, it’s tripled in price.

What’s the context? Trump has already tried once before to get taxpayers to fund the ballroom: In May, proposed text of a Senate immigration funding bill contained $1 billion tucked away for an “East Wing Modernization Project” — the ballroom. That money was later stripped from the bill, however. 

Why is the ballroom so expensive? Based on Trump’s remarks, the ballroom’s planned security footprint (and its overall size) has grown substantially over time. It will now, according to Trump, include a “massive” subterranean military complex and a hospital, as well as “the greatest drone empire that you’ve ever seen.” 

The Trump White House has leaned on those national security features as a justification for the new construction, including after a shooting at an April press dinner attended by Trump and again this week, after an attack on Trump’s birthday fight night was reportedly stopped by the FBI (how the ballroom could have helped protect the massive outdoor event, exactly, is unclear). 

As the Wall Street Journal reported over the weekend, the ballroom is also being built at double time as the administration attempts to “outrun” court rulings that could stop it.

And with that, it’s time to log off…

I appreciated this reminder from my colleague Jonquilyn Hill that writing things by hand is good for our brains and we should take the time to do it more often. (I promised my editor I won’t start filing this newsletter in longhand, though.)

Plus, a World Cup thing: The Scotland fans chartering their own school buses.

Thanks for reading, have a great evening, and we’ll see you back here tomorrow!

As OpenAI files SEC paperwork ahead of an expected initial public stock offering, newly leaked financial documents show a company with quickly growing revenues that are currently being overwhelmed by even larger expenses.

The audited financial statements, obtained by independent journalist Ed Zitron, show OpenAI's reported revenue growing from $3.7 billion in 2024 to $13.07 billion in 2025. The Financial Times, which reviewed the same documents, writes that the company's monthly revenues had grown to nearly $2 billion by the end of 2025, suggesting that its ongoing revenue rates continued to grow throughout the year.

R&D expenses alone still easily outpace OpenAI's quickly growing revenues. Credit: Ars Technica

But the company's fast-growing revenues are still dwarfed by its even more significant expenses. OpenAI's total revenues in both of the last two years were outpaced by research and development alone, which grew from a $7.81 billion line item in 2024 to a massive $19.18 billion cost in 2025. Those numbers seem to reflect the significant costs OpenAI incurred in training new models and include $10.59 billion in R&D costs paid to Microsoft alone in 2025.

On top of that, OpenAI's "cost of revenue" (i.e., the money spent producing and distributing the product) increased from $2.65 billion in 2024 to $7.5 billion in 2025. This cost line likely reflects the significant compute costs incurred at "inference time" as the company's models respond to a growing number of user prompts. Costs associated with sales and marketing also grew from $1.11 billion in 2024 to $5.73 billion in 2025.

OpenAI's operating loss is shrinking as a percentage of revenue, but there's a long way to go before it becomes a profit. Credit: Ars Technica

All told, OpenAI's day-to-day "loss from operations" increased from $8.78 billion in 2024 to $20.92 billion in 2025, a concerning direction for a company that is telling investors it hopes to be profitable by 2030. But measured as a percentage of revenues, the company's operating losses slightly improved year to year, from 237 percent in 2024 to 160 percent in 2025.

Gotta spend money to make money

Operating numbers aside, OpenAI's headline "net loss" number of just over $5 billion in 2024 ballooned to nearly $39 billion in 2025. But the 2025 number includes a significant accounting charge related to investor valuations that shifted amid the company's 2025 conversion to a for-profit structure. The Financial Times cites "a person familiar with the matter" in reporting that this non-recurring charge was approximately $30 billion and that OpenAI's 2025 net loss amounted to a more reasonable-looking $8 billion without it.

As OpenAI tries to shift all these losses to eventual profits, it will have to start reining in its costs, especially the massive (and growing) R&D costs associated with model training. It will also have to deal with enterprise customers that are beginning to balk at token-based pricing and starting to demand a measurable return on investment for their AI spending. And on the subscription side, pressure from rival Anthropic may force the company to lower prices, which could further increase operating losses in the near term.

OpenAI shut down its Sora video generation model in March. Around the same time, OpenAI CEO of Applications Fidji Simo told employees that the company would be cutting back on "side quests" and focusing on its core coding and business users.

In March, OpenAI raised $122 billion of financing in a funding round that valued the company at $852 billion. The company reports over 900 million weekly active users of ChatGPT, though only about 50 million of those are paid subscribers.

Read full article

Comments

SpaceX will acquire AI coding tool Cursor for $60 billion in an all-stock transaction, the companies announced today. The deal is expected to close in the third quarter.

It comes just two days after SpaceX's unprecedented IPO and a few months after the merger of SpaceX and xAI, which brought a significant restructuring of xAI.

Cursor was one of the first tools to fully bake features that leverage large language models into an IDE. It's a branch of Visual Studio Code with heavy AI integration. However, incumbent platforms and bigger AI companies have since rolled out comparable features.

Cursor has seen considerable revenue growth over the past year, but its market share has also slipped as Anthropic's Claude Code has achieved dominance in the space. TechCrunch reported that Cursor was struggling to break even.

Early this year, the Cursor team said its future growth was bottlenecked on compute. This spring, xAI struck a deal to give Cursor access to its compute infrastructure, foreshadowing similar, larger deals with Anthropic and Google in the future. xAI and Cursor also began training models together at that time, including Grok Build, xAI's coding and knowledge work model.

Those deals with Anthropic and Google have relatively favorable termination clauses for SpaceX, so if SpaceX's enterprise AI efforts take off and see high demand, it will theoretically be possible to reallocate compute from competitors directly to SpaceX and the Cursor team.

This is a marriage between two companies that have arguably been falling behind in the AI race. xAI-turned-SpaceX's Grok chatbot has been riddled with controversies, but its lack of a competitive coding model or harness has also been a strategic weakness. The tool has largely been stuck in an older, chatbot-centric paradigm, compared to offerings from Anthropic, Google, and OpenAI.

Cursor had good talent and a strong product, but it couldn't compete with larger companies on compute. SpaceX had the capacity but lacked the product and models to be competitive, even though much of its more than $2 trillion IPO's promise hinged on providing AI services to enterprise customers.

This acquisition is a direct response to both of their problems, though it still does not guarantee success in such a competitive field.

Read full article

Comments

The release of macOS 27 later this fall won't quite close the book on the Intel Mac. The last handful of models that could run macOS 26 Tahoe will be eligible for security and Safari updates for two more years, and elements of the Rosetta compatibility layer for running Intel code on Apple Silicon Macs will be with us in some form for some indeterminate amount of time after that.

But macOS 26 is definitely the last chapter of the Intel Mac story. Anything that happens after this is a coda or an epilogue.

Most of our WWDC coverage has been forward-looking, so indulge us if you will in a look backward at the full history of the Intel Mac, a partnership between two companies that made Macs dramatically better, until it started making them worse.

"Project Marklar"

An early 2000s-era titanium PowerBook G4 running Mac OS X Leopard. Apple was never able to squeeze the PowerPC G5 into a laptop. Credit: Andrew Cunningham

The Mac's history with Intel didn't start with version 10.4.4, the first Mac OS X version to ship on a commercially available Intel Mac. But we won't go as far back as the x86-compatible versions of NeXTSTEP or Apple's abortive '90s efforts to make a version of classic Mac OS that could be licensed for third-party x86-based systems.

Let's begin with JK Scheinberg, an Apple engineer in June of 2000, who was looking for a solo project to help him transition to working from home. His pitch? A version of the then-still-in-progress Mac OS X that could run on Intel processors.

"I've been working on the Intel platform for the last week getting continuations working," Scheinberg wrote to his boss in an email shared by his wife. "I've found it interesting and enjoyable, and, if this (an Intel version) is something that could be important to us I'd like to discuss working on it full-time."

At the time, all Macs still used PowerPC processors co-developed by Apple, IBM, and Motorola, as they had since 1994. Early Mac OS X versions ran on G3 and G4 chips, and the 64-bit G5 processor was launched in mid-2003. A version of Mac OS X that ran on Intel's chips wasn't strictly necessary, and for around a year and a half, it existed only as a sort of hobbyist side project codenamed "Marklar."

By early 2002, Marklar had attracted more attention within Apple, and then-CEO Steve Jobs briefly flirted with the idea of allowing Mac OS X to run on Sony's Vaio laptops. By that August, a dozen or so engineers had been added to the project as it grew from "proof-of-concept" to "contingency plan."

That's because Apple was having problems with PowerPC chips. Jobs promised that the desktop version of the G5 would climb in clock speed from 2 GHz to 3 GHz within a year, a promise that never came to pass. And Apple was never able to squeeze the hot, power-hungry processor into a laptop—iBooks and PowerBooks were stuck with revised versions of the G4. Future CEO Tim Cook called a G5-based laptop "the mother of all thermal challenges."

Jobs had been fuming about PowerPC chips for a while; Walter Isaacson's Jobs biography describes a heated call between Jobs and Motorola CEO Chris Galvin in 1997, in which Jobs declared that PowerPC chips "sucked." And he may have harbored other bad feelings; Geoffrey Cain's Steve Jobs in Exile says that Apple's PowerPC switch doomed further development of the Motorola m68k chips that NeXT's computers relied on, helping to kill NeXT's already-struggling hardware business.

And IBM, for its part, didn't want to devote its resources to developing a bunch of chips that would be used exclusively in the low-volume Mac lineup (in 2003, Apple shipped roughly 3 million Macs; the company no longer reports unit sales in its earnings reports, but analysts peg that number at just under 26 million Macs in 2025).

Intel's Paul Otellini helped convince Jobs to jump to Intel's chips, and Apple didn't need to start the software switch from scratch because of its existing work on Marklar. In June of 2005, Apple publicly demonstrated Mac OS X 10.4 running on Intel hardware for the first time. His presentation obliquely mentioned Marklar, though not by name.

"And so today for the first time, I can confirm the rumors that every release of Mac OS X has been compiled for both PowerPC and Intel," announced Jobs. "This has been going on for the last five years. Just in case."

The transition

The "first" Intel Mac was a Developer Transition Kit (DTK) made available to software developers after WWDC 2005. It was essentially a Pentium 4-based PC inside a Power Mac G5 case, and it was available strictly as a loan to developers who could pay $499 per year for a developer account and another $999 for the kit. Few, if any, of these DTK kits survived; Apple required developers to return the systems by the end of 2006 and offered to trade them for a real retail Intel Mac to seal the deal.

The WWDC keynote laid out the timeline, in addition to the tools Apple would use to help developers and users navigate the transition. The next version of Mac OS X, version 10.5 Leopard, would be compatible with both PowerPC and Intel Macs. A compatibility layer called Rosetta would run most PowerPC apps tolerably well while developers worked on Intel-native versions, which could be distributed as universal binaries that supported both CPU architectures. This transition worked well enough that Apple essentially handled the Intel-to-Apple-Silicon switch the exact same way.

Apple would also take advantage of the fact that its computers would use the same hardware as other PCs. Right from the start, Apple officially supported running Windows directly on Intel Macs via Boot Camp; a Mac OS X app would handle partitioning the Mac's disk and downloading Windows drivers for the Mac you were using, and a Windows-side app supported rebooting back into Mac OS (and eventually provided some other nice-to-haves like read-only access to HFS+ formatted volumes).

By January of 2006, Apple started shipping the first Intel Macs, starting with a new iMac and a renamed MacBook Pro to replace the outgoing PowerBook series. These first systems were externally almost indistinguishable from the PowerPC models they replaced, another strategy Apple recycled for the first Apple Silicon Macs—the implied message was "maybe these machines were different on the inside, but they're still the Macs you know and love."

A 2010-era white plastic MacBook. The first-generation version of this design was Apple's signature consumer laptop during the early Intel era. Credit: Andrew Cunningham

The first new design of the Intel Mac era came later that year, when Apple launched the MacBook to replace the old iBook. Like the iBook, this laptop was made mostly of white plastic (a black version, inexplicably several hundred dollars more expensive, was also available eventually), and it used slower processors with Intel's integrated graphics rather than the MacBook Pro's dedicated graphics chips. But it was a popular machine—I was a college student at the time, and it was definitely the laptop you'd see the most often when you were out and about on campus (or maybe the second-most-often, if you added up every single permutation of "something cheap from Dell").

During the WWDC 2005 presentation, Jobs predicted that the Intel transition would be mostly complete by the end of 2007. Unlike the 3GHz G5 prediction, this one actually wasn't optimistic enough: Apple completed its switch from PowerPC to Intel chips with the announcement of a new Mac Pro and Intel-based Xserve in August of 2006.

A productive partnership

"As we look ahead, we can envision some amazing products we want to build for you, and we don't know how to build them with the future PowerPC roadmap," said Jobs while explaining the rationale for the switch. (It's funny to think of now, but some of the Mac's staunchest loyalists did react to the switch with disproportionate dismay.)

For the first few years of the Intel era, updates came fast and often. The first wave of Intel Macs briefly reverted to 32-bit chips, a retreat from the 64-bit architecture of the G5; this was fixed the next year with a switch to 64-bit Intel Core 2 Duo processors. A flashy new aluminum-and-glass iMac overhaul came in 2007, defining an aesthetic that is still recognizable in today's Apple products. By the early 2010s, Intel's rapidly improving integrated GPUs enabled the Mac's first high-resolution "Retina" displays.

But the tastiest fruit of the early Apple-Intel partnership, a machine that wouldn't have been possible with PowerPC chips, was the MacBook Air. For that first model, Intel had even made a special version of its Core 2 Duo CPU with 60 percent smaller packaging, something that helped Apple cram an entire laptop into something that could fit in a manila envelope.

That first Air was a bit too ahead of its time; its 4,200 RPM spinning hard drive in particular helped bog it down, and the things it was missing felt like bigger compromises in 2008 than they would have just a few years later. But fast solid-state storage soon became a standard feature, and within just a few years, the MacBook Air was what virtually all laptops looked like. This was something Intel both enabled and encouraged.

Signs of trouble

A 6th-generation Intel Core CPU, codenamed Skylake. This architecture and the 14 nm manufacturing process were where Intel's problems started. Credit: Orestis Bastounis

Apple began making its own Apple-branded processors in 2010, using technology it acquired when it bought P.A. Semi in 2008. But while early chips like the Apple A4 and A5 were energy-efficient and felt snappy in iPhones and iPads, it was extremely difficult to imagine their performance scaling all the way up to what Apple would need to replace the Intel chips in a MacBook, to say nothing of an iMac or a Mac Pro.

But these chips steadily improved, year after year, often by huge leaps and bounds. And there was trouble brewing at Intel.

By the mid-2010s, Intel's "Tick-Tock" model for improving its products was beginning to falter. The company had more trouble than expected getting its 14 nm manufacturing process up and running, and its manufacturing improvements stalled for years. Intel's next-generation 10 nm process wasn't shipping in any volume until late 2019, and for years, it was stuck shipping warmed-over iterations of 2015's 14 nm Skylake architecture.

And it wasn't just the slowed rate of improvement that was a problem. Former Intel engineer François Piednoël claimed that the Skylake architecture was inordinately buggy and that Apple was the one finding a lot of the bugs.

"Basically our buddies at Apple became the number one filer of problems in the architecture. And that went really, really bad," said Piednoël. "When your customer starts finding almost as much bugs as you found yourself, you're not leading into the right place."

The PowerPC-to-Intel switch came because Apple was unhappy with its current chips and because a better, more viable option was readily available. By the late 2010s, both of those things were true again.

Bridge over troubled water

The MacBook Pro Touch Bar was a flawed idea that nevertheless showed how Apple was outgrowing Intel. Credit: Andrew Cunningham

In retrospect, the first "Apple Silicon Mac" was not the M1 MacBook Air or Mac mini that came out in late 2020 but the redesigned butterfly-keyboard MacBook Pros that released in late 2016.

Those models shipped with a now-abandoned piece of technology called the Touch Bar, a narrow strip of touchscreen above the keyboard that attempted to replace the function row with other buttons and sliders that could change dynamically based on what the user was doing.

To make the Touch Bar work, those Macs included a chip called the Apple T1. The T1 wasn’t much—it was essentially a repurposed Apple Watch processor that existed to drive the Touch Bar display and provide Macs with a Secure Enclave that could be used for Touch ID and Apple Pay. But it was a sign that Intel's chips were no longer serving all of Apple's needs. As in the PowerPC days, Apple was envisioning products that its chip supplier couldn't help it build.

The T1 was followed by the T2, a relative of the Apple A10 chip that handled the same things as the T1 plus additional security features, an SSD controller, and video encoding and decoding. Both the T1 and T2 ran their own operating system called "bridgeOS"—in one sense, the "bridge" referred to communication between those Macs' Intel processors and the Apple coprocessors. But in retrospect, you could also read it as a reference to those Macs' status as a bridge between the height of the Intel Mac era and the looming Apple Silicon era.

Apple inside

The powerful, compact, power-efficient Mac Studio is the kind of machine Apple couldn't have made with Intel's chips. Credit: Andrew Cunningham

"When we make bold changes, it's for one simple yet powerful reason," said Apple CEO Tim Cook. "So we can make much better products. When we look ahead, we envision some amazing new products, and transitioning to our own custom silicon is what will enable us to bring them to life."

Cook formally announced the long-rumored Apple Silicon transition in the company's 2020 WWDC keynote, which was delivered fully virtually during the height of the COVID-19 pandemic. (There's something faintly strange about watching this video now, even though basically all of Apple's major announcements are delivered as fully pre-recorded videos these days—it's full of weird cuts, and it feels like none of the presenters are sure what they should be doing with their hands.)

The first Apple Silicon Macs and the Apple M1 chip were announced in November of that year, and from then on, Intel Macs were living on borrowed time. The Apple Silicon transition took quite a bit longer than the PowerPC-to-Intel switch had, but the company finally completed the transition in mid-2023.

Apple promised that Intel Macs would be supported for "years to come," and it did make good on that promise, though later Intel Macs received fewer operating system updates than earlier ones. From 2020's macOS 11 Big Sur to last year's macOS 26 Tahoe, Apple released a total of six macOS releases that supported both architectures, though Tahoe's support list included just a bare handful of Intel models. Those Macs will get security and Safari updates until the fall of 2028. And then the Intel Mac era will be fully in the rearview.

What's striking about the Intel Mac era is that Apple switched to and away from Intel chips for basically the same reason: It was looking for a more compelling processor roadmap and the best possible performance-per-Watt for its chips. When Intel was executing well—and during the decade between the mid-00s and mid-2010s, Intel was executing exceptionally well—Apple wanted in. It was only after years of watching Intel struggle that Apple wanted out.

The big difference? When Apple stopped shipping PowerPC chips, consumer-focused PowerPC chips essentially disappeared. But Intel is still making and shipping processors, meaning that we (and Apple) can still see what could have been if the switch had never happened.

Some of Intel's updates this decade have been pretty good. The current Core Ultra Series 3 chips, in particular, are its most competitive in years, based on their CPU performance, graphics performance, and power efficiency. But I'd take Apple's steady, consistent drumbeat of generation-over-generation improvement any day over Intel's herky-jerky rollercoaster of refreshes, rebadges, and architectural overhauls.

Ditching Intel was a big risk for Apple, but so far, it's been the right decision.

Read full article

Comments