In February 2026, developer Vladimir Varankin published a write-up with a title that went straight to the top of Hacker News: “FreeBSD doesn’t have Wi-Fi driver for my old MacBook. AI built one for me”. The code is on GitHub as narqo/freebsd-brcmfmac.
It would be easy to file this under “AI does something impressive” and move on. That undersells it. The more useful story is how the first attempt went nowhere, and what changed to make the second one work. If you use AI coding agents for anything bigger than a single file, the lessons carry over directly.
All credit for the project belongs to Varankin. This post summarises his account and adds some context. It’s not a first-hand test.
The problem: Broadcom chips and FreeBSD
The machine was a 2016 MacBook Pro with a Broadcom BCM4350 Wi-Fi chip. Linux supports this family of chips through the brcmfmac driver. FreeBSD doesn’t have a native equivalent for this chip.
The usual workaround on FreeBSD is wifibox: run a tiny Linux virtual machine, pass the Wi-Fi card through to it, and let Linux’s driver do the work. It’s clever and it works, but it’s a lot of machinery just to get on a network.
If you’re curious what your own FreeBSD machine thinks its network hardware is, this lists PCI devices with vendor and device names:
pciconf -lv | grep -B3 -A2 networkA device with no driver attached shows up with a none prefix instead of a driver name, which is the tell that you’re in the same situation Varankin was.
Attempt one: “port the Linux driver”
The obvious first move was to ask an AI agent (Claude Code, in this case) to port brcmfmac to FreeBSD. There was a reasonable model to follow. FreeBSD’s Intel Wi-Fi support (iwlwifi) reuses Linux driver code through LinuxKPI, a compatibility layer that maps Linux kernel APIs onto FreeBSD’s.
It didn’t go well. According to the write-up, the module compiled but didn’t do anything. Once it was tested on real hardware, the result was repeated kernel panics. The diff kept growing, and the driver still didn’t work.
This is a failure pattern most people who use coding agents will recognise. Asking a model to “port this large codebase” gives it a vague goal and a huge context. It produces plenty of plausible-looking code, but there’s no clear way to tell whether any of it is right until you run it, and by then there’s too much to debug.
Attempt two: write the spec first
The second attempt changed the order of work. Varankin credits Armin Ronacher’s writing about building a game with Claude and the Pi agent as the inspiration. Instead of asking for code, he asked an agent to write a detailed specification of how the BCM4350 driver works, written as if for a clean-room implementation.
The result was an 11-chapter document covering data structures, the bus layer, the protocol, the firmware interface and the initialisation sequence. In other words, the agent first had to explain the hardware before anyone wrote a line of driver code.
Then came the step that’s easy to skip and probably mattered most: the spec was reviewed by different models.
- One model (Codex) checked the specification against the actual Linux driver source.
- Another (Claude Opus) reviewed the corrections the first one proposed.
- Varankin also compared how several models handled the task, including Opus 4.5 and 4.6, Codex 5.2 and Gemini 3 Pro. His observation was that Gemini hallucinated the most.
Using a second model as a reviewer is a cheap way to catch the confident mistakes that any single model makes. It’s the AI equivalent of asking a colleague to read your design doc.
Attempt three: build from the spec, not the source
With a reviewed spec in hand, a fresh agent session started the implementation using only the document. Before writing code, the agent asked questions and recorded decisions about where the code would live in the source tree, which language to use and how to build it.
Development ran iteratively, with the agent able to SSH into a build host and a test VM to compile, load and test. Partway through there was a significant course change. After several sessions, the LinuxKPI approach was dropped and the driver was refactored to use native FreeBSD kernel primitives instead.
That kind of mid-project pivot is normal in human engineering. What made it possible here was that the plan and decisions were written down, so changing direction didn’t mean starting from nothing.
What works, and what doesn’t
By the end of the write-up, the driver could:
- scan for Wi-Fi networks,
- connect on both 2.4 GHz and 5 GHz bands,
- authenticate with WPA and WPA2.
That’s a genuinely working driver for the basic job. But Varankin is clear about its limits. He advises against using it for anything beyond studying, testing and experimenting. Kernel code runs with full privileges, and a bug in a driver can crash the machine or worse. “It connects to my home Wi-Fi” is a long way from “it’s safe for daily use.”
The licensing question
Hacker News commenters quickly raised licensing. If an AI writes a driver based on a spec derived from Linux code, what licence applies? The Linux brcmfmac driver is ISC-licensed, which is permissive and compatible with FreeBSD. Varankin chose ISC for the new driver too, and noted that the agent hadn’t added any licence by default. He documented the decision in the repository.
It’s a useful reminder. Coding agents don’t think about licensing unless you ask. If you’re building on open source code, make licence decisions on purpose and write them down.
What this says about AI coding in 2026
The headline says “AI built a driver.” The write-up says something more interesting: the agent only made real progress once it was forced to plan, record decisions and iterate. As Varankin put it, “AI coding hasn’t changed these fundamentals — not by 2026, at least.”
Here’s a checklist you can take from this for your own agent-driven projects:
- Don’t start with “port this” or “build this”. Start with “explain this” and get a written spec.
- Have a different model review the spec against the real source material before any code is written.
- Keep a decisions file. Where does the code live, which approach, why? Agents lose context between sessions. Documents don’t.
- Give the agent a tight test loop. Here, that was SSH access to a build machine and a test VM. Without a way to run the code, an agent is just guessing.
- Expect to change direction. Dropping LinuxKPI halfway through wasn’t a failure. It was the plan working.
- Be honest about the result. A working prototype is not production code, and the project’s own README says so.
Should FreeBSD users try it?
If you have the same MacBook and enjoy kernel work, the repository is worth reading, especially the spec, which is arguably the most valuable part of the project. For a machine you depend on, wifibox or a supported USB Wi-Fi adapter is still the sensible choice.
For everyone else, the takeaway isn’t about FreeBSD at all. It’s that the gap between “the AI wrote a lot of code” and “the AI helped me ship something that works” is closed by ordinary engineering discipline: specs, reviews, written decisions and testing on the real thing.
Related reading
- A Practical Workflow for Writing Software with LLMs
- Claude Code Workflow Guide: Separating Planning from Execution
- Why AI Coding Agents Sometimes Ignore You, and How to Stop It
Sources: Vladimir Varankin’s write-up, narqo/freebsd-brcmfmac on GitHub, Hacker News discussion.
