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:

  ... required me to learn ...

▲ rmoriz 5 days ago | parent | next [-]

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.

▲

AdieuToLogic 5 days ago | parent | next [-]

> Gatekeeping is toxic.

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.

0 - https://en.wikipedia.org/wiki/Kernel_panic

▲

kelnos 5 days ago | parent | next [-]

> 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.

	▲	skydhash 5 days ago \| parent [-]
		Anyone can write kernel module. On their computers. Not mine.

▲

5 days ago | parent | prev | next [-]

[deleted]

▲

BestHackerOnHN 5 days ago | parent | prev [-]

[dead]

▲

5 days ago | parent | prev [-]

[deleted]

▲ rgoulter 5 days ago | parent | prev | next [-]

> 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.

I read "junior" as 'subordinate' and 'lacking in discernment'.. -- Sycophancy is a good description. I also like "bullshit" (as in 'for the purpose of convincing'). https://en.wikipedia.org/wiki/Bullshit#In_the_philosophy_of_...

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".

▲ badsectoracula 5 days ago | parent | prev | next [-]

> Another key activity identified as a benefit to avoid in the above quote is: ... required me to learn ...

"...kernel development as it was done 25 years ago."

Not "...kernel development as it is done today".

That "25 years ago" is important and one might be interested in the latter but not in the former.

▲ kelnos 5 days ago | parent | prev [-]

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.