Original Article Title: The layoffs will continue till we learn to use AI
Original Author: Arnav Gupta, AI Engineer
Translated by: Bao Yu, AI Analyst
Inside our company's executive office, somewhere lies a list of up to 8,000 people for layoffs. I have a 10% chance of being on this list. In a few more days, on May 20th, I will know my fate.
Seeing today's announcement from Coinbase about "AI Layoffs," I decided to write this article. I deliberately started writing before May 20th because I wanted to share some of the most genuine perspectives, devoid of any personal "stay or leave" emotions. These thoughts are not only related to whether I will be laid off but also go beyond just my company. They come from the real voices of my friends working in various large and mid-sized enterprises.
There are numerous articles now debating whether this new wave of layoffs (widely believed to have started with Jack Dorsey laying off 40% of Square's employees) is truly due to AI or merely a case of "AI-washing" (referring to companies using the embrace of AI as a cover-up for other business failures or true layoff purposes).
I don't want to cram the article with various news and paper links to torture you, as you may have already seen them, or can easily find them by Googling or asking ChatGPT.
The touted "AI productivity" and the elusive evidence
Has AI truly made us more efficient? This is a highly controversial and weighty question! If we were to think in reverse and assert "AI has changed nothing," even the most skeptical of AI's value wouldn't agree with such a statement.
Especially in tech companies, the skyrocketing use of AI is an undeniable fact. Even the most conservative companies that limit AI budgets and do not equip employees with AI tools cannot deny that some work is effectively done by AI—whether employees are just miserably sneaking in Gemini or Copilot to edit documents within Google or Microsoft Office Suites.
As for those with foresight, diving headfirst into the AI token ocean, such as Uber or Shopify (excluding companies like Meta or Microsoft that develop their large language models and companies actively building AI infrastructure like Vercel or Cloudflare; only referring to pure "users"), their AI usage is simply going berserk.
We've seen it all: from 90% to 100% of code generated by AI, to a 2 to 5x increase in weekly code review (PRs/diffs) counts, to a multi-million dollar AI budget for the year being depleted in a matter of months.
Yet, tech critics and investors like Ed Zitron, Will Manidis, Gary Marcus, and Michael Bury would surely hit you with a soul-searching question: If that's the case, why haven't these companies seen a 2 to 5x growth in revenue? Why does their app look almost identical to half a year ago? If AI is so productive, what exactly have they produced with AI? If they've written 5x more code and end-users are unaware, what's the point of that code? This is an incredibly sharp and valid question.

Let's first dive into some business management basics. When a rapidly growing, over-funded, cash-splurging mid-sized company finally faces a cash crunch, you seek advice from a seasoned CEO. They'll advise you to bring in the McKinsey folks. The consultants will start their presentation with a plain white slide, with three words in default Arial font: "Input, Output, Outcome."
They'll explain to you a fundamental of business that everyone understands but often forgets:
Code is merely the input.
Features are the output.
When users willingly pay for your product, that's the outcome.
AI (or at least products like the Claude Enterprise Edition) is essentially a business-to-business software-as-a-service (B2B SaaS) product. You'll find that SaaS products have different pricing and go-to-market strategies. If a product can directly impact the "outcome," they usually take a cut from the "outcome." Imagine a sales pitch like this: "Our tool can accelerate your lead-to-sale conversion rate by 36%. Experience it now for a modest service fee of just 5% of the sales revenue."
This can definitely hook customers. All else being equal, if you closed 100 deals in the last 100 days, now you can do it in just 63 days. The saved 36 days (if my math serves me right) could help you close an extra 57 deals! In other words, your potential sales revenue grows by 57%. Anyone would gladly give up 5% of their sales commission for a 57% increase in income. And if you don't use the product, you don't pay a dime.
You may have already guessed what I'm going to say—Claude's Tokenomics pricing model is nothing like that. If your software engineers are as addicted to coding with Claude as they are to drugs (I just realized both their English abbreviations are "cc"), generating 100 million Tokens per day, then you'll have to pay $100 per day for each engineer.
Even if some of the code they generate ends up in the trash because it doesn't work;
Even if some code later triggers critical system failures (SEVs) and requires emergency rollbacks;
And even if some of the code is just a facelift for internal tools to make VPs smile when they look at the data dashboard;
You have to foot the bill for all of it. Because code is just an "input." While usually, as long as the direction is right, more "input" often leads to more "output," resulting in better "outcomes." However, when you overnight increase the input by 5 times, this rule may not apply. The additional "input" you've added may suddenly become headless flies, completely deviating from the expected "output" or "outcomes."

In the past, whenever a CEO or product manager (PM) wanted to do 10 things, the development team always said they could only handle the top two, leaving the other 8 undone. Why? Because coding is not child's play, developing a complex and functioning software requires a significant amount of time.
Well... but now coding is almost free. Why haven't we done those remaining 8 things?
The answer has two parts: one that CEOs and PMs don't like to hear, and another that middle management and senior staff don't like to hear.
Just because a CEO or PM had 10 thoughts flash through their minds, doesn't mean they can actually translate into real business results. Even if you do create 10 new features (output), it doesn't guarantee that users will all buy in and use your app more as a result (outcomes).
In fact, precisely because development resources were limited before, this "friction" forced everyone to engage in more heated debates, killing off those bad ideas early before they consumed too many resources and selecting the top two. And now, with coding becoming fast and cheap again, arguing about the quality of ideas seems pointless. Even if you try to argue against them, do you think you can stop the CEO or PM from turning to Claude for requirements? Forget it, you don't even need to try.
We all know how excruciating this can be. First, you have to get all stakeholders aligned on the “why”; then, you have to have another meeting to discuss the “what”; and finally, everyone has to tug-of-war on the “how.”
The more teams involved, the more projects get stuck in this “alignment hell.” This problem used to be masked by slow code writing. Now, as soon as the “what” is decided, someone immediately pulls an all-nighter to produce a Minimum Viable Product (MVP) (a product developed with the minimum features to demonstrate the core concept, used for rapid testing) and schedules another meeting the next day.
In the meeting, you are shocked to find out that another team has sneakily built an MVP too! To make matters worse, due to different assumptions, the logic of the two products operates in completely opposite directions.
Of course, you could sit down and painstakingly discuss whose assumptions are correct.
But let’s be real. You with your infinite Claude Tokens and your team are too lazy to do that. The other team isn’t either. You would quickly pivot to embrace Claude and have it re-implement the other team's work in the way you believe is perfect. And Claude will just obediently say, “You are absolutely right!” and promptly start coding.

Well, thank you for patiently listening to me ramble on for half a day about these obvious truths. I know you all want to get to the heart of the matter.
What can layoffs actually achieve? In my hypothesis, if AI hasn’t truly managed to replace 30% of employees one-to-one (we should all agree on this, right? Although it is superior to entry-level employees in many tasks, in others, it's inferior to humans—it is by no means a plug-and-play part that can directly substitute 10%, 20%, or even 30% of a company).
If that's the case, where does the logic of layoffs come in? Because they can immediately solve two short-term problems on the table.
It's really just basic cash flow arithmetic. Clearly, if your engineers addicted to Claude are squandering $100 on Claude every day (which amounts to $2,500 per month, $30,000 per year), in India, this amount of money could cover the salary of a Software Development Engineer (SDE); in Europe, it could cover half an SDE; and in the U.S., it could cover a quarter of one.
If we do a rough back-of-the-envelope calculation: Assuming in a flat company, all employees are SDEs. To maintain the current total wage bill (including spending on purchasing Tokens), you must cut 50% of employees (India), 33% (Europe), or 20% (USA).
In fact, as the usage of AI is growing crazily while the company's revenue is not growing accordingly, layoffs have become an inevitable choice. Otherwise, the company's balance sheet will completely collapse. If your input costs increase by 50%, but the final business outcome shows no improvement or even remains unchanged, then the unit economic efficiency of your entire software development lifecycle will collapse completely.
If we truly learn how to use AI — figure out how to turn a 50% increase in input costs into a 50% increase in revenue outcomes, we wouldn't have to take this step. However, because you haven't learned yet, some of you must pack up and leave to free up money to pay Anthropic.
Undoubtedly, the scale of any large company far exceeds the size necessary merely for "survival." This is precisely the characteristic of large companies; large organizations are destined to accumulate "organizational fat," which is an inevitable result of organizational design.
In these companies, even if someone leaves, the system can still operate because there will always be someone else who knows what they used to do. In many large companies, you can even take a six-month maternity leave at ease, and the project you are responsible for will remain intact. These are all good signs! But at the same time, it is also evidence: if you lay off some people, the company will not immediately collapse. On the contrary, after experiencing the initial systemic pain in the first few weeks, the operating speed may even increase in the following months!
Remember the two teams that were deadlocked over a technical solution earlier? It's simple: just lay off one of the teams, then let the remaining team work a few all-nighters to get the job done — they no longer need to "align" with anyone.
We cannot predict what will happen in the long run (or applying the famous words of economist Keynes — "In the long run, we are all dead"), but in the short term, laying off 10-20% of employees in a large enterprise will only make the work pace faster.
Over time, large enterprises inevitably accumulate redundancy, overstaffing, just as they accumulate a lot of "organizational debt" as they accumulate technical debt. This is the bane of large companies. Today, laying off 10% of people will not stop the recurrence of old problems two years from now. However, when you see everyone boasting that they have submitted five times more code than before, but are still unable to go live due to being blocked by other teams, the most direct, most brutal remedy is clearly: lay off some people so that no one can block each other.

Has your job been taken over by a new Claude instance running on a virtual machine? We all know that's not the case.
Nevertheless, are there many workflows in the company that used to require you to type away in VS Code, Figma, Canva, or Google Docs, but have now been streamlined to someone (the people who used to rely on you for these outputs) simply shouting a prompt at a large language model and no longer bothering to ask for your help? That's an undeniable fact as well.
Are these layoffs really part of "AI washing"? In other words, does the company have underlying non-AI-related issues (such as over-hiring, profit decline, competitive pressure, poor business decisions), and is now just using AI as an "excuse" for the layoffs? Well, to some extent, that argument also holds.
You might also notice that if you were to compile all the "layoff emails" sent by CEOs during this time, you'd start to wonder if they're all in a group chat, collaborating on these emails. Phrases like "AI-native team," "coding manager," "increasing span of control," "flattening the hierarchy," "managing an AI-powered team,"... You'll find these buzzwords appearing consistently in every email. It's almost as if they fed the same prompt to GPT.
But the truth is, even if these layoffs aren't a result of AI directly replacing you, and even if they contain elements of "AI washing," these layoffs ultimately stem from AI. And this wave of layoffs will continue until we truly learn how to utilize AI.
Until we learn how to translate the abundance of AI tokens into tangible business outcomes, not just code input; until we learn to align organizational speed with the coding speed of a whole new generation; until we figure out how to harness the surplus productivity beyond the 2 good ideas and 8 bad ones to chase another 10 promising new concepts.
Until we truly grasp how AI is driving global GDP growth, companies will have to resort to reducing employee salaries to "rob Peter to pay Paul" in order to cover the annual $700 billion Token expense (the combined enterprise revenue of OpenAI and Anthropic).
Until we learn how to more efficiently unclog the bottleneck between teams, there will always be only one solution to solve the problem - directly erase us from the organizational chart.

There are 15 days left until I can find out my fate. But no matter the outcome, I think I already know the reason. Even if I was the one sitting in that spacious CEO office in the corner making the decision at the time, I don't know if I could have done better. Maybe I would also make the same generic choice like the other CEOs in the group.
Original Post
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia