Engineering & Technology: How AI can best tutor this subject

What you'll be able to do: Use AI for the part of engineering that's judgement, and know why its answers in this subject need checking more carefully than in most.

What engineering assessment is actually testing

Not arithmetic. Anyone can execute a calculation.

Engineering tests whether you can set a problem up, which idealisation, which free body, which control volume, and whether you know what you assumed. The marks and the real failures both live there, which is why the inquiry report into any serious failure is a story about an assumption nobody wrote down.

That should determine how you use the tool: for setup, assumptions, behaviour and failure, not for numbers.

What it is genuinely good at here

Surfacing the assumptions you made without noticing. Give it your setup and ask what you're relying on but haven't stated, then which of those, if false, would change not just the number but whether the approach is valid at all. This is the highest-value use in the subject and maps directly onto where marks go.

Playing stakeholders. The client, the contractor, the regulator, and, the one nobody rehearses, the maintainer in year fifteen, working at height, in the rain, with incomplete drawings. That single role-play produces more design changes per minute than anything else available.

Narrating failure cascades. Be the component at the moment it fails; what do my neighbours now carry, can they carry it, what goes next, does anything stop it? Single-component failure is easy; the cascade is the engineering.

Explaining what a standard is for. Almost every clause exists because something failed. Asking what failure a requirement responds to turns compliance from box-ticking into reasoning, and tells you when you're in a situation the clause never anticipated.

Parameter behaviour. Which way does it move, and with what power? Design intuition is knowing that deflection goes with the fourth power of span, not being able to look up the formula.

Marking your work strictly against a real scheme, itemised, which reveals that method marks and assumption marks are where you're losing, not arithmetic.

What it is bad at here, specifically

Numbers, and this matters more than elsewhere. Engineering answers have consequences. Treat every computed value as unverified: check dimensions, check order of magnitude, check against an anchor you know. The method in this subject is that you'd catch its errors the same way you catch your own, by estimating first.

Codes and standards. It will confidently state clause numbers, factors and limits that are wrong, out of date, or from a different jurisdiction's code. Never take a code value from it. Use it to understand the purpose of a requirement; look the requirement up.

Material properties. Plausible numbers, wrong grade, wrong temperature, wrong condition. Same rule: use the handbook.

Knowing your jurisdiction, your client, your site. Generic engineering advice applied to a specific context produces designs that are technically reasonable and locally wrong.

Recognising when something is dangerous. It has no stake and no liability. Anything safety-critical goes to a qualified person, and that isn't a disclaimer, it's the professional structure the subject exists inside.

The shape of a good session

1. Estimate first: order of magnitude, direction, sensitivity, with a reason. Before any calculation.
2. Draw the load path: or the current, heat or flow path, from memory, and ask what's missing rather than whether it's right.
3. State your assumptions, then ask which ones you didn't state, and what changes if each is false.
4. Sweep one parameter and predict the power before seeing it.
5. Ask how it fails, and narrate the cascade.
6. Defend it to a maintainer, then a regulator.

None of that is arithmetic, and all of it is what you're actually assessed on.

The instruction to set

For this session you are tutoring me in engineering. Rules, before any calculation, ask me to estimate the order of magnitude and direction with a reason; when I give you an analysis, tell me the assumptions I relied on but didn't state rather than whether the answer is right; never give me a code clause number or a material property as fact, tell me what to look up and why the requirement exists; and if something I'm designing is safety-critical, say so plainly.

The failure that looks like success

A confident, complete, well-presented solution with correct arithmetic, based on an idealisation that doesn't apply.

Engineering has a specific version of this: the answer is wrong not because a step was wrong but because the problem was wrong, a steady-state relation on a transient problem, a small-deflection formula outside its range, a pinned connection that's actually semi-rigid. Every line checks out. The whole thing is void.

The tell: you've never had an answer rejected on grounds of the setup rather than the working. Either you're unusually good at setup, or nobody has been checking the part that matters.

What it cannot replace

Judgement under liability. Engineering decisions are made by people who are accountable for them, and that accountability shapes the decision. A tool with no stake produces reasonable-sounding advice and bears none of the consequence.

Use it to think. Don't use it to decide anything that could hurt someone.

Where to go next

01 Assumption surfacing is where both the marks and the failures are. 03 Sketch critique and the load path carries the best single diagnostic in the subject: if you can't trace the load to the ground, you don't understand the structure.