I run OmniOS on an Aoostar WTR PRO as my NAS and for most of my self hosting needs. After installing a new fan, I wanted to see if I could read and control the fan speed from the OS instead of just the BIOS. Using Claude chat, I got a working kernel driver that gives me fan speed, PWM control, temperature readings, and even (incorrect) voltage readings.
I wanted to share as an example of what’s currently possible. I’ve even seen people vibe code ethernet drivers for freeBSD.
What do you all think of using LLMs to cobble together drivers like this?
spits on ground, squints reeeeaaal slow
Now listen here sonny… we don’t take kindly to none of that AI business around these parts.
We is simple, God fearin’ folk, raised on sweat, dirt, and good honest labor, not all of that fancy machine learnin’ contraption nonsense.
Ain’t no place for thinkin’ machines where a man’s meant to use his own two hands. So I reckon I’ll mosey on over and downvote this here post myself, nice and proper.
That’s awesome! Can you describe your set up for vibe coding this? I’d like to take a look at porting postmarketOS linux, or ubports to some phones I have laying around.
I just used the free chat with Claude, it created and tracked the files in its own webchat thingy. Being a kernel module, I was happy to manually check, copy/paste, compile, then run the code for each iteration.
Porting postmarketOS to a phone sounds like it may require some amount of manual running and explaining results back to the chat. Ultimately the output only starts to get functional when it hits reality and needs to keep adapting to feedback.
I wrote a blog on the process that more focuses on the journey and technical details of the controller chip.
I’ve even seen people vibe code ethernet drivers for freeBSD.
Please make sure to read what considerations that developer had before undertaking that effort using an LLM: https://github.com/Aquantia/aqtion-freebsd/issues/32#issuecomment-3997341698
Specifically, they (the human) were kept in the loop for the entire process, which included referencing the working Linux driver to do a clean-room reimplementation. This already means they have some experience with software engineering to spot any issues in the specifications that the LLM might generate.
Also, Aquantia (before the merger) already had a published FreeBSD driver but it hasn’t been updated. So this port wouldn’t have to start from zero, but would be a matter of addition support for new NICs that have been released since, but Aquatia hadn’t updated the driver.
This is very much not an example of an Ethernet NIC driver being “vibe coded” from scratch, but a seasoned engineer porting Linux support over to FreeBSD, a kernel that already has a lot of support for easily adding new drivers in a fairly safe manner, and then undertaking a test plan to make sure the changes wouldn’t be abject slop. That’s someone using their tools with reasonable care. In the industry, this is called engineering.
Admiration for what people can do with the right tools must always be put into the right context. Even with the finest tools, it’s likely that neither you nor I could build a cathedral.
I used a very similar method in a similar situation to albb0920. They describe it as vibe coding too.
The exact chip that handles everything is undocumented, but similar ones in the same series have datasheets. A maintained version of the linux driver handily collated all of the available datasheets and configurations used by different motherboards. Between that and my microcontroller/hardware experience, that side of things wasn’t too bad.
What I didn’t know anything about was writing an Illumos driver. I used the chatbot with a free claude account, compiling and running the code manually myself. I was impressed that it was able to build out the boilerplate and get something going at all. Course it took a few tried to get something that compiled and worked somewhat correctly. At some points I needed to look through the generated code and point out exactly what what wrong, but at least it would address it.
Code running in the context of the kernel is definitely not something I would have autonomously executing by a LLM. The end result is absolutely not something I would want put into the official Illumos source.
Pretty cool so long those fans don’t go berserk. Faster troubleshooting if it’s tested well. I remember setting up fan curves on bios at one point and it was annoying enough. Also I don’t think you can stress test there so if your use case needs that then sure.
I’ve always geeked out about fan curves and monitoring, though I readily admit for most PCs leaving the default BIOS curve works fine enough.
Personally it’s what I use them for the most. I do not have the time to reverse engineer arbitrary things like this. I have a scooter that uses Bluetooth BLE which has no connectivity beyond that. I’ve been using Claude to help reverse engineer the protocol to hopefully get a home assistant integration up and running.
Claude can see things I can’t, patterns in hex that are coming back, I send in results from wireshark and it can try ad neaseum to try and get something working. Right now it’s about half working. When I have time I’ll keep plugging away. Then hopefully other people will be able to use it, and we can have one less vendor locked in device
That’s awesome! Can you describe your set up for vibe coding this? I’d like to take a look at porting postmarketOS linux, or ubports to some phones I have laying around.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters FTS Flight Termination System LOX Liquid Oxygen SECO Second-stage Engine Cut-Off SES Formerly Société Européenne des Satellites, comsat operator ~ Second-stage Engine Start USSF United States Space Force
5 acronyms in this thread; the most compressed thread commented on today has 6 acronyms.
[Thread #177 for this comm, first seen 17th Mar 2026, 06:40] [FAQ] [Full list] [Contact] [Source code]
Go home, bot. You’re drunk.
