AI is changing our jobs: what future for engineering consultancy?

What is changing: tasks before professions

AI is often talked about as if it were going to replace a profession in one go. In engineering consultancy, the question is more precise: which tasks can it help with, under what conditions, and with what control?

An engineer does not spend the day only calculating. They look for information, read documents, prepare meetings, compare options, write and check. A business manager does not just look for a CV: they clarify a need, understand an organisation and support a relationship over time.

Some AI tools can help prepare a summary, structure a text or explore a set of documents. These are possibilities, not a description of our internal uses. Their value depends on the quality of the data, access rights and the time needed to check the result.

The International Labour Organization study cited at the end of this article distinguishes the exposure of tasks to AI from the disappearance of jobs. For our professions, this distinction is essential: speeding up part of the work is not enough to take on a whole assignment.

The value of advice is no longer just about producing

If a first draft of minutes or of a document becomes easier to obtain, producing it is no longer enough to show the value of a service. The difference lies in understanding the problem and in the reliability of the answer.

A summary can be clear and still miss the constraint that decides everything: an installation that must stay in service, access that is impossible during the works, a poorly defined interface between two packages. AI does not make these constraints any less important.

For a consultancy, this means explaining better what a team brings: suitable skills, a technical reading of the need, the ability to coordinate stakeholders and to follow decisions through to implementation. A deliverable remains useful, but it must serve a decision or an action.

Our view is simple: we must not confuse volume produced with service rendered. More documents do not necessarily mean a better-controlled project.

For engineers: knowing how to check matters even more

A generated answer can have the tone of expertise without its substance. A reference can be wrong, an assumption missing, a requirement misinterpreted. On a technical facility, a fluent text is not proof.

Take a hypothetical example: preparing a summary of the requirements of an electrical package. A tool can help organise the elements. The engineer still has to go back to the applicable documents, check the versions, spot contradictions and determine what actually falls within their scope. This preparation is neither an approved calculation note nor a technical approval.

The job therefore calls for two complementary skills: using a tool when it is relevant, and recognising when its result does not allow a conclusion. Being able to say "a piece of data is missing" remains better than delivering an answer that only looks complete.

Knowledge of the field keeps its full place. Interfaces, site conditions, testing and discussions with contractors cannot be reduced to a body of texts. On a data center as on an office building or a transport infrastructure, documents have to be confronted with reality.

For business managers: better qualification rather than more volume

Matching a client's need with an engineer's experience can look like a keyword problem. Yet two CVs that mention the same skill do not tell the same story.

You need to understand the role actually held, the level of autonomy, the project phase, the site constraints and the expectations of the client team. You also need to listen to the consultant: what kind of assignment are they looking for, and in what environment can they succeed and grow?

If tools make research or the preparation of discussions easier, the point is not to send more applications indiscriminately. It is to devote more attention to qualification. A well-argued proposal is worth more than a long list whose relevance nobody has checked.

This shift could strengthen the role of the business manager as the person who understands both the project and the engineer's career. It requires a real technical culture, not just command of a tool.

For our model: measuring quality, not promising speed

A faster task does not automatically make an assignment cheaper. Data preparation, licences, integration, training and checks all have to be counted. An error corrected late can cancel out the time saved at the start.

This raises a question for the consultancy model: how can the value created be made visible if the production time of some tasks falls? Depending on the assignment, it may show in a better-defined need, rework avoided, a better-documented decision or clearer coordination.

Technical assistance, owner's engineering (AMO) and dedicated project teams do not carry the same commitments. AI does not transform them all in the same way, and does not by itself change the contractual scope. It would therefore be premature to announce a uniform change in prices or headcount.

The right approach is to observe a well-defined use: what was produced, the total time spent, the errors detected and the usefulness for the recipient. Without this measurement, talking about productivity remains an intention.

Training without removing learning

Preparation tasks are also learning moments. Re-reading a file, looking for a requirement and drafting a first analysis allow a young engineer to build their reasoning.

Delegating everything to a tool too early can deprive them of this understanding. Conversely, comparing a generated proposal with the source documents can become a useful exercise, provided it is supervised and the corrections can be explained.

The goal is not only to know how to ask for an answer. It is to know how to defend an assumption, identify a limit and explain a decision to someone else. Technical fundamentals, site experience and the eye of experienced engineers remain necessary.

Limits to set before uses

A CV, interview notes or a client document are not data to be dropped into any service. Before professional use, permissions, confidentiality, the supplier's terms and the rules applying to personal data must be examined.

The CNIL resources and the NIST framework cited below shed light on these precautions. They do not constitute a certification of Miles Group's tools. This article does not claim to establish where our data is hosted or how a supplier processes it.

The same caution applies to results: a suggestion must not become a decision out of mere habit. Control must be real, with the option of rejecting the proposal and going back to the sources.

The change we should aim for

For Miles Group, the interesting question is not how to appear more automated. It is how to practise our profession of construction engineering consultancy better.

AI can change how work is shared out. It can also make more visible what requires presence, experience and accountability: understanding a need, building a team, resolving an interface and supporting engineers over time.

This is the direction we argue for here, not the announcement of a programme already rolled out. Producing faster can be useful. Understanding, checking and staying committed until handover remains what matters most.