Início Tecnologia As novas regras para código assistido por IA no kernel Linux: o...

As novas regras para código assistido por IA no kernel Linux: o que todo desenvolvedor precisa saber

36
0

Emilija Manevska/Second/Getty Photographs

Siga ZDNET: Adicione-nos como fonte preferencial no Google.


Principais conclusões da ZDNET

  • Torvalds e os mantenedores do Linux estão adotando uma abordagem pragmática para usar IA no kernel.
  • Com IA ou sem IA, são as pessoas, e não os LLMs, que são responsáveis ​​pelo código do Linux.
  • Se você tentar mexer no código do Linux usando IA, coisas ruins acontecerão.

Após meses de debate acalorado, Linus Torvalds e os mantenedores do kernel Linux oficialmente codificou a primeira política formal do projeto em contribuições de código assistido por IA. Esta nova política reflete a abordagem pragmática de Torvald, equilibrando a adoção de ferramentas modernas de desenvolvimento de IA com os rigorosos padrões de qualidade do kernel.

As novas diretrizes estabelecem três princípios fundamentais:

  1. Os agentes de IA não podem adicionar tags Signed-off-by: Somente humanos podem certificar legalmente o Certificado de Origem do Desenvolvedor (DCO) do kernel Linux. Este é o mecanismo authorized que garante a conformidade do licenciamento do código. Em outras palavras, mesmo que você tenha entregue um patch que foi escrito inteiramente pela IA, você, e não a IA ou seu criador, é o único responsável pela contribuição.

  2. Atribuição assistida obrigatória: Qualquer contribuição que make the most of ferramentas de IA deve incluir uma tag Assistida por identificando o modelo, o agente e as ferramentas auxiliares utilizadas. Por exemplo: “Assistência de: Claude:claude-3-opus coccinelle esparsa.”

  3. Responsabilidade humana complete: Junte tudo isso e você, o remetente humano, terá complete responsabilidade pela revisão do código gerado pela IA, garantindo a conformidade da licença e por quaisquer bugs ou falhas de segurança que surgirem. Não tente inserir código incorreto no kernel, como dois estudantes da Universidade de Minnesota tentaram em 2021, ou você pode dar adeus às suas probabilities de se tornar um desenvolvedor ou programador de kernel Linux em qualquer outro projeto de código aberto respeitável.

A tag Assistido por serve tanto como um mecanismo de transparência quanto como um sinalizador de revisão. Ele permite que os mantenedores forneçam aos patches assistidos por IA o escrutínio further que podem exigir, sem estigmatizar a prática em si.

Além disso: Linux depois de Linus? A comunidade do kernel finalmente elabora um plano para substituir Torvalds

A atribuição Assistido por foi forjada no meio da controvérsia quando o engenheiro da Nvidia e proeminente desenvolvedor de kernel Linux Sasha Levin enviou um patch para o Linux 6.15 inteiramente gerado por IAincluindo o changelog e os testes. Levin revisou e testou o código antes de enviá-lo, mas não revelou aos revisores que uma IA o havia escrito.

Isso não foi bem aceito por outros desenvolvedores de kernel.

O papel da IA ​​como ferramenta e não como coautor

O resultado de toda a agitação subsequente? Na Cúpula de Código Aberto da América do Norte de 2025, o próprio Levin começou a defender regras formais de transparência de IA. Em julho de 2025, ele propôs o primeiro rascunho do que se tornaria a política de IA do kernel. Ele inicialmente sugeriu uma tag co-desenvolvida por para patches assistidos por IA.

Discussões iniciais, tanto pessoalmente quanto no Lista de discussão do kernel Linux (LKML)debateu se deveria usar uma nova tag Generated-by ou redirecionar a tag Co-developed-by existente. Os mantenedores finalmente optaram pelo Assisted-by para refletir melhor o papel da IA ​​como ferramenta, e não como coautor.

A decisão ocorre no momento em que os assistentes de codificação de IA se tornam repentinamente genuinamente úteis para o desenvolvimento do kernel. Como Greg Kroah-Hartman, mantenedor do kernel estável do Linux, me disse recentemente, “algo aconteceu há um mês e o mundo mudou” com ferramentas de IA agora produzindo relatórios de segurança reais e valiosos, em vez de bobagens alucinadas.

Além disso: Linux explora uma nova maneira de autenticar desenvolvedores e seu código – como funciona

A escolha closing de Assistido por em vez de Gerado por foi deliberada e influenciada por três fatores. Primeiro, é mais preciso. A maior parte do uso de IA no desenvolvimento do kernel é assistencial (completar código, sugestões de refatoração, geração de testes) em vez de geração completa de código. Em segundo lugar, o formato da tag reflete as tags de metadados existentes, como Revisado por, Testado por e Co-desenvolvido por. Por fim, Assisted-by descreve a função da ferramenta sem sugerir que o código seja suspeito ou de segunda classe.

Esta abordagem pragmática teve um impulso inicial quando, numa conversa LKML, Torvalds disse: “Eu *não* quero que nenhuma documentação de desenvolvimento do kernel seja alguma declaração de IA. Temos gente suficiente em ambos os lados do “céu está caindo” e “isso vai revolucionar a engenharia de software program”. Não quero que alguns documentos de desenvolvimento do kernel assumam qualquer posição. É por isso que quero fortemente que esta seja aquela declaração de ‘apenas uma ferramenta’.”

O verdadeiro desafio são patches de aparência confiável

Apesar da nova política de divulgação de IA do kernel Linux, os mantenedores não dependem de software program de detecção de IA para detectar patches não divulgados gerados por IA. Em vez disso, eles estão usando as mesmas ferramentas que sempre usaram: conhecimento técnico profundo, reconhecimento de padrões e revisão de código à moda antiga. Como Torvalds disse em 2023: “Você precisa ter um certo bom gosto para julgar o código de outras pessoas”.

Além disso: esta é minha distribuição Linux favorita de todos os tempos – e eu tentei todas elas

Por que? Como Torvalds apontou. “Não faz sentido falar sobre desperdício de IA. Porque o pessoal do desperdício de IA não vai documentar seus patches como tal.” O problema difícil não é um lixo óbvio; isso é fácil de rejeitar, independentemente da origem. O verdadeiro desafio são patches de aparência confiável que atendam às especificações imediatas, correspondam ao estilo native, compilem de forma limpa e ainda codifiquem um bug sutil ou uma taxa de manutenção de longo prazo.

A aplicação da nova política não depende da detecção de todas as violações. Depende de tornar as consequências de ser pego graves o suficiente para desencorajar a desonestidade. Pergunte a qualquer pessoa que já foi alvo da ira de Torvalds sobre manchas de lixo. Mesmo que ele seja muito mais temperamental do que costumava ser, você ainda não quer irritá-lo.



fonte