Automation doesn’t steal our jobs: it changes our craft

(…and most of the time we don’t notice)

Automation has become culture, not just a set of tools

In recent years I’ve realized something simple but rarely said:
we don’t just use automation anymore, we live inside automation.

Once upon a time, adding a new script, a scheduled job, or a pipeline was “doing automation”.
Today, without CI/CD, infra-as-code, and a minimum level of observability, a team doesn’t even leave the starting blocks.

Automation has become:

• an implicit pact between dev, ops, security, product;
• a mindset: every repetitive process is suspicious, and therefore a candidate to be automated;
• a quality constraint: if something can’t be automated, we start wondering whether it’s poorly designed.

It’s not just technology: it’s organizational culture.

And when something becomes culture, it reshapes roles far more deeply than any “simple” new technology ever could.

Some concrete examples: CI/CD, AI copilots, predictive monitoring

To understand how our work is changing, it’s enough to look at three areas where automation has become the “background noise” of our days.

CI/CD: from pipeline as object to pipeline as environment

At the beginning, CI/CD was “the build server” in a corner, managed by two “tinkerers”.
Today, in a healthy team, the pipeline is part of the system architecture:

• it governs releases;
• it defines boundaries between teams;
• it encapsulates policies for quality, security, and compliance.

This radically changes the work:

• for devs, “Done” is no longer “it compiles and passes local tests”, but “it passes the whole automated chain up to (almost) production”;
• for DevOps/SRE, the work shifts from “fixing broken builds” to designing delivery systems that are robust, self-explanatory, with clear feedback;
• for the CTO/tech lead, the pipeline becomes a tool of governance: what doesn’t go through CI/CD basically does not exist in the system.

Production work (build, deploy, regression testing) is more and more automated.
Human value moves to designing the flow, not executing the steps.

AI copilots: from “I write the code for you” to “I structure your reasoning”

Many people see AI copilots as tools “to write more code, faster”.
In reality, they’re doing something deeper: they’re compressing the mechanical part of cognitive work.

• Repetitive refactoring? The AI does it.
• Integration boilerplate? The AI does it.
• Standard SQL queries on recurring patterns? The AI does it.

This doesn’t mean the dev “disappears”, it means:

• value shifts to understanding the domain;
• to the ability to break down complex problems into clear steps for the AI;
• to the critical validation of what the AI produces.

Those who only “execute specs” risk being thrown off balance.
Those who think in terms of architecture, trade-offs, business impact find in AI a powerful multiplier.

Predictive monitoring: from “watching metrics” to “designing alarm thresholds”

Observability and monitoring are going through the same transition.

We no longer just:

• look at dashboards,
• attach alerts to CPU, RAM, error rate.

We’re moving towards:

• systems that predict anomalous trends;
• alerting based on behavioral patterns rather than individual metrics;
• automatic correlation between infrastructure, application, and business events.

Here human work moves from:

“Whoever is on-call watches the metrics and reacts”

to

“We design an observability system that tells us what’s happening before it hurts.”

Once again: less “production” work, more orchestration of complexity.

What really changes for CTOs and tech leads

If automation moves human value from execution to complexity design, the roles of CTO and tech lead change deeply.

From “choosing technologies” to “designing the socio-technical system”

Being a CTO today is not (just) choosing whether to use Kubernetes or ECS, this framework or that one.

It’s mainly about:

• deciding how teams interact with automation tools;
• defining who owns what: who owns the pipeline, who owns monitoring, who owns security policies;
• designing interfaces between teams (APIs, contracts, SLO agreements, handover flows).

In other words: the CTO no longer governs only the technical system, but the socio-technical system.

Automation makes the system more powerful but also more sensitive:
if you get responsibility boundaries wrong, a single script can stall half the business.

Tech lead: from “senior fixer” to “flow curator”

The tech lead is no longer just the person who “knows where to put their hands when everything is on fire”.

Their value lies in:

• taking care of the quality of the flow: how a feature goes from idea to production;
• promoting healthy practices: testing, code review, feature flags, progressive releases;
• helping the team use automation and AI properly, not bypass them.

In practice, the tech lead becomes a sort of orchestra conductor:

• they don’t play every instrument,
• but they ensure the score (process) is clear,
• the instruments (tools) are in tune,
• and every musician (dev, ops, QA, data…) knows when to come in and when to stop.

How to keep meaning and motivation alive in the team

Here’s the delicate point:
if you remove most of the “production” work from the team (writing code, triggering releases, manual monitoring), how do you prevent people from feeling useless?

A few ideas I see working:

Make impact visible, not effort

Many internal metrics still measure the quantity of output (stories closed, lines of code, tickets solved).

In an automated context, it makes far more sense to measure:

• lead time reduction (from idea to production);
• stability increase (fewer incidents, lower MTTR);
• improvement of SLOs that matter to the business (error rate on critical transactions, average response time of core APIs, etc.).

When you connect people’s work to these numbers, not to “how many things they do manually”,
it becomes easier to make them feel that designing a good pipeline is worth more than “doing ten manual deploys”.

Reward simplifiers, not complexity hoarders

In many technical cultures (especially where there’s a strong “craftsman” legacy), there’s an almost proud tendency to keep systems complex, tricky, full of hacks.

Automation needs the opposite:

• processes simple to understand;
• linear, standardized deployment paths;
• clear, codified policies.

If you want the team to truly embrace automation and AI, you need to reward those who:

• remove unnecessary complexity;
• reduce manual steps;
• make the system more “boring” (in a good way).

Motivation also comes from the implicit message:

“Your value is not in keeping chaos alive, but in making sure chaos is not needed.”

Grow meta-skills: domain, communication, decision-making

If scripts and AI reduce routine work, everything that is hard to automate becomes central:

• understanding the domain better than the customer themselves;
• communicating technical trade-offs clearly to the business;
• making decisions under uncertainty;
• knowing when to say “no” to requests that would damage architecture and processes.

A motivated team in a highly automated environment is a team that knows:

• they’re not paid to “write code n hours a day”,
• but to make technical decisions that keep the business running over time.

Conclusion: towards a new digital craftsmanship

Here’s the idea I’m left with:

Automation doesn’t eliminate human value; it moves it from production to the orchestration of complexity.

We’re less “code factory workers” and more system craftsmen:

• we design delivery flows;
• we encode rules into pipelines, policy-as-code, infrastructure-as-code;
• we use AI and automation as levers of leverage, not as brain parking lots.

It’s a new form of digital craftsmanship because:

• it still requires taste, experience, and sensitivity;
• it can’t be reduced to checklists;
• it lives at the boundary between tech, organization, and business.

Those who insist on measuring their worth by “how much” they produce (lines of code, tickets, manual patches) will feel threatened by automation.

Those who are willing to move to the “how” and the “why”:

• how we orchestrate complex systems,
• why we choose one solution over another,
• how we put the team in a position to spend less effort and create more impact,

will discover that automation doesn’t steal the job — it promotes it to a higher categories.

And that, in my view, is where it’s really worth being.