Something not yet mentioned by other commenters is the "giant caveat":
As a giant caveat, I should note that I have a small bit of
prior experience working with kernel modules, and a good
amount of experience with C in general, so I don’t want to
overstate Claude’s success in this scenario. As in, it
wasn’t literally three prompts to get Claude to poop out a
working kernel module, but rather several back-and-forth
conversations and, yes, several manual fixups of the code.
It would absolutely not be possible to perform this
modernization without a baseline knowledge of the internals
of a kernel module.
Of note is the last sentence:
It would absolutely not be possible to perform this
modernization without a baseline knowledge of the internals
of a kernel module.
This is critical context when using a code generation tool, no matter which one chosen.
Then the author states in the next section:
Interacting with Claude Code felt like an actual
collaboration with a fellow engineer. People like to
compare it to working with a “junior” engineer, and I think
that’s broadly accurate: it will do whatever you tell it to
do, it’s eager to please, it’s overconfident, it’s quick to
apologize and praise you for being “absolutely right” when
you point out a mistake it made, and so on.
I don't know what "fellow engineers" the author is accustomed to collaborating with, junior or otherwise, but the attributes enumerated above are those of a sycophant and not any engineer I have worked with.
Finally, the author asserts:
I’m sure that if I really wanted to, I could have done this
modernization effort on my own. But that would have
required me to learn kernel development as it was done 25
years ago.
This could also be described as "understanding the legacy solution and what needs to be done" when the expressed goal identified in the article title is:
... modernize a 25-year-old kernel driver
Another key activity identified as a benefit to avoid in the above quote is:
Gatekeeping is toxic. I love agents explaining me projects I don‘t know. Recently I cloned sources of Firefox and asked qwen-code (tool not significant) about the AI features of Firefox and how it‘s implemented. Learning has become awesome.
Learning what must be done to implement a device driver in order for it to operate properly is not "gatekeeping." It is a prerequisite.
> I love agents explaining me projects I don‘t know.
Awesome. This is one way to learn about implementations and I applaud you for benefiting from same.
> Recently I cloned sources of Firefox and asked qwen-code (tool not significant) about the AI features of Firefox and how it‘s implemented. Learning has become awesome.
Again, this is not the same as implementing an OS device driver. Even though one could justify saying Firefox is way more complicated than a Linux device driver (and I would agree), the fact is that a defective device driver can lock-up the machine[0], corrupt internal data structures resulting in arbitrary data corruption, and/or cause damage to peripheral devices.
> Learning what must be done to implement a device driver in order for it to operate properly is not "gatekeeping." It is a prerequisite.
Apparently it's not, though. The author here had some baseline knowledge of how Linux kernel modules work, but the impression I got is that they would not have been able to do this on their own without a lot of learning.
> the fact is that a defective device driver can lock-up the machine[0], corrupt internal data structures resulting in arbitrary data corruption, and/or cause damage to peripheral devices.
Now that's some gatekeeping right there. "Only experts can write kernel modules" is a pretty toxic attitude to have.
> I don't know what "fellow engineers" the author is accustomed to collaborating with, junior or otherwise, but the attributes enumerated above are those of a sycophant and not any engineer I have worked with.
The point being, there's nuance to "it felt like a collaboration with another developer (some caveats apply)". -- It's not a straightforward hype of "LLM is perfect for everything", nor is it so simple as "LLM has imperfections, it's not worth using".
> Another key activity identified as a benefit to avoid in the above quote is:
> > ... required me to learn ...
It would be bad to avoid learning fundamentals, or things which will be useful later.
But, it's not bad to say "there are things I didn't need to know to solve a problem".
To be fair, a "baseline knowledge of the internals of a kernel module" is not that difficult to acquire.
I think a moderately-skilled developer with experience in C could have done this, with Claude's help, even if they had little or no experience with the Linux kernel. It would probably take longer to do, and debugging would be harder, but it would still be doable.
Then the author states in the next section:
I don't know what "fellow engineers" the author is accustomed to collaborating with, junior or otherwise, but the attributes enumerated above are those of a sycophant and not any engineer I have worked with.Finally, the author asserts:
This could also be described as "understanding the legacy solution and what needs to be done" when the expressed goal identified in the article title is: Another key activity identified as a benefit to avoid in the above quote is: