Why the engineer's oldest tool may be the most valuable one in the age of AI.

Most engineering problems aren't really engineering problems. They look that way at first: equations to solve, deadlines to hit, machines that won't behave. But underneath, you find the same situation again and again. Too many variables, not enough clarity about which ones matter.

Mathematical modelling is the discipline of dealing with exactly that. It is a way of looking at problems that turns vagueness into structure. And with AI now writing code from plain English, this skill (framing, not implementation) is the actual edge.

The Everyday Problem Is a Math Problem in Disguise

Take a question that has nothing to do with engineering. Should I take the new job offer?

Most people answer it with a pros-and-cons list, a phone call to a parent, and a sleepless night. A modeller answers differently. They ask:

The decision stops being a gamble and becomes a structured comparison. You will probably still go with your gut at the end, and you should, but your gut is now working from a map rather than a fog.

The same skeleton scales easily. Personal finance is an optimisation: long-term wealth, subject to cash-flow and risk. Time management is a scheduling problem: output, subject to hours and energy. Choosing a pump, designing a workout, allocating a budget. They all reduce to the same four moves: objective, variables, constraints, trade-offs. Engineers run into this instinctively after years of sizing beams or tuning control loops, but the instinct is teachable.

The AI Era Changes the Stack, Not the Skill

The popular story about AI gets the framing wrong. The real bottleneck in hard problems was never implementation. It was always clear, systematic thinking: the ability to look at a tangled situation and see the structure underneath. Implementation wasn't hard in principle, it just took time. Writing code, running simulations, crunching numbers. None of that was conceptually difficult once the thinking was done. It was just slow, and that slowness demanded years of practice.

Because the time tax was so heavy, coding became the visible badge of competence, even when the harder work, the framing, the modelling, had already happened invisibly before any code was written.

What AI changes is the cost in time of implementation. You describe what you want, and the machine writes the code, runs the simulation, makes the chart, debugs the script. The labour that used to sit on top of clear thinking is being lifted off.

But mistaking that speed for actual problem-solving is a category mistake. Watching AI generate code at superhuman pace and concluding the problem is solved is like watching a child learn the alphabet and concluding they will be a poet. The letters are a prerequisite. They are not the poetry.

"Code is a prerequisite. It is not the thinking."

What doesn't change is the thinking itself. AI is brilliant at execution and pretty mediocre at problem definition. It will build the wrong thing for you quickly and well, if you cannot specify the right one. The bottleneck that was always underneath, what exactly are we solving?, is now fully exposed. The person who gets useful answers out of AI is the one who can state the problem cleanly in those four moves. Everyone else gets confident-sounding nonsense, produced faster than before.

"AI did not move the bottleneck. It revealed it."

What it revealed is the same skill that separated the best engineers, founders, and thinkers all along: the ability to model a problem before solving it.

What Modelling Actually Looks Like

A model is just a structured way of turning a messy situation into something you can reason about. Most useful ones go through four steps:

  1. Name the goal in measurable terms. "Be happier" is not a model. "Three evenings a week with my family" is.
  2. List the levers you can pull. Money, time, headcount, pipe diameter, whatever applies.
  3. Map what you can't move. Budget, physics, laws, your own energy. Be honest about this one.
  4. Describe how the variables interact. Usually a spreadsheet. Sometimes an equation. Occasionally just a clear paragraph.

A fifth step is iteration. You test the model against reality and refine it. No first model is right, and good modellers know to expect that.

There is a side effect of doing this honestly. The exercise drags you, almost against your will, into first-principles thinking. You stop reasoning by analogy ("the last project did it this way") and start reasoning from the actual mechanics of the problem. Inherited assumptions get exposed. The model will not let you hide behind "this is how it has always been done." That alone, before you even reach an answer, is half the value.

A Concrete Example

Take something most engineers have run into: sizing a pump for a fluid transfer system.

Run the numbers for three or four configurations. The optimum almost never sits at the extremes, and the trade-off curve shows where engineering judgement needs to step in. Same for a heat exchanger, an HVAC system, or a manufacturing line. The numbers change. The shape of the thinking doesn't.

"A model does not remove uncertainty. It removes confusion."

Two Pitfalls Even Good Modellers Fall Into

A model is only as good as the thinking behind it. Two failure modes show up over and over, both named sharply by people who have spent their lives solving hard problems.

Pitfall 1: Optimising Something That Shouldn't Exist

"The most common error of a smart engineer is to optimise a thing that should not exist." — Elon Musk

This is the trap of skipping straight to optimisation. You inherit a process, a workflow, a constraint and start polishing it. You make it faster, cheaper, more elegant. Then one day you realise the whole thing should have been deleted, not improved. Musk admits to making this mistake repeatedly at Tesla, accelerating and automating processes that, on reflection, never needed to exist.

Before you optimise the objective function, question whether the variables and constraints even belong in the model. A beautifully optimised solution to the wrong problem is worse than a rough solution to the right one, because it eats the energy you needed for the real fight. Ask yourself, ruthlessly: does this constraint actually exist, or did I inherit it? Does this variable need to be here at all? What happens if I delete it? The best part of any model is often the part you can take out.

Pitfall 2: Forgetting What You Were Really Trying to Do

"A majority of life's errors are caused by forgetting what one is really trying to do." — Charlie Munger

This is the slower, more insidious failure. You start with a clear goal. Three weeks in, you are deep in trade-offs, refinements, and edge cases, and somewhere along the way the original objective has shifted without you noticing. You are now optimising for the model rather than the goal that prompted it.

Engineers see this when a feature meant to reduce cost ends up adding complexity. People see it in their own lives when a career chosen for freedom becomes the thing that eats their freedom. The model keeps working; the goal it was built for has been forgotten.

The fix is small but it works: write your objective at the top of the page, and re-read it before every major decision. If the next move does not honestly serve that objective, you are optimising for something else. At minimum, know what.

Together, these two pitfalls cover almost every bad model ever built.

"The right answer to the wrong question, and the wrong answer to a forgotten one."

The Long View

The barrier to doing things is collapsing. Anyone can summon code, draft documents, generate images, and analyse data with a few sentences. What stays scarce, and arguably becomes more valuable, is the ability to frame the right problem in a form that can actually be solved.

There is also a technical reason this matters now. The biggest factor in what AI produces is the quality of what you put into it: the framing, the constraints, how precisely the question is stated. Garbage in is still garbage out, just faster and more confidently. And AI companies, Anthropic, OpenAI, and the rest, can't yet reliably verify whether their own models' outputs are correct. They run evaluations, but no benchmark captures whether a given answer is right for your particular problem. The model doesn't know when it's wrong.

Which means you have to. The only way you can is by carrying your own model of the problem: your own sense of what the variables are, what the constraints are, and what a reasonable answer should look like. Without that, you cannot tell genius from nonsense. With it, you use AI like a power tool. Fast, leveraged, pointed in the right direction.

Coding taught a generation how to instruct machines. Modelling teaches you how to instruct yourself: to see the structure under the noise, to ask the questions that lead somewhere useful, and to recognise a good answer when it lands. In the AI era, that might be the most useful skill you can have.