I've been tinkering with making website since I had an internet connexion, but I switched to full-time dev only recently. Before that I was more on track to do computations in civil, thermal and energy engineering. I was studying and doing research in the early 2000's, exactly when computer simulations were booming.

Computations that used to take weeks were done in seconds, precision scale exploded. For engineers it felt like software was eating their craft and that juniors would never learn the ropes. For newcomers like me, not running large simulations seemed unthinkable. Sounds familiar doesn't it? Let's explore what happened there, so maybe we can draw some parallels, including some not so comfortable truth on career path.

Computing power isn't smartness

During my first year as an engineer, a new recruit from the same class as me had put together a numerical model to compute heating power in open spaces. The idea was to add power to things like benches so they could provide a lot of comfort with as little energy as possible. He gave a long presentation with all the math behind it, then the code. At one point, a senior interrupted him and said, “And so, we need 400W of infrared and 160W of thermal resistance, right?” And… hmm, yes, indeed. How did you know?

The senior had guessed the result of a week’s worth of coding in a mere minute. Better yet, the junior had compared infrared versus thermal resistance, while the senior had found the optimal mix of both.

Why? Because he had seen a lot, and thus the numbers were well calibrated in his head. Because he had excellent fundamentals in thermal engineering. And last but not least, because he could do mental calculations. This was a simple example, but when projects got more complex, a good senior brought so much insight into what to simulate, while juniors were better at how to simulate it.

Today, any building or urban engineer with strong fundamentals and knowledge makes a terrific difference in any project—and they’re actually in high demand, despite simulation tools taking a huge part of the “intelligence.” And guess what? We still learn to solve equations by hand. We still learn all the internals of simulation tools. The best engineers today have deep knowledge of what happens inside their tools.

We thought computing was everything, and we were wrong. We thought we could delegate equations to computers and never think about them again, and we were wrong.

This seems obvious now that we’ve lived through it, it’s obvious: computing power isn’t intelligence. Computers without AI are dumb—everyone knows that from firsthand experience. Mind you, it hasn’t always been obvious. For a long time, we thought our ability to compute, to make logically perfect deductions, was the pinnacle of our intelligence. What separated us from animals. Surprise: it’s neither.

In the Turing era, computers were described as capable “to carry out any operations which could be done by a human computer.” And yet, there were so many missing pieces to the puzzle of what intelligence is. Valiant’s Probably Approximately Correct learning is certainly another. See where I’m going? Let’s not rush things, though—back to simulations.

More, more, more… for the better?

Despite still learning how to compute by hand, we kept those simulation tools, so they must bring something, don’t they? Or do they just compensate for their debilitating effect on juniors?

Let’s be fair: a lot of things that are possible today in building infrastructure just weren’t possible before we had simulations. All kinds of cracks in concrete, all kinds of failure modes in structures, some wind and airflow turbulences, linking energy systems, computing natural light access—this changed a lot about how we design infrastructures and buildings today. From street-level pedestrian comfort to the seismic design of Taipei 101, from fire safety gates to flood controls, from tall, weird buildings to speakers in train stations you can actually hear—the list is infinite. A lot of what we can compute today just wasn’t possible before numerical simulations.

Now, has this raised the standard of quality? That’s more questionable. On some aspects, like safety—fire, flood, seismic, nuclear, etc.—things are undeniably safer, and computations are more fine-grained. On others, like structural engineering, it’s more of a double-edged sword.

On the one hand we can do extremly complex structures today and some clever engenineers can achieve some crazy material effeciency. On the MX3D bridge, every single gram of material participate to supporting the bridge, as much as designing it. But on something like the Vuitton Fundation in Paris, you have those wings supported by a very thick metal structure with only one-of pieces. Impossible to compute by hand for sure and an absolute display of bruteforce engineering. Architect draws weird stuff, engineers compute stuff and here we go. No feedback, no elegant compromises. We can compute anything? we can build anything! Wether it's efficient or not isn't the question.

On the MX3D, load is optimised so that every part contributes equally to aesthetic and structure. Such a shape is of course undoable without computer simulation.

The Vuitton Fondation is typical of "whatever it takes to hold" engineering. You end up with this very thick metal structure that serve no purpose but holding the aesthetic wings.

To the old timers, many of the current buildings and infrastructure lacks elegance. The kind of refinement that scarcity of resources can bring you. Sure, we can compute thirty meters long cantilevers and find materials that work. Why? Not the engineer business, I'm paid to compute stuff, I compute, I don't ask questions. Things like Centre Pompidou or the Basento Bridge can be calculated by hand fairly easily. It's beautiful because it's easy and simple and it's simple and easy because with scarce computing resource, you're careful about not overspending.

The parallel seems pretty obvious. LLMs can raise the bar on many things: security, factoring, best practices and but also just plain functionnalities that we didn't have time to implement. Things that were deemed just too complex. And someone who puts an emphasis on clever design and efficient code can do things that were just unthinkable before LLMs. But brute forcing things will just be ever so tempting.

