Quem responde pelo código que o agente de IA escreveu?

Resposta curta: você responde, e o git já diz isso. No repositório por trás deste site, os 251 commits sem merge feitos entre 18 de julho e 10 de agosto de 2026 trazem um único nome humano no campo de autor do git, enquanto 69,8% das linhas vivas naquele código hoje foram escritas dentro de uma sessão de agente de IA. O git registra quem rodou o commit, nunca quem produziu o texto, então a responsabilidade não se divide com a ferramenta. O que ainda dá para decidir é se existe algum registro do que o agente fez, porque esse registro não se reconstrói depois.

O que o git registra de fato sobre quem escreveu o código?

O git guarda duas identidades em cada commit, o autor e quem commitou, e as duas são pessoas. A documentação do git commit-tree lista os dois como campos separados, de um lado nome, e-mail e data do autor, do outro nome, e-mail e hora de quem commitou. Ela não diz por que a separação existe, então a explicação usual é nossa e não do manual: os dois campos divergem quando alguém aplica um patch escrito por outra pessoa, que é a coisa mais próxima que o git tem da situação em que você está com um agente de IA. Nenhum dos dois campos tem espaço para uma ferramenta.

O que o git oferece é o trailer, uma linha Chave: valor no fim da mensagem do commit, lida pelo git interpret-trailers. A convenção que mais gente já viu é a Co-authored-by, que o GitHub usa para mostrar um segundo rosto no commit, documentada como jeito de creditar mais de uma pessoa. Parte das ferramentas de agente acrescenta o próprio trailer: neste repositório, commits feitos dentro de uma sessão de agente carregam uma linha Claude-Session apontando para a sessão que os produziu.

O importante é que nada disso acontece sozinho. Um trailer existe só se algo o escreveu na hora do commit, e um commit feito sem ele é indistinguível, para sempre, de um commit digitado à mão. Confira o que o seu repositório registra antes de supor que ele registra alguma coisa: git log -1 --format='%(trailers)' imprime os trailers do seu último commit, e resposta vazia também é resposta.

Quanto do código que está rodando agora saiu de uma sessão de agente de IA?

Medimos isso no repositório deste site em 12 de agosto de 2026. É uma amostra extrema, e é isso que a torna útil: o site é escrito por agentes de IA trabalhando em worktrees paralelas do git, com um operador humano revisando e commitando. O método é rodar blame em cada linha viva no HEAD, resolver cada linha até o commit que a tocou por último e perguntar se aquele commit carrega o trailer de sessão.

De 90.456 linhas vivas em 641 arquivos rastreados, sem contar binários, 63.166 linhas, ou 69,8%, vêm de commits feitos dentro de uma sessão de agente. Restringindo a arquivos PHP e Blade, que é onde a aplicação de fato mora, a fatia é de 87,2% de 58.849 linhas. A diferença entre os dois números tem duas fontes de peso parecido, e nenhuma delas é código de aplicação: o composer.lock guarda 12.631 linhas escritas por um instalador de pacotes, só 10% delas vindas de sessão, e a documentação em Markdown do projeto guarda outras 13.547 linhas, 55% delas vindas de sessão.

O comando tem três passos e só lê. Excluir binários não é preciosismo: o git blame trata um favicon como 1.790 linhas de autoria sem pestanejar, e isso infla o resultado.

git log --format=%H --grep='^Claude-Session:' | sort > agent.txt

git ls-files -z ':!:*.png' ':!:*.ico' ':!:*.jpg' ':!:*.webp' ':!:*.woff2' ':!:*.pdf' \
  | xargs -0 -n1 git blame --line-porcelain -w HEAD -- 2>/dev/null \
  | grep -aE '^[0-9a-f]{40} [0-9]+ [0-9]+' | cut -c1-40 | sort | uniq -c \
  | awk '{print $2, $1}' | sort > lines.txt

join agent.txt lines.txt | awk '{s+=$2} END{print s}'

O segundo arquivo também te dá o total, com awk '{s+=$2} END{print s}' lines.txt. Troque o nome do trailer pelo que a sua ferramenta escreve e estenda a lista de exclusão para os formatos binários que o seu projeto realmente tem. Se o seu repositório não tem trailer nenhum, o primeiro arquivo sai vazio, e a leitura honesta é que a fatia é impossível de medir, não que ela é zero.

Por que "foi o agente que escreveu" não sobrevive a uma análise de incidente?

Porque as perguntas de um incidente não são sobre digitação. São quem aprovou isto, quem explica a decisão por trás disto e quem está consertando na próxima hora. Um agente de IA não responde a nenhuma das três, e essa é a nossa leitura de por que a frase desmonta tão rápido na prática, não uma afirmação jurídica.

Os números dão forma ao problema. Neste repositório, 214 dos 251 commits carregam o trailer de sessão, e esses 214 commits vieram de apenas 24 sessões distintas, com mediana de 7 commits por sessão e uma única sessão assinando 37 commits sozinha. Ou seja, o trailer diz a que conversa uma mudança pertence, não que decisão a produziu. Saber que 37 commits compartilham uma sessão é quase não saber nada sobre nenhum deles.

