When AI produces the answer, what makes someone a good engineer?

A convincing answer can arrive before anyone has agreed what the problem really is. That makes engineering judgement a more interesting skill to talk about.

Imagine a junior engineer arriving at a review with a neatly written design explanation. The assumptions are listed. The calculation is laid out. There is even a confident paragraph explaining why the proposed component should be suitable.

An AI assistant helped prepare it.

Then someone asks a question: what happens when the load changes direction?

The answer on the page may be mathematically tidy and still fail to address the situation in which the component will work. The question was missing before the calculation began.

This is a hypothetical review, not a reported failure. But it points towards a more useful conversation about AI in engineering than whether a machine can pass an exam or produce something impressive on screen.

When generating a first answer becomes easier, how do we develop the people who can tell whether it answers the right question?

There is more than one kind of AI in this conversation

First, some precision. A general-purpose language model drafting an explanation is not the same thing as an optimisation system searching a defined design space. Neither should be casually equated with an established engineering solver whose numerical methods and limitations have been examined.

The checks depend on the tool, its task and the consequences of being wrong.

The IET’s 2025 engineering and technology skills survey covers several kinds of AI use, including analysis and generative design. It is useful evidence that employers are thinking about AI and skills together. It does not tell us that every engineering team is using a chatbot to make design decisions. IET, UK Engineering and Technology Skills.

This piece focuses on generative assistants used to help produce explanations, ideas or code, and on the human learning around them. It is a narrower question than the future of all engineering automation.

Fluency changes the first impression

A rough calculation on a scrappy sheet of paper practically invites questions. A fluent explanation can feel finished before it has earned that status.

NIST’s Generative AI Profile describes the risk of systems confidently producing erroneous content, including misleading logic or citations that appear to support an answer. That is a reason to investigate the basis of an output, rather than treat its presentation as evidence. NIST, Generative AI Profile.

In engineering, the problem can be subtler than an invented fact. A method might be valid under assumptions that do not hold in the intended application. A material property might describe a different condition. A script might execute without testing the behaviour that actually matters.

Those are familiar categories of engineering error. Generative tools give teams another way to encounter them.

The valuable response is to ask what would make the proposal wrong. Which assumption is most uncertain? What simple independent check is available? What evidence comes from the actual application, rather than from the generated explanation?

A good review looks for reasons to trust the answer beyond the answer itself.

We still have to learn how to notice

There is a difficult educational question beneath the productivity promise.

Some early-career work is repetitive. Some of it is also where people begin to recognise orders of magnitude, question units and connect a result to physical behaviour. If assistance changes that work, what takes its place as a learning experience?

It would be premature to claim that AI inevitably weakens engineering judgement. A tool might also give a learner another explanation, help them explore a variation or make it easier to ask questions they would otherwise leave unasked.

The Engineering Council’s 2025 AI working-group report welcomes appropriate AI use in engineering education while recognising risks that need consideration. That leaves room for a more ambitious approach than simply permitting or prohibiting the technology. Engineering Council, AI working-group report.

The useful distinction is between receiving an output and doing something that develops understanding.

For example, a supervisor could ask a learner to predict the direction of a result before using a tool, then explain any surprise afterwards. Or ask them to identify which assumptions would need to change for a suggested solution to stop being suitable. Or have them compare a generated explanation with an independently checked reference example.

These are possible teaching approaches, not a claim that a particular exercise has been proven to produce competent engineers. Their purpose is to keep reasoning visible and give the supervisor something substantive to discuss.

The senior engineer is part of the system too

It is comforting to imagine that an experienced reviewer will reliably catch whatever the software misses. Experience matters, but a human name in an approval box is not enough on its own.

Does the reviewer understand the method? Have they been given the inputs and limitations? Is there time to test the uncertain part? Can they call for a different approach when the proposed one looks outside their competence?

The Engineering Council and Royal Academy of Engineering’s updated ethical principles emphasise working within competence or under competent supervision, testing evidence objectively and recognising uncertainty. These expectations apply to engineering judgement, however the first draft was produced. Engineering Council, ethical principles.

A review needs more than someone willing to accept responsibility. It needs the conditions in which that responsibility can be exercised.

That is a management question as much as a technical one. If an organisation expects production to accelerate while reducing the time available for examination, it should ask where the saved effort has actually gone.

Use the help to open the discussion

There is a positive version of this future.

Imagine the same junior engineer bringing several approaches to the meeting, helped by an assistant to organise their initial thinking. They can explain which assumptions they checked, which suggestions they rejected and where they need help. The review starts further into the problem because the preparatory work has made the uncertainties clearer.

That is a possible way of working, not a performance promise. Whether it succeeds depends on the task, the tool and the team.

It also gives a more interesting account of what expertise is for. Engineers frame problems, make trade-offs, interpret evidence and connect decisions to the people who will build, operate and live with the result. Producing an answer is one part of that work.

A generative assistant might help with parts of the process. The engineering organisation still needs to decide what constitutes adequate evidence for the decision being made.

Return to the opening review and the changing load. The most valuable contribution in the room was a question the polished explanation had not answered.

The next generation needs opportunities to learn how to ask those questions, whether its tools become modestly better or dramatically more capable.

The answer may arrive faster. Understanding why it deserves to be used still takes work.