[Bashmatica!] Q1: 52K Cut, Shift-Left Gone

Let’s Call It Faith-Based Engineering

Between January and March 2026, the tech industry cut 52,000 jobs. That figure, sourced from Challenger, Gray & Christmas, represents a 40% increase over the same quarter last year. At the daily rate tracked by TrueUp, that is 973 people per day, the highest pace since the 2023 peak. The raw numbers are significant, but they are not the story. The context behind them is.

Atlassian cut 1,600 positions while reporting 26% year-over-year cloud revenue growth. Meta is cutting thousands to redirect spending toward a $135 billion AI infrastructure buildout. Dell has reduced its workforce by 10% for three consecutive years. Oracle sent a mass layoff notification to an estimated 30,000 employees at 6am on March 31, with no advance warning, while simultaneously pouring $156 billion into AI data center construction. These are not companies tightening their belts during a downturn. These are profitable organizations with growing revenue cutting workers to fund a technology whose ability to replace them has not been demonstrated.

In March 2026, for the first time, AI was the number one cited reason for job cuts in the United States. Not restructuring. Not macroeconomic headwinds. AI. And the roles being cited as replaceable include the ones responsible for making sure the software works before it reaches your users.

This issue's companion script: stale-test-finder — find test files that haven't kept pace with their source code. Details in the Quick Tip below.

Further Reading

• Companies Are Laying Off Workers Because of AI's Potential, Not Its Performance — Harvard Business Review, January 2026. The framing this issue builds on.

• Challenger Report: AI Leads All Reasons for Job Cuts in March — Challenger, Gray & Christmas. The source for the 52,000 Q1 figure.

• Tech Layoffs 2026 Tracker — TrueUp. Real-time tracking of tech layoffs with daily pace data.

• The AI-Layoff Playbook Just Got Its First Case Study — Bashmatica #004. Our coverage of Block's 4,000 cuts when the playbook was just emerging.

• When the Dashboard Says 94% — Bashmatica #008. The coverage metrics piece this issue builds on directly.

On Faith Alone

Harvard Business Review published a piece in January 2026 with a title that should have stopped boardrooms cold: "Companies Are Laying Off Workers Because of AI's Potential, Not Its Performance." The argument is straightforward. Executives are not eliminating roles because AI has proven it can perform those roles. They are eliminating roles because they believe it will, eventually, and they do not want to be the last company to place the bet.

Jack Dorsey was unusually direct when Block cut approximately 4,000 employees, roughly 40% of its workforce: "This is not driven by financial difficulty, but by the growing capability of AI tools to perform a wider range of tasks." That is a CEO telling you, on the record, that the layoffs are not a response to a demonstrated capability. They are a response to a projected one.

The pattern has a circular logic to it that deserves more scrutiny than it is receiving. The layoffs justify the AI investment: we freed up budget for transformation. The AI investment justifies the layoffs: AI will absorb the work these roles performed. Neither claim requires evidence that the technology is actually absorbing the work right now. The announcement is treated as the proof. Company boards are actively pressuring CEOs to demonstrate AI-driven headcount reduction, turning this into a governance directive rather than a technical assessment. The frenzy is not a strategy. It is a contagion, and it is moving through earnings calls and board presentations faster than the technology itself is maturing.

What separates Q1 2026 from the 2022-2023 layoff wave is the stated rationale. The earlier wave was a correction: pandemic-era over-hiring unwound as growth normalized. That logic, while painful, was grounded in observable market conditions. The current wave is speculative. CEOs have stopped using euphemisms like "restructuring" and are openly attributing cuts to AI automation. The transparency is notable; the evidence behind it is not.

Shift-Left And The Void Left Behind

For nearly two decades, the software industry pushed an idea called shift-left: move quality assurance earlier in the development lifecycle rather than treating it as a gate at the end. The principle is sound. Defects caught during design or development cost a fraction of what they cost when discovered in production. The earlier you involve someone who understands failure modes, integration risks, and testing strategy, the fewer surprises reach your users.

