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

201–210 of 343 posts

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

#201

Post by codeulike »

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…

Why haven't we collectively emphasized the creation of new tools to reduce boilerplate and grunt work?

You dont understand how things evolve.

There have been plenty of platforms that got rid of boilerplate - e.g. ruby on rails about 20 years ago

But once they become the mainstream, people can get a competitive edge by re-adding loads of complexity and boilerplate again. E.g. complex front end frameworks like react.

If you want your startup to look good you've got to use the latest trendy front end thingummy

Also to be fair, its not just fashion. Features that would have been advanced 20 years ago become taken for granted as time goes on, hence we are always working at the current limit of complexity (and thats why we're always overrun with bugs and always coming up with new platforms to solve all the problems and get rid of all thr boilerplate so that we can invent new boilerplate)

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

#202

Post by skydhash »

wyager wrote: post #71
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…

> Why hasn't there been a minimal-boilerplate language and framework and programming environment? Haskell mostly solves boilerplate in a typed way and Lisp mostly solves it in an untyped way (I know, I know, roughly speaking). To put it bluntly, there's an intellectual difficulty barrier associated with understanding problems well enough to systematize away boilerplate and use these languages effectively. The difficu…

Lisp can be very productive, but it requires actual design skills to wield it. It’s easier to teach python.

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

#203

Post by [deleted] »

jay-barronville wrote: post #198
jxf wrote: post #139

Earlier quoted context omitted.

Everything we do is a stochastic process. If you throw a dart 100 times at a target, it's not going to land at the same spot every time. There is a great deal of uncertainty and non-deterministic behavior in our everyday actions.

As much as it’s true that there’s stochasticity involved in just about everything that we do, I’m not sure that that’s equivalent to everything we do being a stochastic process. With your dart example, a very significant amount of the stochasticity involved in the determination of where the dart lands is external to the human thrower. An expert human thrower could easily make it appear deterministic.

[deleted]

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

#204

Post by jason-johnson »

theshrike79 wrote: post #114
Brendinooo wrote: post #13

When I read an article like this it makes me think about how the demand for work to be done was nowhere close to being fully supplied by the pre-LLM status quo.

LLM assisted coding can get you from an idea to MVP in an evening (within maybe 1 or 2 Claude 5 hour quota windows). I've done _so_ many of these where I go "hmm, this might be useful", planned the project with gemini/chatgpt free versions to a markdown project file and then sic Claude on it while I catch up on my shows. Within a few prompts I've got something workable and I can determine if it was a good idea or not…

This, for me, is the actual gain and I don't see a lot of people talking about it: it's not that I finish a project faster the LLMs. From what I've read and personally experienced, it probably takes about as long to complete a project with or without the LLMs. But the difference is, without it I spend all that time deeply engaged, unable to do anything else. With the LLMs I no longer require continuous focus. It may be the same wall-clock time but my own mental capacity is not being used at or near capacity.

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

#205

Post by creesch »

KingMob wrote: post #160
lordhumphrey wrote: post #69

Earlier quoted context omitted.

> 2. We will not accept changes (code or otherwise) created with the aid of "AI" tooling. "AI" models are trained at the expense of underpaid workers filtering inputs of abhorrent content, and does not respect the owners of input content. Ethically, it sucks. Do you disagree with some part of the statement regarding "AI" in their CoC? Do you think there's a fault in their logic, or do you yourself personally just not…

Setting aside the categories of art and literature, training LLMs on FOSS software seems aligned with the spirit, if not the letter, of the licenses. It does nothing to fix the issues of unpaid FOSS labor, though, but that was a problem well before the recent rise of LLMs.

> FOSS software seems aligned with the spirit, if not the letter, of the licenses.

Yeah, only if you look at permissive licenses like MIT and Apache, it most certainly doesn't follow the spirit of other licenses.

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

#206

Post by jason-johnson »

fruitworks wrote: post #193
DrNosferatu wrote: post #187

Earlier quoted context omitted.

If it delivers what we need, isn't it a net positive? And clearly define what we need with specs and thorough tests.

Do we need code generated from a stochastic model of previous code? I think we need actual people who are familiar with the kernel and hardware and are capable of reasoning about it. We are constantly reminded that LLMs are the future despite the real world evidence to the contrary. Look at what happens when LLMs are trained on the output of other LLMs, such as the low quality code flooding the internet. It is all a…

As sad as it makes some version of me to say, the majority of code that gets written every day doesn't need to be good code. I am doing a pet side project right now, completely with copilot. I haven't written a line of code, documentation or anything else. The code is pretty poor but I don't care because I just need it to take a specific input and produce a specific output and I only need this to happen once and then I'll throw the whole thing away. As I mentioned elsewhere: this didn't get me the result faster than I could have done by hand, but it did let me not spend the entire time in deep focus trying to write all this.

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

#207

Post by johnisgood »

matwood wrote: post #171
baq wrote: post #122

Earlier quoted context omitted.

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

It'll be interesting if tools like Claude will end up being used to highlight the people who have no clue what they are doing.

I think you can do this already. If you do not know the underlying concepts, or have no idea about how you have to architecture your project and so forth, then you will have problems with LLMs. So I think many if not most people who have problems with LLMs, it is most likely due to their lack of knowledge and/or their expectation that you can just simply write two sentences and it will figure out what you want and how you want it.

You cannot outsource thinking to LLMs, at least not yet, if ever. You have to be part of the whole process. You need to have knowledge. If you have no idea what it is doing or what you want it to do, you are going to have a difficult time.

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

#208

Post by rob_c »

Qudos to the author.

I keep beating on the drum that they correctly point out. It's not perfect. But it saves hours and hours of work in generating compared to small conceptual debugging.

The era of _needing_ teams of people to spit out boilerplate is coming to an end. I'm not saying doing learn to write it, learning demands doing, making mistakes and personal growth. But after you've mastered this there's no need to waste time writing booklet plate on the clock unless you truly enjoy it.

This is a perfect example of time taken to debug small mistakes Time, equivalent money, energy saved all a testament to what is possible with huge context windows and generic modern LLMs :) :) :)

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

#210

Post by mexicocitinluez »

jillesvangurp wrote: post #191

I think this is illustrative of the kind of productive things you can do with an LLM if you know what you are doing. Is it perfect, no. Can they do useful things if you prompt correctly, absolutely. It helps knowing what you are doing and having enough skill to make good judgment calls yourself. There are currently multiple posts per day on HN that escalate into debates on LLMs being useful or not. I think this is a…

The more you use the tools, the more you're able to recognize the situations in which they're useful.

These studies keep popping up where they randomly decide whether someone will use AI to assist in a feature or not and it's hard for me to explain just how stupid that is. And how it's a fundamental misunderstanding of when and how you'd want to use these tools.

It's like being a person who hangs up drywall with screws and your boss going "Hey, I'm gonna flip a coin and if it's heads you'll have to use the hammer instead of a screwdriver" and that being the method in which the hammer is judged.

I don't wake and go "I'm going to use AI today". I don't use it to create entire features. I use it like a dumb assistant.

> I've had similar mixed results with agentic coding sometimes impressing me and other times disappointing me. But if you can adapt to some of these limitations it's alright. And this seems to be a bit of a moving goalpost thing as well. Things that were hard a few months ago are now more doable.

Exactly my experience too.

Post reply on HN