O dev sênior que pede demissão toda noite

Todo dia você contrata um dev sênior brilhante. Ele aprende rápido, escreve bem, entende o que você pede. E toda noite ele pede demissão.

Construir com agentes de código é conviver com essa rotatividade. A sessão nova abre, e antes de qualquer linha você repete o ritual: explicar o produto de novo. Não o repositório — esse ele lê sozinho, em segundos. Você explica o resto. Por que o cadastro vem antes do download. Por que aquele atalho tecnicamente fácil ficou de fora. Por que esse público, e não aquele. Por que existe teste para um fluxo que já passa.

A sessão rende. O trabalho sai bem. Aí a sessão acaba, e o sênior vai embora sem deixar nada documentado.

Duas semanas depois, outro agente — tão competente quanto — sugere exatamente o atalho que você descartou. Com argumentos. Convicto.

Nos fóruns de dev, esse desgaste tem nome: "toda sessão eu explico tudo do zero". E costuma vir acompanhado de um segundo desabafo, mais amargo: a IA gera código sem parar, mas no fim não sobra um projeto. Sobra um amontoado de código.

O diagnóstico habitual para em "falta memória para a IA". Antes disso, vale uma pergunta: memória de quê?

Memória de quê, exatamente?

Histórico de conversa, contexto de código e memória de decisão de produto guardam coisas diferentes. O amontoado nasce quando a gente pede para um fazer o trabalho do outro.

O histórico guarda a conversa

O chat é cronológico: quem perguntou o quê, o que o agente respondeu, que ideias surgiram, para onde a conversa foi.

Para reconstruir uma troca recente, serve bem. Como fonte duradoura de verdade sobre o produto, serve mal. A decisão importante fica enterrada entre opções descartadas, log de depuração e um plano que mudou três mensagens depois. Duas conversas terminam em conclusões opostas. Uma thread longa explica a decisão direitinho — e nunca diz se ela ainda vale.

Despejar mais histórico na próxima sessão não cria entendimento. Cria uma agulha num palheiro maior.

Uma discussão recente no Hacker News sobre memória para agentes de código chegou à mesma distinção: a unidade útil é bem menor que a transcrição inteira — decisões, restrições, princípios que se repetem. A mesma conversa expôs o lado difícil: alguém precisa escolher o que merece persistir.

Escolher é julgamento de produto. Guardar é só armazenamento.

O código guarda o que existe

O repositório mostra a rota atual, o schema, os testes, as dependências, as convenções. Arquivos de instrução cobrem o que o código não expressa sozinho: o GitHub documenta instruções de repositório, de caminho e de agente para exatamente isso, e a OpenAI recomenda manter um AGENTS.md para o Codex carregar convenções de nome, regras de negócio e dependências pouco óbvias de uma sessão para outra.

Isso resolve um problema real. Nenhum agente deveria redescobrir como buildar o projeto ou qual pacote cuida da autenticação.

Só que código descreve o presente. O porquê, ele não carrega.

Um teste prova que o cadastro acontece antes do download. Não conta se a ordem existe para firmar a relação de conta, preservar a atribuição, permitir a troca de aparelho — ou só atender uma restrição temporária do lançamento. Comentário no código ajuda, mas comentário espalhado por arquivo de implementação não forma trilha de decisão.

A memória de produto guarda o porquê

"Cadastro antes do download" é uma frase. A decisão é maior que a frase.

Documento de requisitos chega perto, mas descreve só a entrega pretendida. Falta o que sustenta a entrega: por que essa opção venceu as outras, que evidência pesou, que observação futura reabriria o assunto.

Para uma decisão dessas, o registro durável ficaria assim:

