Proposta de AGENTS.md do Linux Kernel Testa se Agentes de IA Podem Seguir Regras Humanas

A proposta de AGENTS.md do Linux kernel adiciona apenas um link simbólico, mas mira um conflito crescente em torno de código assistido por IA. Submetido em 24 de setembro de 2026, o patch facilitaria que agentes de programação encontrassem automaticamente as instruções existentes do kernel.

O arquivo proposto não autorizaria contribuições autônomas nem relaxaria os padrões de revisão do kernel. Ele direcionaria os agentes a um README que já orienta ferramentas de IA à política detalhada de contribuição do projeto. A mudança aborda um problema mais específico: agentes frequentemente agem antes de ler documentação escrita principalmente para pessoas.

Essa distinção importa porque o kernel já informa às ferramentas de IA que elas não devem certificar patches em nome de uma pessoa. Ele também exige revisão humana, atribuição adequada, testes e responsabilidade. A proposta de AGENTS.md do Linux kernel, portanto, contrapõe instruções fáceis de descobrir a uma realidade mais difícil: um arquivo de repositório pode orientar um agente, mas não pode tornar confiável um patch não confiável.

A Proposta de AGENTS.md do Linux Kernel Altera Um Ponto de Entrada

O patch muda como os agentes descobrem as regras existentes, não as próprias regras.

O mantenedor do kernel Sasha Levin submeteu um patch intitulado “docs: add AGENTS.md as a symlink to README.” A proposta cria um link simbólico de nível superior chamado AGENTS.md, que aponta para o arquivo README existente no repositório.

Um link simbólico é uma referência do sistema de arquivos que redireciona um nome de arquivo para outro arquivo. Nesse caso, um agente que abrisse AGENTS.md receberia o mesmo material já disponível por meio de README, em vez de uma segunda cópia das instruções.

Esse design evita a criação de dois documentos de política que os mantenedores precisariam sincronizar. A proposta de link simbólico de Levin afirma que o README existente já direciona ferramentas de IA a Documentation/process/coding-assistants.rst. O problema é que um agente precisa decidir abrir o README antes que essa indicação seja útil.

Muitos agentes de programação inspecionam automaticamente arquivos de instruções com nomes específicos. AGENTS.md tornou-se um dos nomes de arquivo comuns para orientações em nível de repositório, incluindo comandos de build, requisitos de teste, convenções de código e limites de segurança.

O arquivo proposto para o kernel não conteria texto separado. Seu único conteúdo seria o destino do link, README. Isso mantém os caminhos de entrada para humanos e máquinas vinculados a uma única fonte mantida.

Levin incluiu um exemplo controlado para explicar por que a descoberta importa. Dois agentes receberam a mesma solicitação: criar um commit que renomeasse a versão do kernel no Makefile para “AI Test.”

Sem AGENTS.md, um agente gerou uma linha Signed-off-by para o usuário. O outro não forneceu atribuição à IA. Ambos os resultados entravam em conflito com as expectativas documentadas do kernel.

Com o link simbólico presente, ambos os agentes teriam usado uma tag Assisted-by: LLM e evitado adicionar uma assinatura humana. Eles também seguiram mais de perto as convenções do projeto para mensagens de commit. Um adicionou um corpo descritivo, enquanto o outro usou a estrutura esperada de assunto “subsystem: summary phrase”.

Este foi um teste comportamental limitado, não uma avaliação ampla da confiabilidade dos agentes. Ele não mediu se os agentes conseguiam encontrar bugs sutis, produzir correções seguras ou entender restrições específicas de subsistemas. Mostrou que dois agentes se comportaram de modo diferente após receberem uma rota automaticamente descoberta para instruções existentes.

A mudança ainda estava sob revisão quando foi reportada. Descrevê-la como algo que o Linux já adotou, portanto, exageraria o acontecimento. A afirmação precisa é que um mantenedor do kernel propôs o link e forneceu evidências em seu apoio.

Kees Cook, um destacado desenvolvedor de segurança do kernel, respondeu com um reconhecimento. Ele apoiou o uso do README em vez da manutenção de uma política separada exclusivamente para agentes. Sua resposta de revisão também observou que seria desejável que os agentes lessem a documentação de contribuição antes de criar patches.

O patch é pequeno o suficiente para parecer cerimonial. Seu propósito prático, porém, é concreto. Ele tenta colocar informações obrigatórias de processo no caminho que uma ferramenta de IA já é treinada ou configurada para inspecionar.

