Here's the situation with AI: I'm writing a compiler. I ask the AI, "Tell me the opcodes for mem -> reg and reg -> mem."
It names these opcodes, and I attach the code with them to my backend, then send it for review, in case I forgot to add an offset or specified ModR/M incorrectly.
Of course, I could do everything myself, with only the Intel Manual, OSDev, and Wikipedia, but with the AI, development goes faster. However, it often doesn't provide complete information.
I asked the AI,
"Tell me the opcodes for ADD reg/64/32/16/8, imm32/16/8."
It seems to answer, but when I open the manual and see this...
04 ib ADD AL, imm8 ; add imm8 to AL
05 iw ADD AX, imm16 ; add imm16 to AX
05 id ADD EAX, imm32 ; add imm32 to EAX
There's no such phrase in English literature as "burned ass"
but that's exactly what I feel.
And that’s the point — AI can list opcodes, but it doesn’t understand them.
It doesn’t know why 04 ib applies only to AL, or why REX.W changes the whole meaning of an instruction.
It doesn’t realize that a single misplaced ModR/M bit can make your “add” turn into “segfault in disguise.”
AI works like a fast, obedient assistant — it fetches data, summarizes manuals, and can even generate skeleton code.
But the real craft of a systems engineer isn’t in typing code, it’s in knowing why the code must be written that way.
It’s about understanding the invisible contracts between hardware and software, between registers and bytes — the part that no large language model truly “feels.”
A compiler, an OS kernel, or even a bootloader isn’t just text — it’s a negotiation with the machine.
And AI doesn’t negotiate. It just repeats.
That’s why AI won’t replace system developers.
Because where an LLM sees patterns, a systems engineer sees cause and effect.
And when something goes wrong — when your ADD suddenly writes to the wrong register and your stack pointer vanishes into chaos —
only a human can look at it and say:
“Okay, I know exactly which bit ruined my day.”A__****
Top comments (0)