Esse sentimento eu tive um pouco antes da IA, quando eu passei de Desenvolvedor Senior para Tech Lead.

No dia em que você para de escrever todo o código e passa a distribuir a responsabilidade entre outros devs, aquela memória enciclopédica da codebase evapora.

Você deixa de saber onde cada coisa mora, deixa de lembrar cada linha, e quando cai um bug você não sabe mais exatamente onde olhar. É luto mesmo, e é desconfortável.

O que você não pode perder é outra coisa, e essa lista é bem específica:

• as regras de negócio;
• as decisões que já foram tomadas e o porquê delas;
• as decisões que ainda estão em aberto;
• os trade-offs que foram aceitos conscientemente;
• os limites do sistema (o que ele não faz de propósito).

Isso é o ownership que importa. Detalhe de implementação é recuperável em cinco minutos lendo o código. Contexto de decisão, se ninguém registrou, morre.

E é exatamente aqui que a resposta pro seu problema com IA já existe: são as mesmas técnicas de gestão de projeto que a gente usa com time humano. Só que agora aplicadas a um "dev" que produz dez vezes mais rápido e tem amnésia a cada sessão.

Na prática, o que funciona:

1. ADR (Architecture Decision Record). Um arquivo curto por decisão relevante: contexto, opções consideradas, decisão, consequência. Isso substitui a sua memória e, de quebra, vira contexto que você joga direto pro agente. Quando você não lembra por que a tabela X tem aquela coluna estranha, a resposta não está no seu cérebro nem no código, está no ADR.

2. Especificação antes de código. Com dev júnior você não manda "faz o checkout". Você escreve o critério de aceite. Com IA é igual, e por um motivo mais duro: se você não sabe descrever o comportamento esperado, você também não vai saber revisar o que voltou. A spec é o que transforma review de "ler código" em "conferir contrato".

3. Lote pequeno e revisável. O volume de código irrevisável que você citou não é culpa da IA, é falta de limite de WIP. Se o PR não cabe na cabeça, ele não sobe. Vale igual pra humano e pra agente. Eu prefiro cinco PRs de 200 linhas que eu entendo a um de 2000 que eu aprovo no chute.

4. Convenção forte no lugar de vigilância. Framework opinativo, camadas definidas, lint, tipos, teste. Quanto mais o "certo" for estruturalmente óbvio, menos você precisa reler cada linha pra confiar nela. Review vira exceção, não rotina.

5. Documentação viva no repo. CLAUDE.md, README de módulo, glossário de domínio. Duas funções ao mesmo tempo: onboarding de gente nova e contexto do agente. Documentação parou de ser custo puro no momento em que virou input executável.

6. Observabilidade como memória externa. Você não vai lembrar onde olhar quando der problema. Log estruturado, trace e alerta bom te dizem onde olhar. Isso resolve a parte do seu desconforto que é operacional, não cognitiva.

Sobre o "usar IA pra revisar IA": concordo que sozinho não resolve, mas o diagnóstico merece um ajuste. Ela confunde decisão de produto com erro de implementação porque ela não tem acesso à decisão de produto. Ninguém escreveu em lugar nenhum. Quando o repositório carrega as regras e os ADRs, a taxa de falso positivo despenca bastante. O problema não é o revisor, é o briefing, exatamente como acontece com um dev novo no time.

Resumindo o que eu faria no seu lugar: pare de tentar recuperar a memória, ela não volta e não deveria voltar. Troque memória por sistema. Sua função deixou de ser lembrar do código e passou a ser garantir que o código continue obedecendo a um conjunto de decisões que estão escritas, versionadas e verificáveis.

Você não virou um programador pior. Você virou tech lead de um time que trabalha rápido demais pra caber na sua cabeça. O ferramental pra isso existe há décadas, só nunca tinha sido tão obrigatório.