Table of Contents
Quick Summary
- A developer successfully created an experimental native FreeBSD WiFi driver for the Broadcom BCM4350 chip (MacBook Pro 2016) by acting as a "project manager" for AI agents.
- After a direct port of Linux code failed, he used a three-act "vibe coding" process: generating an 11-chapter technical specification via one AI, double-proofreading it with others, and finally having a separate agent implement the driver from scratch using that spec.
- The resulting driver supports WPA2-PSK on 2.4GHz and 5GHz bands, though it remains experimental.
Introduction
Today, we will discuss an interesting true story. A developer named Vladimir Varankin had an old 2016 MacBook Pro gathering dust. He wanted to run FreeBSD on it, but he faced a big problem: the WiFi did not work.
Most people solve this by running a small Linux system in a virtual machine (VM) called wifibox. But, Vladimir wanted a native driver that worked directly with the FreeBSD kernel.
Since he did not want to write thousands of lines of code by hand, he turned to AI coding agents. This story shows how "vibe coding" can solve hard hardware problems.
How AI Built a Native FreeBSD WiFi Driver
The First Attempt: A Simple Copy-Paste
At first, Vladimir tried a very simple idea. He took the existing Linux driver code and asked an AI named Claude to "port" it to FreeBSD. He used a tool called LinuxKPI, which acts like a helper layer to run Linux drivers on FreeBSD.
Unfortunately, this plan failed quickly. The AI struggled with missing features, and the code caused the system to crash, or "panic," constantly. Vladimir realized that simply copying code was too messy.
Act 2: Building a "Book" First
Vladimir decided to change his strategy. Instead of writing code right away, he asked an AI agent called Pi to write a detailed 11-chapter specification. This document explained exactly how the WiFi chip works "to the bits".
To make sure the AI did not make mistakes, Vladimir used several other AI models like Codex and Opus to proofread the spec. He compared the spec against the original Linux source code to find any errors. This created a solid foundation for the actual build.
Act 3: The "Vibe Coding" Workflow
With a perfect spec in hand, Vladimir started a fresh project. He told the AI to build a native FreeBSD driver from scratch without using the Linux helper layer.
He set up a very smart workflow:
- The Build Loop: The AI had access to a testing VM via SSH. It would write code, build the module, and test it automatically.
- Safety First: Vladimir used a virtual machine for testing. This was critical because if the new driver crashed the system, the VM would reboot in seconds without hurting his main computer.
- Decision Logs: He forced the AI to record every major decision in a file called
AGENTS.md. This helped the AI stay on track during long coding sessions.
The Result: It Actually Works!
After many sessions, Vladimir finally got a working driver. Even though he did not write the code himself, the driver can now scan for networks and connect to 2.4GHz and 5GHz WiFi using WPA2.
However, he warns that the driver is still experimental. It has some stability issues and is mostly for testing right now.
The developer has added the Wifi driver in his GitHub repository. You can even see that he used a mix of C and a new language called Zig for the project.
Key Insight: Context Engineering over Coding
The project’s success demonstrates that for complex system-level tasks, the human's role shifts from writing syntax to context engineering and milestone management.
Rather than just "prompting," the developer maintained a persistent state for the AI using AGENTS.md and decisions.md files to track architecture choices and progress.
This "clean-room" simulation—where one AI writes the spec and another implements it—allowed the agent to navigate the vast differences between Linux and FreeBSD kernel APIs without getting bogged down in messy compatibility shims like LinuxKPI.
You can read more technical details about this story in Vladimir's blog.
Surprising Detail: Not a Single Line of Code is Written by Human Developer!
Despite being a project for a native FreeBSD kernel module, a task usually requiring deep expertise in C, the developer did not write a single line of the code himself.
Furthermore, the AI agents independently chose to write roughly 5% of the driver in Zig for pure logic components, while using C for kernel interactions, a decision that was recorded and followed by the agents across multiple coding sessions
Is it License Laundering or Smart Engineering?
This project sparks a big debate on hackernews about how we build software. Some developers worry about "license laundering", the idea that AI might "wash away" the legal rules of the original code. Others argue that using AI to translate hardware logic for a new OS is just smart engineering.
Regardless of the debate, Vladimir proved that a single developer can bridge a massive hardware gap using AI agents. In the future, we might treat software like "cattle" rather than "pets"—building and throwing away custom solutions whenever we need them.
