Torvalds usou Claude Code no kernel Linux e a revisão achou uma race: quem tem razão?

Em 13/10/2026, Linus Torvalds mandou para a lista do kernel Linux uma série de 10 patches escrita com o Claude Code, sob a direção dele, que resolve um gargalo de escalabilidade no page cache aberto desde 2024. Cerca de quatro horas depois, o desenvolvedor Kiryl Shutsemau respondeu com uma race condition no código. Um lado diz que a IA resolveu em semanas o que humanos não resolveram em dois anos e meio. O outro lembra que o patch ainda não está pronto. Os dois têm razão, e o que importa para quem programa com agente é o processo que pegou o bug.

O que Torvalds fez com o Claude Code no kernel Linux?

Ele reescreveu a leitura do page cache para não mexer no contador de referência da página no caminho mais comum de read(). O anúncio está no e-mail "Improve page refcount scalability", de 13/10/2026, e o código no branch rcu-free-v3 do repositório público dele.

• O problema: com muitas threads lendo o mesmo arquivo, toda leitura escreve no mesmo contador, e essa linha de cache pula de núcleo em núcleo. Matthew Wilcox relatou o caso em 2024, a partir de um cliente real.
• As tentativas anteriores: um rascunho do próprio Torvalds, que ele usou "quebrado" na máquina dele por um ano e meio; uma versão de Shutsemau há um ano, "que também tinha problemas"; e a série de Ilya Gladyshev, na versão 6, "com problemas fundamentais conhecidos" (palavras de Torvalds no e-mail).
• O papel do Claude Code: segundo a carta de apresentação da primeira versão, resumida pela Hardware Busters, o agente escreveu a implementação, os programas de teste, a revisão que gerou a lista de problemas em aberto e o primeiro rascunho da própria carta. Os benchmarks rodaram na máquina de Torvalds.
• O nome do branch: a primeira versão foi publicada como noref-filemap-read-with-llm. O uso de IA estava no nome.

Qual é o argumento a favor do patch?

Funciona, é pequeno e chegou depois de dois anos e meio de tentativas que não chegaram. Torvalds respondeu a uma objeção de Wilcox com esta frase: "I have a patch series. It's clean. It's ten patches, each of them cleanly separated, half of them *tiny*, and none of them more than 150 lines of code. It works."

Os números são dele, medidos no próprio hardware:

O próprio Torvalds pôs a ressalva no e-mail: é "a very artificial case", ler o mesmo pedaço de página em loop em todas as CPUs, e "any real life impact will be much much less". O que o número mostra é que o gargalo some, não que o seu servidor vai ficar 23 vezes mais rápido.

O que os revisores encontraram?

Uma race condition real, objeções de desenho e uma dúvida de fundo sobre se a mudança vale o risco. Tudo em menos de 24 horas, na lista pública.

• A race: Shutsemau mostrou que, se a página é trocada no cache e o tamanho do arquivo cresce no meio da leitura, o leitor pode copiar da página antiga "data that never got written there". A correção proposta tem duas linhas: conferir de novo, com xas_reload(), que a página ainda é a mesma depois de ler o tamanho do arquivo.
• O desenho: Wilcox disse não gostar da nova flag PG_rcu_free e propôs outro caminho. Harry Yoo pediu um limite para a memória que fica esperando liberação.
• O custo-benefício: Pedro Falcato escreveu que, até aparecer um caso real em que o desempenho mude de verdade, "not a microbenchmark", os patches "look to be more trouble than they're worth".
• Há regressão conhecida: na primeira versão, uma leitura de 16 bytes numa página de usuário ainda não mapeada subiu de cerca de 4.150 para 6.550 ciclos (Hardware Busters). Não está claro se continua na v3.

Torvalds aceitou o ajuste da race e passou a série para Shutsemau: vai sair de férias e cuidar da janela de merge. Nada disso foi incorporado ao kernel ainda.

Onde os dois lados concordam e onde não?

A última linha é a que mais importa. Nenhum revisor rejeitou o patch por ter sido escrito com IA. As objeções são as mesmas que um patch humano receberia, e o bug é do tipo que o rascunho manual do próprio Torvalds também tinha.

Como repetir o método de Torvalds no seu projeto?

Separe o trabalho do agente, peça a lista de problemas, meça você mesmo, rode um detector de race e deixe outra pessoa revisar antes do merge. Em comandos:

1. Branch que diz o que é.

git switch -c filemap-read-with-llm

2. Peça ao agente a lista do que pode estar errado, não só o código. Foi o que Torvalds fez. Um prompt de exemplo, para colar na sessão:

Liste os problemas em aberto desta mudança: condições de corrida possíveis,
ordem de leitura e escrita entre threads, casos em que o recurso é liberado
enquanto alguém ainda lê. Para cada um, diga se há teste que cobre.

3. Rode um detector de race. Revisão a olho, humana ou de agente, deixa passar race. Ferramenta pega parte delas em tempo de execução:

# Go
go test -race ./...

# C e C++ com ThreadSanitizer
clang -fsanitize=thread -g -O1 app.c -o app && ./app

# Kernel Linux (KCSAN), no .config
CONFIG_KCSAN=y

4. Meça na sua máquina e diga o que o número não prova. Torvalds publicou o benchmark junto com a frase "any real life impact will be much much less". Faça igual.

5. Declare o uso de IA no commit. O kernel tem regra escrita para isso em Documentation/process/coding-assistants.rst: o agente nunca adiciona Signed-off-by, só o humano, e a contribuição leva uma linha no formato Assisted-by: LLM [TOOL1] [TOOL2]. Na Verboo Code, o texto que o /commit acrescenta no fim da mensagem é configurável:

/commit-message set "Assisted-by: LLM"
/commit-message status

Para revisar um PR com o agente antes de chamar um humano, o comando /review roda gh pr diff e devolve a análise. Trate como primeira passada: no caso do kernel, a série passou pela revisão do agente e chegou à lista com a race.

Qual é a posição da Verboo Code?

O episódio é o melhor argumento até agora a favor de agente de programação em código sério, e não pelo motivo que a manchete sugere. O número que importa não é 23x. É que a race apareceu em cerca de quatro horas porque o código foi para revisão pública de quem entende do assunto. O código tinha passado pelo agente e por Torvalds e chegou à lista com ela.

A regra que a gente tira daqui: não faça merge de código que só você e o agente leram. O agente acelera a parte de escrever, testar e listar riscos; a revisão de um especialista continua sendo o que separa "funciona no meu benchmark" de "funciona".

A parte barata dessa conta é pedir mais uma rodada ao agente: a lista de problemas, o teste que falta, a segunda revisão do diff. Na Verboo Code o uso é com tokens ilimitados, então a terceira revisão custa o mesmo que a primeira e sobra mais tempo para a revisão humana que pegou o bug.