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. How to specify work. How to establish boundaries. How to give agents the right context. How to structure systems so that work can happen safely in parallel. How to verify the results. How to detect when an agent has gone off course. How to roll back changes. How to 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 lesson hidden in all of this. I don't think you should try to make yourself irreplaceable. You should try to make yourself replaceable at the task level.
If an AI can write the CRUD endpoint you used to spend half a day implementing, great. Let it. If an agent can write the tests, great. Let it. If a tool can refactor 50 files in seconds, great. Let it.
Your goal shouldn't be to protect those tasks. Your goal should be to move upward.
From implementation to architecture. From architecture to product. From product to domain. From individual tasks to systems of work. From writing code to deciding what code should exist in the first place.
The safest engineer isn't necessarily the one who can write the most code. It is the engineer who can create the most value when the cost of writing code approaches zero.
Coding was never the destination
This is why I keep coming back to Carmack's observation. Coding was never the source of value. It was the mechanism through which we created value.
For decades, writing software was expensive enough that the ability to write it well was itself a significant competitive advantage. AI changes that equation. And that is scary. But it is also liberating.
Because it forces us to ask what we should have been asking all along: What are we actually here to do?
We're here to solve problems. We're here to create useful products. We're here to improve businesses. We're here to make systems more reliable. We're here to reduce costs. We're here to create new possibilities.
Code is one of the tools that allows us to do those things. It is not the thing itself.
Linus's attitude toward AI is useful here because it cuts through a lot of the noise: Use the tool. Judge it on technical merit. Keep the engineering standards. And if the tool becomes genuinely useful, don't confuse refusing to use it with preserving engineering.
The future engineer may write less code than today's engineer. They may spend more time understanding a business. More time talking to customers. More time designing systems. More time specifying problems. More time verifying results. More time coordinating machines. And potentially produce vastly more valuable software as a result.
That's the career shift I'm preparing for. Not how do I make sure AI never replaces what I do? But: How do I become the person who can use AI to create more value than I could ever create by myself?
Because career safety doesn't come from protecting the work that machines are learning to do. It comes from developing the judgment, expertise and reputation to remain valuable when the work itself changes.
Top comments (6)
The domain-expertise-as-moat point really lands, that's already showing up in hiring. And "verification becomes more important than generation" is the most underrated line here; everyone's optimizing for output speed, but almost nobody's built the infrastructure to verify it at that speed yet.
Problem solving through code = programmer. Code is a medium, like a car is for driving, doesnt make you any less a taxi driver if you sit in the seat of a tesla on auto-pilot? Your job is taxi driver, your service is taxiing, your goal is to take passengers from point A-B safely for money. Even if the car drives itself, you're responsible for the goal, because it's your job and your quality of service.
Same goes for programming. Company A wants a mobile game, so you make them a mobile game, whether by hand over 10 years, or via AI in 10 minutes, if the quality of service render is sufficient, they'll pay for it. That's the value you bring as a programmer to a company, quality. You deliver garbage code, you're out of job, with or without AI. But if your code is clean and runs well, neither an employer, nor a client cares how it was done.
The illusion that we owned the code is taking credit for what a computer does. We simply instruct through a keyboard, whether it's in an IDE, or a chatbox, same thing different syntax.
Take Carmack for example, you think he'd have written Doom's engine by hand if he had AI? He'd have used Roslyn if he had it, anything to get the job done faster and clear, he'd have taken it! Not because they were lazy, or unmotivated, but because the engine was the medium by which people played the game and people bought the game, not the engine. They didnt even buy the game FOR the engine, or BECAUSE of the engine, they bought it because it was cool, fun and it played well. That's it, high quality code, regardless of origin, is still high quality code.
I would frame it diferently. You don't drive one car anymore. Instead you have a group of self-driving cars working for you. However, you need to make decisions such as at what time should they be fully charged to maximize profits? What weeks of the year make sense to do maintenance? What location gives better returns? What models are better for ROI? You go from taxin driver to taxi operator.
Optionally yes, but nobody said you have to run multi-agent systems?
Yo do if you want to be 10x. The important part is that not all agents will be implementers. Some of them will be planners others will be for verification.
Well not quite. What's your typing speed? That's keys per second, models run at tokens (often entire words or 1/2 words per token) and blast well past 100/s. So even just using AI actually already puts you past 10x. Orchestration is where you redraw the baseline at AI accelerated. I am aware, I built an entire teams studio into velocity IDE specifically for multi-agent MoE delegation. That being said, there's no way to be omnipresent if you're running multiple agents at once, you can backtrack and pay attention to what's been done and what happens next. Think of a machine operator switching to a machine maintainer. Entirely different job, same quality gate. Think Charly and the Chocolate Factory, Charly's father, who screwed on caps for a living, turned mechanic on the machines that replaced him. Learn how your replacement ticks, so you can maintain it in a way that keeps the standards you upheld. Like you said about Linus, dont refuse to preserve, if you can use and preserve. But that's the boundary you need to draw yourself, how many agents can you comfortably handle, without cracks forming and quality slipping?