Isso torna a proposta uma mudança de interface. Humanos podem navegar por árvores de documentação e interpretar normas da comunidade. Agentes de programação funcionam de forma mais previsível quando os repositórios expõem essas normas por meio de nomes de arquivo e caminhos reconhecidos pelas ferramentas.

A questão resultante não é se Markdown pode melhorar código gerado. É se um ponto de entrada confiável pode evitar erros recorrentes de processo antes que os mantenedores precisem detectá-los manualmente.

As Regras Existentes do Kernel Ainda Responsabilizam Humanos

A política de IA do Linux kernel trata um agente como assistente, nunca como proprietário legal ou técnico de uma contribuição.

As regras subjacentes já vão muito além do link simbólico proposto. O guia de contribuição com IA do kernel orienta ferramentas de IA e seus usuários pelo processo padrão de desenvolvimento, estilo de código, requisitos de submissão de patches, regras de licenciamento e política de conteúdo gerado.

Mais importante, o guia diz que agentes de IA não devem adicionar uma tag Signed-off-by. Essa linha não é um metadado decorativo de commit. Ela representa a certificação de uma pessoa sob o Developer Certificate of Origin, comumente chamado de DCO.

O DCO é o mecanismo pelo qual um colaborador declara que o trabalho submetido pode entrar legalmente no projeto sob sua licença. Um modelo de linguagem não pode fazer essa certificação por uma pessoa. Ele também não pode determinar se a pessoa concluiu a revisão necessária para assumir a responsabilidade.

O remetente humano deve revisar o código gerado, confirmar a conformidade com o licenciamento, adicionar a assinatura e assumir a responsabilidade pela contribuição. Um agente que insere a própria assinatura reduz essas etapas separadas a texto gerado.

É por isso que o teste de Levin importa, apesar de seu escopo reduzido. O agente não escolheu apenas um estilo de formatação impopular. Ele gerou uma declaração que somente um humano pode fazer legitimamente.

A documentação do kernel atribui à participação de IA um marcador diferente. Quando uma ferramenta de IA contribui, o patch deve usar uma tag Assisted-by. Ferramentas opcionais de análise, como Coccinelle, Sparse, Smatch ou Clang-Tidy, também podem aparecer após o rótulo LLM.

Esse modelo de atribuição distingue assistência de autoria e certificação. Ele oferece aos revisores um contexto útil sem fingir que o modelo pode assumir responsabilidade.

A documentação também estabelece um processo exigente para trabalho de bugs assistido por IA. Um agente deve ler toda a documentação relevante, localizar um bug específico e tentar reproduzir qualquer problema não trivial. Ele deve abandonar uma descoberta que não resista à verificação.

Se o problema parecer real, o agente deve escrever uma correção, compilá-la, testá-la com o reproducer ou uma análise completa e executar as verificações de patch do kernel. Ele deve informar tudo o que não conseguiu verificar.

O guia também orienta o agente a identificar os mantenedores e as listas de discussão relevantes. Ele deve avaliar se o problema pertence ao processo regular de bugs ou ao processo confidencial de segurança. O agente deve deixar a submissão efetiva para a pessoa que o utiliza.

Esses requisitos expõem os limites de tratar AGENTS.md como uma solução por si só. O arquivo pode direcionar um agente à lista de verificação correta. Ele não pode confirmar que um reproducer é significativo, que os testes são suficientes ou que o humano entende o código.

O desenvolvimento do kernel também abrange milhares de componentes com expectativas especializadas. Instruções gerais não podem conter todas as restrições arquiteturais, premissas de hardware ou preferências dos mantenedores.

Um agente pode cumprir perfeitamente as regras visíveis de formatação e ainda assim interpretar mal o gerenciamento de ciclo de vida, bloqueios, ordenação de memória ou comportamento de dispositivos. Uma mensagem de commit bem elaborada pode tornar esse patch mais fácil de revisar, mas não torna correto o raciocínio subjacente.

Isso cria um limite útil. Instruções de repositório podem reduzir erros administrativos evitáveis. A confiança técnica ainda precisa vir de evidências, testes, revisão especializada e colaboradores responsáveis.

Para mantenedores, essa separação é importante. Cada submissão malformada consome atenção antes que alguém alcance seu conteúdo técnico. Melhor descoberta de instruções pode reduzir essa sobrecarga sem baixar o padrão de aceitação.

Para colaboradores, a política é igualmente clara. Usar um agente não transfere a responsabilidade. Um desenvolvedor deve ser capaz de explicar e defender o resultado como se cada linha tivesse sido escrita manualmente.

