Career safety in the Age of AI Layoffs

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 requiremen