When the tool can do the work, where does expertise still lie?

Expertise doesn’t disappear when you automate the gesture. It moves.

A few years ago, when an engineer designed a mechanical part, they had to master their CAD tool, build the geometry, define the constraints and check the result.

Today, an AI can generate part of that geometry, produce parametric design code and sometimes even prepare what is needed to manufacture it.

So a question arises: what is left for the engineer?

The answer seems simple: their expertise.

But where exactly does it lie?

Knowing how to do it, and knowing what to do #

Take an example.

I want to design a mechanical part meant to house an electronic board.

Today I can ask an AI to generate parametric CAD code from constraints: dimensions, tolerances, component placement, mechanical interfaces, manufacturing processes.

The resulting model can be modified, checked, then sent to a 3D printer.

A significant part of the modelling work is then automated.

But the AI doesn’t necessarily determine which constraints are relevant.

It doesn’t spontaneously know why a particular tolerance is needed, why a part must be removable, why one material is preferable, or why a perfectly modelled solution might still cause problems at industrialisation.

These things come from understanding the product and its environment.

The skill is therefore no longer only to produce the model, but to define what the model must respect and to check that it does.

And this distinction goes well beyond CAD.

Automation shifts the work #

In electronics, we can automate part of netlist generation, schematic analysis or routing optimisation.

In software development, an AI can produce code from specifications.

In project management, it can cross-reference decisions, identify dependencies or track actions.

Each time, part of the operations once done by hand can be delegated.

But this delegation brings another kind of work into view.

Rules have to be formalised.

Constraints defined.

Data organised.

Interfaces built.

Results checked.

The errors automation cannot detect have to be identified.

And above all, decisions still have to be made.

Because automating a task doesn’t necessarily mean automating the reasoning that judges whether it is relevant.

The risk of confusing output with competence #

For a long time, we assessed a skill through a person’s ability to produce something.

A developer writes code.

A draughtsman produces drawings.

An electronics engineer designs circuits.

A project manager builds and tracks schedules.

These activities remain important.

But when a tool can carry out part of that output, they are no longer enough to characterise expertise.

Take two people with the same AI tool.

The first asks it to produce a solution and accepts the result because it seems to work.

The second knows how to question the assumptions, refine the constraints, spot inconsistencies, confront the results with reality and determine the checks that are needed.

They use the same tool.

Yet they don’t necessarily have the same ability to produce a reliable result.

Access to a tool doesn’t automatically grant the competence needed to judge what it produces.

And that is probably one of the major challenges of integrating AI into technical work.

Can you automate your own know-how? #

For several years, I have been building tools to reduce repetitive tasks in my work.

Gradually, these tools began to share their data, then their functions.

The arrival of local AI models let me go further, integrating some of my working methods into a common environment.

But the exercise is interesting for another reason.

For a system to reproduce part of the way I work, I first have to manage to describe it.

Why do I check this parameter?

Why do I favour this architecture?

What criteria make me rule out a solution?

At what level of uncertainty should I stop a design to take a measurement?

Questions we sometimes answer almost instinctively after years of practice.

Building the tool forces part of that know-how to be made explicit.

And you then discover that some decisions can be translated into rules, others need additional data, and others still resist formalisation.

That last category is particularly interesting.

It is a reminder that not everything we know how to do is necessarily something we know how to explain or automate.

Efficient automation doesn’t remove responsibility #

When an AI generates a mechanical model, who guarantees it can be manufactured?

When it proposes a PCB routing, who checks the electrical, thermal or electromagnetic-compatibility constraints?

When it generates embedded code, who ensures the behaviour meets the system’s requirements?

These questions don’t disappear because production becomes faster.

They become even more essential as the volume of production grows.

A tool able to generate ten times more solutions isn’t necessarily progress if we can’t verify them properly.

Efficiency isn’t simply about producing faster.

It is about obtaining a usable result with fewer resources, without degrading the level of confidence its use requires.

That means treating verification, validation and arbitration as integral parts of the work, not as formalities added after generation.

In the end, what do we hand over to the machine? #

A method?

Knowledge?

Experience?

A series of past decisions?

Probably a bit of all of it.

But two things must be distinguished: a system able to reproduce certain decisions in known situations, and a system able to determine whether those decisions remain relevant in a new one.

Part of the difficulty lies in that gap.

We can automate gestures, formalise rules, capitalise on knowledge and build systems able to mobilise it.

We can even obtain results that would have taken us far longer to produce by hand.

But we must remain able to understand what has been produced, why it works, and under what conditions it might stop working.

Expertise isn’t only what lets you produce a solution.

It is also what lets you know whether that solution is the right one.

And the more our tools become able to produce in our place, the more that distinction matters.