What I told an engineer who asked if AI will replace us

In a recent 1:1, an engineer on my team told me that Claude Code now handles most of the work they used to do by hand. Then they asked me whether we can be replaced.

I didn't treat it as a strange question. I'd been asking myself the same thing for months. Watching a machine do things I spent years learning was honestly depressing, and I still don't have a settled answer. What I gave them was the answer I do have: the way we execute is changing a lot, but the core of the job isn't. This post is a longer version of that conversation.

What the job is

Stripped down, the job looks like this. Someone has a problem. We work out what the problem really is, decide what is worth building, and turn that into software that takes some of the load off their life. They get back time and attention they can spend on something that matters more to them.

That holds regardless of the product. For a consumer app, it might mean a shopper no longer has to compare prices across five tabs. For enterprise software, it might mean a finance team no longer chases approvals over email. For an internal tool, it might mean a teammate deploys with one command instead of a checklist. The users and the code are different. The work underneath is the same: understand the problem, then remove it.

Fred Brooks made a version of this point in 1986, in No Silver Bullet: "The hardest single part of building a software system is deciding precisely what to build." He split software difficulty into essence, the problem itself, and accident, the friction of the tools we use to express it. Most improvements in tooling, from high-level languages to better IDEs, attacked the accident. AI coding agents are a much bigger attack on the same side. They don't touch the essence.

A faster oven is useful. It doesn't decide the menu, and it doesn't know which guest is allergic to peanuts.

What changes is how we execute

The part that is changing fast is the path from a decision to working software. To show what I mean, here is roughly how I think about where time goes across the phases of building something.

The bars are illustrative, not measured. Before AI, the build bar was also where a lot of the joy was. Typing code and seeing it work for the first time is one of the best feelings in this job. Even so, good engineers always tried to spend less time typing. They built macros, snippets, and autocomplete, and the most dedicated ones learned Vim motions and set up language servers so they could move through code without leaving the keyboard. Agents are the biggest step yet in that same direction. Anthropic looked at about 400,000 Claude Code sessions and found that humans still made around 70% of planning decisions but only about 20% of execution decisions (Anthropic).

The bars don't all get shorter, though. When one phase speeds up a lot, the rest of the system sets the pace. Engineers will recognize this as Amdahl's law applied to a team. With agents, the work piles up in review and verification. Not every line needs a human read, and simple changes can skip a careful review. But someone still has to spot the changes that really matter, read those carefully, and decide whether the result is safe to ship.

So "I automated most of my work" and "I deliver more value" are two different statements. I wrote about that gap in The illusion of output. Automation removes the typing. It doesn't remove the need to know whether the result is right.

We have been here before

New tools have always landed hardest on the people whose work was tied to the old tool, and history has plenty of examples. Electric street lights replaced the lamplighters who lit gas lamps every evening. Refrigerators ended the trade of cutting ice from frozen lakes and delivering it door to door. Automatic switching replaced telephone operators, and automatic elevators replaced elevator operators. Electronic computers took over from human computers, the people who did calculations by hand for science and engineering teams, NASA included. Cheap alarm clocks ended the knocker-uppers in Britain, who were paid to tap on windows to wake workers for early shifts. Tractors and combines moved most farm workers off the land, and the internet did the same to many travel agents and video rental clerks.

In each case the need stayed. People still wanted light at night, cold food, a call put through, a ride to the tenth floor, a correct calculation, and a way to wake up on time. What disappeared was the job of meeting that need with the old tool.

Each shift hit hardest the people whose work was defined by the old tool. A lamplighter's job was lighting gas lamps, not keeping streets lit at night, so when the lamps changed, the job went with them. The work moved to whoever could serve the same need with the new tool.

For us, typing code by hand is the old tool. The need is the problem someone wants solved. That need isn't going away, and learning new tools to serve it has always been part of the job.

If 80% of the work is automated

Here is the thought experiment I offered in the 1:1. It isn't a forecast. Assume that 80% of what you do today can be done by an agent. Look at what is left in the other 20%, and put your effort there.

When I do this exercise, the remaining part looks like this.

Understanding a problem that arrives unclear. Real requests rarely come as clean specifications. Someone might say the checkout is slow when the actual issue is a confusing step that makes people abandon it. An agent can work on whichever problem you hand it. Deciding which problem to hand it is still on you. The habit that helps most is writing down the problem in the user's words before writing anything about the solution, and checking it with the people who feel it.

Choosing an approach when every option has a cost. Agents are good at producing options. Picking one means weighing things they can't see well: what the team can maintain, what the business needs next quarter, what risk is acceptable. A simple practice is to write down the options you rejected and why. It makes your reasoning visible and easy to challenge.

Owning whether it works. Verification is now the slow part of the pipeline, which makes it one of the most valuable. Define done as the outcome for the user, not as a merged pull request. Read the output as if you will be woken up when it breaks, because you might be.

Caring about how it fits into someone's life. When I wrote about this on X, I called it the human soul of a product: someone cared enough to make it useful. That care shows up in small decisions no specification lists.

None of this means ignoring the tools. The faster execution stops being your bottleneck, the more time you have for the part that is left. Learn the agents properly, then spend the time you win on the 20%.

What I can't promise

The entry point into this profession is getting narrower. Stanford researchers found that employment for 22 to 25 year olds in AI-exposed jobs is about 19% below where it would otherwise be, mostly because companies are hiring fewer of them (Stanford Digital Economy Lab). Judgment is worth more, but the usual path to building it is shrinking. There may also simply be fewer of some roles, especially the ones defined mostly by execution.

When a junior engineer asked me how to keep up when AI moves faster than anyone can learn, I used a Formula 1 analogy. The car is the AI tooling. The track is the system and the product you build with it every day. A good driver knows the car well, what it can do and where its limits are. But a fast car has never won a race on its own. The driver still needs to know the track by heart, where to push and where to brake. The faster the car gets, the more the driver matters. Keeping up doesn't mean reading every line the agent writes. It means knowing where it tends to get things wrong and which parts of your system are critical enough to understand deeply.

Another worry I hear is that AI steers juniors away from the mistakes that used to teach us. I see it the other way. You can learn faster, across more topics, and try several approaches to the same problem side by side, which used to cost too much time to be worth it. If you treat something as a disadvantage, everything around it starts to look like a disadvantage too. If you treat it as an advantage, you find ways to turn the rest in your favor.

And I can't promise AI will never do the 20% too. If it eventually understands people and cares about what it builds, we'll have much bigger questions to work through as a society. Those are not questions software engineers alone should have to answer.

None of this changes the advice. It only raises the cost of ignoring it.

Back to the 1:1

What I told the engineer, in the end, was that the nature of our work isn't changing. We're problem solvers. As long as we keep that core and keep learning the new tools, there is still plenty of room to grow. If I could add one thing now, it would be to watch where the saved time goes. If it goes into understanding the problem better, choosing better, and checking the result more carefully, they're doing the part of the job that isn't going away. If it goes into producing more of the same output faster, they're competing with the tool on the tool's terms.

I still don't have a settled answer to the bigger question. But I can build things today that used to need a whole team, and that has made me curious about building again.

If this resonated with you, subscribe to my blog. I share what I learn while building software with AI in the loop. You can also follow me on X or Threads.