←back to thread

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

(dmitrybrant.com)
925 points dmitrybrant | 3 comments | 07 Sep 25 23:53 UTC | HN request time: 0.3s | source
Show context
theptip ◴[08 Sep 25 00:17 UTC] No.45163517[source]▶
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 also a boon at big tech companies where there are just lots of tech stacks and frameworks in use.

I feel there is an interesting split forming in ability to gauge AI capabilities - it kinda requires you to be on top of a rapidly-changing firehose of techniques and frameworks. If you haven’t spent 100 hours with Claude Code / Claude 4.0 you likely don’t have an accurate picture of its capabilities.

“Enables non-coders to vibe code their way into trouble” might be the median scenario on X, but it’s not so relevant to what expert coders will experience if they put the time in.

replies(16): >>45163642 #>>45163857 #>>45163954 #>>45163957 #>>45164146 #>>45164186 #>>45165282 #>>45165556 #>>45166441 #>>45166708 #>>45167115 #>>45167361 #>>45168913 #>>45169267 #>>45178891 #>>45193900 #
bicx ◴[08 Sep 25 00:36 UTC] No.45163642[source]▶
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 having CC often one-shot a great UI for internal tools.

Being able to think at a higher level beyond grunt work and framework nuances is a game-changer for my career of 16 years.

replies(3): >>45163945 #>>45168650 #>>45178896 #
kccqzy ◴[08 Sep 25 01:31 UTC] No.45163945[source]▶
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 and grunt work?
replies(20): >>45163980 #>>45163984 #>>45163986 #>>45163988 #>>45164135 #>>45164160 #>>45164367 #>>45164431 #>>45164851 #>>45165100 #>>45165366 #>>45165709 #>>45166197 #>>45166665 #>>45166912 #>>45170253 #>>45171572 #>>45171850 #>>45174629 #>>45176581 #
anyfoo ◴[08 Sep 25 01:41 UTC] No.45163986[source]▶
Because people think learning Haskell is too hard.
replies(1): >>45164066 #
1. do_not_redeem ◴[08 Sep 25 02:02 UTC] No.45164066[source]▶
Haskell isn't immune to boilerplate. Luckily if you're stuck using Haskell there's a package to help you deal with it all: https://hackage.haskell.org/package/boilerplate
replies(2): >>45164076 #>>45164442 #
2. anyfoo ◴[08 Sep 25 02:05 UTC] No.45164076[source]▶
I find of all languages, Haskell often allows me to get by with the least boilerplate. Packages like lenses/optics (and yes, scrap your boilerplate/Generics) help. Funny package, though!
3. wyager ◴[08 Sep 25 03:39 UTC] No.45164442[source]▶
It's very minimal-boilerplate. It's done an exceptional job of eliminating procedural, tedious work, and it's done it in a way that doesn't even require macros! "Template Haskell" is Haskell's macro system and it's rarely used anymore.

These days, people mostly use things like GHC.Generics (generic programming for stuff like serialization that typically ends up being free performance-wise), newtypes and DerivingVia, the powerful and very generalized type system, and so on.

If you've ever run into a problem and thought "this seems tedious and repetitive", the probability that you could straightforwardly fix that is probably higher in Haskell than in any other language except maybe a Lisp.