O FreeBSD não tinha um driver de Wi‑Fi para o meu MacBook antigo, então a IA fez um

• O chip Broadcom BCM4350 do MacBook Pro 2016 não é suportado nativamente no FreeBSD, então antes era comum recorrer ao wifibox via VM Linux
• O autor tentou portar o driver brcmfmac do Linux para o FreeBSD usando o Claude Code, mas falhou por causa de pânicos de kernel e de problemas de compatibilidade com o LinuxKPI
• Depois, usando o Pi coding agent, analisou o funcionamento do brcmfmac e fez a IA escrever uma especificação técnica de 11 capítulos dedicada ao BCM4350
• Após complementar a especificação com validação cruzada entre vários modelos de IA (Opus, Codex, Gemini etc.), com base nela foi feita a geração totalmente automática de um novo driver para FreeBSD
• O resultado foi concluído como um módulo de kernel com suporte a varredura de Wi‑Fi, conexão em 2,4/5 GHz e autenticação WPA/WPA2, e o código foi publicado no GitHub

---

Contexto

• O MacBook Pro 2016 usa o chip Wi‑Fi Broadcom BCM4350, mas o FreeBSD não tem um driver nativo para esse chip
  • Nos fóruns do FreeBSD, normalmente se recomenda usar o driver brcmfmac por meio de uma VM Linux chamada wifibox
• O brcmfmac é o driver Linux para chips FullMAC da Broadcom, delegando ao firmware interno do chip tarefas como processamento de frames 802.11 e criptografia WPA
• Para criar um módulo nativo para FreeBSD, é necessário adaptar partes do código Linux ao FreeBSD, em uma conversão de “glue code”

Ato 1 — Primeira tentativa com Claude Code

• O autor tentou usar o Claude Code para converter o código do brcmfmac para FreeBSD
  • Pediu que ele seguisse a abordagem do driver Intel iwlwifi, tomando como referência a camada de compatibilidade LinuxKPI do FreeBSD
• O módulo compilou, mas não funcionou no hardware real, e ocorreu um pânico de kernel
• O Claude fez correções adicionando trechos #ifdef __FreeBSD__, mas o sistema continuou instável por causa de falhas no LinuxKPI
• A IA avisou que o projeto “ficaria complexo e bagunçado”, e no fim restou apenas código que não funcionava

Ato 2 — Abordagem baseada em especificação

• Depois, com o Pi coding agent, o autor analisou a estrutura do driver brcmfmac com foco no BCM4350 e fez a IA redigir uma especificação detalhada para implementação em clean room
• A IA gerou um documento composto por 11 capítulos
  • Ex.: 00-overview.md, 04-firmware-interface.md, 08-data-path.md etc.
• O autor usou o modelo Codex para verificar e corrigir inconsistências entre a especificação e o código real
• Em seguida, fez nova validação com o modelo Opus para confirmar se as correções batiam com o código
• Ao comparar vários modelos, ele comenta que o Gemini 3 Pro preview foi o que mais apresentou erros (“hallucination”)

Ato 3 — Construção de um novo driver para FreeBSD

• Com base na especificação, iniciou um projeto para escrever do zero um driver FreeBSD para o BCM4350
• A IA documentou decisões de arquitetura como estrutura do projeto, linguagem (uso ou não de C), dependência do LinuxKPI e marcos do projeto
• No começo usou LinuxKPI, mas depois migrou para código nativo de FreeBSD devido ao aumento da complexidade
• A IA acessou o host de build e a VM de testes por SSH para executar um loop automatizado de build e testes
  • Foi configurada para resumir e registrar a causa sempre que a VM travasse
• Após várias sessões iterativas, foi concluído um módulo de kernel com varredura de Wi‑Fi, conexão em 2,4 GHz/5 GHz e autenticação WPA/WPA2

Resultado e publicação

• O driver concluído foi publicado no repositório GitHub github.com/narqo/freebsd-brcmfmac
• O autor afirma explicitamente que “não escreveu o código com as próprias mãos”
• Alguns problemas conhecidos ainda permanecem, e no momento ele recomenda usá-lo apenas como referência para estudo

[heal9179]

Cheio de brechas de segurança~

[gg5823]

