Se a IA escreve o código, a sessão também deveria fazer parte do commit?

• git-memento é uma ferramenta de extensão que registra automaticamente sessões de código geradas por IA em commits do Git, armazenando o histórico de conversas de IA correspondente a cada commit como git notes
• Ao informar o ID da sessão de IA no momento do commit, o resumo é salvo em refs/notes/commits e a conversa completa em refs/notes/memento-full-audit, garantindo ao mesmo tempo rastreabilidade e privacidade
• Suporta diversos provedores de IA, como Codex e Claude, e permite aplicar skills personalizadas na geração de resumos para controlar a qualidade das notas de commit
• Integra-se ao GitHub Actions e oferece recursos como comentários automáticos de notas de commit, validação por gate no CI e migração automática de notas na mesclagem (merge-carry)
• Compatível com Windows/macOS/Linux. É uma ferramenta que aumenta a transparência da geração de código por IA e garante a possibilidade de auditoria do histórico de contribuições de IA em ambientes colaborativos

---

Visão geral do git-memento

• git-memento é uma extensão do Git para registrar sessões de codificação com IA por commit
  • No momento do commit, organiza o conteúdo da conversa da sessão de IA e o salva como notas em Markdown
  • Mantém a origem e o contexto da conversa da sessão de IA em cada commit, permitindo rastrear o processo de geração de código
• Suporta Codex por padrão, e também pode ser configurado para outros modelos de IA, como Claude
• É distribuído sob licença MIT e publicado como um executável único baseado em NativeAOT

Principais comandos e recursos

• Inicializa a configuração por repositório com git memento init e armazena as informações do provedor de IA em .git/config
• O comando git memento commit adiciona notas de sessão ao mesmo tempo que faz o commit
  • Ao usar a opção --summary-skill, o resumo e a sessão completa são salvos separadamente
  • O resumo é registrado em refs/notes/commits, e o log completo em refs/notes/memento-full-audit
• git memento amend permite adicionar ou modificar novas sessões em commits existentes
• git memento audit verifica a ausência de notas dentro de um intervalo de commits e a validade dos metadados
• git memento doctor inspeciona configurações, referências de notas e o estado de sincronização remota

Gerenciamento e sincronização de notas

• Use git memento share-notes para enviar notas ao repositório remoto (origin etc.)
• git memento notes-sync mescla notas remotas com segurança e cria backups
  • Sincroniza tanto refs/notes/commits quanto refs/notes/memento-full-audit
• git memento notes-carry transfere notas para novos commits após rebase ou squash
• git memento notes-rewrite-setup ativa a configuração de migração automática de notas

Integração com GitHub Actions

• O repositório inclui uma GitHub Action reutilizável
  • mode: comment — lê as notas do commit e gera comentários automaticamente
  • mode: gate — verifica a ausência de notas na etapa de CI e bloqueia o build em caso de falha
  • mode: merge-carry — transfere as notas para o commit de merge quando o PR é mesclado
• Cada modo é definido em action.yml e inclui o artefato para publicação no Marketplace (dist/note-comment-renderer.js)
• PRs com o rótulo ignore-notes ignoram a verificação do gate e recebem o comentário “Notes ignored”

Formato das notas e controle de versão

• As notas são salvas no formato git notes add -f -m ""
• Para suportar múltiplas sessões, são usados uma tag de versão(``) e separadores de bloco
• As mensagens do usuário são rotuladas com o nome de usuário do Git, e as respostas da IA com o nome do provedor
• Notas antigas de sessão única são atualizadas automaticamente quando necessário para manter a compatibilidade

[wedding]

Em projetos privados, eu exporto a sessão e faço o commit; nos públicos, só faço o commit de um arquivo de resumo quando julgo que ele é realmente necessário.
De qualquer forma, tem a questão dos dados pessoais... e, embora varie de ferramenta para ferramenta, é fácil passar de 10 MB por sessão... então não me parece muito adequado sair enviando tudo assim.

[roxie]

Mas estamos vivendo em uma era em que o disco está mais barato do que nunca!

[GN⁺]

Comentários do Hacker News