Shift-left was never a tool you could install. It was a discipline, and it required specific people with direct expertise embedded at multiple points througout the process. QA engineers in scoping meetings, raising questions about how a new feature would interact with existing infrastructure. Testers providing time estimates so product managers could make informed scheduling decisions. Performance engineers running load tests before launches rather than diagnosing outages after them. The value these roles provided was not the testing itself. It was the judgment about what to test, when, and why: judgment informed by institutional knowledge of the system's history and its failure patterns.

That judgment does not transfer to a dashboard. It does not survive a headcount reduction.

Eleven-to-One

I watched this play out over three years at my last full-time position. Between 2021 and 2024, my QA and DevOps team went from eleven engineers to one. Me. Some were laid off in successive rounds. Others left voluntarily and their positions were never backfilled. The erosion was gradual enough that each individual departure felt manageable. The cumulative effect was not.

The first capability to disappear was integration impact analysis. When the team was fully staffed, new features went through a review process that assessed how they would interact with existing systems: what services they touched, what dependencies they introduced, what could break downstream. That process required people who knew the system's topology well enough to anticipate conflicts that no requirements document would surface. When those people left, the analysis stopped. Not because anyone decided it was unnecessary, but because no one remaining had the bandwidth or the institutional context to do it. Conflicting feature impacts that would have been caught during scoping started reaching production, where they became volatile and directly detrimental to end users.

Next went testing time estimates. Product managers lost the ability to plan releases with any realistic understanding of how long validation would take, because the people who could provide those estimates were gone. Front-end performance testing and load testing were dropped entirely; there was not enough capacity to sustain them. Risk and reward assessments during feature scoping disappeared. No one was in the room to ask whether the engineering cost of a proposed feature justified its projected value, or whether integration risk was being accounted for in the timeline.

By the end, shift-left had become fortify-right. I was not preventing defects from entering the system. I was triaging them after they arrived, alone, across every layer of the stack, reacting to the consequences of decisions I had not been consulted on. The practices that made shift-left effective did not survive the headcount reduction, even though the expectation that quality would remain high never changed.

Quality Assurance Ain't Just A River In Egypt

That was one team at one company. The Q1 2026 data suggests the same pattern is playing out across the industry simultaneously.

Microsoft explicitly named QA among the roles being displaced by Copilot, with an estimated 1,000 to 1,500 positions cut in Q1 that included quality assurance engineers. Indeed discontinued dedicated QA roles during its restructuring. The broader data from the World Quality Report shows the field splitting along a fault line: routine and manual testing roles are being eliminated at pace, while strategic QA and SDET positions have grown 17% over the same period. That second number sounds reassuring until you look at what it actually represents. The roles growing are a different discipline than the ones being cut. Hiring an AI test automation architect does not restore the institutional knowledge held by the six mid-career QA engineers who were laid off last quarter. The system's memory of its own failure modes walked out the door with them.

Last week, we covered the gap between coverage metrics and actual test quality: dashboards that report 94% coverage without measuring whether any of that coverage verifies meaningful behavior. That gap becomes significantly wider when the people who understood what "meaningful" meant in the context of a specific system are no longer reviewing the results. The dashboard stays green. The person who would have said "that 94% does not mean what you think it means" has been removed from the timeline.

There Are No Guarantees For Anyone

The cost of removing QA expertise from the development lifecycle does not appear on the layoff spreadsheet. It surfaces in production, weeks or months later, attributed to complexity or technical debt rather than to the organizational decision that removed the humans who managed that complexity.

Integration failures compound because nobody is performing impact analysis before features ship. Performance regressions reach users because load testing was quietly deprioritized when the team shrank. Defects that would have been caught during scoping survive into production because no one with testing expertise is present when features are being designed. The feedback loop that shift-left was supposed to create, where production failures inform earlier-stage decisions, requires someone to close the loop. An automated test suite, however comprehensive, does not walk into a sprint planning meeting and say "the last time we changed the payment module without load testing, we had a two-hour outage."

