Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using Claude Code to modernize a 25-year-old kernel driver

dmitrybrant.com

Post reply on HN
Print view View original

121–130 of 343 posts

Re: Using Claude Code to modernize a 25-year-old kernel driver

#121

Post by baq »

zipzapzip wrote: post #111
kccqzy wrote: post #30

Earlier quoted context omitted.

This is more of a reflection of how our profession has not meaningfully advanced. OP talks about boilerplate. You talk about grunt work. We now have AI to do these things for us. But why do such things need to exist in the first place? Why hasn't there been a minimal-boilerplate language and framework and programming environment? Why haven't we collectively emphasized the creation of new tools to reduce boilerplate a…

Because of the obsession with backwards compatibility and not breaking code. The web development industry is the prime example. HTML, Javascript, CSS, a backend frontend architecture - absolutely terrible stack.

if the simplest web page pulls in react in an attempt to be a small OS unto itself, that's what you get.

Re: Using Claude Code to modernize a 25-year-old kernel driver

#122

Post by baq »

ZYbCRq22HbJ2y7 wrote: post #32
theptip wrote: post #3

A good case study. I have found these two to be good categories of win: > Use these tools as a massive force multiplier of your own skills. Claude definitely makes me more productive in frameworks I know well, where I can scan and pattern-match quickly on the boilerplate parts. > Use these tools for rapid onboarding onto new frameworks. I’m also more productive here, this is an enabler to explore new areas, and is al…

We have members on my team that definitely feel empowered to wade into new territory, but they make so much misdirected code with LLMs, even when we make everyone use Claude 4 thinking agents. It seems to me that if you have been pattern matching the majority of your coding career, then you have a LLM agent pattern match on top of that, it results in a lot of headaches for people who haven't been doing that on a team…

> they make so much misdirected code with LLMs

just points to the fact that they've no idea what they're doing and would produce different, pointless code by hand, though much slower. this is the paradigm shift - you need a much bigger sieve to filter out the many more orders of magnitude of crap that inexperienced operators of LLMs create.

Re: Using Claude Code to modernize a 25-year-old kernel driver

#123

Post by ako »

jazzyjackson wrote: post #100
abathologist wrote: post #37

Earlier quoted context omitted.

This is the glaring fallacy! We are turning to unreliable stochastic agents to churn out boilerplate and do toil that should just be abstracted or automated away by fully deterministic, reliably correct programs. This is, prima facie, a degenerative and wasteful way to develop software.

Yes and its why AI fills me with impending doom: handing over the reigns to an AI that can deal with the bullshit for us means we will get stuck in a groundhog day scenario of waking up with the same shitty architecture for the foreseeable future. Automation is the opposite of plasticity.

I don’t think that will happen. It’s more like a 3d printer where you can feed in a new architecture and new design every day and it will create it. More flexibility instead of less.

Re: Using Claude Code to modernize a 25-year-old kernel driver

#124

Post by baq »

rmoriz wrote: post #62
BowBun wrote: post #24

Earlier quoted context omitted.

> Use these tools as a massive force multiplier of your own skills. I've felt this learning just this week - it's taken me having to create a small project with 10 clear repetitions, messily made from AI input. But then the magic is making 'consolidation' tasks where you can just guide it into unifying markup, styles/JS, whatever you may have on your hands. I think it was less obvious to me in my day job because in a…

In times of Rust and Typescript (just examples) coding standards are explicit. It‘s not optional anymore. All my vibe coding projects are using CI with tests including style and type checks. The agent makes mistakes but it sees the failing tests and fixes it. If you vibe code like we did Perl and PHP in 1999 you‘re gonna have a bad time.

In a startup, especially early, the only thing that isn't optional is shipping. You can fix any and all issues later, first you have to ensure there is a 'later'. (That's not to say you shouldn't do it at all, but definitely focus on the business before the tech.)

Re: Using Claude Code to modernize a 25-year-old kernel driver

#125

Post by tonkinai »

theptip wrote: post #3

A good case study. I have found these two to be good categories of win: > Use these tools as a massive force multiplier of your own skills. Claude definitely makes me more productive in frameworks I know well, where I can scan and pattern-match quickly on the boilerplate parts. > Use these tools for rapid onboarding onto new frameworks. I’m also more productive here, this is an enabler to explore new areas, and is al…

It’s less about AI vs boilerplate and more about having good tests. if the code works and you can move fast, who cares who typed it.

Re: Using Claude Code to modernize a 25-year-old kernel driver

#126

Post by tankenmate »

elzbardico wrote: post #101
jclarkcom wrote: post #72

Earlier quoted context omitted.

When humans are in the loop everything pretty much becomes stochastic as well. What matters more is the error rate and result correctness. I think this shifts the focus towards test cases, measurement, and outcome.

No. This is a fundamentally erroneous analogy. We don't generate code by a stochastic process.

I have a strong suspicion that the world is not as deterministic as you'd like it to be.

Re: Using Claude Code to modernize a 25-year-old kernel driver

#127

Post by baq »

eviks wrote: post #115
0xbadcafebee wrote: post #5

I had a suspicion AI would lower the barrier to entry for kernel hacking. Glad to see it's true. We could soon see much wider support for embedded/ARM hardware. Perhaps even completely new stripped-down OSes for smart devices.

Nothing was lowered because there was no barrier: > 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 But yeah, the dream of new OSes is sweet...

I'd bet a couple dollars that it'd take a week for someone who hasn't hacked on the kernel at all, but knows some C and two weeks for someone who doesn't even know C but is a proficient programmer. This would previously take months.

We're talking about an order of magnitude quicker onboarding. This is absolutely massive.

Re: Using Claude Code to modernize a 25-year-old kernel driver

#128

Post by eviks »

baq wrote: post #127
eviks wrote: post #115

Earlier quoted context omitted.

Nothing was lowered because there was no barrier: > 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 But yeah, the dream of new OSes is sweet...

I'd bet a couple dollars that it'd take a week for someone who hasn't hacked on the kernel at all, but knows some C and two weeks for someone who doesn't even know C but is a proficient programmer. This would previously take months. We're talking about an order of magnitude quicker onboarding. This is absolutely massive.

It's so massive that your own fantasy bet is just a couple of dollars...

Re: Using Claude Code to modernize a 25-year-old kernel driver

#129

Post by rgoulter »

AdieuToLogic wrote: post #52

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 co…

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

Re: Using Claude Code to modernize a 25-year-old kernel driver

#130

Post by IanCal »

kccqzy wrote: post #30
bicx wrote: post #11

Earlier quoted context omitted.

This is a good takeaway. I use Claude Code as my main approach for making changes to a codebase, and I’ve been doing so every day for months. I have a solid system I follow through trial and error, and overall it’s been a massive boon to my productivity and willingness to attempt larger experiments. One thing I love doing is developing a strong underlying data structure, schema, and internal API, then essentially hav…

This is more of a reflection of how our profession has not meaningfully advanced. OP talks about boilerplate. You talk about grunt work. We now have AI to do these things for us. But why do such things need to exist in the first place? Why hasn't there been a minimal-boilerplate language and framework and programming environment? Why haven't we collectively emphasized the creation of new tools to reduce boilerplate a…

Because the set of problems we make to be solvable with code is huge and the world is messy. Many of these things really are at a very high level of abstraction and the boiler plate feels boilerplatey but is actually slightly different in a way not automatable. Or it is but the configuration for that automation becomes the new bit you look at and see as grunt work.

Now we have a way we can get computers to do it!

Post reply on HN