AI Is Replacing Engineering Tasks, Not Jobs
If your engineers only did what they were told, Claude Code already does that better.
Every CTO I talk to has a version of the same conversation happening on their team right now. An engineer is scared. They’ve seen what Claude Code can do. They’re watching AI ship entire features. They’re wondering out loud whether their job has a runway.
Here’s what’s worth saying out loud. AI isn’t replacing engineering jobs. It’s replacing engineering tasks. That distinction matters, and most leaders are fumbling it.
The easier parts of the job are getting automated. That isn’t new. Software engineers have been automating other people’s work for forty years. Now AI is automating ours. Writing code has always been the easy part. Knowing what to write has always been the hard part. AI is great at the first one. It is nowhere near the second.
A Task Is Not a Job
A task is a unit of work handed to you. A job is ownership of an outcome.
If your job is “close these tickets,” AI can already do that. Claude Code reads the spec, writes the code, opens the PR, passes the tests. If the requirements are detailed enough, AI is faster and cheaper than a human engineer will ever be.
If your job is “make checkout convert better,” or “keep our infrastructure costs from bleeding us dry,” AI is a tool you wield. Not a replacement. Those are outcomes, not tickets. Outcomes require judgment, context, trade-offs, and conversations with people who are not engineers.
The uncomfortable part: if your team has been run like a ticket factory, AI is exposing that. Not because AI is magic. Because the job was defined too narrowly to begin with.
Writing Code Was Always the Easy Part
In 1986, Fred Brooks wrote an essay called “No Silver Bullet.” It’s one of the most important things ever written about software engineering, and it lives inside his book “The Mythical Man-Month,” which you should read if you haven’t.
Brooks drew a line between two kinds of complexity in software. Accidental complexity is the stuff that’s hard because of our tools, our languages, and our platforms: the typing, the scaffolding, the glue between systems. Essential complexity is the stuff that’s hard because the problem itself is hard: figuring out what the software should do, specifying it correctly, and understanding the people who will use it.
Brooks argued that productivity tools would keep attacking the accidental side and would never put a dent in the essential side. He was right about compilers, IDEs, frameworks, ORMs, serverless, and no-code. Each wave was supposed to replace engineers. Each wave made the job bigger, not smaller. More software got written, and someone still had to decide what it should do.
AI is the same thing, just bigger. It absorbs the accidental complexity in one enormous gulp: syntax, scaffolding, boilerplate, glue, first-draft implementations. None of that is where software engineering was ever actually hard.
I built VinSolutions and Stackify from nothing. The parts I remember are not the parts where I was typing. They were the parts where I was trying to figure out what a car dealer actually needed at 11pm on a Tuesday. Or what a developer using Stackify cared about when their production app went down. The code wasn’t the mountain. The users were.
That is the shift every engineer has to make now. Stop thinking about the code and start thinking about the people who will live with it. What are they trying to accomplish? What would make their life easier tomorrow? Where is the thing they put up with every day because nobody bothered to fix it? Step out of the editor. Go find the real problem. The real problems are not inside your repo. They are inside your users’ days.
What Survives, What Doesn’t
What AI is absorbing:
Boilerplate, scaffolding, glue code
First-draft implementations from a clear spec
Rote test writing
Tier-one bug triage
Internal tools, admin panels, most CRUD
What it isn’t touching:
Problem framing and product judgment
Technical trade-offs under real constraints
Understanding the customer well enough to build the right thing
Communicating with people who are not engineers
Owning an outcome end to end
The honest version of this conversation is: if you built a team around ticket throughput, a chunk of those engineers are exposed. That isn’t an AI problem. It’s a management problem that AI is making visible.
What Engineers Should Actually Do
Start asking why. Ownership and understanding both start with that one question. Why are we doing this? Who is it for? What happens if we don’t? If you’re writing code before you can answer those questions, you’re doing what AI does. The engineer AI cannot replace is the one who refuses to start until the problem is clear.
Own an outcome, not a backlog. Pick a number that matters to the business, whether that’s conversion rate, activation, build time, or churn, and tie your week to moving it. If you can’t show a number moved, don’t count the work. Tickets closed is not an outcome.
Ship end-to-end, not to the PR. Your job is not done when the merge goes through. It is done when the customer sees value. Watch your feature land in production, read the support tickets it generates, and find one user who will tell you what they actually do with it. That last step is where almost everyone quits, and it’s where the job now lives.
Review AI’s code with more rigor than you’d review a junior’s PR. The most dangerous engineer on your team right now is the one who can’t tell when Claude handed them subtly wrong code. Reading code used to be a useful skill. Now it is the critical one. If you can’t explain why every line is there, you don’t own it, and you shouldn’t be merging it.
Use AI to buy yourself time for judgment, not more tickets. The trap is using AI to close Jira cards faster. The play is using the hours you save to talk to users, understand the product, and push back on bad requirements. If your throughput went up but nothing else about your work changed, you’re doing it wrong.
What Engineering Leaders Should Actually Do
Actually do your one-on-ones. You might not enjoy them. Do them anyway. One-on-ones matter more now than they did three years ago, not less. This is where you hear how AI is actually changing the day-to-day for your engineers, where they feel exposed, and what they think their job is becoming. It is also where you reconnect each engineer to the bigger picture: why the work matters and how it fits into what the company is trying to build.
Ditch the vanity metrics. The old velocity signals (commits, PRs merged, story points, team velocity) were always game-able, and AI makes them trivially game-able. What matters now is the impact of the work, not the volume of it. What outcomes for your users can you track instead? Pick one your team can actually move, and make that the new north star.
Put every engineer on a support rotation. Two hours a week reading real customer tickets will change what your team builds more than any kickoff meeting ever has. If you can’t run a real rotation, forward the top five support tickets to the team channel every Monday. Engineers who never see the damage their software causes will never fix it.
Protect your team’s focus. AI made code cheap. It did not make attention cheap. If your engineers are still context-switching across ten competing priorities, you have not adjusted to the new world yet. The highest-leverage move a leader makes now is cutting the list in half. Focus is a leadership job, not one you can delegate to your team.
Invest in clarity before velocity. AI will write the wrong code faster than any human ever could. If the problem is fuzzy, the speed multiplier works against you. Get the brief crisp before a single line is written: what are you solving, who is it for, what is in scope, what is out. Product clarity, scope clarity, and technical clarity are the real unlocks now, not more AI tooling.
Stop shielding engineers from product. You do not need every engineer in every messy stakeholder meeting where nobody makes a decision. What they do need is to see the roadmap and understand why each choice on it got made the way it did. The old version of engineering leadership buffered engineers from product ambiguity, and it produced exactly the kind of engineer AI can now replace. The goal isn’t more meetings for your team, it is more understanding of the product.
The Real Question
The panic is real, but it’s aimed at the wrong thing. AI is doing what every abstraction before it has done. It’s pushing the work up. Engineers whose jobs were defined as “execute tickets” are in a bad spot. Engineers whose jobs were defined as “solve business problems” just got the biggest leverage boost of their careers.
It has never been more fun to build software, if that is what you are focused on. The fun is in building for users, not writing code for yourself.
Here is the big question...
Are your engineers doing their job, or only the tasks you assigned them?
Your team needs goals, not just tasks.