Career safety in the Age of AI Layoffs

The Contradiction

There is a strange contradiction happening in software engineering right now. A lot of developers are worried that AI is going to make them obsolete. At the same time, the people building the most capable AI coding tools are demonstrating something that should probably make us rethink what being a software engineer actually means.

I don't think the future is one where nobody understands software anymore. I think it is one where writing the software becomes dramatically cheaper. And if that happens, the thing that makes an engineer valuable has to move. That is what I mean by career safety. Career safety isn't about making yourself impossible to replace. It is about making your value portable.

We've Always Resisted Giving Up the Code

Developers have a long history of being suspicious of abstractions that take work away from us. We went from machine code to assembly, from assembly to higher-level languages, from manually managing memory to garbage collection, from building everything ourselves to libraries and frameworks, and from text editors to IDEs. We even had entire categories of tools, such as CASE tools, designed to automate parts of software development. And every time, there was resistance. Because programmers don't just use code. We build our identities around it.

John Carmack captured this unusually well when he wrote:

"Coding" was never the source of value, and people shouldn't get overly attached to it. - John Carmack

He followed that with the more important point:

Problem solving is the core skill. - John Carmack

That is a difficult idea for developers to internalize because coding is tangible. You can point at the repository. You can point at the pull request. You can count the commits. You can say, "I wrote this." But the business doesn't ultimately pay you for the number of lines you wrote. It pays you for what those lines accomplish.

The Business Never Really Bought the Code

A company doesn't wake up in the morning thinking: "We need 14,000 more lines of TypeScript." It thinks: "We need to reduce the cost of this process." "We need to launch this product." "We need to increase conversion." "We need to satisfy this regulatory requirement." "We need to reduce operational risk." "We need to make our customers happier."

The code is the mechanism. The outcome is the value. That distinction matters enormously when the cost of producing code starts approaching zero.

And I think this is where the current AI discussion often goes wrong. The argument becomes:

• "AI can't write perfect code." Maybe.
• "AI still makes mistakes." Absolutely.
• "I had to spend an hour fixing what the AI generated." I've done that too.

But those observations don't answer the important question. How quickly is the capability improving? The code AI generated a year ago was often laughably bad. Today's systems are substantially better. And the direction of travel matters more than whether today's models can replace every engineer. You don't need AI to become perfect for the economics of software development to change. You only need the cost of producing implementation to keep falling.

Linus Torvalds recently made essentially this pragmatic argument about AI in the Linux kernel:

"AI is a tool, just like other tools we use. And it's clearly a useful one." - Linus Torvalds

He went further, saying that decisions in the kernel should be based on:

technical merit. Not fear of new tools. - Linus Torvalds

That distinction is incredibly important. The question isn't whether AI is morally good or bad. The question is: Does the tool help us produce better technology? If the answer increasingly becomes yes, then refusing to use it isn't protecting the profession. It is simply refusing a tool.

Understanding Code Isn't the Same as Typing It

This is where I think we need to separate two things that have become conflated. Understanding software and manually producing software are not the same skill. A compiler already transforms the code we write into something else. Libraries allow us to avoid implementing primitives ourselves. Frameworks give us enormous amounts of functionality without us writing the underlying infrastructure. Garbage collectors manage memory we previously had to manage ourselves. IDEs autocomplete, refactor and navigate code for us. Nobody seriously argues that using these tools means we aren't software engineers.

AI is another step in the same direction. The difference is that this step is much larger. Instead of automating one small part of implementation, AI can potentially automate substantial portions of the implementation itself. That doesn't make understanding less important. It makes understanding more important.

If I ask an AI system to build a payment workflow, I need to understand payments. If I ask it to design an insurance pricing system, I need to understand insurance. If I ask it to modify a distributed system, I need to understand distributed systems. The machine can increasingly help with the implementation. It cannot magically give me the context that determines whether the implementation is the right thing to build.

And that leads to what I think will become one of the biggest career advantages of the next decade.

Domain Expertise Becomes a Moat

Imagine two engineers:

The first is: Senior Full Stack TypeScript Engineer.
The second is: London Specialty Insurance Product Engineer.

The first might be excellent at React, Node.js, TypeScript, databases and cloud infrastructure. The second understands specialty insurance. They understand brokers. They understand underwriting. They understand policies. They understand claims. They understand regulatory constraints. They understand how the business actually makes money. They understand which workflows are painful. They understand which problems are worth solving.

If AI makes software implementation dramatically cheaper, which of those profiles becomes more differentiated? Probably the second. Because technology knowledge is increasingly becoming something AI can augment. Deep knowledge of a particular business domain is much harder to manufacture on demand.

This doesn't mean you should abandon technical expertise. Quite the opposite. It means you should combine technical expertise with domain expertise. If you're working in finance, learn finance. If you're working in healthcare, learn healthcare. If you're working in insurance, learn insurance. Read the books. Understand the regulations. Talk to customers. Understand the economics. Learn how the industry actually works.

I increasingly think engineers should be reading as many books about their industry as they read about technology.

The Engineer Becomes a Product Person

