[veunes]

To be fair if you open up driver source code from the vendors themselves, it's often the same hell with magic numbers and lack of checks because "we know what the hardware will return". But you're right on the main point: AI writes C like a very confident junior who skipped memory safety lectures - it copies the style, but not the discipline. It works as long as you're on the "happy path", but debugging a kernel panic in code like that is going to be painful

[varankinv]

I was personally surprised when the agent debugged kernel panics caused by its own code (many times by now). It just iterates from the stack traces and crash dumps. The nice part is that, when you do see that the code smells — you ask the agent to rework it, focusing on specific problems. This is just code, and you don't need to dance around, hoping that AI will spill some "magic" at you.

[veunes]

Dumping panic traces to an agent works fine if it's just a vanilla page fault at an obvious address. But when your memory gets corrupted by some scuffed DMA sync or a race condition in an interrupt handler, the kernel panics a million clock cycles after the actual bug occurred. The dump is just pure garbage by then, and no LLM is going to untangle it because the root cause context literally isn't in the logs tbh

[irishcoffee]

> The nice part is that, when you do see that the code smells — you ask the agent to rework it, focusing on specific problems.

I think that is the crux of the problem. How do you know code smell if you don't write it, and you don't read it? I'm pretty confident the spdx header isn't correct even.