Using Claude Code to modernize a 25-year-old kernel driver
dmitrybrant.com917 points by dmitrybrant 6 days ago
917 points by dmitrybrant 6 days ago
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.
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.
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?
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.
Saying boilerplate shouldn’t exist is like saying we shouldn’t need nails or screws if we just designed furniture to be cut perfectly as one piece from the tree. The response is “I mean, sure, that’d be great, not sure how you’ll actually accomplish that though”.
Great analogy. We've attempted to produce these systems and every time what emerges is software which makes easy things easy and hard things impossible.
You can design furniture without nails or screws. See https://en.m.wikipedia.org/wiki/Japanese_carpentry
Reason Japanese carpenters do or did that is that sea air + high humidity would absolutely rot anything with nail and screw.
No furniture is really designed from a single tree, though. They aren't massive enough.
I agree with overall sentiment. But the analogy is higly flawed. You can't compare physical things with software. Physical things are way more constrained while software is super abstract.
> Reason Japanese carpenters do or did that is that sea air + high humidity would absolutely rot anything with nail and screw.
The other reason was that iron was very expensive in Japan as they had only low quality iron ore.
I can and will compare them, analogies don’t need to be perfect so long as they get a point across. That’s why they’re analogies, not direct perfect comparisons.
I very much enjoy the Japanese carpentry styles that exist though, off topic but very cool.
This is a terribly confused analogy, afaict. But maybe if you could explain in what sense boilerplate, as defined in https://en.wikipedia.org/wiki/Boilerplate_text, is anything like a nail, it could be less confusing.
I can tell you about 1000 ways, the problem is there are no corporate monetary incentives to follow them, and not much late-90s-era FOSS ethos going around either...
By that, you must admit that at least in a sense you imply they’re not cost effective, or practical.
There are construction systems, for example in Japanese traditional architecture, that use no nails or screws. Good joinery often removes their need.
Carpenters/framers are less skilled and paid less than cabinetmakers. But the world needs more carpenters.
While it sounds likely true for the US, it's the opposite in Germany: likely due to societal expectations on "creature comforts" and German homes not being framed with 2x4's but instead getting guild-approved craftsmen to construct a roof for a brick building (with often precast concrete slabs forming the intermediate floors; they're segmented along the non-bridging direction to be less customized).
The value is where the demand is, or where the market values it and not just in a skill of working with wood with tools to create nearly anything.
Saying boilerplate should exist is like saying every nail should have its own hammer.
Some amount of boilerplate probably needs to exist, but in general it would be better off minimized. For a decade or so there's sadly been a trend of deliberately increasing it.
>Saying boilerplate should exist is like saying every nail should have its own hammer
It's rather saying that we should have parts that join without nailing by now, especially for things we do again and again and again and again.
I didn’t say it should exist, only implied it’s a practical inevitability for the moment.
Since we invented the tree and control its parameters and features, this is actually correct.
We’re limited by the limits of our invention though. We can’t set the parameters and features to whatever we want, or we’d set them to “infinitely powerful” and “infinitely simple” - it doesn’t work like that however.
Those parameters of the invention that limit people from just doing away with boilerplate are ones they won't change, not can't.
Well, depending on the value proposition, or the required goals, that’s not necessarily true. There are pros and cons to different approaches, and pretending there aren’t downsides to such a switch is problematic.
Even Star Trek has self-sealing stem bolts, they don't just 3d print their ships
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.
Ground Hog day is optimistic, I think. It will be like "The Butterfly Effect": every attempt to fix the systems using the same dumb, wrote solutions will make the next iteration of the architecture worse and more shitty.
Maybe if you fully hand over the reigns and go watch Youtube all day.
LLMs allow us to do large but cheap experiments that we would never attempt otherwise. That includes new architectures. Automation in the traditional sense is opposite of plasticity (because it's optimizing and crystalizing around a very specific process), but what we're doing with LLMs isn't that. Every new request can be different. Experiments are more possible, not less. We don't have to tear down years of scaffolding like old automated systems. We just nudge it in a new direction.
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.
I find it more likely it will result in an influx of new architectures.
Eventually, prog-lang designers will figure out how to get llms to create new prog-langs.
> 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.
Not me, because I know how to avoid falling into nonsense speculation based on worthless analogies :D
Sand away! Enjoy copying and pasting your nails, or having LLMs apply your varnish or whatever. I hope it brings happiness.
Maybe nail guns that have a chance to randomly shoot nails into your leg and apologize when you ask why it did that.
Great analogy. As someone else pointed out in a different subthread, quality furniture isn't held together with nails.
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.
You don't? I do.
A few days ago I lost some data including recent code changes. Today I'm trying to recreate the same code changes - i.e. work I've just recently worked through - and for the life of me I can't get it to work the same way again. Even though "just" that is what I set out to do in the first place - no improvements, just to do the same thing over again.
We don't understand how human minds work anywhere close to well enough to say this.
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.
> throw a dart ... great deal of uncertainty and nongdeterministic behavior in our everyday actions.
Throwing a dart could not be further away from programming a computer. It's one of the most deterministic things we can do. If I write if(n>0) then the computer will execute my intent with 100% accuracy. It won't compare n to 0.005.
You see arguments like yours a lot. It seems to be a way of saying "let's lower the bar for AI". But suppose I have a laser guided rifle that I rely on for my food and someone comes along with a bow and arrow and says "give it a chance, after all lots of things we do are inaccurate, like throwing darts for example". What would you answer?
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.
Go say this to a darts player who has hit a 9 darter…..
Actually no wait let’s expand it. Why not go say this to Ronnie O’Sullivan too!
The way you’re describing is such that there is no determinism behind what is being done. Simply not true.
a stochastic system can can deterministic sub-parts, a deterministic system cannot have stochastic sub-parts.