- El chip Broadcom BCM4350 de la MacBook Pro 2016 no tiene soporte nativo en FreeBSD, por lo que hasta ahora lo habitual era usar la solución alternativa con wifibox mediante una VM de Linux
- El autor intentó portar a FreeBSD el driver brcmfmac de Linux usando Claude Code, pero fracasó por kernel panics y problemas de compatibilidad con LinuxKPI
- Después usó Pi coding agent para analizar cómo funciona brcmfmac y la IA redactó una especificación técnica de 11 capítulos dedicada al BCM4350
- Tras complementar la especificación validándola de forma cruzada con varios modelos de IA (Opus, Codex, Gemini, etc.), a partir de ella generó de forma totalmente automática un nuevo driver para FreeBSD
- El resultado fue un módulo de kernel con soporte para escaneo Wi‑Fi, conexión en 2.4/5 GHz y autenticación WPA/WPA2, y el código se publicó en GitHub
Antecedentes
- La MacBook Pro 2016 usa el chip Wi‑Fi Broadcom BCM4350, pero FreeBSD no tiene un driver nativo para ese chip
- En los foros de FreeBSD, normalmente se sugiere usar wifibox, que emplea el driver brcmfmac a través de una VM de Linux
- brcmfmac es el driver de Linux para chips FullMAC de Broadcom, y delega tareas como el procesamiento de tramas 802.11 y el cifrado WPA al firmware interno del chip
- Para crear un módulo nativo para FreeBSD, hace falta convertir parte del código de Linux en “glue code” adaptado a FreeBSD
Acto 1 — Primer intento con Claude Code
- El autor intentó convertir el código de brcmfmac para FreeBSD usando Claude Code
- Le pidió que tomara como referencia la capa de compatibilidad LinuxKPI de FreeBSD y siguiera el enfoque del driver iwlwifi para Intel
- El módulo compiló, pero no funcionó en el hardware real y provocó kernel panics
- Claude hizo ajustes añadiendo directivas
#ifdef __FreeBSD__, pero seguía siendo inestable debido a fallas en LinuxKPI
- La IA advirtió que el proyecto “se volvería complejo y desordenado”, y al final solo quedó código que no funcionaba
Acto 2 — Enfoque basado en especificación
- Después usó Pi coding agent para analizar la estructura del driver brcmfmac con foco en el BCM4350 y hacer que redactara una especificación detallada para una implementación clean-room
- La IA generó un documento compuesto por 11 capítulos
- Por ejemplo:
00-overview.md, 04-firmware-interface.md, 08-data-path.md, etc.
- El autor usó el modelo Codex para verificar y corregir discrepancias entre la especificación y el código real
- Luego volvió a validarla con el modelo Opus para confirmar que las correcciones coincidieran con el código
- Tras comparar varios modelos, menciona que Gemini 3 Pro preview fue el que mostró más errores (“hallucinations”)
Acto 3 — Construcción de un nuevo driver para FreeBSD
- Con base en la especificación, inició un proyecto para escribir desde cero un driver de FreeBSD para el BCM4350
- La IA documentó decisiones de diseño como la estructura del proyecto, el lenguaje (si usar C), la dependencia de LinuxKPI y los hitos
- Al principio se usó LinuxKPI, pero debido al aumento de complejidad se cambió a código nativo de FreeBSD
- La IA accedió por SSH al host de compilación y a la VM de pruebas para ejecutar un bucle automático de build y test
- Se configuró para resumir y registrar la causa cada vez que la VM se caía
- Tras varias sesiones iterativas, se completó un módulo de kernel con escaneo Wi‑Fi, conexión en 2.4 GHz/5 GHz y autenticación WPA/WPA2
Resultado y publicación
- El driver terminado se publicó en el repositorio de GitHub github.com/narqo/freebsd-brcmfmac
- El autor deja explícito que “no escribió el código directamente”
- Aún quedan algunos problemas conocidos, y por ahora recomienda usarlo solo como referencia de aprendizaje
3 comentarios
Tiene agujeros de seguridad por todos lados~
Deberían haberlo hecho así, reforzar la seguridad, revisarlo y al menos dejar un PR upstream, o fortalecerlo más en su propio GitHub y darlo a conocer bien en la comunidad BSD; si lo dejaron ahí, no sé qué tanta autenticidad haya. Si de verdad fuera un usuario real, taparía manualmente los huecos de seguridad, y si es alguien que usa bien Windows y solo juega con otros SO como hobby, entonces lo abandonaría. Viendo que es de 2016, parece más bien lo segundo.
Comentarios de Hacker News
Me parece que la idea clave es el enfoque spec-first
En generación de código con IA, si haces que el modelo redacte primero una especificación detallada antes de implementar, el ciclo iterativo se reduce muchísimo
Si arrancas sin especificación, el modelo divaga entre enfoques que suenan plausibles, pero con una buena especificación puede mantener coherencia incluso a lo largo de miles de líneas de código
También es interesante el plazo de desarrollo de dos meses. Al final es como si hubiera aparecido un nuevo driver de kernel, así que si el costo en llamadas de API fue de unos 500 dólares, parece un experimento que valió la pena
Me llamó la atención la parte donde, en vez de código, abrió una nueva sesión de Pi y le pidió al agente que redactara una especificación detallada del driver
brcmfmacEste tipo de documento de planificación (markdown) es realmente importante en trabajos grandes con LLM
El caso descrito en el artículo parece haber cruzado esa línea. En un diseño clean room tradicional, un equipo documenta solo la interfaz, no el código
Yo también tuve una experiencia parecida. QEMU ya no compilaba en una versión vieja de MacOS (arquitectura M1), pero se lo dejé a Sonnet 4.6 y en minutos escribió el parche y hasta completó la instalación
Solo le indiqué que viera el error y lo corrigiera, y lo resolvió perfectamente. Si soy sincero, sin IA probablemente me habría rendido
Parece que viene una era en la que la gente ya no comprará software, sino que lo hará por su cuenta
El filtro de spam de Thunderbird se rompió, así que hice uno nuevo yo mismo y funciona mucho mejor
Si tu CRM no tiene la función que quieres, la haces tú. Ahora será fácil crear y desplegar soluciones personalizadas para resolver tus propios problemas
La gente de mi familia, por ejemplo, que no trabaja en áreas técnicas, va a seguir usando la App Store o sitios web
El software estandarizado también tiene ventajas importantes. Las empresas pueden contratar gente que ya conoce herramientas familiares como Photoshop o Xero
Parece que pronto el soporte de hardware va a quedar completamente resuelto en todos los sistemas operativos
Los agentes de programación con IA están avanzando hasta el punto de poder crear drivers para casi cualquier dispositivo
A menos que el fabricante oculte deliberadamente la interfaz, el soporte para BSD o Linux terminará llegando de forma natural
Más bien, el papel de gestión y revisión de la persona se volvió aún más importante
El software se está comiendo al mundo todavía más rápido
Ahora va a aparecer software vibe-coded por todas partes, y la gente probablemente lo use sin cuestionarlo mucho
El problema es que podría salir código con malware mezclado. ¿Quién va a verificar todo eso?
Por ejemplo, si quieres comprar boletos para un concierto, un agente de IA podría generar y ejecutar código al instante
Si vuelves a comprar al año siguiente, regenerará código nuevo según la versión actual del API
Puede parecer un desperdicio, pero es una estructura mucho más dinámica y flexible
Al final, el proveedor solo necesita ofrecer el API, y el usuario puede tener su propia UI
Por ejemplo, podría dejarle a la IA mi app para gestionar mi colección de juegos de mesa, pero para apps financieras o de seguridad usaría algo hecho por especialistas
Un módulo de kernel hecho por IA se carga en ring 0, y hasta su creador dice “tiene muchos problemas, no lo usen en producción”
Da la impresión de que estamos entrando a toda velocidad en una época “insegura por defecto”
Aun así, es mejor que no hacer nada, y como el código está publicado, también se puede mejorar
No todos los proyectos de GitHub tienen que ser productos comerciales
Este trabajo se parece más a una tarea de porting que aprovecha una implementación existente
Sería interesante compararlo desde la perspectiva de la GPL, para ver si está más cerca de ser una “inspiración” o una “base”
Incluso en las empresas, cuando ya existe una implementación previa avanzan con confianza, pero a quienes abren camino por primera vez no se les reconoce tanto
El autor dijo que “no escribió el código directamente, tiene muchos bugs y solo debe verse como material de aprendizaje”
Después de tres intentos a lo largo de varios meses, apenas logró que funcionara, pero algunos exageran diciendo que “la IA conquistó la programación”
En realidad es un buen artículo, pero hay muchos comentarios que malinterpretaron el contenido por leer solo el título
Haber creado un driver funcional sin conocimientos de hardware ni de drivers marca un nuevo hito
Como punto de partida, este tipo de resultado tiene muchísimo valor
En vez de renderizar directamente en alta resolución, la GPU rellena la diferencia de forma “ilusoria”, y aquí pasa algo similar
Ojalá aparecieran drivers modernos para Mac en Asahi Linux. Me parece un muy buen caso de uso de la IA
No se puede descartar que la IA haya aprendido de documentación o binarios de Apple, y tampoco se puede garantizar la compatibilidad de licencias del código generado