← New here? Start with Part 1: Will AI Take More Jobs Than It Creates?
Part 1 of this series made a case. AI will retire a lot of repetitive work, but it will not empty out your engineering team. The tasks change shape. The people stay. We landed on a line: AI is leverage for your engineers, not a replacement for them.
That answer is true. It is also incomplete. Because the moment a room full of engineers accepts it, someone asks the quieter question. Fine, my job survives. But survives as what? Am I still good at this in two years, or is the thing I am good at about to stop mattering?
That is a fair question and it deserves a straight answer. Part 2 is about the people, not the workflows. What actually changes for the engineer at the bench, which skills gain value and which quietly lose it, and what it takes to bring a whole team along instead of the two people who were already curious.
The skill that stops mattering, and the one that starts
For twenty years, a lot of an engineer's value lived in execution speed. How fast you could build the drawing, rebuild the assembly, chase the revision, remember where the file lived. Real skill, hard won, and it paid.
AI is best at exactly that layer. Not the thinking. The producing. It drafts the first version of the drawing, finds the file, proposes the revision. So the value of being fast at production starts to fall, because the tool is faster and it does not get tired.
What rises in its place is judgment. Knowing what good looks like. Framing the problem before anyone touches the geometry. Catching the moment the AI is confidently wrong, which it will be, because it does not know your customer, your tolerances, or the failure you saw on the floor last year. The new core skill is not producing a first draft. It is evaluating one. That is a different muscle, and most of your engineers already have it. They have just spent their careers using it on their junior staff instead of on a machine.
From doing the work to directing it
Here is the shift in one sentence. Your engineers move from doing the work to directing it.
Your senior people already know the move. Hand a task to a junior engineer, set the intent, check the result, correct it, send it back. AI turns every engineer into that senior engineer, all day, for a tireless report that produces in seconds and needs every output checked.
Two things follow. First, the ability to state intent clearly becomes a technical skill, not a soft one. Vague in, vague out. The engineer who can say precisely what they want, and what "done" means, gets far more out of the same tool than the one who cannot. Second, the quiet, careful reviewer who was never the fastest producer on the team may turn out to be your strongest performer in this new shape. Speed at the keyboard stops being the tell. Quality of judgment is.
The new roles nobody has a title for yet
When the work changes, new jobs appear before anyone writes the job description. Two are already showing up on engineering teams that have started.
The data steward. In Part 1 we said AI is only as good as the data underneath it. Someone has to own that data. Not as an IT chore, but as an engineering responsibility. The person who keeps the vault clean, the naming honest, and the history intact, because they understand that every sloppy file is a wrong answer waiting to happen.
The workflow owner. The engineer who builds and tunes how the team actually uses AI. Which prompts work, which steps to trust, and where a human check is not optional. This person turns one clever use into a standard the whole team can run.
Neither has to be a new hire. In most shops they are hats that existing people put on. And for the engineer willing to raise a hand, they are the clearest career upside in the building right now.
It will not land evenly, and that is the real risk
Be honest about this part. Adoption does not spread on its own, and it does not spread fairly. Some of your people will run at this. Others will wait it out, quietly hoping it turns out to be a fad.
The ones at risk are not your weakest engineers. They are the ones, at any skill level, who refuse to change how they work. And the ones who thrive are not always who you would guess. Curiosity, a willingness to check the machine's work, and comfort saying out loud what they actually want matter more than raw seniority.
That makes adoption a management problem, not a personality lottery. Leave it to whoever is naturally into it and you get two power users and a team that quietly routes around the tools. Bringing everyone along is a decision someone has to own.
This is a people change, not a software install
Here is the trap. The tools keep getting better on their own. Your team's ability to work alongside them does not.
You can buy every AI feature on the market and change nothing about how the work gets done, because nobody redesigned the day around it, nobody decided what to trust, and nobody taught the careful reviewer that their judgment is now the point. That is not a licensing question. It is training, workflow, and culture.
This is where we spend our time. We are engineers who implement and integrate these tools, not a reseller that turns them on and walks away. The software is the easy part. Helping your people change how they work, so the whole team gets the lift and not just the early adopters, is the work that actually moves the numbers.
The question worth asking inside your building
The public debate about AI and jobs will run for years. Inside your building the question is smaller and far more useful. Not whether the jobs survive. What your people need to learn, and who is going to help them learn it.
That is a conversation worth having before the gap Part 1 described opens any wider.
