I'm too young to have known the assembly wizard world, but how is the job market for people of that skill-set and expertise?
My assumption was that being closer to hardware tends to be more resistant to AI hype since they work in environments where just vibe coding some slop carries much higher risk than vibe coding a webpage or mobile app does.
Getting closer to the hardware exponentially magnifies failure modes that LLMs cannot reason about. Being closer to the hardware also moves you to build and compiler machinery that LLMs lack in their training set. Being closer to the hardware also moves you closer to fields that require deep domain knowledge external to computer science, eg. electrical engineering via embedded systems (telecom and SDR), mechanical engineering and control systems via robotics, computer engineering via AAA game engine development (like OP) or silicon bringup, or rigid documentative fields like medical devices or aerospace.
You're facing strict requirements for fundamentals in 3 independent axis. If there's recommendation to anyone looking to "write code" today, its to specialize in a field where software (or firmware) is applied to a hard engineering domain. This has been common advice since 2010 [1], long before LLMs:
"People who can code in the world of technology companies are a dime a dozen and get no respect. People who can code in biology, medicine, government, sociology, physics, history, and mathematics are respected and can do amazing things to advance those disciplines."
I work on firmware and deep embedded systems. Trust me when I say LLMs are getting just as capable in this domain. Eg LLMs can do RF filter design. Tell the LLM your target metrics and it will give very reasonable design constraints, especially when you come back with simulation results and relevant feedback.
Right, but that is self contained domain. Hook it up to anything and an impedance mismatch will offset the intent of your poles. Failure modes, cross domains, integration, loads, design intersections; AI can build components, but its the sprouting of these components that exponentially magnifies the number of failure modes.
Engineering needs to be failure free, or at least failure preventive via redundancy, and the latter requires the same full systems understands as the former
If one works in AI it's quite lucrative because shaving off a couple percent is worth the big bucks. But increasingly, there is enough training data for LLMs to do the same thing because the number of unique computations is fairly small.
As part of learning how to work with coding agents, I had them code up a bunch of games that had been in my head for years. They were never going to see the light of day otherwise because I have too much on my plate, but it was fun to make them come to life. I didn't do it for money and it's not my day job nor will it ever be but it was educational in learning the limits of Codex and Claude.
But the app stores have been hosed for years ever since the Zynga playbook and DLC. And on Android, if you release something honest and original without those things, it will just get copied and re-released filled with malware. So why bother?
I don't really miss the old days because despite all the nostalgia, engineers were really underpaid relative to equally difficult professions and they usually got terrible shares of equity compared to the C-suite. And has everyone forgotten EA spouse?
They are not saying the assembly is bad all the time, but merely that sometimes, for some inputs, the assembly is bad. Which is definitely true, though I would prefer the term "suboptimal."
Again, to the OP's point, look at any of the ultra optimized video codecs. You will often find hand rolled assembly to squeeze out that extra bit of perf; having the compiler do its job would probably emit something that does the job, but you can absolutely spend the extra time to do it yourself and do it better.
This is a tired non-analogy.
I'm too young to have known the assembly wizard world, but how is the job market for people of that skill-set and expertise?
My assumption was that being closer to hardware tends to be more resistant to AI hype since they work in environments where just vibe coding some slop carries much higher risk than vibe coding a webpage or mobile app does.
Getting closer to the hardware exponentially magnifies failure modes that LLMs cannot reason about. Being closer to the hardware also moves you to build and compiler machinery that LLMs lack in their training set. Being closer to the hardware also moves you closer to fields that require deep domain knowledge external to computer science, eg. electrical engineering via embedded systems (telecom and SDR), mechanical engineering and control systems via robotics, computer engineering via AAA game engine development (like OP) or silicon bringup, or rigid documentative fields like medical devices or aerospace.
You're facing strict requirements for fundamentals in 3 independent axis. If there's recommendation to anyone looking to "write code" today, its to specialize in a field where software (or firmware) is applied to a hard engineering domain. This has been common advice since 2010 [1], long before LLMs:
"People who can code in the world of technology companies are a dime a dozen and get no respect. People who can code in biology, medicine, government, sociology, physics, history, and mathematics are respected and can do amazing things to advance those disciplines."
[1] https://learnpythonthehardway.org/book/advice.html
I work on firmware and deep embedded systems. Trust me when I say LLMs are getting just as capable in this domain. Eg LLMs can do RF filter design. Tell the LLM your target metrics and it will give very reasonable design constraints, especially when you come back with simulation results and relevant feedback.
Right, but that is self contained domain. Hook it up to anything and an impedance mismatch will offset the intent of your poles. Failure modes, cross domains, integration, loads, design intersections; AI can build components, but its the sprouting of these components that exponentially magnifies the number of failure modes.
Engineering needs to be failure free, or at least failure preventive via redundancy, and the latter requires the same full systems understands as the former
If one works in AI it's quite lucrative because shaving off a couple percent is worth the big bucks. But increasingly, there is enough training data for LLMs to do the same thing because the number of unique computations is fairly small.
As part of learning how to work with coding agents, I had them code up a bunch of games that had been in my head for years. They were never going to see the light of day otherwise because I have too much on my plate, but it was fun to make them come to life. I didn't do it for money and it's not my day job nor will it ever be but it was educational in learning the limits of Codex and Claude.
But the app stores have been hosed for years ever since the Zynga playbook and DLC. And on Android, if you release something honest and original without those things, it will just get copied and re-released filled with malware. So why bother?
I don't really miss the old days because despite all the nostalgia, engineers were really underpaid relative to equally difficult professions and they usually got terrible shares of equity compared to the C-suite. And has everyone forgotten EA spouse?
https://ea-spouse.livejournal.com/274.html
Do they? It might have been true month ago, not sure right now.
Of course. Auto-vectorization isn't magic, for one. In any video codec, the hot kernels will all be in hand-written assembly.
Now I'm not saying AI can't write ASM. I'm saying that compilers have a hard job. They output bad assembly, because the task is difficult.
I find it hard to believe that the output of modern compilers is objectively 'bad assembly'.
They are not saying the assembly is bad all the time, but merely that sometimes, for some inputs, the assembly is bad. Which is definitely true, though I would prefer the term "suboptimal."
Again, to the OP's point, look at any of the ultra optimized video codecs. You will often find hand rolled assembly to squeeze out that extra bit of perf; having the compiler do its job would probably emit something that does the job, but you can absolutely spend the extra time to do it yourself and do it better.