Uses like this will only get more pervasive.
If we allow it
Using Claude Code to modernize a 25-year-old kernel driver
181–190 of 343 posts
Re: Using Claude Code to modernize a 25-year-old kernel driver
#182LLMs are also good for writing quick experiments and benchmarks to satisfy someone's curiosity. For example, once I was wondering, how much time does it take to migrate a cache line between cores when several processes access the same variable - and after I wrote a detailed benchmark algorithm, LLM generated the code instantly. Note that I described the algorithm completely and what it did is just translated it into…
Also I wanted to add that LLMs (at least free ones) are pretty dumb sometimes and do not notice obvious thing. For example, when writing tests they generate lot of duplicated code and do not move it into a helper function, or do not combine tests using parametrization. I have to do it manually every time. Maybe it is because they generate the code in one pass and cannot return back and fix the issues. LLM makers, you…
> I have to do it manually every time.
You can tell it to move it and they'll move it and use this shared code from now on.
Re: Using Claude Code to modernize a 25-year-old kernel driver
#183Off-topic, but I wish Linux had a stable ABI for loadable kernel modules. Obviously the kernel would have to provide shims for internal changes because internal ABI constantly evolves, so it would be costly and the drivers would probably run slower over time. Yet, having the ability to use a driver from 15 years ago can be a huge win at times. That kind of compatibility is one of the things I love about Windows.
I think this would be terrible for the driver ecosystem. I don't want to run 15 year old binary blob drivers because they technicially still work.
Just get the source code published into mainline.
Re: Using Claude Code to modernize a 25-year-old kernel driver
#184Earlier 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…
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.
Reliably correct is good, but why does it need to be fully deterministic?
Re: Using Claude Code to modernize a 25-year-old kernel driver
#185Earlier 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…
I think this one way of looking at what your parent was describing.
They weren’t just saying ‘AI writes the boilerplate for me.’ They were saying: once you’ve written the same glue the 3rd, 4th, 5th time, you can start folding that pattern into your own custom dev tooling.
AI not as a boilerplate writer but as an assistant to build out personal scaffolding toolset quickly and organically. Or maybe you think that should be more systemized and less personal?
Re: Using Claude Code to modernize a 25-year-old kernel driver
#186Earlier quoted context omitted.
>>> Use these tools for rapid onboarding onto new frameworks. > Also new languages - our team uses Ruby, and Ruby is easy to read, so I can skip learning the syntax and get the LLM to write the code. If Ruby is "easy to read" and assuming you know a similar programming language (such as Perl or Python), how difficult is it to learn Ruby and be able to write the code yourself? > ... but I don't need to learn Ruby to w…
are you advocating for not having code reviews...? Just straight force push to main?
Code reviews (especially internal ones) generally assume that the person writing the original code has an idea of what they are doing and are designed to catch mistakes that humans might make. Just because they probably work to improve codebases with human submissions doesn't mean that they are good enough filter for LLM-generated code that the submitter doesn't sufficiently understand and has submitted without their own review. Same goes for CI and testing.
This reminds of some of the comments made by reviewers during the infamous Schön scientific fraud case. The scientific review process is designed to catch mistakes and honest flaws in research. It is not designed to catch fraud, and the evidence shows that it is bad at it.
Another applicable example would be the bad patches fiasco with the Linux kernel. (And there is going to be a session at the upcoming maintainers' summit about LLM-generated kernel patches.)
Re: Using Claude Code to modernize a 25-year-old kernel driver
#187Re: Using Claude Code to modernize a 25-year-old kernel driver
#188A 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…
those who use claude code, what you think are its best features which you cannot live without and makes your life so much easier? I am using claude code but I am not sure what stuff i should look into.
Re: Using Claude Code to modernize a 25-year-old kernel driver
#189Earlier quoted context omitted.
> This is the glaring fallacy! It feels like toil because it's not the interesting or engaging part of the work. If you're going to build a piece of furniture. The cutting, nailing, gluing are the "boiler plate" that you have to do around the act of creation. LLM's are just nail guns.
At least for me when woodworking, the cutting, nailing, and gluing are the fun bits. The sanding and finishing is the grunt work/boilerplate.
The AI BAD folks camping in this thread would be angry that you're still producing work that requires sanding.
Re: Using Claude Code to modernize a 25-year-old kernel driver
#190Earlier 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.
Reliably correct is good, but why does it need to be fully deterministic?
Reduced mental load. When it’s proven that a set of input will always result in the same output, you don’t have to verify the output. And you can just chain process together and not having to worry about time wasted because of deviations.