• Quando escrevo código com IA, começo com um arquivo project.md
  Nele descrevo o resultado que quero, e faço a IA escrever um plan.md com base nisso
  Depois reviso o plan.md várias vezes até chegar ao plano desejado, então gero uma lista de tarefas detalhada e a adiciono ao final do plan.md
  Quando estou totalmente satisfeito, instruo a IA a executar as tarefas e seguir até o fim sem perguntar mais nada
  Por fim, faço commit do project.md, do plan.md e de todo o código
  Assim, o plan.md vira uma espécie de artefato reproduzível, que depois pode ser usado por modelos mais avançados para modificar algo ou encontrar erros

  • Eu faço algo parecido, mas separo em três documentos — design, plan, debug
    O design é escrito por funcionalidade, com as perguntas em aberto explicitadas
    O plan é gerenciado na estrutura plan/[feature]/phase-N-[description].md, e paro quando bato em limites de build ou execução
    Na fase de debug, levanto hipóteses de causa possível, valido com logging/tracing e então corrijo
    Com esse método, tive quase 100% de sucesso tanto em projetos novos quanto legados
    A desvantagem é o acúmulo de arquivos markdown demais, mas como o histórico antigo ainda ajuda em mudanças futuras, ainda não automatizei isso
  • Isso parece uma abordagem baseada em spec
    Vale dar uma olhada no GitHub spec-kit
  • A função “brainstorming” do obra/superpowers é praticamente o mesmo fluxo de trabalho. Vale muito a pena usar
  • Eu costumava usar o Beads assim, e depois criei o GuardRails
    Ao iterar com o modelo para pesquisa de mercado e revisão de propostas, você acaba fazendo a engenharia de prompt em uma linguagem que o próprio modelo consegue entender
    Recentemente descobri que XML afeta o comportamento do Claude, então estou repensando a estrutura do GuardRails
    Link do post de apresentação
  • Eu também uso uma estrutura parecida, mas mantenho um arquivo separado de “context”
    Quando o plano está pronto, crio um “context.md” para consultar depois, caso precise reverter um plano ruim
    Ainda não precisei usar isso na prática, mas conceitualmente parece útil
    Só que ainda é meio incerto onde guardar esses arquivos, então ainda não os incluí no repositório
    Fico curioso para saber onde vocês armazenam esses arquivos md por tarefa

• Na minha opinião, isso é como perguntar “devemos fazer commit de todas as linhas?”
  No fim, o ponto central é para quem esse registro existe
  A maioria das sessões tem muito ruído, muitas tentativas erradas e informação desnecessária
  O que importa é o produto da sessão, não o processo em si
  Ainda assim, o spec inicial ou o primeiro prompt podem ter valor. É melhor resumir isso em uma mensagem de commit ou em um arquivo markdown

  • Para humanos isso é complexo e barulhento, mas esse tipo de informação de sessão pode ser útil para a IA do futuro
    Dá para usar sessões passadas como contexto de aprendizado e continuar o trabalho atual
    Isso pode ajudar especialmente a entender as limitações do modelo e identificar onde o código se desviou da intenção do usuário
    No fim, acho importante registrar toda entrada humana para o avanço dos modelos open source
  • Em vez de “fazer commit de todas as linhas”, talvez a analogia mais adequada seja “guardar todas as notas e tentativas fracassadas”
  • A pesquisa científica já passa por esse problema — a crise de reprodutibilidade
    O mesmo resultado deveria sair mesmo incluindo condições iniciais e ruído
    Caso contrário, a manutenção futura do código vira um jogo de adivinhar intenções
    Artigo relacionado
  • Em organizações onde transparência é importante, isso pode ter valor para auditoria, mas realisticamente, quem vai ler logs tão longos?
  • Não é preciso salvar todas as sessões, mas o momento em que os requisitos se tornam mais concretos durante os ajustes detalhados tem valor

• Propus uma ideia parecida uma semana atrás (link)
  Mas também houve muita oposição — projetos com IA não são gerados a partir de uma única entrada; são um processo conversacional, então é difícil transformá-los em artefatos como código-fonte
  Mesmo assim, há tantos projetos gerados aparecendo no Show HN que o ruído ficou sério
  Não dá para excluir totalmente, mas do jeito que está agora ficou menos interessante
  Estou pensando em como a comunidade deveria lidar com isso

  • Eu me baseio no método de escrita de código com Claude do Boris Tane
    Faço commit de research.md e plan.md e os uso como um dicionário vivo da arquitetura e das funcionalidades
    Coloco o nome da funcionalidade como prefixo no nome do arquivo, para o Claude conseguir recuperar rapidamente o design relacionado
    Blog de referência
  • O problema não é falta de contexto, e sim que o padrão de esforço caiu
    Projetos que antes eram interessantes agora ficaram fáceis demais de fazer
    Obrigar alguém a ler logs longos de sessão não resolve isso. Capacidade de síntese e de planejamento passaram a importar mais
  • Seria bom se o Codex pudesse exportar a sessão inteira em markdown
    O valor real do vibe coding está em ver o processo de tentativa e erro
  • Eu também estou pensando se devo postar dois projetos no Show HN
    Fica mais interessante quando há processo de criação e explicação, não apenas o resultado final
    Por isso, eu gostaria que existisse uma categoria como [Creations], separada de [Show HN]
    Ex.: um motor de xadrez simples seria [Creations], um motor de xadrez feito em 1k seria [Show HN]
    PerfBoard e Lerc são exemplos disso