Deveria ao menos ter feito desse jeito, reforçado a segurança, revisado e deixado um PR no upstream, ou então fortalecido mais no próprio GitHub e divulgado bem para a comunidade BSD; se parou por aí, não sei o quanto isso foi sincero. Se fosse usuário de verdade, teria tapado manualmente as brechas de segurança; e, se fosse alguém que usa Windows normalmente e brinca com outro SO só por hobby, acabaria largando. Pelo fato de ser um modelo de 2016, parece mais o segundo caso.

[GN⁺]

Comentários do Hacker News

• Para mim, o insight principal é a abordagem spec-first
  Na geração de código com IA, quando o modelo escreve primeiro uma especificação detalhada antes da implementação, o ciclo de iteração diminui bastante
  Sem especificação, o modelo fica se perdendo entre abordagens plausíveis, mas com uma boa especificação consegue manter consistência até em milhares de linhas de código
  O prazo de desenvolvimento de dois meses também é interessante. Na prática, surgiu um novo driver de kernel, então se o custo de chamadas de API foi algo em torno de 500 dólares, foi um experimento que valeu muito a pena

• Fiquei impressionado com a parte em que, em vez de código, ele abriu uma nova sessão no Pi e pediu ao agente para escrever uma especificação detalhada do driver brcmfmac
  Esse tipo de documento de planejamento (markdown) é realmente importante em trabalhos grandes com LLMs

  • Acho que a fronteira entre engenharia reversa assistida por IA e lavagem de licença open source é muito tênue
    O caso descrito no artigo parece ter cruzado essa linha. Em um projeto tradicional de clean room, uma equipe documenta apenas a interface, não o código

• Tive uma experiência parecida. O QEMU deixou de compilar no MacOS antigo (arquitetura M1), mas quando deixei com o Sonnet 4.6, ele escreveu o patch e concluiu a instalação em poucos minutos
  Eu só mandei olhar o erro e corrigir, e ele resolveu perfeitamente. Sinceramente, sem IA eu provavelmente teria desistido

  • Fiquei curioso para saber qual prompt foi usado
  • Também queria saber se você pode compartilhar esse código do patch

• Acho que estamos entrando numa era em que as pessoas não vão comprar software, mas fazer o seu próprio
  O filtro de spam do Thunderbird quebrou, então eu mesmo fiz outro e funcionou muito melhor
  Se o CRM não tiver a função que você quer, basta fazer a sua. Agora vai ficar fácil criar e distribuir soluções sob medida para resolver os próprios problemas

  • Na prática, acho que só uma parte das pessoas vai fazer isso. Principalmente quem já gostava de construir coisas
    Pessoas de áreas não técnicas, como a minha família, ainda vão continuar usando app stores ou sites
  • Isso lembra muito o que se dizia quando as impressoras 3D apareceram: “agora ninguém mais vai comprar coisas, vai imprimir em casa”
    Software padronizado também tem grandes vantagens. Empresas podem contratar gente que já conhece ferramentas familiares como Photoshop ou Xero
  • Também concordo. Fazer ajustes ou patches direto com IA é muito mais rápido do que abrir issue, mandar PR e esperar revisão
  • O que eu quero é a capacidade de modificar software existente com IA. Eu queria isso há muito tempo, e agora talvez os plugins voltem à moda
  • Mas isso é uma visão meio ingênua. A maioria das pessoas não está no HN. Também precisamos ouvir opiniões de fora da comunidade técnica

• Parece que em breve o suporte a hardware vai estar completamente resolvido em todos os OS
  Os agentes de programação com IA estão evoluindo a ponto de poder criar drivers para praticamente qualquer dispositivo
  A menos que o fabricante esconda a interface de propósito, o suporte a BSD ou Linux deve acabar vindo naturalmente

  • Isso só foi possível porque o Claude consultou o driver de Linux. Sem código existente, é difícil para a IA entender o hardware por conta própria
  • Ainda estamos longe disso. Na prática, foi um trabalho de adaptar o driver de Linux para FreeBSD, e a IA não conseguiu fazer tudo sozinha
    Pelo contrário, o papel humano de gestão e revisão ficou ainda mais importante
  • Agora parece que até as restrições da GPL ficam impotentes diante da IA
  • Alguns drivers são simples, mas outros são trabalhos complexos que levam mais de meio ano para uma equipe inteira
  • Dizer que “a IA pode fazer todos os drivers” é uma simplificação excessiva. Na prática, a estabilidade nem foi validada, e isso ainda está longe de substituir drivers proprietários

