Somewhere in a high-level office in my company lies a layoff list of 8,000 people. I have a 10% chance of being on that list. In a few days, on May 20th, I will know my fate.

Seeing the 'AI layoff' news announced by Coinbase today, I decided to write this article. I purposely wrote it before May 20th because I want to share some of the most genuine perspectives, untainted by the personal sentiment of 'whether I'm staying or going.' These thoughts are not only independent of my being laid off but also not limited to my company. They come from the true voices of my friends working in various medium-to-large enterprises.

There's a flood of articles now debating: Is this new wave of layoffs (commonly thought to have started with Jack Dorsey cutting 40% of Square's staff) actually caused by AI, or is it merely 'AI-washing' (referring to companies using the embrace of AI as a pretense to conceal the real reasons for other business failures or layoffs).

I don't want to fill this article with links to various news pieces and papers to torture you; you've probably seen this content already, or you can easily find it with a Google search or by asking ChatGPT.

The much-touted 'AI Productivity' and the Elusive Evidence

Has AI really made us more efficient? That's a truly controversial heavyweight question! If we think in reverse and assert 'AI hasn't changed anything,' I doubt even the most skeptical of AI's value would agree with that statement.

Especially in tech companies, the rocket-like surge in AI usage is a fact staring us in the face. Even the most conservative companies that cap AI budgets and don't equip employees with AI tools cannot deny that a portion of the work is essentially done by AI—even if employees are just laboriously using Gemini or Copilot in Google or Microsoft Office suites to secretly edit documents.

As for the more visionary companies diving headfirst into the ocean of AI tokens (the basic units of text processed by AI models, with enterprise usage of large language models often billed based on token consumption), like Uber or Shopify (I'm excluding companies like Meta or Microsoft that develop their own LLMs, and also excluding infrastructure builders like Vercel or Cloudflare; I'm talking only about pure 'users'), their AI consumption has gone insane.

We've become accustomed to it: from 90% to 100% of code being AI-generated, to the number of code review submissions (PRs/diffs) per week exploding by 2 to 5 times, to annual AI budgets in the hundreds of millions being exhausted in just a few months.

However, tech commentators and investors like Ed Zitron, Will Manidis, Gary Marcus, and Michael Burry would undoubtedly retort with a soul-searching question: If that's the case, why haven't these companies' revenues grown by 2 to 5 times accordingly? Why do their apps look almost identical to how they did half a year ago? If AI is so productive, what exactly are they producing with it? If they're writing 5 times more code, yet end-users notice nothing, what's the point of all that code? This is an extremely sharp and reasonable question.

Input, Output, and Outcome

We need a brief interlude on business management fundamentals. When a fast-growing, overfunded, cash-burning midsize company finally faces a cash crunch, you go ask a seasoned CEO for advice. They'll suggest you bring in McKinsey to take a look. The consultants will put up a plain white slide as the first page of their presentation, with three words in default Arial font: 'Input, Output, Outcome.'

They'll explain a business truth that everyone knows but often forgets:

Code is merely an input.

Features are the output.

Users willingly paying for your product is the outcome.

AI (or at least products like Claude Enterprise) is essentially a B2B SaaS product. You'll notice that SaaS products are priced and marketed differently. If a product can directly change the 'outcome,' they typically take a cut directly from that 'outcome.' Imagine this sales pitch: 'Our tool increases your sales lead conversion speed by 36%. Try it now for a low service fee of just 5% of the sale value.'

That would be an instant killer for customers. All else being equal, if you closed 100 deals in 100 days before, now it takes only 63 days. The saved 36 days (if my math is correct) allow you to close an additional 57 deals! That is, your sales potential increases by 57%. Anyone would be more than happy to pay 5% from their sales commission for an extra 57% revenue. And if you don't use the product, you pay nothing.

You've probably guessed what I'm about to say—Claude's token consumption pricing model is nothing like that. If your software engineers are addicted to programming with Claude (I just realized both have the abbreviation 'cc'), generating 100 million tokens per day, you'll be paying $100 per engineer per day.

