FreeBSD doesn't have Wi-Fi driver for my old MacBook, so AI built one for me

Original Article ↗ Hacker News Discussion ↗

What Actually Happened in the FreeBSD Driver Case

  • The “AI-built” driver is essentially a port of Broadcom’s Linux brcmfmac Wi‑Fi driver (ISC-licensed) to FreeBSD.
  • The author used an AI agent iteratively: first to write a detailed spec from the Linux driver, then (in a fresh session) to implement a FreeBSD version.
  • It took about two months, has known issues, wasn’t deeply code-reviewed, and is explicitly not recommended for production use.
  • Several commenters stress this is a good demo of AI-assisted porting, not “AI discovering hardware from scratch.”

Feasibility of AI-Generated Drivers

  • Optimistic view: this shows we’re closer to ubiquitous cross‑OS hardware support; AI can handle tedious porting and boilerplate.
  • Critical view: AI struggled even with full source; writing robust drivers without prior open code or datasheets is far harder.
  • Many note the real bottleneck is documentation and hardware knowledge, not typing C.

Testing, Safety, and Hardware Risks

  • Drivers fail via rare race conditions, power-state and timing edge cases; AI is weak at debugging once-in-weeks bugs.
  • “Brute forcing” drivers risks bricking hardware (e.g., bad voltages, eFuses, EEPROM).
  • Some propose automated test jigs (VM passthrough, microphones, logic analyzers, robot “mouse movers”), but admit complexity and cost.

Licensing, GPL, and “Copyright Laundering”

  • In this specific case, Linux brcmfmac is ISC, and the FreeBSD driver credits and retains ISC licensing, which commenters generally see as fine.
  • Broader worry: LLMs trained on GPL code being used to generate non‑GPL drivers (or “rewrite” GPL code) may undermine copyleft.
  • “Spec-first” AI workflows look similar to historical clean-room techniques, but critics argue training-data contamination makes this legally murky.
  • Some projects (e.g. Apple reverse‑engineering efforts) explicitly avoid AI for code and docs to preserve clean-room guarantees.

Code Quality and Engineering Practice

  • Mixed reactions to the resulting C: some call it “atrocious” (uninitialized vars, magic numbers, inconsistent error paths), others say it’s typical low-level driver style.
  • Several highlight the real win is process: keeping AGENTS.md/decisions logs, having the model write specs first, and iterating like a manager over agents.

Vibe-Coded, Disposable Software Future

  • One camp imagines agents generating throwaway apps and workflows on demand (e.g., buying tickets, custom CRMs), with code treated as “cattle, not pets.”
  • Others counter that:
    • Most people won’t build their own tools; they’ll keep using standard apps.
    • Battle-tested, shared software is more secure, predictable, and maintainable than endless bespoke “vibe code.”
    • There are environmental and quality concerns if millions of ephemeral tools replace a few well-engineered ones.

Impact on Open Source and SaaS

  • Some foresee AI eroding traditional SaaS (companies auto‑building internal tools instead of buying licenses), which is already reflected in market jitters.
  • Others caution this is mostly “concern” and hype; integration, maintenance, interfaces, and organizational behavior still dominate real-world software choices.
  • Overall sentiment: AI is already useful as an accelerator and patch generator (e.g., QEMU fixes), but not a magic replacement for expertise, testing, or licensing discipline.