Coinbase is cutting about 14% of its workforce, and Brian Armstrong is tying the move to both market pressure and AI.

AI is changing how we work.

The 8-K filing puts the cut at about 700 employees, or about 14% of global headcount as of May 1, 2026. Coinbase also expects $50 million to $60 million in restructuring expenses, mostly severance and termination benefits.

I do not like writing about layoffs as if they are a tidy product strategy. Real people just got the worst email in their inbox. Still, I am not surprised by the direction.

A couple months ago I told my family, friends, and the team at Msty that company headcount was going to get ugly. I used the word “bloodbath”, which is not exactly elegant dinner-table analysis. It also may have been less wrong than I wanted.

Coinbase is not alone here. Challenger, Gray & Christmas said AI led all stated reasons for job cuts in March 2026, with 15,341 announced cuts that month. Through Q1, AI was cited in 27,645 job-cut plans, about 13% of the total.

I would be careful with that number. A company can call something an AI cut when it is really cost cutting, margin pressure, a reorg, or all of the above with a shiny label on it. But the label itself matters now. AI has moved from a tools discussion into a management argument.

At Msty, I am already seeing a smaller version of it.

I wrote in the Msty Studio 2.7.0 post about Adam shipping Media Studio without coming from a traditional programming background. We have other people on the team doing similar work. Honestly, outside of maybe structuring some code differently, I am not sure I would have done a better job than what they can now do with AI.

I still pause on that. I have spent most of my life treating code as the work. Now a lot of code is the output of the work.

Does it matter if a person can read and understand all of it?

I still think yes, but maybe in a narrower way than before. If AI wrote perfectly working code in assembly, bytecode, or even binary, would I care that I could not read it line by line? We already made peace with that in other places. Compilers turn our source into things most of us do not read. JVM bytecode runs plenty of production software without everyone on the team understanding every instruction.

So I keep wondering if English, tests, screenshots, specs, and review notes are becoming the higher-level language. Maybe source code is becoming a little more like an intermediate artifact.

The catch is “perfectly working code.” Current AI code is not that. I still want people who understand systems, tradeoffs, failure modes, and where the generated thing is probably lying. I am just less convinced those people need to spend most of the day typing every line by hand.

The pressure shows up in QA first.

I wrote recently about using Codex Computer Use for desktop QA. Once coding sped up, QA started getting squeezed. The app still needs to be opened. Flows still need to be tried. Someone still has to notice the weird little thing that broke.

We just hired two QA engineers this week, and we are interviewing another one today. Their job is not to sit around waiting for a developer to fix what they find. Their job is to test the app, verify the bug, fix it, and send a PR.

The funny part is that they are all developers academically. Computer engineering students. During interviews I make the role clear: we are not hiring people to pile up hand-written code. AI can do a lot of that faster. We are hiring people to fill the human gap: use the product, notice what is wrong, understand the context, and push the fix through.

One fresh grad told me, “Even my teachers told me that they are moving on from writing code.”

I had to stop for a second after that one.

The other part of Armstrong’s note that grabbed me was the company structure:

  • fewer layers
  • no pure managers
  • AI-native pods

I want Msty to stay close to that.

We do not really have layers. Everyone reports and everyone listens. Everyone should have enough context to know what is happening and why. A candidate recently asked about our layers. I said we do not have them. He suggested layers are important.

That answer felt stuck in the old job market. Layers were already slow before AI, and now the gap is worse because the work itself can move faster.

I do not want a company where one person defines the work, another person writes the ticket, another person writes the code, another person tests it, and another person decides whether it matters. AI makes that chain feel even heavier.

The person I want can take a messy problem and move it forward: users are confused here, onboarding leaks there, this release feels fragile, this flow needs to be faster. They can research it, use AI to explore and implement, read enough code to catch nonsense, run the app, test the ugly cases, fix what they find, and send the PR.

Mentoring new people still matters. Taste still matters. Code structure still matters. But if your main contribution is telling other people what to do, AI is going to make that look very expensive.

My bar for Msty is simple: use AI aggressively, keep judgment in the loop, and ship the fix instead of creating another handoff.