Tech layoffs stopped being a rumour and became a line item in the budgets of the biggest technology companies on earth. But the data shows something the headlines lose: the market is not shrinking evenly, it is splitting. And the split starts exactly at the point where you stopped learning.
The question doing the rounds is some version of will AI replace software engineers, or the more personal will AI take my job. Both are the wrong version, and the wrong version has no useful answer. There is a moment in every technological revolution when two contradictory things are true at once. People lose their jobs, and at the same time there is more work than ever before. It happened with the steam engine. It happened with the spreadsheet. It is happening now.
The difference is speed. Previous revolutions gave a generation twenty years to adapt. This one gives you about eighteen months.
What follows is neither a panicked "we're all doomed" nor a soothing "relax, AI is just a tool." It is an attempt at an honest answer to the question almost everyone in tech is quietly asking: what exactly do I need to do to still be valuable two years from now?
What the data actually says about tech layoffs
Let's start with numbers, because without them the discussion collapses into an exchange of gut feelings.
In its Future of Jobs report, the World Economic Forum projects that by 2030 technological transformation will displace roughly 92 million jobs while creating roughly 170 million new ones, a net gain of about 78 million positions. But the same report contains a sentence that should worry you far more than the headline numbers: around 39% of the core skills required in today's jobs will change by 2030.
Read that again. Not "39% of people will lose their jobs." 39% of what you are paid for today will stop being what you are paid for.
That is the whole story in one line. The net job count is positive, but competence does not migrate automatically from the shrinking column to the growing one. Nobody is going to move you across, and that transfer is the one part of this process you have to perform yourself.
On top of that there is a phenomenon that gets far less coverage because it does not generate headlines: the silent reduction.
Companies do not always fire people. More often they simply stop backfilling the ones who leave, freeze junior hiring, and shift budget from "more people" to "more tooling per person." The effect on the market is identical to layoffs, only spread over time and invisible in the statistics.
You will never see a headline saying "Company X did not hire the 200 people it would have hired two years ago." And yet that is where most of the reduction is actually happening.
Who is actually losing their job
Over the past two years a fairly clear profile of the most exposed worker has emerged. Counterintuitively, it is not "someone who doesn't use AI."
The most exposed people are those whose work consisted of executing well-defined tasks in a narrow scope, without understanding the layer underneath.
Specifically:
- The single-tool specialist. Someone who spent five years doing exactly one thing in exactly one framework and never looked under the hood. When the tool changes, the competence evaporates with it.
- The ticket executor. Someone who implements work that has already been precisely specified by somebody else. That is the shape of work large language models reproduce best.
- The junior without foundations. Someone who learned to assemble applications from prefabricated blocks but cannot explain why they work. Two years ago the market tolerated this because there were not enough hands. Today there are.
- The senior who stopped learning in 2019. Seniority is not immunity. Seniority without renewal is deferred risk.
So who is safe? People who can judge whether an answer is correct. That sounds trivial until you realise what the skill is now worth.
The model generates code in fifteen seconds. It compiles, the tests pass, and everything looks fine. Then it takes a person who genuinely understands database indexing to notice that this query will bring production down at a hundred thousand rows. Over the last two years, that person quietly became the most expensive asset on the team.
Why AI eliminates tasks, not professions
The most useful mental model for automation does not operate at the level of job titles. It operates at the level of tasks.
Your job is not one monolith. It is a bundle of a few dozen distinct activities, and automation does not take the whole bundle at once. It removes individual items from it, usually the most repetitive and most clearly specified ones.
Take a backend engineer. From that bundle, AI is currently removing boilerplate, translating code between languages, generating unit tests, writing documentation, and initial library research. Realistically that can be 30 to 40% of the working week.
What stays in the bundle? Designing architecture against real business constraints. Debugging a problem that only shows up in production, only on Tuesdays, only for customers in Asia. Deciding whether the feature should exist at all. Talking to a person who cannot articulate what they want but knows exactly what hurts.
And here is the fork in the road that decides everything. If that automated 40% was 90% of the value you brought, you have a problem. If it was 40%, and you redirect the freed-up time into the harder work, you have just been promoted without anyone telling you yet.
It is also worth knowing Jevons paradox: when technology makes something cheaper, consumption of it usually rises rather than falls. Cheaper software means companies that previously could not afford custom systems will now commission them. The market is not shrinking. What it pays for is changing.
The automation paradox: why experts matter more
In 1983 Lisanne Bainbridge published Ironies of Automation, a paper about industrial control systems that today reads like a diagnosis of the software industry.
Her observation was this. The better you automate a system, the less often a human has to intervene. But when they finally do, the situation is exceptionally hard, because the automation already handled everything easy and only edge cases remain. Meanwhile the operator, who spends most of their time merely supervising, loses the very skill the emergency demands.
Automation raises the bar for humans instead of lowering it.
We are watching the same dynamic now. When AI writes 60% of the code, human work shifts toward the 40% that is hardest. Nobody will pay you to write a CRUD endpoint any more. They will pay you because you know when a generated CRUD endpoint is a time bomb.
This shift has a practical consequence for how you learn. You cannot build the skill of verifying something you have never done yourself. Someone who has never hand-written a SQL query will not spot an N+1 problem in generated code, and someone who does not understand the memory model will not catch the leak. Fundamentals did not become less important. They moved from the "needed in order to write" category into the "needed in order to judge" category, and judging is the harder of the two.
The skills to learn for 2026: a competence pyramid
Below are five layers of competence, ordered from most resistant to automation to most replaceable. Be honest with yourself about where you sit.
Layer 1: foundations (most resistant). Data structures, computational complexity, concurrency models, networking, operating systems, security basics. This is knowledge that does not expire when a framework changes, and it lets you evaluate any new tool in hours rather than weeks.
Layer 2: systems thinking. Architecture design, consistency-versus-availability trade-offs, observability, operational cost. The model does not have this competence, because it does not know your company's context, your budget, or your technical debt.
Layer 3: verification and critical judgement. The ability to quickly determine whether a proposed solution is correct, secure, and maintainable. No skill has appreciated faster over the last two years.
Layer 4: domain knowledge. Understanding the industry you build for, whether that is fintech, medtech, logistics, or e-commerce. The model knows code. It does not know the regulation whose breach costs your client their licence.
Layer 5: specific tool knowledge (most replaceable). Syntax, APIs, configuration. Still necessary, but no longer an edge. It is the price of admission.
Most people who feel anxious about their job today built their career primarily on layer five. The good news is that layers one to three can be acquired. The harder news is that they cannot be acquired by watching.
Why watching tutorials stopped working
Most upskilling advice stops here and says something useless along the lines of "learn new technologies." So let's drop down to the level of mechanics instead.
Decades of research into learning point to the same phenomenon, known as the testing effect: attempting to retrieve information from memory strengthens it far more effectively than re-reading it. The classic Roediger and Karpicke study from 2006 showed that a group who took tests after reading remembered substantially more a week later than a group that re-read the same material repeatedly, despite the second group feeling considerably more confident.
That last clause is the important one. Passive consumption produces the feeling of competence without the competence. You watch a four-hour course, everything makes sense, you nod along. Three weeks later, in an interview, you cannot articulate the difference between two concepts from chapter one.
Robert Bjork named this effect desirable difficulties: conditions that make learning harder in the moment improve how durable it is. The effort of retrieval is exactly that kind of difficulty. If learning feels smooth and pleasant, you are probably not learning, you are consuming content.
The third element is spaced repetition. The same material reviewed at expanding intervals persists many times longer than material crammed into a single session.
The practical conclusion is simple:
If your learning consists mainly of reading and watching, you are building confidence instead of competence. If it consists of attempting answers, being wrong, and immediately understanding why you were wrong, you are building something that survives all the way to the interview and beyond.
That gap is why squizzu is built around the question rather than the lesson: a question forces retrieval, and every answer carries an explanation, so getting it wrong ends in understanding rather than a red cross.
A 90-day plan
The plan assumes a realistic 45 minutes a day, which is less time than most of us spend scrolling.
Days 1 to 30: diagnosis and foundations
Goal: stop guessing what you don't know.
- Week 1, audit. Run test sessions across every technology listed on your CV. Write down every area where you score below 70%. That list is your real map of gaps, not the one in your head.
- Weeks 2 and 3, one fundamental area where you scored worst. Not a framework, a foundation: data structures, the memory model, database transactions, the network stack.
- Week 4, review everything from weeks 2 and 3 in randomised order. If you cannot reproduce it without prompts, you do not know it.
Days 31 to 60: depth and verification
Goal: learn to judge, not just to produce.
- 20 minutes of questions and 25 minutes of practice, daily.
- Practice in this phase takes one specific form: generate AI solutions and hunt for the flaws in them. Ask the model for an implementation, then review it as if a junior had sent it to you. Every time you cannot justify your verdict, you have located a gap.
- Add a second area from your gap list.
Days 61 to 90: consolidation and exposure
Goal: turn knowledge into evidence.
- Keep the daily review sessions. Fifteen minutes is enough, because review is cheaper than relearning.
- Build one thing that requires all three areas simultaneously. It does not need to be a big project, it needs to be a hard one.
- Start writing publicly about what you are learning, one note a week. It is the cheapest way to build visibility and, conveniently, another form of active retrieval.
After 90 days you will not be a different person. You will be a person with 67 hours of advantage over the version of yourself from three months ago, and with a habit that does not end when the plan does.
How technical interviews have changed
Everything above has one practical consequence, and it is worth knowing before you sit down with a hiring manager.
Syntax questions have essentially disappeared. Nobody asks about array methods when a model answers in a second. That is good news for people with foundations and bad news for anyone who memorised a list of interview questions off the internet.
Questions about evaluating someone else's solution have appeared. "Here's an implementation, what's wrong with it?" is now one of the most common formats, and it tests exactly layer three of the pyramid.
Trade-off questions carry more weight. Not "how do you do X," but "why X rather than Y, and what do you lose by choosing it." A model can enumerate the options. Choosing between them in a specific context is still human work.
Attitudes toward using AI during the exercise have flipped. More and more companies allow, and even expect, you to use an assistant, and then watch how you do it. Do you verify the output? Do you notice when the model confabulates? Can you ask a good clarifying question?
The common denominator is that interviews have moved from recall to comprehension. If you want to see what that looks like inside one stack, how to prepare for a React interview in 2026 walks through the five areas current React loops test, and how to prepare for an AI engineer interview does the same for AI roles.
Seven mistakes that cost people their careers
- Confusing tool familiarity with competence. A framework is the price of admission, not an advantage.
- Learning purely through consumption. The feeling of understanding is not understanding.
- Waiting for your employer to fund your development. They will fund whatever raises their profit this quarter. Your resilience on the open market is your own expense.
- Rejecting AI on principle. People who refuse the tools do not lose to the model. They lose to the colleague who uses it.
- Relying on AI uncritically. This is the other side of the same coin and the more dangerous one today, because delegating your thinking erodes layers one to three systematically.
- Spreading yourself across ten technologies at once. Shallow familiarity with ten things is precisely what automation replaces most easily.
- Treating learning as a project with an end date. With 39% of skills changing inside five years, learning is not a project. It is an operational function, like sleep and food.
How ready are you?
So: will AI take your job? Not the whole of it, and not on the timeline the headlines imply. Tech layoffs are real, but this is not a story about the end of work. It is a story about value relocating: from executing to evaluating, from tool familiarity to understanding fundamentals, from one-time education to continuous learning.
The people who will lose the most are not the ones who do not know AI. They are the ones who stopped checking what they actually know.
The cheapest first step is also the most uncomfortable one, which is to measure your actual level rather than your estimate of it. Run one session on squizzu on the technology you list on your CV as a strength. Every question carries an explanation and an in-depth breakdown, so each miss turns into a specific thing you can close rather than a vague worry.
Starting from the foundations layer? ML fundamentals and SQL are the two that expose gaps fastest.