A primeira série de patches assistida por LLM de Linus Torvalds

Um importante mantenedor do kernel Linux usou um assistente de codificação LLM para redigir uma série de patches voltados ao desempenho, provocando debate sobre como o código gerado por IA se encaixa em normas de longa data sobre revisão de código, copyright e licenciamento open source. Os comentadores ponderam os ganhos práticos em produtividade e exploração de código contra preocupações com qualidade, dependência excessiva de serviços proprietários de IA, impactos ambientais e sociais, e a manutenção de longo prazo de infraestrutura crítica cada vez mais tocada por código gerado por máquina.

Reação geral aos patches do kernel assistidos por LLM

  • Muitos não se surpreendem que um mantenedor altamente pragmático adotasse LLMs, dada a mudança para revisão/gestão em vez de programação prática.
  • Outros se surpreendem, vendo isso como uma ruptura com uma imagem percebida de “old school” e com a hostilidade anterior a coisas como C++ no kernel.
  • Alguns temem que isso seja mal utilizado como “se é bom o bastante para o kernel, é bom o bastante para qualquer lugar”, ignorando a expertise e a revisão por trás disso.

Qualidade, confiabilidade e revisão

  • Há forte ênfase de que a saída de um LLM só é aceitável com revisão de especialistas, testes e patches pequenos e compreensíveis.
  • Comentadores observam que LLMs muitas vezes produzem código que parece correto, mas contém bugs sutis (por exemplo, condições de corrida).
  • Faz-se uma distinção entre usar IA como assistente de codificação e delegar programas complexos inteiros, fazendo apenas uma revisão superficial.

Questões de copyright e licenciamento

  • Uma linha de argumentação: código escrito por máquina não é passível de copyright, portanto não pode ser “open source” e deve ser excluído do kernel.
  • Contra-argumentos:
    • Conteúdo de domínio público ou CC0 pode coexistir legalmente com licenças copyleft.
    • Pequenas quantidades de código sem copyright ou em domínio público são comuns e não são inerentemente “tóxicas”.
  • Um thread separado cita jurisprudência anterior aos LLMs e posições do US Copyright Office de que apenas humanos podem deter copyright, reforçando o requisito de “humano no circuito”.
  • Preocupação de longo prazo: se uma base de código se tornar efetivamente sem copyright em excesso, seu status legal pode ficar nebuloso.

Modelos fechados vs. abertos

  • Alguns estão desapontados que um projeto emblemático de FOSS tenha usado um assistente proprietário em vez de modelos de pesos abertos.
  • Outros argumentam que os modelos abertos atuais ainda são notavelmente mais fracos para programação de sistemas complexos.
  • A justificativa predominante é o pragmatismo estrito: escolher a ferramenta que funciona melhor, independentemente de ser aberta.

Atitudes mais amplas em relação à IA no software

  • Defensores: veem melhorias rápidas, ganhos reais de produtividade e consideram inevitável a assistência de IA em infraestrutura crítica.
  • Céticos:
    • Preocupam-se com “slopware”, impacto ambiental, expansão de data centers e efeitos sociais de longo prazo (empregos, vigilância, deepfakes).
    • Alguns discutem boicotar projetos assistidos por IA ou buscar sistemas operacionais “sem IA”.
  • Vários comentários rejeitam o enquadramento de guerra cultural, distinguindo entre usar IA de forma responsável e abusá-la.