Even if some of the code they generate is thrown in the trash because it doesn't work;

Even if some code later causes severe system failures (SEVs) (SEV stands for Severity, commonly used in tech companies to refer to serious online incidents causing service outages) and gets rolled back urgently;

And even if another portion of the code is just for reskinning internal tools to make data dashboards look cuter for VPs;

You pay for it all. Because code is just an 'input.' While generally, as long as the direction is right, more 'input' tends to lead to more 'output,' and then to better 'outcome.' But when you multiply the input by 5 overnight, this rule doesn't necessarily hold. The extra 'input' you've added might suddenly become aimless, completely deviating from the expected 'output' or 'outcome.'

What's Really Holding Us Back!

In the past, whenever the CEO or product manager (PM) wanted to do 10 things, the development team would always say they could only handle the top two most important ones, leaving no time for the other 8. The reason? Because writing code isn't child's play; developing complex, functional software takes a lot of time.

Hmm... but now code is almost free. Why haven't we done those other 8 things?

The answer has two parts: one CEOs and PMs don't like to hear; the other middle managers and senior employees don't like to hear.

1. Perhaps those 8 ideas... just weren't good?

Just because the CEO or PM had 10 ideas flash through their minds doesn't mean they can actually translate into tangible business outcomes. Even if you truly built 10 new features (output), it doesn't guarantee users will buy in and use your app more because of them (outcome).

In fact, precisely because development resources were limited before, this 'friction' forced everyone to have more intense debates, thus killing off bad ideas early before they consumed too many resources, selecting the best two. Now, with code being fast and cheap to write, arguing about the merit of ideas seems pointless. Even if you try to push back, do you think you can stop the CEO or PM from turning around and asking Claude themselves? Don't even bother trying.

2. Getting everyone 'aligned' is too painful.

We all know how torturous this is. First, you need all stakeholders to agree on 'why' to do something; then, you need another meeting to discuss specifically 'what' to do; finally, everyone needs to haggle over 'how' to do it.

The more teams involved, the more projects get stuck in 'alignment hell.' Previously, this problem was masked because writing code was slow. Now, as soon as the 'what' is decided, someone immediately pulls an all-nighter to whip up a Minimum Viable Product (MVP) (developing a product with the lowest cost that just showcases the core idea, for quick iteration and testing) and schedules the next meeting for the very next day.

In the meeting, you're shocked to discover another team secretly built an MVP too! Worse, because you based your work on different assumptions, the two products operate on completely different logics.

Sure, you can sit down and slowly grind out whose assumptions are correct.

But let's be honest. You and your team, armed with unlimited Claude tokens, can't be bothered. Neither can the other team. You'd turn right back to Claude without hesitation, asking it to reimplement the other team's work exactly as you see fit, in what you believe is the perfect way. And Claude would just obediently reply, 'You are absolutely right!' and immediately start typing code.

What Do Layoffs Actually Solve?

Alright, thank you for patiently listening to me ramble about these seemingly obvious common-sense truths. I know you want the core substance.

What purpose do layoffs serve? Based on my assumption, if AI isn't truly one-for-one replacing 30% of employees (I think we can agree on this? While it's better than junior white-collar workers at many tasks, it's worse at others—it's definitely not a plug-and-play component, let alone directly replacing 10%, 20%, or 30% of a company's workforce).

So, what's the logic behind layoffs? Because it can immediately solve two glaring short-term problems.

1. Offset 'AI Expenditure'

This is essentially a basic cash flow arithmetic problem. It's obvious: if your Claude-addicted engineers are splurging $100 per day on Claude (that's $2,500 per month, $30,000 per year), that amount already equals the total salary of a Software Development Engineer (SDE) in India; half an SDE in Europe; and a quarter of an SDE in the US.

Doing the simplest, crudest calculation: assuming a flat company where all employees are SDEs. To maintain the existing total wage expenditure (including token purchase costs), you must lay off 50% (India), 33% (Europe), or 20% (US) of the staff.