The big bloat

This “everything is computable” philosophy has had some perverse effects on smaller, more commonplace projects. There, money is scarce, things need to go fast, and we can’t spend much on studies. There used to be a tight loop between architects and engineers to figure out what was doable and how to do it. When everything is doable, the loop becomes:
Architect gives plan to engineer → Engineer computes until it’s doable → Done.

Again, the feedback between initial plans and final design has greatly decreased because we can make any initial design “work.” Work well? Work cleverly? That’s much less certain. It’s just cheaper to brute-force and not overthink it.

This has led to an abundance of poorly designed dwelling units—built with the best computation tools and looking pretty high-tech, yet we still seem to struggle with heating, HVAC, ventilation, lighting, and sometimes even door openings. (Hey, we’ve only been at it for 5,000 years!) Partly because they’re built cheap—I’m not arguing that—but also because the engineering is cheap. My simulation software says it works, despite being an obvious turd? Then it works. I’m not paid for more.

Typical of this: in my very last study during my final two weeks in civil engineering, I had an illuminance study to do. There was a huge fifty-meter-long, three-meter-high wall with not a single window—old stonework the architect wanted to keep intact. I was asked to “make the daylight simulation work” without windows. Natural light through an f-ing stone wall with no windows. I knew I could tweak the hypotheses a bit, find some reflections from the ceiling, etc. I also knew it was horseshit, and I decided I was done with this craziness. “Couldn’t finish it in time, sorry.”

It’s not hard to imagine a world where product owners ignore developers’ feedback on UX and just say, “I don’t have time to argue with you—just prompt your AI to do what I ask.” Yet developers are the first users. We click everywhere for hours during development, and scarce programming resources were often a great incentive to be clever and ship as few features as possible—the minimal thing the user wanted. Now? Just ship 500 features a month. As long as the customer is happy and the careless PO is happy, who cares? You can prompt it? You can do it! Whether it’s useful, whether it’s clever—those are secondary questions. Bloat will be absolutely everywhere.

Is the job still fun?

So, is being an engineer in the age of numerical simulations still fun? Weeeeell, it depends. As you might have guessed from the last example, not always.

For a large chunk of engineers, it means setting up routine simulations in a given software they specialize in, emailing the results, rinsing, and repeating—running the same software over and over, just with different inputs. These are low-added-value jobs, aside from using a given software. To the point where they were rightfully underpaid at one time (before an actual lack of trained engineers changed that).

For another part of the crowd, though, this has pushed the work toward more R&D. Basically, what you routinely compute can be turned into software, and then you can do new kinds of computations. Whether by putting together new simulation pipelines—I loved Ladybug Tools—or by actually being the one writing software. A good part of my studies included actually coding new software and stuying the math behind numerical simulations. You might be surprised, but the Lax-Milgram theorem is surprisingly fascinating. And let’s be real: as much as I enjoyed doing calculations by hand in school, doing them repeatedly, project after project, is kind of boring. So I was glad I could move on to the next thing. But as we saw, not everybody could..

The paradox and hypocrisy of the software industry

The silver lining here is that simulations have been putting people’s skills and knowledge into software. For better or worse, that’s not the question. You could have the same argument for spreadsheets and accountants, or HR SaaS, etc. At some point, software makes things “more efficient,” and “more efficient” eventually means either “taking other people’s jobs” or taking a share of physical growth (food, oil, etc.).

And indeed, there’s been a growing complaint in the engineering community that software vendors have way too much power and are taking a larger and larger share of their revenue. Autodesk has such a grip on the civil engineering and architecture industry that many smaller consultancies feel their survival depends on what Autodesk decides to implement. A substantial part of engineering revenues—and power—has shifted to the software vendors. You know, the ones who employ… well, devs, maybe?

You get the irony. Software was eating the world; it was only a matter of time before software ate software. Let’s be real: our software engineering positions were extremely privileged in the first place, and most of us weren’t really questioning where the money came from or why we were paid double what a civil or mechanical engineer made. But what’s so special about software engineering? What’s so special about us?

Parallels

The parallels between engineering with simulation tools and development with LLMs are pretty obvious to me. And while there are limitations, they seem plausible, too. It doesn’t sound crazy that LLMs will both raise the bar on many things (security, refactoring, etc.) and the bloat; that they’ll create exciting jobs and very boring ones; that they’ll help create some incredibly clever software and loads of very doubtful software. Some jobs will be incredibly fun on the frontier of R&D; others will involve prompting in circles. All of this seems to be unfolding in a similar way.

But there are two more interesting things about this parallel. First, simulations didn’t replace learning equations, they certainly made senior insight extremly valuable and they didn’t even replace juniors. Both juniors and seniors are in high demand in civil engineering. Second, and more interestingly: some people were prompt to claime that thought we had figured out human intelligence once and for all with computing. It was ever so slightly off. But surely this time, with PAC learning, we’ve figured it out once and for all… don’t we?