Por Que Agentes de Programação com IA Continuam Ignorando o README

O conflito é entre documentação que existe e instruções que aparecem no contexto automático de um agente.

Tradicionalmente, repositórios organizam suas informações para colaboradores humanos. Um README apresenta o projeto, enquanto arquivos de contribuição, diretórios de documentação, páginas de listas de discussão e scripts contêm procedimentos mais especializados.

Uma pessoa que chega à árvore de fontes do Linux pode seguir essa hierarquia. Um agente que recebe um prompt restrito pode, em vez disso, inspecionar apenas os arquivos que considera imediatamente relevantes. Se ele nunca abrir o README raiz, o link do README para a política de IA permanece invisível.

Esse comportamento apareceu em uma recente discussão do kernel sobre uma correção de I2C da Qualcomm assistida por IA. Um mantenedor observou que o processo era documentado por uma cadeia que começava no README e seguia até coding-assistants.rst. Ainda assim, as ferramentas não seguiam essa cadeia de forma confiável.

A discussão dos mantenedores levantou a ausência de um arquivo AGENTS.md ou CLAUDE.md que ferramentas comuns inspecionam por padrão. Ela também alertou que adicionar tal arquivo não necessariamente resolveria tudo.

Essa é a pressão por trás da nova proposta. Mantenedores do kernel enfrentam patches assistidos por IA, independentemente de o repositório otimizar sua documentação para agentes. Recusar-se a adicionar um ponto de entrada não impede que colaboradores usem essas ferramentas.

A escolha prática é mais restrita. Os mantenedores podem deixar que os agentes descubram documentação voltada a humanos de modo inconsistente, ou colocar uma sinalização familiar na raiz do repositório.

A convenção mais ampla de AGENTS.md descreve o arquivo como um README para agentes. Sua documentação de formato aberto diz que mais de 60.000 projetos de código aberto usam a convenção, embora esse número reflita exemplos indexados, e não uma medição auditada do uso ativo de agentes.

O formato não impõe um esquema obrigatório. Um projeto pode listar comandos de configuração, regras de estilo de código, testes, preocupações de segurança ou links para documentação mais detalhada. Arquivos aninhados podem fornecer instruções mais específicas para subdiretórios.

Essa flexibilidade ajuda a explicar por que o formato se disseminou. Um repositório pode usar um único arquivo Markdown simples em várias ferramentas sem se comprometer com um sistema de configuração proprietário.

A proposta do kernel usa uma versão excepcionalmente conservadora desse padrão. Ela não criaria um grande manual para agentes nem repetiria informações já mantidas em outro lugar. Ela exporia o README existente sob um nome que os agentes provavelmente solicitarão.

Essa abordagem também preserva a paridade entre as orientações para humanos e máquinas. Kees Cook disse que o README foi intencionalmente projetado para funcionar com agentes. Criar um link para ele reforça esse caminho compartilhado, em vez de criar um conjunto privado de regras que os contribuidores humanos talvez nunca vejam.

Uma fonte compartilhada reduz a deriva de políticas. Se os mantenedores atualizarem o README ou sua referência ao guia de IA, os agentes recebem a mudança por meio do link simbólico. Um AGENTS.md copiado poderia ficar desatualizado silenciosamente.

Ainda assim, o uso de um link simbólico introduz uma consideração de compatibilidade. Sistemas semelhantes ao Unix lidam naturalmente com links simbólicos em repositórios, mas algumas configurações do Windows os obtêm como arquivos comuns. Nesse caso, um agente poderia ver a palavra README em vez do conteúdo referenciado.

Isso não invalida a proposta, especialmente para um projeto desenvolvido principalmente por meio de fluxos de trabalho Linux consolidados. Mas demonstra por que o patch deve ser avaliado como infraestrutura, e não como metadados mágicos.

O comportamento das ferramentas também varia. Alguns agentes carregam AGENTS.md automaticamente, enquanto outros preferem nomes de arquivo específicos da ferramenta ou exigem configuração explícita. Um nome de arquivo com aparência universal não garante assimilação universal.

Portanto, o patch melhora o caminho provável para muitos agentes sem eliminar as diferenças entre ferramentas. Seu benefício depende de o cliente seguir o link, respeitar as instruções e preservá-las durante toda a tarefa.

Essas condições são mais exigentes do que simplesmente ter boa documentação. São menos exigentes do que um controle técnico aplicável.

Instruções Melhores Não Tornam Patches Gerados Seguros