In reality, since AI usage is growing wildly and uncontrollably, while company revenue shows no corresponding growth, layoffs become the inevitable choice. Otherwise, the company's balance sheet collapses. If your input costs increase by 50%, but the ultimate business outcomes remain stagnant or unchanged, then the unit economics of your entire software development lifecycle are completely broken.

If we truly learned how to use AI—figured out how to translate a 50% increase in input cost into a 50% increase in revenue outcome—we wouldn't need to take this step. But precisely because you haven't learned, some of you must pack up and leave to free up money to pay Anthropic.

2. Cut 'Alignment Tax'

Undoubtedly, the size of any large company far exceeds what is strictly necessary for its 'survival.' This is precisely the characteristic of large companies; large organizations are destined to accumulate 'organizational fat,' an inevitable result of organizational structure design.

In these companies, even if someone leaves, the system can still operate because someone else always knows what they used to do. In many big tech firms, you can even safely take six months of maternity leave, and the projects you were responsible for remain fine. These are good things! But it's also solid proof: if you cut a portion of people, the company definitely won't collapse immediately. On the contrary, after the initial few weeks of systemic pain, the pace might even speed up over the following months!

Remember those two teams stuck in a stalemate over technical solutions earlier? Simple: just lay off one of the teams, then let the remaining team pull a few all-nighters to get it done—they no longer need to 'align' with anyone.

We can't predict what happens in the long term (or, to paraphrase economist Keynes—'In the long run, we are all dead'), but in the short term, cutting 10-20% of employees in a large enterprise only makes the work pace faster.

Large enterprises inevitably accumulate redundancy and bloat over time, building up significant 'organizational debt' just like technical debt. This is the chronic illness of large corporations. Cutting 10% of people today won't stop the old ailment from recurring two years later. But when you see everyone boasting about submitting 5 times more code than before, yet being stuck unable to launch because other teams are bottlenecks, the most direct, brutal remedy is clearly: lay off some people, so no one bottlenecks each other.

This is AI Layoffs, Even if AI Didn't Directly Replace Your Seat

Was your employee ID replaced by a new Claude instance running on a virtual machine? We all know that's not the case.

Nevertheless, isn't it true that within the company, many work processes that once required you to type in VS Code, click in Figma, Canva, or Google Docs are now handled by others (those who originally needed your output) simply yelling a prompt at an LLM, no longer bothering to ask for your help? This is also an indisputable fact.

Are these layoffs considered 'AI-washing'? That is—did the company already have various fundamental problems unrelated to AI (like over-hiring, declining profits, competitive pressure, poor business decisions), and now they're just using AI as an 'excuse' for layoffs? Well, that makes sense to some extent.

You might also notice that if you collected all the 'layoff emails' CEOs have sent during this period, you'd even think they might have a group chat where they coordinated writing these emails. 'AI-native squads,' 'managers who code,' 'increasing management span,' 'flattening structure,' 'managing teams of AI agents'... You'll find these buzzwords appearing identically in every email. It's almost as if they fed GPT the same prompt.

But the truth is, even if these layoffs aren't because AI directly replaced you, even if they contain elements of 'AI-washing,' these layoffs are ultimately still caused by AI. Moreover, this layoff wave will continue until we truly learn how to use AI.

Until we learn how to translate massive amounts of AI tokens into tangible business outcomes, not just code inputs; until we learn to make organizational 'alignment' speed keep up with the coding speed of this new generation; until we figure out how to use this extra productivity to pursue another 10 promising new ideas beyond the original 2 good ideas and 8 bad ones.

Before we truly understand how AI actually drives global GDP growth, to fill that $70 billion annual token expenditure hole (the combined enterprise revenue of OpenAI and Anthropic), companies can only 'rob Peter to pay Paul' by cutting employee salaries.

And before we learn how to more efficiently resolve team bottlenecks, the solution will always be the same—simply erase us from the org chart.

In 15 days, I will know my fate. But regardless of the outcome, I think I already know the reason. Even if I were the one making the decision in that spacious CEO office in the corner, I don't know if I could do better; perhaps I would only make the same choice, just like the other CEOs in that group chat.