ON the last day of July 2026, about 30 engineers attended a half-day seminar on artificial intelligence (AI) and automated workflows for structural engineers, held at IEM Sabah Training Centre in Kota Kinabalu. The seminar reminded us how far computing has advanced. To see how far we’ve progressed, we need to look at the foundation of science and engineering – specifically how solutions are derived. A solution, in this context, refers to the explicit result: a formula, equation, or value.
The foundation and the old wayScience and engineering have always leaned towards analytical solutions – exact formulas derived mathematically from governing physical laws, themselves established through centuries of experiment and observation. One of the most famous is Newton’s second law, F = ma, first published in 1687. Solving these governing equations for a specific scenario produced an exact, guaranteed-correct answer – the same principle behind calculating compound interest on a fixed deposit, or a student working out how far a dropped ball falls in two seconds. We use this kind of solution every day without giving it much thought. Before computers, this was the only language engineers had, worked entirely by hand with pen, paper, and a slide rule. For generations it was precise, elegant, and solvable: bridges, buildings, and dams were designed using exact formulas refined over centuries.
The limitationsBut nature rarely cooperates with elegant mathematics. The moment a problem involves irregular shapes, unpredictable materials, or turbulent forces – a river bending around a bridge pier, wind gusting against a skyscraper – these formulas break down. And that gap is only widening: flat, easy ground has largely been developed, leaving hillsides, reclaimed land, and seismic zones for the future to build on, while taller buildings force engineers to reckon with wind forces that barely mattered a century ago.
Engineers found a way around this long before computers existed. In fluid mechanics, they measured real rivers and channels, then reverse-engineered practical formulas from observation alone – “accurate enough,” without a complete theoretical foundation. Water flow equations from Antoine de Chézy (18th-century Paris) and Robert Manning (19th-century America) were born this way. Remarkably, both are still used today. It was an early sign of a pattern that would repeat: when exact answers proved impossible, engineers found ways to approximate them instead.
The past futureBy the mid-20th century, the finite element method was born, attributed to Alexander Hrennikoff (structural engineer, 1941) and Richard Courant (mathematician, 1943) – a collision of two branches of science. It runs on the same logic most of us learned in school: matrices, used to solve several equations at once. But nature’s problems depend on position in every direction (x, y, z) and time (t), so instead of a handful of equations, engineers write millions – one for every tiny piece a structure is broken into – solved together as one enormous matrix. Technically, partial differential equation is a more accurate representation but we will leave this for another article. At its simplest, one unknown and one equation, this is essentially what Chézy and Manning had already achieved by hand; the finite element method simply scaled that instinct up, from what an engineer could solve alone to what only a machine could.
The idea was sound, but almost no one could run it – the 1950s and 60s only offered room-sized mainframes costing millions, reserved for a handful of universities and corporations. That changed with the microprocessor, now commonly called the CPU, as computing power shrank dramatically and personal desktop computers were born. Firms could finally run software like ETABS in-house. Even the Courant number – still used today in modelling rivers and floods – is a direct descendant of the same mathematician’s work, decades on. The wall had cracked. But it would take hardware becoming not just affordable, but abundant, before the next shift could begin.
The future futureA modern desktop PC can now handle complex problems that once needed a mainframe. For the truly demanding ones, such as modelling floodwater across a city, engineers call on the GPU, which excels at repetitive matrix arithmetic; larger models lean on RAM; and when even that isn’t enough, work is offloaded to the cloud entirely. Nearly anything can be calculated today.
With computing power no longer a constraint, AI is the next frontier – engineers now run software simply by describing what they want in plain English, a “prompt.” That barrier is falling much like 3D printing changed manufacturing: where a custom part once meant a specialist workshop and weeks of waiting, an engineer can now print it themselves overnight. Coding is following the same arc – building working tools in minutes, without ever learning to code. Software companies are increasingly using AI to develop faster and ship fewer bugs. The bottleneck has quietly shifted – no longer hardware, no longer even software, but the code behind it.
Numerical intelligence – an engineering evolutionThrough all of this, AI is nothing more than a tool for building other tools. Like a 3D printer, it doesn’t design the part – it builds whatever the engineer designs. The judgment, the design intent, the responsibility, still belongs entirely to the engineer typing the prompt.
What this represents is a quiet democratisation: complex analysis once reserved for large firms is now within reach of a single engineer with a laptop.
But AI cannot rewrite the fundamentals. It cannot change the value of gravity, or Newton’s second law. What it changes is how quickly, and how many, of their consequences we can work through. Given enough time, AI may even find a more efficient way than matrices and meshes – the way Courant and Hrennikoff once did.
It began with engineers who were, quite literally, the computers. It has since evolved into computers that think alongside the engineers who built them. The tools have changed almost beyond recognition. The discipline they serve has not.