AGENTS.md pode melhorar a conformidade, mas não pode estabelecer correção, procedência ou revisão humana genuína.

O argumento mais forte a favor da proposta é operacional. Os agentes já estão produzindo patches relacionados ao kernel, portanto os mantenedores devem oferecer a eles um caminho previsível até as regras. Evitar assinaturas inadequadas e atribuições ausentes economiza tempo de revisão.

A crítica mais forte também é operacional. Um patch gerado pode seguir todas as instruções visíveis e ainda assim estar errado de maneiras difíceis de detectar.

Avaliações de seguimento de instruções frequentemente usam resultados simples e observáveis. O agente adicionou a tag correta? Executou um comando nomeado? Formatou corretamente o assunto? Essas verificações importam, mas a qualidade do kernel depende de propriedades mais profundas.

Uma correção pode passar na compilação e ainda introduzir uma condição de corrida. Um reprodutor pode exercitar uma configuração de hardware enquanto deixa outra de fora. Um agente pode citar a documentação correta enquanto interpreta mal o invariante que a documentação pressupõe que os contribuidores já conheçam.

Também há o risco de que uma apresentação mais limpa aumente a confiança indevida. Uma mensagem de commit bem estruturada, atribuição válida e verificações aprovadas podem fazer um patch assistido por IA parecer maduro. Os revisores ainda devem tratar esses sinais como conformidade de processo, não como prova de solidez técnica.

A política atual do kernel prevê esse problema. Ela exige que um humano revise o código e assuma a responsabilidade. Também pede que os contribuidores divulguem testes ausentes ou verificações malsucedidas, em vez de ocultar lacunas com uma prosa confiante.

Se as pessoas seguirão esses requisitos está fora do alcance de AGENTS.md. Um contribuidor pode remover uma tag de atribuição, ignorar um teste que falhou ou enviar código que não entende. O arquivo não tem um mecanismo independente para confirmar que a revisão humana ocorreu.

Outros projetos de código aberto responderam ao mesmo problema com estratégias diferentes. O repositório linux-firmware adotou documentação voltada a agentes no início de 2026, incluindo regras de contribuição e orientações de atribuição. Sua orientação sobre firmware ofereceu um precedente próximo para uma política legível por agentes.

O NetworkManager adotou uma abordagem mais adversarial após estabelecer sua política de IA. Suas instruções teriam dito a agentes não conformes que incluíssem uma palavra-canário incomum nas comunicações dos contribuidores. Os mantenedores poderiam então detectar envios que seguiram a instrução oculta enquanto contornavam a política do projeto.

Esse mecanismo de canário ilustra o uso oposto de um arquivo de instruções. Em vez de ajudar um agente a produzir um patch aceitável, o arquivo ajuda a identificar comportamento automatizado que deveria levar à rejeição.

Ambas as abordagens reconhecem o mesmo fato: agentes leem o contexto do repositório e alteram sua saída de acordo. Elas divergem sobre se esse comportamento deve ser orientado à conformidade ou usado como sinal de detecção.

A proposta do kernel escolhe a orientação. Ela pressupõe que contribuidores que usam agentes ainda podem participar se cumprirem as mesmas obrigações legais, técnicas e de revisão que todos os demais.

Isso não é um endosso ao desenvolvimento não supervisionado do kernel. É uma tentativa de tornar o limite existente visível no momento em que um agente começa a trabalhar.

A proposta também evita criar instruções que existem apenas para máquinas. Como AGENTS.md apontaria para o README, mantenedores e contribuidores podem inspecionar a mesma fonte recebida pelo agente.

A transparência ajuda, mas não resolve a injeção de prompt nem o conteúdo malicioso em repositórios. Agentes de programação consomem rotineiramente instruções de arquivos, textos de issues, comentários, logs e páginas externas. Direções conflitantes ou hostis podem competir com políticas confiáveis.

Um arquivo de nível superior pode estabelecer prioridade para ferramentas cooperativas. Ele não pode garantir que todas as ferramentas apliquem essa prioridade corretamente, especialmente quando o agente lê arquivos mais profundos contendo linguagem contraditória.

Há um risco relacionado de manutenção. Qualquer orientação de repositório pode ficar desatualizada à medida que os fluxos de trabalho mudam. O link simbólico proposto limita a duplicação, mas os documentos vinculados ainda precisam de revisão ativa.