É também por isso que "foi o agente" e "fui eu" são a mesma resposta numa revisão, mudando só o tom. Quem abriu a sessão escolheu a tarefa, leu o resultado e apertou commit. Tudo o que a ferramenta contribuiu passou por esse portão, e o portão tem nome no campo de autor.

O que dá para recuperar meses depois, e o que se perde para sempre?

O que sobrevive é a corrente que vai da linha ao commit: o git blame te dá o commit, a mensagem do commit te dá o trailer, o trailer te dá um identificador de sessão. Essa corrente basta para responder "esta linha nasceu em sessão de agente" muito depois de todo mundo ter esquecido a semana em que aquilo aconteceu.

O que não sobrevive é tudo o que fez a mudança ser o que ela é. O pedido que a iniciou, as alternativas que o agente propôs e você recusou, o teste que você rodou antes de aceitar, o trecho que você leu por cima porque parecia óbvio: nada disso está no git, a menos que você tenha escrito lá. Identificador de sessão é ponteiro, e ponteiro vale o que vale o lugar para onde ele aponta, que pode não estar legível para quem investigar daqui a seis meses.

A consequência prática é incômoda e merece ser dita sem rodeio: a rastreabilidade que você vai querer durante um incidente precisa ser criada antes do incidente, por hábito, e ferramenta nenhuma instalada depois recupera uma semana que ninguém registrou.

Qual registro diz o quê?

Como deixar o trabalho do agente rastreável antes de precisar?

Comece descobrindo o que você já tem, porque muita gente registra mais do que imagina. Rode git log -20 --format='%h %s%n%(trailers)' e procure qualquer linha escrita por ferramenta. Se algo já carimba os seus commits, o trabalho é não perder isso, o que na prática significa não esmagar as mensagens em squash e não reescrever histórico por capricho de arrumação.

Se nada carimba, o hábito mais barato e útil é você mesmo escrever uma linha na mensagem do commit: qual ferramenta produziu a mudança e o que você verificou antes de aceitar. Essa frase única vale mais num incidente que qualquer marcador automático, porque registra a decisão humana e não o evento da máquina.

Depois, mantenha a unidade de mudança pequena o bastante para o registro significar algo. Uma sessão que assina 37 commits, como a nossa assinou, é uma sessão que ninguém vai auditar; o mesmo trabalho espalhado em commits pequenos com mensagens honestas é auditável por um estranho. A nossa medição não prova que menor é mais seguro, e não estamos afirmando que prova, mas um registro cuja menor unidade é uma sessão enorme é um registro que responde "quando" e se recusa a responder "o quê".

Avisar que foi um agente que escreveu muda quem responde?

Não. Avisar muda o que o revisor olha primeiro, e é o erro mais barato quando o projeto não tem política declarada, mas não desloca a responsabilidade para lugar nenhum. Quem manda a mudança continua dono dela. Isso é pergunta diferente de saber se um projeto vai aceitar código de agente, que tratamos à parte em por que projetos estão desabilitando pull requests para código gerado por IA, onde a porta é fechada de fora. Este artigo é sobre o código que já entrou, num repositório que é seu.

As duas situações puxam para o mesmo lado, aliás. O que torna uma mudança revisável por um mantenedor que não confia em você é o mesmo que a torna auditável por um colega que a herda, e tudo desce para tamanho, qualidade de mensagem e um teste que falha quando a mudança está errada.

O que esta medição não prova

Um repositório é um repositório. Este site é um caso extremo de propósito, então os 69,8% dizem como é um projeto pesado em agente, não como é o seu. Rode o comando no seu próprio histórico antes de supor que algo disto se transfere.

O trailer de sessão marca a sessão, não a linha. Um humano abriu aquela sessão, leu a saída e commitou, então linha contada como "de sessão de agente" não é linha que pessoa nenhuma viu. No sentido contrário, os 37 commits sem trailer não provam código digitado à mão: um commit feito fora de sessão, ou com o marcador faltando por qualquer motivo, fica idêntico a um digitado do zero. Esse 37 é aritmética, 251 menos 214, e não tem relação com os 37 commits da maior sessão citados acima; os dois números coincidem e significam coisas diferentes.

Mais dois limites que valem ser ditos. Rodamos git blame -w, que ignora mudança só de espaço em branco, e o blame sempre atribui a linha viva ao commit que a tocou por último, então uma refatoração posterior move a autoria mesmo sem ter movido nada relevante. E se você comparar estes 69,8% com a fatia que publicamos antes no artigo sobre pull requests desabilitados, repare que as duas respondem a perguntas diferentes: aquela mede a mudança como ela aconteceu ao longo do histórico, incluindo código que já foi apagado, e esta mede só o que continua de pé hoje.