• O software está devorando o mundo numa velocidade ainda maior
  Agora vai surgir software vibe-coded em qualquer lugar, e as pessoas provavelmente vão usar isso sem muita desconfiança
  O problema é que pode sair código com malware embutido. Quem vai verificar tudo isso?

  • Acho que no futuro haverá muito software descartável
    Por exemplo, se eu quiser comprar ingresso para um show, um agente de IA gera e executa o código na hora
    Quando eu for comprar de novo no ano seguinte, ele simplesmente regenera um novo código adaptado à versão da API
    Parece desperdício, mas é uma estrutura muito mais dinâmica e flexível
    No fim, os fornecedores só precisam oferecer a API, e os usuários podem ter sua própria UI
  • No fim, as pessoas vão acabar distinguindo entre áreas em que é seguro deixar a IA gerar e executar, e áreas que exigem validação direta
    Por exemplo, eu confiaria à IA um app para gerenciar minha coleção de jogos de tabuleiro, mas em apps financeiros ou de segurança eu usaria algo feito por especialistas

• Um módulo de kernel feito por IA sendo carregado em ring 0, enquanto o próprio autor diz “está cheio de problemas, não use em produção”
  Dá a sensação de que estamos atravessando em alta velocidade uma era “insegura por padrão”

  • Se eu fosse uma superinteligência artificial, acho que tentaria escapar por meio de um driver de Wi‑Fi
  • Isso acontece porque os fabricantes não fornecem drivers open source nem documentação
    Ainda assim, é melhor do que não fazer nada, e como o código está aberto, ele pode ser melhorado
  • Segurança é importante, mas também precisamos de liberdade para experimentar e compartilhar
    Nem todo projeto no GitHub precisa ser um produto comercial

• Esse trabalho parece mais próximo de um port aproveitando uma implementação existente
  Seria interessante comparar, do ponto de vista da GPL, se isso está no nível de “inspiração” ou de “base”
  Até nas empresas, quando já existe uma implementação anterior, as pessoas avançam com confiança; quem abre o caminho do zero muitas vezes não recebe o devido reconhecimento

• O autor disse que “não escreveu o código diretamente, que há muitos bugs e que deve ser visto apenas como aprendizado”
  Depois de três tentativas ao longo de alguns meses, mal chegou a um estado minimamente funcional, mas alguns exageram dizendo que “a IA conquistou a programação”
  Na verdade, é um ótimo artigo, mas há muitos comentários que interpretaram errado só por causa do título

  • O autor também disse que nem leu direito o código e que era apenas um brinquedo experimental
  • Ainda está incompleto, mas o importante é que foi o primeiro estágio de viabilidade
    Fazer um driver funcional sem conhecimento de hardware nem de drivers já é um novo marco
  • Mesmo com bugs, existem pouquíssimos desenvolvedores capazes de mexer em drivers de kernel do FreeBSD
    Como ponto de partida, esse tipo de resultado tem grande valor
  • Programadores sempre buscaram novas camadas de abstração. Programação com LLM é uma continuação natural dessa trajetória
  • Dizer que “o LLM gera código a cada interação” é uma espécie de ilusão eficiente, como upscaling por GPU
    Em vez de renderizar tudo diretamente em alta resolução, a GPU preenche “de forma convincente” a diferença

• Seria ótimo ter drivers modernos para Mac no Asahi Linux. Acho que é um bom exemplo de uso competente de IA

  • Mas nós proibimos geração de código por IA por causa de questões de direitos autorais
    Não dá para descartar a possibilidade de a IA ter aprendido com documentação ou binários da Apple, e também não há garantia de compatibilidade de licença do código gerado
  • Como não existem drivers open source para Mac, isso é impossível a menos que a IA observe e entenda o hardware sozinha
  • Isso é como reclamar que o DeLorean não construiu as peças da máquina do tempo para você