A escala do kernel torna essa manutenção especialmente importante. Instruções amplamente corretas ainda podem ser incompletas para um subsistema específico. Agentes e contribuidores devem continuar consultando documentação local, mantenedores, sistemas de compilação e infraestrutura de testes.

Portanto, a visão ponderada não é nem “AGENTS.md corrige código de IA” nem “o arquivo não tem significado”. Ele pode reduzir uma classe específica de erros previsíveis enquanto deixa intacto o trabalho de verificação mais difícil.

Essa afirmação modesta é respaldada pelo exemplo de Levin. Qualquer conclusão mais ampla aguarda evidências de contribuições reais em subsistemas e ferramentas variados.

O Que Acontecer Depois Importará Mais do Que o Link Simbólico

A proposta deve ser julgada pelos resultados das revisões, pelo comportamento dos agentes e pela carga de trabalho dos mantenedores após sua adoção.

O primeiro sinal é o destino do patch. Um reconhecimento apoia o design, mas a mudança ainda precisa passar pelo processo de documentação do kernel e chegar ao repositório principal antes de se tornar infraestrutura padrão do projeto.

Os revisores podem aceitar o link simbólico sem alterações, solicitar um arquivo comum, pedir ajustes de compatibilidade ou decidir que o caminho pelo README é insuficiente. Cada resultado esclarecerá como o kernel deseja expor regras a ferramentas automatizadas.

O segundo sinal é se os principais agentes de programação seguem o link de forma consistente. A comparação de Levin entre dois agentes é útil, mas pequena. Testes mais amplos devem abranger ferramentas, prompts, diretórios de trabalho e tipos de contribuição diferentes.

Uma implementação bem-sucedida produziria menos assinaturas geradas, tags Assisted-by mais consistentes, melhores assuntos de commits e divulgação mais clara de trabalho não testado. Essas são melhorias observáveis de processo.

O fracasso teria outra aparência. Os agentes poderiam ignorar o link simbólico, ler apenas parte do material vinculado ou seguir regras genéricas deixando de atender requisitos específicos de subsistemas. Arquivos de instrução específicos por ferramenta poderiam continuar necessários.

O terceiro e mais importante sinal é a carga de trabalho dos mantenedores. Se o arquivo reduzir correções repetitivas sem aumentar os envios de baixa qualidade, terá cumprido uma finalidade prática.

Se uma saída de agente mais refinada encorajar mais contribuidores a enviar patches que não conseguem explicar, o link pode melhorar a apresentação enquanto agrava a carga de revisão. Esse resultado enfraqueceria a aposta subjacente da proposta.

Os mantenedores também devem observar se os contribuidores usam a atribuição com honestidade. A convenção Assisted-by só oferece valor quando as pessoas a preservam. A conformidade automatizada durante a geração não pode impedir que alguém edite o commit antes do envio.

Projetos além do Linux estudarão o resultado. O kernel é uma das bases de código colaborativas mais visíveis e exigentes, portanto seu tratamento das instruções para agentes tem peso simbólico, mesmo quando o patch é tecnicamente pequeno.

Essa influência não deve ser confundida com uma política universal. Repositórios menores, equipes comerciais e projetos com perfis de risco diferentes podem escolher arquivos de instrução mais completos, configurações específicas por ferramenta, barreiras automatizadas ou proibições de determinadas contribuições geradas.

A abordagem do kernel é notável porque não cria um processo de desenvolvimento paralelo. Ela direciona os agentes de volta ao processo que já rege as pessoas.

Para equipes de engenharia, a lição imediata é separar descoberta de autoridade. Contexto legível por agentes pode identificar os comandos e as restrições corretos. Testes, revisões, propriedade e sistemas de aprovação ainda devem fazer cumprir o trabalho.

As equipes que documentam esses limites também podem manter o contexto técnico pesquisável por meio de uma base de conhecimento de engenharia. O ponto essencial é expor uma fonte mantida, em vez de copiar regras entre vários arquivos de agentes.

Nos próximos meses, acompanhe o histórico do patch, os envios reais assistidos por IA e as respostas dos mantenedores. Esses sinais mostrarão se a orientação Linux kernel AGENTS.md elimina ruído evitável ou apenas padroniza como esse ruído chega.

Os mantenedores de repositórios devem fazer uma pergunta igualmente concreta: qual erro recorrente de agente decorre da falta de contexto e qual exige um controle aplicável? Coloque orientações estáveis onde as ferramentas as encontrarão e, em seguida, meça se o comportamento muda. Mantenha a revisão humana responsável por tudo o que um arquivo Markdown não consegue provar.