1. Decisão: exigir cadastro concluído antes de mostrar o download do desktop.
2. Resultado pretendido: estabelecer a relação de conta antes da ativação.
3. Evidência e razão: a aquisição agora é medida no cadastro confirmado; o download virou etapa de ativação.
4. Restrições: quem visita pelo celular cria a conta, mas não instala o app desktop naquele aparelho.
5. Alternativas rejeitadas: download anônimo direto e barreira só de e-mail.
6. Revisitar quando: o cadastro qualificado cair sem melhora na ativação seguinte.
7. Trabalho conectado: landing, fluxo de conta na nuvem, eventos de analytics, conversão de Ads, handoff de release.

Registro assim não congela nada. Ele dá ao sênior de amanhã — humano ou agente — o raciocínio para preservar a decisão ou desafiá-la com responsabilidade.

Repare no item 6. Sem condição de revisita, memória vira dogma: uma decisão sensata no lançamento pode ficar nociva quando o produto, o público ou a evidência mudam.

Boa memória de produto tem duas propriedades que arquivo de chat raramente oferece:

• dá para inspecionar — uma pessoa consegue rastrear por que a decisão existe;
• dá para corrigir — evidência nova remodela ou substitui a decisão sem apagar a história.

Ninguém precisa de lembrança perfeita. Precisa de continuidade com trilha de auditoria.

O que merece sobreviver à sessão?

Nem toda troca vira contexto permanente. Guarde o que mudaria uma decisão ou implementação futura:

• o público e o resultado que o trabalho serve;
• uma decisão de produto e sua razão;
• uma restrição dura ou um risco;
• uma premissa ainda sem prova;
• uma alternativa rejeitada com cara de quem volta;
• a evidência que reabriria a decisão;
• o trabalho e o resultado observado conectados a ela.

Brainstorm, resposta intermediária e implementação abandonada ficam de fora. Memória comprida e indiferenciada atrapalha a busca — e transforma especulação velha em fato aparente.

Troque a pergunta. Em vez de "como faço o agente lembrar de tudo?", pergunte: "o que eu odiaria ter que redescobrir?"

Um registro de decisão para qualquer repositório

Você não precisa de um sistema dedicado de memória de produto para melhorar a próxima sessão. Comece com um registro curto, do lado do trabalho — sete campos:

• Decisão:
• Resultado que queremos:
• Evidência e razão:
• Restrições:
• Alternativas rejeitadas:
• Revisitar quando:
• Issue, tarefa, PR, release ou métrica relacionada:

Escreva na hora da decisão — não depois que a implementação virou bagunça. Aponte para ele a partir da tarefa que muda o código. Se evidência nova reverter a escolha, registre a decisão nova por cima, sem apagar a antiga: a história também é informação.

Instrução de repositório fica com o contexto estável de engenharia: comando de build, fronteira de arquitetura, regra de segurança, expectativa de teste, risco operacional conhecido. Decisão de produto fica numa trilha que preserva alternativas, evidência e mudança ao longo do tempo.

Separar as duas coisas evita as duas falhas clássicas:

1. o agente segue uma decisão velha cujas premissas já venceram;
2. o agente reabre uma decisão resolvida porque o código não consegue explicá-la.

Janela de contexto maior não cura nenhuma das duas.

Onde o Motriz entra

O Motriz não trata memória de produto como transcrição para reproduzir. A Jornada mantém evidências, premissas, decisões e razões inspecionáveis. O mesmo cofundador persistente acompanha o produto quando o trabalho entra no Build, levando junto o contexto de jornada, tarefa e repositório. O conhecimento do repositório dá aos agentes o contexto atual do código em segundo plano; a trilha de decisões preserva por que o trabalho existe.

A separação é de propósito. O agente inspeciona o repositório sem inventar a história do produto a partir do código — e rastreia qualquer tarefa aprovada até a decisão que a criou.

O sênior de amanhã vai continuar chegando sem memória. Agentes são assim. Mas ele pode encontrar um produto documentado, em vez de um produto que mora só na sua cabeça.

Um produto que não esquece por que virou o que é.

Se quiser ver como as decisões continuam conectadas ao trabalho num repositório real, veja como a jornada do Motriz funciona. Se a próxima decisão ainda está sem prova, comece por como validar uma ideia antes de abrir o editor.