Bringing AI into engineering teaching

Telling apart things that are all called "AI" and have nothing to do with each other: the language model you talk to, the constrained optimisation behind generative design, the pattern recognition built into professional software, the predictive models trained on process data. Different technologies, different failure modes.

What each can do, what data it was trained on, and what it structurally cannot know — starting with the real state of the installation in front of you.

The second half of the session is about the plumbing, because that is what these students will have to install: the difference between a chat window and an API call, what a context window is and why it limits what you can submit, what an agent is, what a task orchestrator does, and what separates a model run online from a model run on a company machine — in cost, performance and confidentiality.

A plausible value is not a correct value. A language model will unhesitatingly produce a cutting speed, a material grade, an ISO tolerance, a standard's article or a component reference that does not exist. On screen, the error can be corrected; once in production, it has to be paid for.

Case study in class, chosen according to the track: a machining routing, a calculation note, a choice of components, a risk analysis. It is produced entirely by AI, then dismantled line by line against reference sources — charts, manufacturer catalogues, standards text. What the exercise installs is the reflex to verify.

Technical vocabulary is not jargon: it is the parameter setting. Asking for "a rounded edge" and asking for "an R2 blend fillet" do not produce the same result, because the second term carries a geometry, a tool constraint and a functional intent.

The principle applies to every track; the subject matter changes with it. The workshop walks through the vocabulary useful to the target trade and measures each time the gap between an approximate request and an exact one.

We start from a need expressed in everyday language — "a part that holds this bearing and screws in there" — and turn it into a dimensioned, toleranced drawing. AI serves here as an interlocutor: it asks the questions a design office would ask, flags missing dimensions, points out incompatible specifications.

The teaching point: the student decides every dimension and answers for it. AI is not allowed to decide in their place; it is allowed to ask them why.

The fairest criticism of assisted 3D generation is that it produces approximate shapes: a part that looks right, but none of whose dimensions is the one you wanted. Parametric modelling through code removes the objection.

AI does not write the shape, it writes the program that builds it — in OpenSCAD or an equivalent language. Once the overall geometry is validated, the student opens the file and changes numbers: a diameter, the width of a groove, the value of a chamfer, the position of a flat, the centre distance of two holes. The model regenerates to the exact dimension. Tolerance stops being a negotiation with the machine and becomes an engineer's decision again.

The starting point can even be a photograph of the part to reproduce: AI draws a first script from it, which the student then corrects dimension by dimension, with hand measurements as support.

What the module installs along the way, beyond 3D: a named parameter in a readable file beats a frozen shape. It can be re-read, versioned, justified in a review, and handed to someone else.

The central module. The student does not consume a tool: they make one. From a part, a material, a machine park and a tool catalogue, they build their own assistant — a framework of questions and constraints which, fed with a given part, proposes a reasoned machining strategy.

What the assistant must produce: the order of operations, the successive set-ups, the choice of tools, the cutting conditions, the roughing and finishing passes, the allowances — and for every decision, the reason. A proposal without justification is rejected.

What the student learns by building it is exactly what the CAM software silently decides for them when they click "generate".

Systematic comparison of the AI's proposal against three references: tool manufacturers' charts and catalogues, the machining simulation in the CAM software, and the behaviour observed on the machine when the technical facilities allow it.

We measure the gap, document it, and look for where it comes from. This is the module that durably installs the right stance: AI proposes, physics arbitrates.

An engineer who can describe a need precisely can now build the tool that answers it, without writing code in the traditional sense. A small parametric-geometry generator, a 3D photo-scanning application, a standard-parts configurator, a format converter: these are projects of a few hours, not a few months.

The stakes go beyond the exercise. An SME that pays for a full CAD licence every year while using only a fraction of it has an economic decision to make. Knowing how to assess what you can build yourself, what you must buy, and what it would be unwise to replace, is an engineering skill — not a computer scientist's skill.

The module ends on an honest assessment: what the in-house tool does just as well, what it does less well, and the real cost of maintaining it once its author has left the company.

This is the most widespread industrial use of AI, and the one students will meet soonest: measurement series, sensor readings, inspection reports, failure histories. How to explore them, clean them, look for a drift, a correlation, an outlier — without writing the processing chain yourself.

And the lesson that governs everything else: a correlation found by a machine is not a cause. The workshop deliberately has a seductive but false conclusion produced on a real dataset, then asks the student to take it apart. Sample size, hidden variable, selection bias, over-interpretation of a short series.

Extensions depending on the track: statistical production monitoring, anomaly detection, predictive maintenance, design of experiments.

How a department capitalises on its conventions — internal standards, usual references and components, available means, document templates — so that AI works within the company's framework and not in a vacuum. Prompt library, naming conventions, continuity from one project to the next and from one intern to the next.

The part of an engineer's work that consumes the most time for the least added value: manufacturing files, drawings, bills of materials, setup sheets, procedures, test and inspection reports, user manuals, review minutes. This is exactly where assistance gives useful time back.

And the rule that applies here more than anywhere: no document goes into production without an identified, named human checkpoint with the means to say no. A wrong manufacturing file propagates all the way to the machine.

An assistant that answers in a chat window changes little. What changes an organisation is a sequence of steps that chain together on their own: a dropped file triggers a process, which calls a model, which writes a result, which notifies someone. The module shows how that is built — API calls, task orchestrator, agents, and what distinguishes an agent from a simple script.

Then how it breaks. A step that fails silently, a model that changes version, an input format that drifts, a loop that runs away and costs money. The safeguards are designed with it: logging, error recovery, a spending cap, and above all an identified, named human stop point with the means to say no.

The hosting question is dealt with here: online service or locally run model, what each implies in cost, performance and the confidentiality of company data.

A regulatory file — technical compliance file, machine risk analysis, CE declaration, instructions manual, as-built file, building permit — is an assembly of standardised parts whose structure is known, public and stable. This is exactly where assistance pays off most: the standard provides the plan, the engineer provides the data and the judgement, AI provides the assembly and the completeness check.

The workshop follows a sequence, the same whatever the target file:

The same sequence produces a building-permit application, a regulatory file handed over by a design office to its client for production and approval, or the file that a principal sends to its design office. The student learns a process, not a form.

What AI never provides, however, is responsibility for what is signed.

Two technically valid solutions never have the same price. Depending on the track: machining time, tool wear and tool cost, material cost and hourly machine cost; or component cost, development cost, running cost. And, while we are at it, the cost of the AI itself. The engineer who can put a price on their solution is the one people listen to.

What you do not send to an online service: a customer's drawing, a geometry under a non-disclosure agreement, routing know-how. Who owns a shape generated by AI. What a subcontracting contract says about transmitted data. The industrial counterpart of the GDPR module.