The industry is running an experiment at scale on whether AI tooling can replace the judgment that shift-left required. The Q1 numbers say the bet is accelerating. The evidence that the bet is paying off is conspicuously absent from the same earnings calls that celebrate the headcount reductions. And the companies making these cuts are not guaranteed to survive the experiment any more than the workers they let go. An organization that removes its quality feedback loop on the assumption that AI will fill the gap, without evidence that it can, is introducing a category of operational risk that no dashboard is tracking. When those production incidents compound, when the integration failures stack up, when the costs of deferred quality become impossible to attribute to "complexity" any longer, the expertise to rebuild what was lost will be in demand. It already is. The question is whether your organization will realize it before or after the damage shows up in the metrics that executives actually watch.

How Will You Generate Retirement Income?

Quick Tip: Find Tests That Fell Behind Their Source Code

When QA capacity shrinks, test maintenance is one of the first things to slip. This scan finds test files that haven't been updated even though the source code they cover has changed:

# Find test files stale for 180+ days whose source changed in the last 90
for test in $(find . -name "*.test.*" -o -name "*.spec.*" -o -name "*_test.*" | head -50); do
  src=$(echo "$test" | sed -E 's/\.(test|spec)//; s/_test\./\./')
  if [ -f "$src" ]; then
    test_days=$(( ($(date +%s) - $(git log -1 --format=%ct "$test" 2>/dev/null || echo 0)) / 86400 ))
    src_days=$(( ($(date +%s) - $(git log -1 --format=%ct "$src" 2>/dev/null || echo 0)) / 86400 ))
    if [ "$test_days" -gt 180 ] && [ "$src_days" -lt 90 ]; then
      echo "STALE: $test (${test_days}d) — source $src changed ${src_days}d ago"
    fi
  fi
done

A more thorough implementation with configurable thresholds, multiple naming conventions, and CI integration is in the bashmatica-scripts repo.

Quick Wins

🟢 Easy (15 min): Map your team's current testing responsibilities against who held them 18 months ago. Identify which practices were dropped versus reassigned when headcount changed. The dropped ones are your current blind spots, and naming them is the first step toward deciding which ones you can afford to leave uncovered and which ones you cannot.

🟡 Medium (1 hour): Run stale-test-finder on your repository. Any test file untouched for six months while its source file has been actively modified is a shift-left casualty: the relationship between the test and the code it covers has decayed because nobody was maintaining it. Prioritize the stale tests that cover revenue-critical paths.

🔴 Advanced (half day): Document your defect escape rate for the last quarter and trace the last five production incidents backward through the development process. For each one, identify whether there was a point where a QA review, an impact analysis, or a load test would have caught it or changed the timeline. That exercise produces the concrete cost of the feedback loop that was removed, in terms that translate to the language executives understand.

Next Week

The industry's response to QA headcount reduction is AI-powered testing tools that promise to absorb the work. Mutation testing is one approach that measures something those tools typically do not: whether your tests actually catch bugs, not just whether they execute code. Next week, we'll go deep on mutation testing: what it is, how it works at scale (Meta deployed it across Facebook, Instagram, and WhatsApp, generating over 9,000 mutations with a 73% engineer acceptance rate), and whether it offers a quality signal that survives the current restructuring.

Thanks for reading Bashmatica! The Q1 numbers describe an industry accelerating a bet on AI capability while systematically removing the human judgment that kept software reliable. The distance between those two actions is not a technology gap. It is a management gap, dressed up as a technology decision, and the people best positioned to understand what is being lost are the same people being shown the door. Shift-left was built on the assumption that quality expertise would be present throughout the development process. The industry just removed that assumption, and no one running the experiment appears to be measuring the results.

P.S. Eleven to one over three years. That was the trajectory of a team whose work was considered critical enough to keep running but not critical enough to keep staffing. If your team is somewhere on that curve right now, between fully staffed and "we'll figure it out with AI," the companies making these bets are not guaranteed to land them. An organization that strips its quality infrastructure on a projection is taking on risk it is not accounting for, and when the bill comes due, the people who understand what was removed will be the ones rebuilding it. That is not a consolation. It is a market signal. The expertise being discarded does not become less valuable because an executive decided it was replaceable. It becomes more valuable when they discover it was not. If this issue described your last three years or your next three, forward it to whoever is making the staffing decisions, or send them to bashmatica.com. The spreadsheet does not show them what it costs.