Peter was an ML engineer.
For two years, he had worked hard, solved problems, written code, built models, deployed systems, and earned a comfortable living. Like many engineers, he believed his skills had value because what he did required years of learning and experience.
Then his boss discovered an enterprise AI data scientist designed to execute end-to-end ML pipelines.
At first it seemed harmless. Another AI assistant. Another productivity tool. But the more his boss used it, the more he discovered what it could do.
Peter was not immediately worried. After all, engineering was more than writing code.
Or so he thought.
One morning, Peter arrived at work as usual. He greeted the secretary, sat at his desk, and prepared to begin another day.
A few minutes later, the secretary walked toward him with an envelope.
It was a letter.
Peter opened it.
His employment had been terminated.
The reason was painfully simple:
“The machines can now do your work.”
Two years of service had been reduced to a sentence.
The company had not asked what would happen to Peter. It had calculated what Peter's salary cost and what the machine could accomplish for less.
And that is the uncomfortable reality of automation: companies do not experience technological progress emotionally. People do.
Consider something as simple as this:
from sklearn.pipeline import Pipeline
from sklearn.preprocessing import StandardScaler
from sklearn.ensemble import RandomForestRegressor
model = Pipeline([
("scaler", StandardScaler()),
("regressor", RandomForestRegressor(n_estimators=200))
])
model.fit(X_train, y_train)
predictions = model.predict(X_test)
An AI system can generate code like this in seconds.
But engineering has never been merely about producing lines of code.
Why should the data be standardized? Is there data leakage? Is a random forest appropriate? How should the model be evaluated? What happens when the data distribution changes? Where should the model be deployed? How will failures be detected? Who is responsible when the model produces a wrong prediction?
Even this tiny function looks trivial:
def predict(model, data):
return model.predict(data)
But what happens when the model begins to drift?
What happens when the input data changes?
What happens when the model confidently produces the wrong answer?
Generating code is not the same as engineering a reliable system.
Yet AI is already moving upward through the software-development ladder.
It generates snippets, functions, modules, tests, documentation, applications, and infrastructure configurations. Increasingly, it can also coordinate these pieces to help construct much larger systems.
That is where the fear comes from.
Automation does not necessarily eliminate an entire profession at once. It eats away at its layers.
A developer who once spent hours writing a function is now spending minutes reviewing AI-generated code. A team that once needed ten engineers for a particular project is now discovering that five can accomplish much of the same work with AI assistance.
And management is already asking the question Peter's boss asked:
Why do we need as many engineers as before?
The problem is even more serious for junior developers.
Entry-level engineers traditionally learned by doing the small tasks that experienced engineers considered repetitive: writing simple functions, fixing minor bugs, creating tests, preparing documentation, and building small applications.
Those are precisely the tasks AI is increasingly good at performing.
The beginner's work is therefore becoming automated before the beginner has had enough time to turn that work into experience.
This creates a troubling contradiction:
Companies want experienced engineers, while automation is reducing some of the opportunities through which engineers gain experience.
Peter understood this only after losing his job.
At first, he was angry. Then he became afraid. Eventually, he realized that fighting AI itself would not bring his job back.
So he adapted.
Peter was already educated. He did not need to start his career from scratch. He needed to redirect what he already knew.
He began learning about large language models, retrieval-augmented generation, AI agents, cloud infrastructure, model serving, AI security, monitoring, and the engineering systems surrounding AI.
He stopped thinking only about how to build a model.
He started learning how to build, deploy, manage, evaluate, secure, and understand AI systems.
He also learned to use AI as part of his own engineering workflow.
That distinction changed everything.
AI can generate.
Peter learned to judge.
AI can suggest an architecture.
Peter learned to determine whether that architecture actually makes sense.
AI can write a model.
Peter learned to understand its assumptions, limitations, failures, and consequences.
He was no longer trying to compete with AI at the tasks AI performed best. He was learning how to work above, around, and alongside those capabilities.
And that gave him something new to offer.
Peter began looking for organizations that needed engineers who could do more than write code—people who could integrate AI into real systems, deploy and monitor those systems, evaluate their outputs, manage their infrastructure, identify their weaknesses, and take responsibility for how they operated.
He eventually found another organization.
The job was different.
Peter was different too.
He had not defeated AI.
He had learned where he could remain valuable in an economy increasingly shaped by it.
That is perhaps the most realistic path for engineers facing automation.
Not pretending that AI cannot replace parts of their work.
Not refusing to use it.
Not simply becoming faster at doing what machines are already becoming good at.
But learning new capabilities, redirecting existing expertise, using AI to multiply their productivity, and finding where those capabilities are needed.
AI is powerful. Pretending otherwise would be foolish.
But perhaps the greater danger is not that AI destroys engineering.
The greater danger is that we allow automation to make us believe that an engineer's value is nothing more than the tasks they currently perform.
Peter lost his old job.
But he did not lose his knowledge, his experience, his ability to reason, or his ability to learn.
His old role disappeared.
His career did not have to.
For every job displaced by AI, there is a Peter who gets laid off. But for every Peter, there is also hope—even in a world where AI is changing the meaning of work.
This article was originally published by DEV Community and written by Oluwafemi Paul Adeyemi.
Read original article on DEV Community