• A sessão é apenas um artefato intermediário, não precisa fazer parte do resultado final
  Se o motivo das mudanças no código importa, o certo é organizar isso em mensagens de commit ou documentação

  • No fim, isso é um problema de resumo
    No momento do commit, você não sabe que perguntas um leitor futuro vai fazer
    Por isso, prefiro salvar a sessão e depois gerar resumos a partir de perguntas
    O Git AI usa essa abordagem
    Hoje em dia os engenheiros trabalham tão rápido que, depois de só uma semana, muitas vezes já não lembram por que fizeram algo daquele jeito
  • No mínimo, é preciso um resumo da sessão
    Prompts de pesquisa devem ser resumidos, e prompts de geração de código devem ser guardados como estão
    Isso garante reprodutibilidade e possibilidade de revisão
  • Antes eu fazia a LLM escrever só as mensagens de commit, mas agora acho melhor versionar arquivos de plano
    O plano passa a refletir até o processo de correção de erros e vira um documento útil para a próxima iteração
  • No meu caso, o próprio repositório é a memória do agente
    Cada repositório troca mensagens com os outros e gerencia solicitações de funcionalidades
    Guardo a conversa original e também a memória comprimida semanticamente, reorganizando especificações e requisitos
  • Salvar sessões também é útil para rastrear a origem de bugs ou fazer análises posteriores

• Logs de sessão são, na maior parte, ruído
  São uma sequência de tentativas erradas e reversões, então colocá-los ao lado do commit é como salvar o histórico do navegador
  O que importa é a mensagem de commit com intenção e restrições
  Se a IA escreveu o código, o ponto principal não é a conversa, e sim por que aquilo foi pedido daquele jeito
  No fim, talvez o problema não seja salvar sessões, mas sim o hábito de negligenciar mensagens de commit

• Mesmo usando IA, eu mantenho um processo tradicional de design
  requisitos → casos de uso → design de classes → definição de restrições → execução com IA
  Assim, mantenho o julgamento arquitetural humano enquanto a IA acelera a implementação repetitiva
  Em vez de logs de sessão, se você incluir esses documentos de UML/restrições no commit, fica mais claro registrar intenção e contexto
  Acho que o desenvolvedor de 2026 deveria preservar esse tipo de estrutura elegante de colaboração

• Isso é parecido com a questão de fazer ou não squash nos commits
  Quem prefere squash se importa só com o resultado e não registra o processo
  Quem pensa o contrário registra a jornada em si
  Sessões de IA seguem a mesma lógica: são úteis para depurar o processo de raciocínio, mas quem prefere um histórico limpo não vai querer vê-las
  Na prática, faz mais sentido gerenciar as sessões separadamente, fora do repositório

  • Eu também sou do time do squash, mas se houvesse um sistema em que fosse possível expandir o histórico interno, eu gostaria de ver as sessões junto
    Ouvi dizer que Mercurial e Fossil fazem isso melhor
  • Acho que essa analogia é a mais adequada
    No vibe-coding, mais do que o código em si, o prompt mostra os rastros do raciocínio
    Colocar isso no git ou não é outra discussão, mas deixá-lo acessível tem valor
  • Se o desenvolvimento é guiado por humanos, usar IA é apenas uma ferramenta
    Nesse caso, não há necessidade de ver o processo em tempo real
    Mas se o código foi escrito inteiramente pela IA, então é preciso divulgar os prompts

• Eu também já extraí sessões
  Há algum risco de perda de informação, mas a legibilidade e a acessibilidade melhoram muito

• Acho que pelo menos os prompts resumidos da sessão devem ser salvos
  Revisão de código feita por IA é menos rigorosa do que por humanos, e a intenção está só no prompt
  Caso contrário, os mesmos erros vão se repetir
  O valor do code review está no aprendizado e na melhoria, mas como a IA não aprende, o registro dos prompts precisa cumprir esse papel
  Isso também é necessário para avaliar habilidade em prompts ou treinar juniores

  • Mas não concordo que isso seja “óbvio”
    Nós não incluímos em commits coisas como teclas digitadas, cliques em menus ou tentativas de debug
    Salvar toda conversa gera ruído demais
    Em vez disso, o mais realista é deixar apenas documentos com intenção e hipóteses
  • Aliás, também tenho curiosidade sobre qual vocês imaginam ser o tamanho médio dessas sessões

• Isso é como perguntar “devemos incluir o histórico de buscas do Google no commit?” — obviamente acho que não

  • Analogia perfeita. Registrar todos os fragmentos do pensamento tem uma relação sinal/ruído ruim demais
    Melhor deixar só resumos de motivos, hipóteses e alternativas
  • Mas, se a sessão for preservada, também ficam registradas as consultas de busca e os resultados usados pela IA, o que pode ajudar como contexto do projeto
  • Ninguém quer saber quantas vezes alguém pesquisou “como centralizar uma div”
    Do mesmo jeito, logs de modelo se debatendo com problemas triviais são desnecessários
  • Além disso, nem toda busca está relacionada ao commit. Pode até incluir informações sensíveis

[roxie]

> “Será que o histórico de buscas no Google também deveria ser incluído no commit?” — acho que obviamente não

Gostei desse comentário