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:
-
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.
-
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".
-
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.
-
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.
-
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.
-
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.