This also changes the relationship between engineering and product management. For a long time, organizations could afford a relatively clean separation. Product people decide what to build. Engineers decide how to build it. But what happens when the cost of implementation falls dramatically? The bottleneck moves. The scarce resource becomes knowing what should be built. That makes product judgment increasingly valuable for engineers.

Can you understand a customer's problem? Can you translate it into a useful product? Can you understand the business case? Can you identify the constraints? Can you decide what not to build? Can you describe the desired outcome precisely enough that a machine can implement it?

That last question is particularly important. Because the next generation of software engineering may look less like:

"Give me a ticket and I'll write the code."

And more like:

"Give me a business problem and I'll turn it into a system of coordinated machines that can safely solve it."

The Compression of the Middle

There is another consequence of AI that is worth considering: it may not only reduce the amount of implementation work required, but also compress some of the intermediate organizational layers around engineering. As AI makes it easier to gather information, analyze requirements, synthesize feedback, produce specifications, and coordinate work, roles such as analysts, Scrum Masters, and some forms of project or product coordination may become leaner. This doesn't mean these functions disappear, but fewer people may be needed to translate information between customers, product teams, and engineers.

That makes communication an increasingly important engineering skill. An engineer who can speak directly with users, understand their problems, gather and synthesize feedback, identify patterns across different customers, and translate those patterns into general-purpose solutions could become considerably more valuable. Instead of simply implementing a requirement handed down through several layers of an organization, that engineer can participate directly in discovering the requirement.

This also changes what it means to be good at product management. Product thinking isn't simply about writing requirements or managing a backlog; it involves understanding people and their problems, communicating effectively, distinguishing individual requests from broader patterns, and deciding which problems are worth solving. In a leaner organization, the engineer who can bridge the gap between user problem → product insight → technical solution may have significantly more leverage than an engineer who only receives a specification and implements it.

The interesting consequence is that AI may therefore make communication skills more important for engineers, not less. As the number of intermediaries decreases, the ability to communicate directly with the people experiencing the problem becomes increasingly valuable.

The Next Engineering Skill Is Operating Agents

I don't think the most interesting future is one where an engineer has one AI assistant open in their IDE. I think it is one where an engineer can operate a fleet of agents. One agent investigates the existing architecture. Another implements a feature. Another writes tests. Another reviews the implementation. Another performs security analysis. Another evaluates performance. Another updates documentation. Another runs experiments. And potentially dozens or hundreds of these processes can operate in parallel.

At that point, the scarce skill isn't typing. It's orchestration. You need to know how to:

• Decompose a problem
• Specify work
• Establish boundaries
• Give agents the right context
• Structure systems so that work can happen safely in parallel
• Verify the results
• Detect when an agent has gone off course
• Roll back changes
• Evaluate whether the system actually achieved the intended outcome

In other words, the engineer moves up another level of abstraction. From writing code to causing valuable software to be produced.

And I think this is where Linus's pragmatism becomes especially relevant. His position isn't "let the machines do whatever they want." It's essentially the opposite. Use the tool if it is useful. Judge the result on technical merit. Don't confuse opposition to the tool with engineering quality.

The standard doesn't disappear because AI produced the code. If anything, the standard has to become more explicit.

Verification Becomes More Important Than Generation

There is an uncomfortable implication here. If one engineer can produce ten times as much implementation with AI, we cannot simply review ten times as much code manually. The old process breaks. Today we often have:

Human → code → human review

Tomorrow we may have:

Human → specification → many agents → automated verification → human judgment

That requires a different engineering discipline. We need better architectures. Better tests. Better specifications. Better observability. Better evaluation. Better security controls. Better deployment boundaries. Better rollback mechanisms. Better ways of proving that the generated system does what we intended.

This is why I don't think AI makes engineering less important. It makes engineering discipline more important. The amount of generated code may explode. Our ability to trust that code cannot depend on reading every line. We need systems that make correctness easier to verify.

So What Actually Makes a Career Safe?

This is the question I care about most. Because if coding becomes increasingly commoditized, simply becoming a better coder may not be enough. The answer, I think, is to build career capital in layers:

Technical depth. You still need to understand how software works. You need architecture. You need systems thinking. You need to understand databases, networks, distributed systems, security, reliability and the fundamentals of computing. AI doesn't remove the need for this knowledge. It gives you more leverage if you have it.

Domain expertise. Become unusually knowledgeable about something that matters to a business. Don't just be "a TypeScript developer." Become the engineer who understands a particular industry, market or class of problems deeply.

Product judgment. Learn to identify valuable problems. Understand customers. Understand economics. Understand trade-offs. Understand why something should be built, not just how.

Specification. Learn to turn ambiguous goals into precise systems and constraints. This may become one of the defining engineering skills of the AI era. The better you can specify a problem, the more leverage you can get from machines.

Verification. Learn how to determine whether a system is actually correct. Testing. Evaluation. Observability. Security. Performance. Failure analysis. Rollback. These skills become more valuable as the amount of machine-generated output increases.

Reputation. Build proof that exists outside your current employer. Write. Build open source. Contribute. Speak. Teach. Publish. Create things people can see. Your employer can remove your job. They cannot remove the body of work you've built in public. That's what makes career capital portable.

Become replaceable at the task level. There is a strange career