Claude Wrote a FreeBSD Wi-Fi Driver in 11 Chapters (Zero Human Code)
Vladimir Varankin wrote zero lines of code. Yet somehow his 2016 MacBook Pro now connects to Wi-Fi on FreeBSD—thanks to what he calls a "book of 11 chapters" specification fed to Claude.
This sounds like Silicon Valley fairy tale bullshit. But the GitHub repo is real, the Hacker News thread has 244 comments, and I've seen enough hype cycles to know when something actually matters.
Here's what happened: Varankin got fed up with FreeBSD's ancient Broadcom problem. His BCM4350 chip had no native driver, forcing him into the usual workarounds—USB dongles, Ethernet cables, or wifibox (a Linux VM with PCI passthrough that's about as elegant as duct tape on a Ferrari).
The 11-Chapter AI Experiment
Instead of learning kernel programming like a normal person, Varankin tried something different. He cloned Linux's brcmfmac driver (thankfully ISC-licensed), then essentially became Claude's project manager:
- Chapter 1: "Here's how FreeBSD drivers work"
- Chapter 2: "Here's the Linux code you need to port"
- Chapter 3-11: Iterative debugging sessions
The AI used FreeBSD's LinuxKPI compatibility layer, modeling the port after the existing iwlwifi driver. No deep OS expertise required—just very detailed prompting.
<> "I wrote no code myself and warns it's for study only, with known issues pending AI fixes."/>
That disclaimer matters more than Varankin probably realizes.
What Nobody Is Talking About
Everyone's debating whether AI can write kernel code. Wrong question.
The real story is FreeBSD's decade-long Broadcom nightmare. This isn't some edge case—it's systematic vendor hostility that's plagued the BSD community since MacBooks became developer machines.
Broadcom's FullMAC design offloads 802.11 framing and WPA crypto to proprietary firmware blobs. Great for power efficiency, terrible for open source. Linux gets drivers because Linus has leverage. FreeBSD gets workarounds.
Check the forums: BCM4360 chips on 2017 MacBook Airs still rely on Linux compatibility layers. BCM43602 on 2015 models needed manual firmware symlinking. The 2023 Arch Linux users were resetting firmware crashes with custom brcmfmac43602-pcie.txt files.
This is what vendor lock-in actually looks like in 2026.
The Reliability Question Mark
Hacker News is split on the obvious concern: can you trust AI-generated kernel code?
Some praise the ISC license compatibility and Claude's technical chops. Others call it "naive" given the complete lack of human code review. Varankin himself "doubts reliability" and advises against production use.
Smart. Kernel bugs don't just crash your browser—they can brick hardware or create security holes. The difference between a working demo and production-ready code is about 10,000 edge cases AI probably hasn't seen.
But here's the thing: this driver already does more than FreeBSD's official Broadcom support. It handles 2.4GHz/5GHz connectivity, WPA/WPA2 authentication, and basic scanning. For a weekend project, that's not bad.
The Real Winner Here
Not AI coding. Not FreeBSD Wi-Fi support.
Compatibility layers. LinuxKPI is the unsung hero—it's what made this port possible without rewriting everything from scratch. Smart engineering that acknowledges reality: Linux has the drivers, so build bridges instead of walls.
Apple learned this lesson with macOS running iOS apps. Microsoft learned it with WSL. FreeBSD's LinuxKPI might be their smartest strategic decision in years.
Varankin's experiment proves you can now prototype kernel modules without deep systems knowledge. Whether that's terrifying or exciting depends on your faith in AI guardrails.
I'm leaning toward terrifying. But I'll still be watching that GitHub repo.
