Harder, but not impossible. You 3d print a jig for a solenoid and a relay so you can warm/cold reboot the laptop, get a pizerow setup and configured to be a keyboard you can control over SSH, a webcam watching the screen, a hardwired Ethernet port, a second computer to manipulate the Device Under Test (aka the MacBook/laptop with a missing whatever driver). Even though waiting on Claude Code doesn't hit flow state if you've only got one project going, setting things up so it can run with it is still fun, for specific and rather nerdy definitions of fun.

Shouldn't AI be able to take this one step further and just analyze the binary (of the samba server in this case) and create all kinds of interface specs from it?

This process took two months, including re-appraisals of the process itself, and it isn't clear that the calendar on the wall was a motivator.

The next implementation doesn't have to happen in a vacuum. Now that it has been done once, a person can learn from it.

They can discard the parts that didn't work well straight away, and stick to only the parts of the process that have good merit.

We'll collectively improve our methods, as we tend to do, and the time required will get shorter with each iteration.

As I understand it, reverse engineering for the purpose of interoperability is allowed under the law. The only thing subject to copyright is your code. So long as a separate implementation (made by an AI model or made by hand) doesn't use any of your actual code, you have no claim over it. Only the code is yours.

AI models make the process of reversing and reimplementing drivers much cheaper. I don't understand the problem with that - it sounds like a glorious future to me. Making drivers cheaper and easier to write should mean more operating systems, with more higher quality drivers. I can't wait for asahi linux to support Apple's newer hardware. I'm also looking forward to better linux and freebsd drivers. And more hobbyist operating systems able to fully take advantage of modern computing hardware.

I don't see any downside.

Except it often is the case that when you break down what humans are doing, there are actual concrete tasks. If you can convert the tacit knowledge to decision trees and background references, you likely can get the AI to perform most non-creative tasks.

... and then figuring out where the hardware company cheapened out and created a whole unfixable mess (extra fun when you first ship your first 10k batch and things start failing after the vendor made a "simple revision"). Then finding a workaround.

That headers looks pretty reasonable to me. I don't see anything misleading or ambiguous about it. Whenever I am heavily modifying some licensed code, I always make sure to include a similar header.

    > I'm going to ahead and say there are copyright law nightmares, right here.

    // SPDX-License-Identifier: ISC
    /*
     * Copyright (c) 2010 Broadcom Corporation
     */

As I mentioned in another comment, the original referenced source code from the Linux kernel is ISC'd, not GPL'd. See here: https://github.com/torvalds/linux/blob/master/drivers/net/wi...

I don't work on the Linux kernel, but I do poke around the sources from time to time. I was genuinely surprised to see that some hardware drivers are not GPL'd. That is news to me, but makes commercial sense to when I think deeper about it. When these manufacturers donate a driver to Linux, I don't think GPL is a priority to them. In the case of Broadcom, they probably want their WiFi hardware to more compatible with SBCs to drive sales (of future SBCs that use their WiFi hardware and run Linux). If anything, choosing a more liberal license (ISC) increases the likelihood that their Linux driver will be ported to other operating systems. From Broadcom's commercial view, that is a win to sell more SBCs (free labour from BSDers!).

Also, if the original driver was GPL'd, I am pretty sure it is fair game (from US copyright and software license perspective) to use one LLM to first reverse engineer the GPL'd driver to write a spec. Then use a different LLM to implement a new driver for FreeBSD that is ISC'd. You can certainly do that with human engineers, and I see no reason to believe that US courts would object to separate LLMs being used in the two necessary steps above. Of course, this assumes good faith on the part of the org doing the re-write. (Any commercial org doing this would very carefully document the process, expecting a legal challenge.)

I do think this blog post introduces a genuinely (to me!) novel way to use LLMs. My favourite part of that blog post was talking about all of the attempts that did not work, and new approaches that were required. That sounds pretty similar to my experience as a software engineer. You start with preconceived notions that frequently shattered after you walk down a long and arduous path to discovering your mistakes. Then you stop, re-think things, and move in a new intellectual (design) direction. His final solution of asking LLMs to write a spec, then asking other LLMs to proof-read it is highly ingenious. I am really impressed. Please don't view that "really impressed" as my thinking that the whole world will move to vibe coding; rather I think this is a real achievement that deserves some study by us human engineers.